How to run a PAM RFP for open source privileged access management
You are evaluating privileged access management for administrator, vendor and engineer access, and you need answers you can compare side by side. Write one RFP that applies the same questions to Teleport, JumpServer, Apache Guacamole and any commercial product on your list, so that every answer is tied to your own servers, databases, Kubernetes clusters and identity provider rather than to a vendor's general claims. Ask each bidder to answer in writing and to name the edition, the license and the version they are quoting. Start with the edition and license questions, because they rule options out early. Teleport's Community Edition license is limited to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, and the Community Edition single sign-on is limited to GitHub, so an enterprise with identity provider integration needs will usually be pointed at a paid edition from the first round. JumpServer's Community edition is capped at 5,000 assets in a standalone topology, and the features that matter to regulated buyers, such as ticket and just-in-time approval workflows, password rotation and multi-tenancy, appear in its Enterprise tiers. Ask each vendor to confirm which of your required features sit in which edition, and to show the license file that governs their build.
Next, put the operational questions to the bidders in the same form. Ask how session recordings are stored, how long they are retained, how they are searched and exported, and whether recordings can be sent to your SIEM. Ask for break-glass design: who can trigger it, how it is authenticated, how it is alerted and how it is reviewed afterward. Ask how a vendor's access is requested, approved, time-limited and recorded, and whether moderated sessions or dual authorization are included in the edition you are quoting. Ask for the upgrade path and the support model for each edition, including the response commitments written into the contract. Write each answer with your own scenario attached, for example a named administrator reaching a production PostgreSQL cluster through a bastion, and ask the bidder to show that flow in a demonstration on a test environment you control.
Finally, agree the scope, deliverables and timelines in writing before any work starts. For DeployOpen engagements, these are fixed in a written scope before work begins, and a quote follows from that scope, so the RFP answers should feed directly into the statement of work. Ask each implementation partner to state what it will configure, what it will document, what it will leave to your team and what it will test, and ask for the evidence each deliverable will produce for your auditors. Use the written answers to compare the options on the same terms, and confirm any figure you rely on (license limits, support terms, storage sizing) directly with the vendor or in your own environment before you sign.
Which questions to ask about editions, recording, break-glass and integrations
Which edition limits and license terms apply to our organization before we choose Teleport or JumpServer?
Check the license terms against your headcount, revenue and asset count before any build work starts, because they can decide the edition. The Teleport 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. JumpServer's free Community edition covers up to 5,000 assets in a standalone topology, and its Enterprise tiers add high availability and features such as Oracle and SQL Server access and ticket or just-in-time approval workflows. A good answer names the edition for each requirement, states the license threshold in writing, and says what changes on upgrade or when the organization crosses a limit.
Which identity providers does the Community edition support for single sign-on?
In the Teleport feature matrix, Community Edition single sign-on is limited to GitHub, while Enterprise supports Google Workspace, Microsoft Entra ID, Okta, SailPoint, OIDC and SAML. That gap matters if your workforce directory is Active Directory or another SAML or OIDC source. Ask the vendor or partner to show the exact identity provider connector in the edition you plan to run, to test it against your tenant, and to document how MFA is enforced at the gateway. A strong answer lists each connector, the edition it requires, and the fallback for break-glass logins when the identity provider is unavailable.
How do session recording, storage and search work, and how long are recordings kept?
Ask where recordings are written, how they are encrypted, how long they are retained, and how an examiner or security analyst finds a specific session. Teleport's feature matrix lists session recording with playback in both editions, while moderated sessions and dual authorization are Enterprise features. JumpServer lists a session recording transcoding worker among its private Enterprise components, so ask whether your recording format and playback path depend on it. Guacamole documents a session recording player extension. A good answer covers storage sizing per protocol, retention settings tied to your regulatory period, search by user, host and time, tamper protection, and the export path into your SIEM or evidence store.
Which protocols and resources must the platform cover, and where does each one sit by edition?
List every protocol you need, such as SSH, RDP, Kubernetes, PostgreSQL, MySQL, MongoDB, Oracle, SQL Server and web applications, then map each to an edition. Teleport protects SSH nodes, Kubernetes clusters, PostgreSQL, MongoDB, CockroachDB, MySQL, Windows hosts and internal web apps. JumpServer's Enterprise features include Oracle and SQL Server access, and its Enterprise components include Razor for RDP and Magnus for databases. Guacamole supports VNC, RDP and SSH from a browser, and its manual documents database authentication backends on MariaDB or MySQL, PostgreSQL and SQL Server, so confirm whether it fits Oracle needs. The answer should be a per-protocol matrix with the tested version and any gaps called out.
How does break-glass access work when the identity provider or the gateway fails?
A sound design defines who may use emergency access, how it is authorized, where its credentials are stored and how every use is alerted and reviewed. Ask whether break-glass accounts sit outside the normal identity provider, whether they require dual authorization, and whether that control is in the edition you plan to buy, since Teleport lists dual authorization only in Enterprise. Ask how the gateway itself is restored, whether high availability is in your chosen tier (JumpServer lists active-standby HA in Standard and Pro), and how credentials are sealed and rotated after each use. A good answer includes a tested runbook, an alert on every break-glass login and a review record for each event.
How does the vendor access workflow handle requests, approvals and time limits?
Ask how a vendor requests access, who approves it, how the approval is recorded, and how access expires without manual action. Teleport's Enterprise Identity Governance includes just-in-time access requests and reviews, along with access lists and access reviews, while Community Edition roles can only be requested through the CLI. JumpServer Enterprise lists ticket and just-in-time approval workflows and password rotation. A good answer shows the request and approval path end to end, whether the vendor sees any credential (a sound design injects it so the vendor never does), how a session can be watched live, and how offboarding removes access. Ask the partner to walk through this on a test host before you sign.
How does the platform integrate with our identity provider and SIEM?
Confirm the protocol, the directory source and the log format before design starts. Ask which identity connectors are native to your edition, whether group membership maps to roles, and whether MFA is enforced by the identity provider or the gateway. For logs, ask which events are emitted (logins, command or query activity, recording start and stop, approval decisions), in what format, and how they reach your SIEM. Open-source SIEM stacks such as Wazuh and Security Onion are common targets, so ask for a tested ingestion path and a sample event set. A good answer includes a connector test plan, the event schema and the owner of each mapping.
How are upgrades, patches and vendor support handled in each edition?
Ask for the upgrade path, the support channel and the response expectations in writing. JumpServer Community is supported through GitHub and its forum, while Enterprise adds email and ticket support with an SLA and an account manager. Teleport publishes frequent point releases, such as 18.11.3 on October 2, 2026 and 18.11.4 on October 14, 2026, so ask how your partner tests each one before production. A good answer defines the maintenance window, the test environment, the rollback plan, the owner of each patch and whether security patches fall under a retainer. DeployOpen's ongoing support, upgrades and continuous testing are available as retainers, and a written scope defines what they cover.
What does an implementation partner's quote need to include?
A quote should follow from a written scope that lists systems, protocols, identity connectors, recording retention, high availability and integrations. DeployOpen does not publish a price list, and its engagements are typically fixed-scope, so the quote is built from the agreed scope. Ask what is one-time (design, installation, integrations, hardening, testing and documentation) and what recurs (license fees for paid editions, infrastructure, storage growth, support and upgrades). Ask how each cost moves with the number of assets or users, and which items depend on the edition you choose. Request the deliverables, acceptance tests and timelines in the same document.
Why edition and license limits decide the shortlist early
Edition and license limits should be settled before any feature comparison, because they decide which controls you can actually buy. Open-source PAM products often split capabilities across editions. Teleport's feature matrix, for example, limits Community Edition single sign-on to GitHub, while Enterprise adds Okta, Microsoft Entra ID, Google Workspace, OIDC and SAML. Its Community Edition also keeps just-in-time requests to the CLI, and moderated sessions, dual authorization and Device Trust appear only in Enterprise. JumpServer's pricing comparison places Oracle and SQL Server access, password rotation, ticket and just-in-time approval workflows and multi-tenancy in its Enterprise tiers.
Counts and organization size can also disqualify an edition outright. The Teleport Community Edition license is limited to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, so a company above either threshold cannot use it for production regardless of technical fit. JumpServer's free Community edition covers up to 5,000 assets in a standalone topology, while its paid tiers are sized at 50, 500, 5,000 and unlimited assets, with high availability starting at the Standard tier. Calculate your own employee count, revenue, asset inventory and required HA topology before any vendor call.
Ask each vendor for a written edition matrix mapped to your counts, your identity provider and your approval model, and confirm each line item in the signed quote instead of assuming feature parity between editions. Check whether session recording search, approvals and high availability are included in the tier you are quoting, and whether any capability depends on a separate component. Where the license text is ambiguous for your organization, get legal review before deployment, since a license breach discovered during an audit is far more expensive to fix than a clarifying question asked now.
How vendor and implementation partner answers differ
The software vendor answers for the product itself: what the code does, which features sit in which edition, how the license applies to your organization, and how releases and security fixes reach you. Ask for these answers in writing and tie them to a specific version, because product behavior changes between releases. A vendor's answer about a feature is a statement about the software, not a promise that your environment will work the same way.
- Edition and license limits: Which capabilities (session recording, moderated sessions, just-in-time requests, SSO providers, high availability) sit in the free edition and which need a paid one, and whether the license terms allow your organization to use the free build at all.
- Roadmap commitments: Which features are shipped, which are planned, and whether the vendor will commit in writing to any date. Treat unwritten roadmap statements as non-binding.
- Upgrade policy: Supported version lines, end-of-life dates, how long security patches are provided for each line, and whether breaking configuration changes are documented in release notes.
- Support terms: Response channels, severity definitions, hours covered, and whether support includes an account manager or contractual response targets. Ask which of these apply to the edition you would buy.
Check that every vendor statement names an edition and a version number, and that the license answer covers your headcount and revenue, not only the product features.
The implementation partner answers for the work: what will be built in your environment, who performs each step, what gets handed over, and what evidence exists when the work is done. These answers belong in a fixed-scope statement of work that names systems, deliverables and acceptance criteria. The partner's answers should not restate what the vendor's product does, since that is the vendor's responsibility.
- Scope and exclusions: The exact list of protocols, target systems, user groups and sites in scope, and what is excluded, such as legacy hosts or third-party applications that will need a separate integration.
- Deliverables and integration work: Architecture documents, configuration of identity provider and SIEM connections, role and approval design, and any custom connectors, each with an owner and an acceptance test.
- Hardening and testing: The configuration baseline applied to the gateway and its hosts, how it is verified, and whether independent security testing is included or quoted separately.
- Evidence preparation: Which control records are produced for an assessment, such as access lists, approval records, session logs and configuration exports, and in what format they are delivered.
- Handover and support model: Documentation, administrator training, runbooks, and whether ongoing support, upgrades and testing are a separate retainer.
Compare the statement of work against each deliverable and confirm that every acceptance test can be run by your own staff.
Blurring the two sides leaves gaps that surface during audits or incidents. If the partner says a feature works and the vendor says it is a paid-edition feature, neither party carries the cost of the mismatch. Separate written answers make each party accountable for what it controls, and they let you check claims against the right source.
- Edition mismatch: A feature demonstrated in a trial may belong to a paid edition, so the partner's configuration can fail after purchase.
- Version drift: Partner work done on one release may need rework after an upgrade that the vendor documents, and the statement of work should say who pays for it.
- Evidence ownership: Auditors ask about the process and the records. The vendor supplies the product's logging capability, while the partner and your team prepare and retain the evidence.
- Responsibility for security defects: A product vulnerability is handled through the vendor's advisories and patch policy, while a misconfiguration is the implementation's responsibility.
Ask each party to sign off on the answers that concern it, and keep both sets of answers in your procurement file.
Answers that should stop or slow the evaluation
Vendor answers to PAM RFP questions reveal how much the platform and its partner can be trusted in production. The red flags below share one pattern: a claim that sounds complete but cannot be checked against a version, a document, a retention rule or a response term. Treat any of these as a reason to ask follow-up questions in writing before scoring the response.
No written edition matrix
A vendor that cannot state, in writing, which features sit in the free edition and which sit in the paid edition is asking you to find out after purchase. For Teleport, the Community Edition license limits distributed builds to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, so the edition question decides eligibility before features are discussed. Ask for a feature-by-edition table tied to a specific release, and confirm which features you need, such as moderated sessions, dual authorization or just-in-time requests, appear in that table.
Feature claims without versions or docs
Statements such as "we support session recording and approvals" carry no weight until they name a release and link to documentation. Capabilities differ between versions, and maintenance releases can change behavior. Ask for the exact version that will be deployed, the documentation page for each claimed feature, and a short demonstration in your own lab environment. Where the vendor cannot name a version, treat the claim as unverified.
Recording storage without retention controls
Session recordings are evidence, and evidence that is stored without a defined retention period, access restriction or integrity protection will fail an examiner's questions. Ask where recordings are written, who can play them back, how playback access is logged, how long recordings are kept by default, and whether deletion requires a second person. Also ask how recordings are protected from modification and how they are exported to an archive inside your environment.
Break-glass tied to normal SSO
If emergency access depends on the same identity provider that serves daily logins, an outage or compromise of that provider locks administrators out of the systems they must recover. Ask how break-glass accounts are created, where their credentials are held, how they authenticate without the primary SSO, and how each use triggers an alert and a recorded session. A credible answer describes a separate authentication path that is tested on a schedule.
Vendor access that bypasses recording
Vendor support sessions are often the highest-risk privileged sessions, so any answer that offers a direct tunnel, a shared jump account or a remote-assist tool outside the gateway defeats the audit trail. Ask whether every vendor session passes through the bastion, whether the vendor receives credentials or only a brokered session, and whether recording and approval can be enforced for vendor accounts. Confirm this with a test session in which the reviewer checks the recording.
Support promises without response terms
Phrases such as "enterprise-grade support" do not tell you when a critical fault will receive an answer. Ask for the written support tiers, the channels offered, the stated response times for each severity, whether the SLA is in the contract, and who performs upgrades and security patching. For community editions, confirm which support is available through public channels and which requires a paid agreement. Ask the partner the same questions for their own response obligations.
How to score PAM RFP responses
This table lists the main question areas for a privileged access management RFP, the relative weight each deserves, what a full-marks answer contains, and the evidence to request. Use the weights to set priorities before reading vendor responses, and treat a claim without evidence as unscored until it is demonstrated.
| Question area | Relative weight | What full marks require | Evidence to request |
|---|---|---|---|
| Edition and license limits | Very high | Written statement of which features, asset counts, user counts and recording capabilities sit in each edition, with the license terms for your organization size and use case | Current feature matrix, license text for the edition offered, and a written confirmation of thresholds that apply to your entity |
| Session recording and storage | Very high | Recording of every protocol in scope, tamper-evident storage, defined retention, search by user, host and time, and a documented export path for examiners | Live demo of search and playback, sample recording metadata, storage sizing guidance, and a test export of logs into your SIEM |
| Break-glass design | High | Documented emergency access path that bypasses normal approval, is isolated from routine accounts, triggers alerts and is reviewed afterward | Written procedure, a test run in a non-production environment, and sample alert and review records |
| Vendor access workflow | High | Time-limited vendor accounts, approval by named owners before each session, recorded sessions, and credential injection so vendors never see passwords | Demo of a vendor session from request to approval to recording, plus the offboarding steps and their logs |
| Identity provider and MFA integration | High | Support for your identity provider over OpenID Connect or SAML, MFA enforced at the gateway, and group-based role mapping that stays in sync with the directory | Configuration guide for your identity provider, test sign-in with MFA, and documentation of what happens when the identity provider is unavailable |
| SIEM and log integration | Medium to high | Structured event output for session start, command, approval and denial, with delivery options your SIEM supports and documented field mappings | Sample event feed, field dictionary, and a test ingest into a SIEM instance you operate or a reference lab |
| Upgrades, support and patching | Medium to high | Published release cadence, support windows per version, a documented upgrade path with rollback, and defined support channels for the edition you buy | Release and support policy, changelog for recent versions, and a written description of the support tier and response process |
| Deployment and high availability | Medium | Support for your hosting model (on premises, cloud or air-gapped), documented high-availability topology and recovery of recordings and configuration | Architecture diagram, failover test results from the vendor's own deployment, and backup and restore procedure |
What recording storage and break-glass answers must show
Ask every bidder where session recordings are written, who can read them, how long they are kept and how a reviewer finds one session out of thousands. A credible answer names the storage location (local disk, object storage or a database on your infrastructure), the encryption applied at rest, the retention setting and who can change it, and the export format. Ask for the search fields available (user, target system, time window, command or session identifier) and whether recordings can be exported with their metadata intact. Teleport's feature matrix lists session recording with playback in both editions, and JumpServer's Enterprise features include session recording transcoding. Confirm with each vendor whether recording playback, search and export differ between editions before you score the answer.
The reason buyers need this evidence is set by the rules, not by preference. The HIPAA Security Rule at 45 CFR 164.312 requires audit controls that record and examine activity in systems containing ePHI, and the FTC Safeguards Rule at 16 CFR 314.4 requires covered financial institutions to monitor and log the activity of authorized users. Ask the bidder to show a sample export and a sample review record that a examiner could sample. DeployOpen prepares the recording configuration, retention settings and evidence packs for your assessment, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work.
Break-glass accounts need the same rigor as ordinary privileged accounts, because they bypass normal approval. Ask how each emergency account is created, who holds its credential, where the credential is stored, and what triggers its use. A strong answer describes an alert on every use, a session recording, a post-use review by someone outside the team that used it, and an automatic lock or rotation after use. Ask whether break-glass use is blocked, approved or only logged, and whether this depends on an Enterprise feature such as moderated sessions or dual authorization. Ask for the review cadence in writing and confirm it with your own change and audit process.
How to run the evaluation from written questions to a signed scope
This sequence moves a PAM shortlist from written answers to a tested, scored and contractually bounded choice. Each step produces a record you can show procurement, security and the auditor who later samples the access layer.
Send the question set to each shortlisted vendor
Procurement or the security lead sends the same written questions on edition limits, recording storage and search, break-glass design, vendor access workflow, identity provider and SIEM integration, and upgrades and support to every candidate. Use identical wording so answers can be compared line by line. The step closes when each vendor has acknowledged receipt and a named contact for clarifications.
Collect written answers and mark gaps
Gather each response in writing and flag every answer that is vague, conditional or refers to a roadmap item rather than a shipped feature. Ask for the documentation section that supports each claim, and confirm which capabilities sit in the free edition and which sit in paid tiers. The step closes when you have one answer sheet per vendor with an open-items list for follow-up.
Run a proof of concept on one protocol and one target
Your engineers, with the candidate partner or vendor, deploy the platform in a test environment and connect one protocol, such as SSH to a single Linux server, to one target system you control. Test the full path: identity provider sign-in, MFA, approval if used, session recording and playback, and log export to your SIEM. The step closes when a recorded session can be found, played back and traced to a named identity in your logs.
Score responses against the requirements
Score each vendor on the same criteria, using weights agreed before the answers arrived, and record the reason for every score. Include the proof of concept results as evidence, not vendor claims. The step closes when the scoring sheet is signed off by security, operations and the compliance owner, with any disagreement written down.
Verify edition limits against your own counts
Compare your actual number of users, protected servers, databases, Kubernetes clusters and high-availability needs with each edition's published limits and licensing terms. Confirm in writing whether the vendor's free edition is permitted for your organization's size and use, since license terms can depend on headcount or revenue. The step closes when the vendor has confirmed the edition in writing against your counts and the license text has been reviewed by your legal team.
Confirm the partner's scope and deliverables
If you use an implementation partner, ask it to restate the chosen platform's installation, integration, hardening, backup, documentation and support tasks in its own words, with the systems and identity sources in scope. Confirm which items are excluded, such as licenses, storage or hardware. The step closes when the partner's written scope matches your requirements list with no unassigned items.
Agree scope, deliverables and acceptance in writing
Sign a scope document that lists in-scope protocols, targets, integrations, evidence to be produced, acceptance tests and the support model after go-live. Require that the acceptance tests reuse the proof of concept checks. The step closes when both parties have signed the scope and the acceptance criteria are linked from the project record.
What buyers ask before hiring outside help for PAM
What drives the cost of an open source PAM implementation partner engagement?
The scope written into the agreement drives most of the cost, not the software license. The main drivers are the number of protocols and systems to onboard (SSH, RDP, Kubernetes, databases, web apps), the number of identity sources to connect, how many approval and break-glass workflows must be built, and how much session recording storage and retention design is needed. Edition choice also matters: JumpServer's Community edition is free to self-host up to 5,000 assets in a standalone topology, while its Enterprise tiers are priced by quote, and Teleport's Community Edition license is limited to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue. Ask the partner to show which costs are one-time (design, build, onboarding, hardening) and which recur (support, upgrades, testing), and to tie each line to a system or workflow in the written scope.
Can our team run open source PAM in-house after go-live?
Many teams can run a bastion in-house, but the answer depends on staffing, skills and how many systems are onboarded. Operating a PAM layer involves gateway patching, certificate and key management, identity provider integration, role and access list maintenance, session recording storage and search, and periodic restore tests for backups. Teams that already run Linux, containers and identity services usually cover the basics faster than teams that do not. Ask the partner which runbooks, configuration documentation and knowledge transfer sessions are included in the fixed scope, and which tasks would remain with your staff. A written handover list makes the in-house decision concrete before the engagement starts.
What does the work require from our internal team?
The work needs named people from several groups, and their time should be stated in the scope. Typically this includes an identity owner who can supply directory groups and MFA policy, a network engineer for gateway placement and firewall rules, system owners who confirm which accounts and protocols are in use, and a compliance or audit contact who defines the evidence an assessor will request. Security approvers are needed for the approval workflows and break-glass design. Ask the partner for a responsibility matrix that lists each deliverable, the internal owner, and the decision points where your sign-off is required. Gaps found during discovery are a common source of schedule slippage, so agree on how they are handled before work begins.
How is a fixed scope agreed for a PAM project?
A fixed scope is agreed in writing before work starts. The written scope should name the systems and protocols in scope, the identity sources and MFA methods, the approval and session rules, the recording retention settings, the documentation and training deliverables, and the acceptance tests that show each item works. Anything outside that list is a change request with its own quote. Ask the partner to describe the discovery phase that produces the system inventory, what happens if inventory differs from expectations, and how change requests are priced and approved. DeployOpen works on fixed-scope engagements, and a quote follows from that written scope; it does not publish a price list.
Can a PAM partner work in air-gapped or on-premises environments?
DeployOpen plans, implements, hardens and supports self-hosted open source platforms inside the client's own infrastructure, which includes data centers and air-gapped networks. For a PAM project, that means the gateway, session recording storage, identity connections and backups stay in your environment. Constraints to confirm before the engagement include how software packages and container images reach the enclave, how patches arrive by media transfer, which identity sources are local, and where recordings are stored and searched. Edition features also matter: JumpServer's Community edition install script expects internet access to GitHub releases, so offline installation steps and the chosen edition should be confirmed in writing with the partner and the vendor.
What does ongoing support cover after a PAM rollout?
Ongoing support is usually offered as a retainer, and its scope should be defined separately from the initial build. Common items include security patching of the access layer, platform upgrades and their testing, backup and restore verification, monitoring of gateway health, changes to roles and approval rules, and periodic review of session logs and access lists. Vendor support tiers also matter: JumpServer's Community edition is supported through GitHub and its forum, while Enterprise adds email and ticket support with an SLA and an account manager. Ask the partner for the response model, the upgrade cadence, what is included in each retainer tier, and how emergency access changes are handled outside business hours. Retainer terms are agreed in writing, and DeployOpen does not guarantee outcomes.
How DeployOpen works on this
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source privileged access platforms inside your own infrastructure. We help you turn PAM RFP questions into a written scope that names the platform edition, protocols, identity sources and evidence you need before a vendor or partner is selected.
How we scope
- Agree in writing which protocols, servers, databases and Kubernetes clusters the bastion must cover
- Record the edition limits, asset counts and user counts that your chosen platform must support
- Define recording retention, storage location and search requirements before any build work starts
How we build
- Install and configure the chosen platform in your own cloud accounts, data center or air-gapped network
- Integrate single sign-on, MFA, directory groups and SIEM log forwarding according to the agreed design
- Test break-glass, approval and vendor access workflows against the written scope and record the results
How we hand over
- Deliver runbooks for approvals, emergency access, session review and access list maintenance
- Document the configuration, integrations and recording storage so your team can operate the platform
- Provide evidence packs that show access controls and session logs for your assessors or auditors
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Plan patching of the access layer and confirm each upgrade against the agreed configuration
- Confirm support terms, response expectations and escalation paths with your team in the written scope
