Open source PAM for financial services: why admin access is an examiner question
A bank, insurer or payment firm running core banking, a payment switch or a policy administration system usually has administrators who are employees, plus vendors and engineers who reach the same servers, databases and clusters through support tickets. When an examiner asks who changed a configuration, used a database role or touched a payment routing table, and at what time, the firm needs an answer built from recorded, attributable sessions. Shared administrator accounts, shared SSH keys and undocumented console access cannot produce that answer, so the access layer itself becomes part of the control evidence.
Two open-source platforms cover most of this ground. JumpServer fits firms that must broker many protocols from one workspace, including SSH, RDP, Kubernetes, databases and web consoles, with session recording and approval workflows. Teleport fits teams that want certificate-based, short-lived access to servers, Kubernetes and databases. Before choosing, confirm the edition limits that matter for a regulated firm: JumpServer lists Oracle and SQL Server access, password rotation, ticket and just-in-time approval workflows and SSO as Enterprise features, while Teleport's Community Edition license is limited to organizations under the employee and revenue thresholds it states, and its Community SSO is limited to GitHub. Settle these against your headcount, asset count and identity provider early, because they determine the architecture and the paid support you will need.
DeployOpen plans, implements, hardens and documents these controls inside your own infrastructure, and prepares the access lists, approval records and session logs that your internal audit and examiners will sample. DeployOpen does not issue audit reports, attestations or certifications. Your independent auditor and your supervisor decide whether the design meets your obligations, so ask any implementation partner to show how each control maps to evidence you can hand over.
Which financial regulations shape the privileged access build
This table maps the financial regulations and frameworks most likely to govern admin access to core systems onto concrete build decisions at the gateway, identity, session and contract layers. Read each row as a question to answer before design starts, and confirm applicability with your compliance and legal teams. The main takeaway is that most obligations converge on MFA at the gateway, unique identities and complete session logs, while vendor contract and exit terms sit outside the bastion.
| Regulation or framework | What it means for the build | Evidence to prepare |
|---|---|---|
| FTC Safeguards Rule (16 CFR 314.4) | Require multi-factor authentication for any individual accessing any information system unless the Qualified Individual approves an equivalent control in writing. Put MFA in front of the bastion for every admin and vendor login, not only for some hosts. | MFA configuration at the gateway, written exception approvals, and a list of enrolled identities |
| FTC Safeguards Rule activity logging (16 CFR 314.4) | Monitor and log the activity of authorized users. Enable session recording on all protocols the bastion carries and forward logs to the SIEM so access events are retained outside the gateway. | Session recordings with timestamps, user and target, plus log forwarding settings and retention configuration |
| PCI DSS v4.0.1 access and logging requirements | Where cardholder data is in scope, least privilege, MFA for all access into the cardholder data environment, and audit logs for administrative actions apply. Decide early whether the bastion itself falls inside the CDE, because that changes its hardening and review scope. | Role matrix, MFA evidence for CDE access, log samples, and a scoping statement for the bastion (confirm the requirement numbers with a QSA) |
| DORA ICT contract terms (Articles 28 and 30) | Vendor support access and any hosted or supported platform component are ICT services. Contracts must state where services are provided and data processed, give advance notice of changes, and cover data return on termination. Put these terms in the implementation and support agreement. | Contract clauses on location, notice, and data return; entry in the register of information |
| DORA exit strategy (Article 28(8)) | For ICT services supporting critical or important functions, document and test an exit plan. For a self-hosted bastion, this means exporting configuration, recordings, user lists and policies to a standby platform or to a documented manual fallback. | Written exit plan, a tested export or restore procedure, and records of the test |
| SEC ICFR guidance (Release 33-8810) for SOX firms | Access to programs and data is an example IT general control area. Build the admin access list, approval trail and periodic review into the bastion process so auditors can sample privileged access to financial systems. | Privileged user list, approval records, periodic access review sign-offs, and session logs for sampled dates |
| Swift Customer Security Controls Framework v2026 | For payment connectivity, Swift users must have controls independently assessed and attest annually. Privileged access to Swift-connected systems and operators is in scope, so restrict admin paths, enforce MFA and retain session records for that environment. | Mapping of relevant controls to bastion settings, assessor-ready access records, and the annual attestation inputs (confirm current control IDs in the Swift portal) |
Which systems and data a bank's bastion touches
Core banking ledgers and card processing databases are where an administrator can read or change account balances, customer records and card data in a single query. A bastion session into these hosts usually includes database shells, SQL clients and vendor support consoles, so the recording may show customer identifiers, account numbers and, on card systems, masked or tokenized values that still require careful handling. Ask the database team which schemas hold cardholder data and whether any query output can expose full primary account numbers.
- Query-level exposure: A terminal or SQL session records every statement and most result sets, so a single support session can capture large volumes of customer data.
- Break-glass use: Emergency access to production databases is the session most likely to need a documented reason, a second approver and a short time window.
- Vendor shells: Database vendors and their engineers often connect through the same path, so recordings must identify the individual, not a shared database account.
- Recording sensitivity: A recording of a database session is itself a record of personal and payment data, so it needs access controls, encryption and a retention period set by the bank.
- Scope questions: If the bastion reaches systems that store, process or transmit cardholder data, the bastion and its recording store fall into PCI DSS scope.
Confirm with the database owners which connection methods, client tools and accounts will be allowed through the bastion before you size the recording store.
Application servers for payments, loans, customer portals and batch processing are administered through SSH, RDP and file transfer. An administrator on these hosts can read configuration files, service credentials and application logs, and can restart or patch the services that move money. The session content is typically command output, desktop activity and copied files, which means secrets may appear on screen even when they are never typed into the bastion itself.
- Shell and desktop sessions: SSH and RDP recordings show every command, window and error message, including passwords that an operator types or displays by accident.
- Shared service accounts: Many legacy batch and middleware hosts still run under shared accounts, which the bastion can map to named users only where the design supports it.
- File transfer: Uploads and downloads through the session may move configuration, extracts or keys, so confirm whether file transfer is recorded and how it is limited.
- Windows scope: Windows hosts often need RDP through a proxy, so check the Community and Enterprise feature split before choosing a platform.
- Change windows: Patching and change work outside business hours is where a session review is most likely to be sampled by audit.
Confirm the host inventory, the account model on each host and whether any application needs to be reached without an interactive session at all.
Payment switch, message gateway and SWIFT connectivity hosts sit closest to the interbank network. An administrator on these systems can affect message flow, certificates, HSM interfaces and the operator consoles used to release or hold payments. Swift's Customer Security Controls Framework applies to the connectivity environment, so the bastion's access rules and recordings will be read against that framework as well as the bank's own standards.
- Operator function exposure: Sessions may reach consoles where message release, queue management or key operations take place, so an approval record should match each sensitive action.
- Connectivity components: Certificates, connector configuration and HSM-related commands are the material an examiner will ask about when reviewing who changed a connection.
- Dual control: Where the bank requires two people for a sensitive action, the bastion's approval and session records must show both identities.
- Isolation: These hosts are commonly in restricted network zones, so the bastion path itself must be documented and tested.
- Evidence trail: Recordings and approval tickets for these hosts are often sampled first in an examination, so keep them linked by session identifier.
Confirm with the payments and Swift operations teams which hosts count as in scope under the framework and which operator actions need a second approver.
Kubernetes clusters that run digital banking APIs, fraud scoring or payment microservices give an administrator access to secrets, service accounts and the running workloads. A kubectl session can read configuration maps, exec into pods and change deployments, so the recording shows the commands and the output that reveal how the platform is built. Teleport can protect Kubernetes clusters with short-lived certificates, but the cluster's own roles, namespaces and secret stores still decide what an administrator can reach.
- Secret visibility: Commands such as listing secrets or describing pods can display values or references to credentials, which the recording then stores.
- Exec sessions: Shell access into containers can capture data processed in memory, including customer records passing through a service.
- Cluster-wide roles: Cluster administrator rights reach every namespace, so limit them to a small group and record each elevation.
- Ephemeral workloads: Pods are short-lived, so the audit trail depends on the bastion log and cluster audit log rather than on the workload itself.
- Shared kubeconfig files: Static kubeconfig files with long-lived tokens bypass the bastion, so confirm that every access path goes through it.
Confirm the cluster audit logging, the namespace layout and whether the bank will allow exec into production pods through the bastion at all.
JumpServer or Teleport: which fits which financial estate
Banks, insurers and payment firms rarely run one uniform estate, so the choice between JumpServer and Teleport depends on which systems need access and which edition terms the firm can accept. The cards below separate the two products by edition, starting with the license and asset limits that decide eligibility before any feature comparison.
JumpServer Community for core estates
JumpServer Community is free to self-host for up to 5,000 assets in a standalone topology, and it covers SSH, RDP and database access through one workspace. This fits smaller payment firms, regional insurers or a segregated sub-estate of a larger bank. Check that asset counts include every database instance, network device and Windows host you plan to broker, and that a single standalone node meets your availability and recovery targets, since the Community tier has no active-standby HA.
JumpServer Enterprise for regulated scale
Enterprise adds Oracle and SQL Server access, password rotation, ticket and just-in-time approval workflows, custom roles, SSO, RADIUS and LDAP HA. Tiers step up through active-standby HA and a full HA cluster, which matters for core banking and card processing systems that cannot tolerate a single bastion. Confirm current tier limits and which features sit in each tier against the vendor's pricing comparison, because these terms change between releases.
Teleport Community is usually out of reach
Teleport's Community Edition license applies only to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, with an exception for designated critical security patch versions. Most banks, insurers and card processors exceed both thresholds, so the Community build cannot be the default for them. Ask legal to confirm the license terms against the firm's headcount and revenue before any pilot, and treat a Community deployment in a regulated entity as a licensing question rather than a technical one.
Teleport Enterprise for approvals
Enterprise adds moderated sessions, dual authorization, Device Trust and HSM support, along with Identity Governance covering access requests, access lists, access reviews and SCIM provisioning. Moderated sessions and dual authorization are the controls most examiners ask about for production changes to payment or ledger systems. Confirm which features are included in your specific Enterprise agreement, since the feature matrix lists them as Enterprise-only and the terms may vary by deployment type.
FIPS and FedRAMP limits on self-hosted
Teleport lists FIPS binaries and FedRAMP controls only in the self-hosted Enterprise edition, which is relevant where a firm's cryptography policy or a regulator's expectations call for validated modules. Teams that run Teleport as a managed service may not get the same binaries, so the deployment model affects compliance scope. Ask the vendor to confirm in writing which binaries are FIPS-validated for your version and whether your hosting model qualifies.
Confirm features against current editions
Edition boundaries for both products change between releases, so feature availability must be checked against the current edition terms at the time of purchase, not against this page. Ask each vendor for a written feature matrix for the exact version you will deploy, including session recording retention, search, and the Oracle, SQL Server and Windows connectors you need. Record the answers in the vendor evaluation file so the examiner trail shows what was agreed.
Rolling out PAM in a regulated firm, phase by phase
The sequence moves from a written inventory of privileged paths to a tested, evidenced bastion that examiners can sample, with each phase closing on a named output so the firm can show progress and decisions at every gate.
Scope in-scope systems and vendor accounts
The firm's security and infrastructure leads list every core system, database, server group and Kubernetes cluster that holds customer or financial data, plus every administrator, service account and vendor support path that reaches them. Compliance reviews the list against the in-scope systems named in the firm's PCI DSS, DORA or SOX scoping, where those apply. The phase is done when the inventory is signed off and each path has an owner, a protocol and a current access method recorded.
Select edition and topology
The team chooses between JumpServer, Teleport or another gateway against the protocols in scope, and decides the edition using the written feature list rather than assumptions. Items such as moderated sessions, dual authorization, just-in-time approvals, Oracle or SQL Server access, and FIPS binaries are checked against the edition matrix, and the firm asks its implementation partner and the vendor to confirm each one in writing. The output is a decision record covering edition, topology, high availability design and the recording storage location.
Integrate identity provider and MFA
Administrator identities are linked to the corporate identity provider, with dedicated privileged accounts kept separate from everyday user accounts. MFA is enforced at the gateway for every privileged login, and the team confirms which exceptions, if any, the Qualified Individual approves in writing under the FTC Safeguards Rule. The phase closes when test logins from each admin group succeed with MFA and failed attempts appear in the audit trail.
Pilot on non-production core systems
The gateway is deployed against a non-production copy of selected core banking, payments and database systems, and the team runs routine administrative tasks through it. Recording playback, search, retention settings and the log export to the SIEM are tested alongside connectivity. The pilot is complete when the team has documented defects, fixes or accepted them, and recordings from each protocol can be replayed by a reviewer who was not involved in the pilot.
Cut over privileged accounts with credential vaulting
Shared administrator passwords and static SSH keys are moved into the vault, rotated where the platform supports it, and removed from direct use on target systems in agreed change windows. Vendor accounts are reissued through the gateway with time-limited access. The output is a reconciled account register showing every privileged credential, its vault location, its owner and its rotation status, with direct-login paths closed and verified.
Test approvals and break-glass access
The firm tests the approval workflow for elevated access, the time-limited grant, and the break-glass path used when the identity provider or gateway is unavailable. Break-glass accounts are reviewed for who holds them, how their use is alerted and how they are reset after use. The phase produces test records showing an approved request, a denied request, a break-glass event and its after-action review, with each one traceable to a recorded session.
Hand over the evidence pack to compliance
Operations and the implementation partner assemble the evidence set: the in-scope system inventory, configuration baselines, the access lists and approval records, sampled session recordings, MFA settings, break-glass test results and the change records from cutover. Compliance checks each item against the control it supports and records the gaps. Independent auditors and examiners decide sufficiency, so the phase is complete when compliance accepts the pack and the firm knows which items it must refresh on a recurring basis.
Designing break-glass and approval workflows examiners will accept
Break-glass access has to be designed so that an examiner can follow every emergency session back to a documented reason, a named approver and a closed incident record. Start by defining the account or role that can be used in an emergency, who may activate it, the maximum session length and the trigger, such as a sev-1 incident number from the ticketing system. Store the credential outside normal operations, such as a sealed record with dual custody, and alert the security team every time it is used. Set a review step that closes within a fixed window after use, where the reviewer compares the recording with the incident ticket and records any gap. Confirm with each vendor which of these controls are free: in JumpServer, the pricing comparison lists ticket and just-in-time approval workflows as Enterprise features, and in Teleport, the feature matrix places moderated sessions and dual authorization only in Enterprise. Treat these as open questions until the written quote confirms them.
Approval paths for vendor sessions and production changes need separation of duties written into the workflow. The requester, the approver and the person who performs the session should be different identities, and the approver should not be able to grant themselves a role. Record which approver authorized each session, the target systems, the time window and the commands or queries run, because an examiner will sample these records against the access list. For production changes, decide whether a second approver must be present live (moderated or dual authorization) or whether a ticket approval before the session is enough, and document that choice in the access policy. The recording should capture the authenticated user, the source address, the target, the start and end times, the session identity that issued the certificate or credential, and the playback itself. Ask the partner to prove during testing that a recording can be found by user and date and that it cannot be edited by the administrators it covers. Confirm the storage location and retention period for these recordings with your own record-retention policy before the first session.
Questions financial firms ask before implementing PAM
What does an open source PAM implementation for a bank actually cost?
The software license is often the smallest line item, because JumpServer Community and Teleport Community have no per-user fee in the case of JumpServer, while Teleport Community is limited by its license terms. The larger costs are the infrastructure to host the gateway and session recordings, the integration work with your identity provider and SIEM, the rollout effort per system, and ongoing administration. Ask any partner for a fixed-scope quote that lists these components separately, and separate one-time work (design, integration, onboarding) from recurring work (patching, upgrades, support, storage growth). The JumpServer pricing page confirms that Enterprise tiers are priced by quote, so ask for edition limits in writing before you compare totals.
How long does a PAM rollout take for a financial institution?
Duration depends on scope more than on the product. The main drivers are the number of protocols (SSH, RDP, databases, Kubernetes), the count and complexity of target systems, how many privileged accounts must be migrated off shared credentials, the depth of approval and break-glass design, and how many change windows your operations team allows. A fixed-scope engagement should give a timeline per phase in writing: discovery, design, a pilot on a small set of systems, staged onboarding, and handover. Ask the partner which systems are assumed to be in scope and what would extend the schedule.
What must our team provide before a PAM project starts?
Expect to supply named owners from identity and access management, system owners for each core platform, a network team that can confirm routes and firewall rules, and someone who can approve change windows. You also need a decision on the authoritative identity source (for example, your directory or single sign-on provider) and the MFA method for privileged logins. Without these, rollout stalls at the first system that needs a firewall change or a database account decision. Ask the partner to list these dependencies in the statement of work so you can assign them before the kickoff.
Can our internal staff run a self-hosted PAM platform after go-live?
Yes, if you staff it deliberately. Running a bastion requires people who can operate the server or cluster, manage user and role changes, review session logs, rotate credentials, and respond to access incidents. Internal teams usually need training on the product's administrative model and a documented runbook for backup, restore and failover. Many firms keep administration in-house and buy specialist support for upgrades or incident response. Ask the partner which runbooks, handover sessions and knowledge transfer are included, and whether they are optional or part of the fixed scope.
Is JumpServer Community enough for regulated financial use?
Often it is enough for the core job of recording and controlling SSH and RDP sessions, but regulated firms should check each requirement against the edition, not the project name. The JumpServer pricing comparison lists Oracle and SQL Server access, password rotation, ticket and just-in-time approval workflows, custom roles, multi-tenancy, SSO, RADIUS and LDAP high availability as Enterprise features, and Community support runs through GitHub and the forum. If your approval, rotation, SSO or database requirements depend on those features, the Community edition will not meet them alone. Put each control from your examiner's expectations into a table, mark the edition that supplies it, and confirm the result with the vendor before you commit.
How do we keep a self-hosted PAM platform patched without breaking access?
Plan patching as a recurring process with a test environment that mirrors production gateways, a documented rollback, and a change record for each release. Track the release channel of your chosen product (for example, the JumpServer GitHub releases page or the Teleport changelog), confirm which versions are maintenance releases and which are feature releases, and schedule updates around change windows. Back up configuration, the database and session recordings before each upgrade. Your partner should state in writing who performs upgrades, how security patches are prioritized, and whether ongoing support is a retainer or a separate engagement.
Evidence examiners ask for and which component produces it
This table maps each piece of evidence a bank, insurer or payment firm is likely to be asked for to the JumpServer or Teleport component or operating process that produces it. Read it as a checklist of what to configure and export before an examination, since examiners and auditors form their own conclusions from what they sample. Most gaps come from process records, such as access reviews and break-glass justification, that the tool alone does not create.
| Evidence item | What it shows | Which component or process produces it |
|---|---|---|
| Privileged account inventory | Which admin, vendor and service identities can reach core systems, and on which assets | Asset and account inventory in JumpServer or Teleport roles, plus the identity provider group export; confirm the list matches the change record |
| Approval records | Who requested elevated access, who approved it, and the time window granted | JumpServer ticket and just-in-time approval workflows (Enterprise) or Teleport access requests and reviews (Enterprise Identity Governance); CLI-only role requests in Community Edition need a separate ticket trail |
| Session recordings and playback | What an administrator did during a session, with timestamps and user attribution | Session recording in both Teleport editions and JumpServer; confirm storage location, playback access and whether recordings are tamper-protected |
| Access reviews | That standing privileges were checked periodically and removed when no longer needed | Teleport access lists and access reviews (Enterprise); for JumpServer, a documented review process with exported permission reports, since recertification workflows must be confirmed with the vendor |
| Break-glass logs | When emergency access was used, by whom, and the reason recorded at the time | Audit logs for emergency accounts and locks, combined with a signed justification and after-action review; confirm how each platform flags emergency sessions |
| Vendor access records | Which third-party support staff connected, when, to what systems, and under which approval | Session logs tagged to vendor identities, approval tickets and time-limited access grants; the vendor agreement and DORA register entries complement these |
| MFA enforcement proof | That every privileged login required a second factor, with no bypass for specific accounts | Identity provider authentication logs and SSO configuration exported from Keycloak, Entra ID or Okta, plus the platform's SSO or MFA settings; confirm any exception is approved in writing |
| Retention settings | How long session recordings and audit logs are kept and how they are protected from deletion | Recording storage and log retention configuration, backup schedules and storage immutability settings; the retention period itself should follow the firm's regulatory and policy mapping |
Questions to ask a PAM implementation partner in banking
Start with experience on your core systems, not with the product. Ask the partner which core banking, payments, card switch and trading platforms they have hardened behind a bastion, how they handled the database and Oracle or SQL Server access paths, and who on their team would run the work. Then ask for an edition recommendation in writing. For JumpServer, the Community edition is free up to 5,000 assets in a standalone topology, while Enterprise features such as Oracle and SQL Server access, ticket and just-in-time approval workflows and active-standby high availability sit in paid tiers. For Teleport, the Community Edition license is limited to organizations under the stated employee and revenue thresholds, so a bank will almost always need Enterprise. Require the partner to list every feature their recommendation depends on, the edition that includes it, and the limit that applies, so the decision is traceable when an examiner asks why a control was chosen.
Next, test the recording and break-glass design. Ask where session recordings are written, how long they are retained, how they are encrypted and who can search or replay them, and whether the recording store sits inside the same jurisdiction as the data. Ask how break-glass accounts are created, sealed, monitored and tested, who approves their use, and how every use triggers an alert to the security operations team. Confirm how the partner integrates the identity provider for MFA and the SIEM for forwarding session logs. On contracts, ask the partner to state in writing where services are delivered and data is processed, how changes are notified in advance, and how data is returned and exit is handled. These items map to DORA Articles 28 and 30, so the partner's answers should match your register of information and exit plan. Finally, ask what the partner will not do. A credible partner prepares controls, configuration and evidence for your auditors, but does not issue audit reports, attestations or certifications, and says so in the statement of work.
How DeployOpen scopes and supports financial PAM
This sequence takes a financial firm from a written view of its privileged access scope to a running, documented and tested bastion, with the controls and evidence prepared for its own assessors. Each step ends with an output the firm can check.
Agree the scope of privileged systems
DeployOpen and the client's security, infrastructure and compliance leads list the core banking, payment, trading and data systems, the administrator and vendor populations that reach them, and the protocols in use, such as SSH, RDP, Kubernetes and databases. The output is a written inventory of in-scope assets and access paths, which becomes the basis for the fixed-scope proposal. Ask the firm to confirm which systems fall under regulatory scope, since that drives recording and retention requirements.
Select the platform and edition against requirements
Using the inventory, DeployOpen compares JumpServer and Teleport against the required protocols, approval workflows, break-glass design, identity integration and high availability. Edition limits matter here: some features, such as just-in-time approvals, moderated sessions and certain connectors, sit in paid tiers, and the firm must confirm each against the vendor's current documentation. The output is a written platform decision with an edition and license basis for the client's review.
Design the architecture and access model
DeployOpen documents the deployment inside the client's own cloud accounts, data centers or network zones, including gateway placement, high availability topology, identity provider integration, MFA at the gateway, and where session recordings are stored. The design also defines roles, approval paths, break-glass accounts and their monitoring. The output is an approved architecture document and access matrix signed off by the firm's security owner.
Implement, integrate and harden the platform
DeployOpen installs the platform in the client's environment, connects it to the identity provider and the SIEM, configures credential handling so administrators do not hold shared passwords, and applies hardening to the gateway host and its components. Integrations are tested with real administrator flows in a non-production environment before cutover. The output is a configured system with a test record showing that sessions are recorded, approvals are enforced and logs reach the monitoring platform.
Migrate access and run break-glass tests
Systems are onboarded in waves, and shared or direct access paths are removed as each wave goes live. DeployOpen runs documented break-glass drills to confirm that emergency access works when the identity provider or approval path is unavailable, and that each use is logged and reviewed. The output is a cutover record per system and a drill report that the firm's control owners can retain.
Prepare controls and evidence for assessors
DeployOpen maps configured controls to the frameworks the firm is assessed against, such as PCI DSS, the FTC Safeguards Rule or SOX IT general controls, and assembles the evidence an examiner would sample: access lists, approval records, session logs and review records. DeployOpen prepares this material but does not issue audit reports, attestations or certifications; independent auditors and certification bodies make those determinations. The output is an evidence pack and control mapping that the firm's compliance team and assessors can review.
Test the access layer and document operations
DeployOpen's security testing team tests the bastion, its integrations and the paths around it, including bypass attempts and misconfiguration checks, and reports findings with remediation steps. Runbooks cover onboarding, offboarding, upgrades, backups and incident handling. The output is a test report with closed or accepted findings and an operations handbook the client's own staff can follow.
Transfer operations or retain ongoing support
At handover, the firm either runs the platform with its own staff or contracts DeployOpen under a retainer for upgrades, support and periodic testing. Retainers and scope for upgrades are agreed in writing, and quotes follow from the written scope rather than a published price list. The output is a signed handover record or retainer agreement that names the responsibilities for patching, access reviews and session log review.
