Secrets management requirements checklist: how to use it
If your secrets sit in application code, CI variables, configuration files and one or more vaults with no single owner, this checklist defines what a secrets management deployment must cover and how to verify each item. Each requirement is tied to a test or piece of evidence you can collect, so the list works as a proof of concept plan as well as a requirements document. The requirements are grouped into functional, security, integration, operational and compliance categories. Functional items cover secret types (static, dynamic, certificates and encryption keys). Security items cover unseal and key custody, HSM needs, encryption at rest and access policy. Integration items cover authentication for applications and CI jobs. Operational items cover high availability, disaster recovery, rotation and audit logging. Compliance items cover evidence for the frameworks that apply to you.
The list is platform-neutral, so you can score OpenBao and Infisical against the same items. Verification means evidence: a running proof of concept, a restore test, a rotation run, or a log export that a reviewer can inspect. A claim in a vendor brochure does not count until you have seen it work in your environment. Where a capability depends on a license, an edition or a feature that must be applied to the cluster, record that dependency next to the item. Compliance mappings in this checklist are for preparation only. They show where evidence for a control is likely to come from. Independent auditors and certification bodies decide whether a control conforms, and DeployOpen prepares the systems and evidence for those assessments without issuing any attestation.
Use the checklist in two places. In an RFP, copy the items into a requirements matrix, ask each bidder to answer yes, no or partial for each one, and require a demonstration or reference configuration for every item marked as critical to your risk. In an internal review, assign an owner to each item, including the platform team, the security team and the application owners who will change their code, and record the open gaps before any budget is committed. Ask bidders for a written scope that names which items they will deliver, which they will only document, and which remain your responsibility. Items left unassigned in the scope are the most common source of gaps after go-live.
Which secret types and functions must the platform cover
This table lists the secret types and functions a self-hosted secrets platform should handle, why each matters, and how to test it before you commit. Use the verification column as an acceptance test during evaluation, and confirm Infisical's coverage against its own documentation, since the OpenBao references describe OpenBao's documented features only.
| Requirement | Why it matters | How to verify |
|---|---|---|
| Static key/value secrets | API keys, service passwords and tokens used by existing applications are the most common secrets and need versioned, encrypted storage. | Write a secret, update it, read the previous version, then confirm the stored value is not readable from the storage backend in plain text. |
| Dynamic database credentials | Short-lived, per-request database users shrink the window a stolen credential is useful and remove shared service passwords. | Request a credential from a test PostgreSQL or MySQL role, log in with it, then confirm the database user is removed automatically when the lease ends. |
| Dynamic cloud credentials | Temporary cloud access keys issued per workload reduce long-lived access keys in pipelines and servers. | Issue a short-lived cloud credential to a test workload, confirm it expires on schedule, and confirm the cloud provider rejects it afterward. |
| Lease management and bulk revocation | Leases let operators see what was issued and cut access fast during an incident without rotating every secret by hand. | List active leases for one role, revoke a single lease, then revoke all leases under a path and confirm the affected clients lose access. |
| Certificates and PKI | Internal TLS certificates and client certificates need issuance, renewal and revocation under an audited certificate authority. | Issue a short-lived certificate from the internal CA, confirm the chain validates, revoke it, and confirm the revocation appears in the CRL or OCSP responder. |
| Encryption as a service | Applications that encrypt data can call the secrets platform so keys never leave the service boundary. | Encrypt and decrypt a sample record through the API, confirm the plaintext is not stored, and confirm the key is not returned to the caller. |
| Key lifecycle and rotation | Keys must be rotated, versioned and retired on a documented schedule, and old ciphertext must stay readable during the transition. | Rotate an encryption key, confirm new writes use the new version, confirm existing data still decrypts, then confirm the rotation event appears in the audit log. |
| Secret versioning and rollback | Versions let teams roll back a bad change and show auditors what a secret contained at a given time. | Create three versions of a test secret, roll back to version two, and confirm the read returns that value and the change is recorded. |
| Secret metadata and ownership | Metadata such as owner, system, data classification and rotation due date supports reviews and tells responders who to contact. | Attach custom metadata to a secret, query by that metadata, and confirm it is returned in the audit trail and the API. |
| Infisical coverage | Infisical covers secrets, certificates and access, but feature depth for dynamic credentials and key lifecycle may differ from OpenBao. | Check each row above against Infisical's own documentation and test it in a lab before scoring it equally with OpenBao. |
How applications, people and CI pipelines should authenticate
Authentication method choice is a core requirement, not a setup detail. Humans, servers, Kubernetes workloads and CI jobs each need a different way to prove who they are to OpenBao, and one method rarely fits all four. OpenBao documents auth methods including AppRole, JWT/OIDC, Kerberos, Kubernetes, LDAP, RADIUS, TLS certificates, tokens, and username and password, plus login MFA. The project recommends Userpass for developer machines and AppRole for servers. Treat that guidance as a starting point and map each population of callers to one method before anything is onboarded, so every login path has an owner and a reason.
The weakness to test for is the long-lived static token or static role secret that a team copies into a config file, a CI variable or a container image. Such a credential works indefinitely, survives staff changes and is rarely scoped tightly. During design review, confirm that every method issues short-lived tokens with bounded time-to-live and renewal limits, that each application or pipeline receives its own policy rather than a shared broad one, and that AppRole secret IDs are delivered and rotated through a controlled process rather than stored beside the code. Ask the vendor or your own platform team to demonstrate revocation of one workload without affecting others.
Human operators need stronger controls than machines. Require MFA on every interactive login, and integrate OpenBao with the workforce directory (for example, LDAP or OIDC against the identity provider that already governs employee access) so that leavers lose vault access when they lose directory access. Userpass for developer machines should be limited to scoped, short-lived use and should not become a parallel directory. Confirm with your identity team which group mappings drive policy assignment and who approves changes to them. Those decisions determine whether your audit trail can answer the question of which person or job read which secret.
Security requirements: encryption, custody and unseal design
These requirements decide whether a secrets manager protects the keys that protect everything else. Each card covers one design decision, what a sound answer looks like, and what to ask a vendor or implementation partner to demonstrate before go-live.
Encryption at rest before storage
OpenBao encrypts secrets before they are written to its storage backend, so the database or Raft volume should hold only ciphertext. Check that the encryption key is itself protected by the seal mechanism and never written to disk in plain form. Ask the partner to show a raw read of the storage backend returning unreadable data, and to state where the root key lives after startup. Confirm that every backup carries the same protection.
Encryption in transit
Every client, peer and replication link should use TLS, including traffic between HA nodes and between the cluster and the storage backend. Certificates should come from your own PKI with defined lifetimes and a renewal process, not from self-signed defaults left in place. Ask the partner to show the listener configuration, the minimum TLS version, and a test where a plaintext connection is refused.
Unseal and recovery key custody
No single operator should hold enough key material to unseal or recover the cluster alone. Define the number of key shares, the threshold needed to reconstruct the root key, and who holds each share, with shares stored in separate locations and under separate control. Document the recovery procedure, rehearse it, and record each unseal event. Ask how the design handles staff departures and loss of a custodian.
HSM or hardware-backed root of trust
Where a regulator, contract or internal policy requires keys to stay in certified hardware, decide that requirement before choosing a platform. HashiCorp documents HSM support and a PKCS#11 provider as Vault Enterprise features that need a license on the cluster. For OpenBao, confirm the exact HSM or auto-unseal options for the version you plan to run, and ask for test evidence on your hardware.
Least-privilege policies
Each application, pipeline and operator should receive only the paths and capabilities it needs, with separate policies for reading, writing and administering secrets. Avoid a shared root or admin token for daily work, and review policies whenever a service changes owners. Ask the partner to demonstrate a denied request from a workload that tries to read another team's path, and to show how policy changes are logged and approved.
Secret zero for first credentials
Every workload needs one first credential to log in, and that credential is the hardest to protect. Choose a method that avoids storing a long-lived secret in the image or repository, such as platform identity (Kubernetes service account tokens, cloud instance identity) or an AppRole with a secret ID delivered once and bound to a trusted host. OpenBao recommends AppRole for servers. Ask how secret IDs are issued, expire and get revoked.
How to set unseal and key custody before go-live
This sequence turns unseal material and key custody from an open question into a written, tested and evidenced design before any production secret is stored. It is the step most likely to determine whether a secrets platform can be recovered after an outage or a staff change.
Inventory the keys and seals the platform needs
List every key the deployment depends on: the root key that protects stored data, the unseal or recovery material, the TLS keys for the API and cluster traffic, the transit keys used for encryption as a service, and any PKI intermediate keys. For each one, record the owner, the system that uses it and the business impact if it is lost or exposed. The output is a key register that the security team and the platform owner both sign. Confirm with your own architecture team which of these keys will exist in your environment.
Choose the seal and unseal method
Decide whether the platform will be unsealed manually with Shamir key shares, automatically through a key management service, or through an HSM. OpenBao and Vault both document these options, but the availability of each depends on your infrastructure. Confirm whether your security policy allows a cloud key management service to hold the root key, whether an HSM is required for certain keys, and whether the platform must run without any external service. The output is a written seal decision with its rationale and the list of dependencies it creates.
Assign key holders and separation of duties
Name the individuals or groups who will hold each unseal share or recovery credential, and set a rule that no single person can unseal the platform alone and reconstitute the root key. Record the number of shares and the threshold needed to rebuild the key, and confirm that holders are in different reporting lines where your policy requires it. Store the shares in separate, controlled locations. The output is a custodian roster and a signed acknowledgement from each holder that describes their duties and the storage method.
Document the recovery and break-glass procedures
Write the runbook for the events you expect: a sealed node after a restart, a lost unseal share, a compromised administrator credential, the failure of the storage backend and a full cluster rebuild. Each procedure should name the trigger, the custodians who must act, the order of commands and the verification check that proves the platform is healthy again. Include who may invoke break-glass access and how that access is logged and reviewed afterward. The output is a versioned runbook stored outside the platform it describes.
Rehearse a restore in a non-production environment
Build a non-production cluster from the most recent backup, then perform a restore with the custodians following the runbook exactly as written. Time nothing for the record unless you have an agreed internal target, but note every step that required improvisation, missing access or unclear wording. Confirm that the restored platform returns the expected secrets and that the audit log continues from the point of backup. The output is a rehearsal report with findings and assigned fixes, and a repeat rehearsal after each material change to the runbook or the platform version.
Verify backup and storage integrity before go-live
Confirm that the backups of the storage backend and the key material are encrypted, stored in a separate failure domain from the primary cluster, and retrievable without the primary platform being healthy. Check that a backup taken from one node can be restored and that the key shares needed for recovery are not stored alongside the backups. The output is a checklist signed by the platform owner showing where each backup and each custodian item is kept, and who has access to each.
Record evidence for the assessor
Collect the key register, the seal decision, the custodian roster and acknowledgements, the approved runbook, the rehearsal report and the backup verification checklist into one controlled evidence folder with version dates and approvers. Map each item to the control in your framework that it supports, for example access control or cryptographic key management, and note which items an external auditor will expect to sample. DeployOpen can prepare this evidence, but the independent assessor decides whether it is sufficient. The output is an evidence index that the security lead approves before production secrets are loaded.
Integration requirements: pipelines, Kubernetes, databases and SIEM
A secrets manager is only as useful as the systems that can reach it safely. The six integrations below cover how pipelines, clusters, databases, operators, services and monitoring tools authenticate and receive secrets, and each card names what to test before go-live.
CI/CD pipeline login
Pipeline jobs should authenticate to the secrets manager with short-lived identity tokens instead of stored passwords. OpenBao documents a JWT/OIDC auth method, so the design question is which claims (project, branch, runner) map to which policy. Test that a job on an unapproved branch receives no secrets. The common gap is a single broad role shared by all projects, which turns one compromised pipeline into access to every secret.
Kubernetes auth and secret delivery
Workloads in a cluster need a way to prove their service account identity and receive only the secrets their namespace requires. Confirm which delivery pattern the platform team will use (direct API calls, an injector, or a CSI driver) and who owns the policy for each namespace. Test that a pod in one namespace cannot read another namespace's secrets. The common gap is treating native Kubernetes Secrets as the final store, which leaves base64-encoded values readable to anyone with broad cluster access.
Dynamic database credentials
Dynamic secrets let the manager create a database user when an application asks for one and revoke it when the lease ends. OpenBao lists SQL databases among the systems it supports for dynamic secrets, but the database owner must still grant the manager rights to create and drop roles. Ask for the lease duration per application and the revocation procedure after a breach. Test that an expired credential is rejected by the database itself. The common gap is a shared, long-lived database account kept only because the application cannot handle renewal.
Identity provider integration for operators
Human administrators should sign in through the organization's existing identity provider, with multi-factor authentication enforced there, and receive policies tied to group membership. Confirm whether the secrets manager's login MFA is used in addition to the upstream provider, and document break-glass access separately. Test that removing a user from the directory group revokes their access to the secrets manager. The common gap is local root or shared administrator tokens that bypass the directory entirely.
PKI and certificate issuance for services
Services need certificates issued and renewed automatically, which requires an internal certificate authority the secrets manager can drive. Confirm which CA hierarchy, certificate lifetimes and revocation process apply, and whether the PKI engine or a separate CA product will sign service certificates. Test that a renewed certificate reaches the service and that the old one is revoked. The common gap is a certificate that expires silently because renewal depends on a person remembering a calendar date.
Audit log export to the SIEM
Every secret read, login and policy change should produce an audit record that reaches the security monitoring platform in a form analysts can query. The HIPAA Security Rule and the FTC Safeguards Rule both expect activity in systems holding sensitive data to be logged and examined, so the export path matters as much as the logs themselves. Confirm the log format, the transport, and who reviews alerts. Test that a read of a sensitive secret appears in the SIEM within the time your alerting requires. The common gap is audit logs written to a local file that nobody collects. Related DeployOpen work on SIEM and CI/CD integration can inform this design.
How to find and migrate secrets already scattered in code and config
Most buyers start with secrets that already exist in places nobody inventoried: source repositories, CI/CD variables, container images, .env files, configuration templates and, more often than expected, spreadsheets shared with an operations team. Before choosing a target design, run a discovery phase that scans repositories (including history and branches), pipeline definitions and build logs, container image layers, and configuration stores. For each finding, record the secret type, the system it unlocks, the owner who can rotate it, and every consumer that reads it. Discovery usually finds duplicates of the same credential in several places, and those duplicates determine how many consumers must change at cutover.
Treat anything found in a repository or image as exposed. Rotate it at the source system before migrating it, and confirm that the old value is rejected, since copying a leaked value into a new vault changes nothing for an attacker who already has it. Classify each secret by sensitivity and by what it protects, then sort them into waves: low-risk static values first, then application credentials that can move to dynamic issuance, and finally keys and certificates that other systems depend on. Plan each wave with a rollback path that keeps the old source readable until consumers have proven they can fetch from the new store, and remove the old copies only after that proof. Confirm that the migration tooling and every step behave as documented in a test environment before running it against production. OpenBao's migration guide describes moving from Vault, but it was tested only against Vault 1.14.1 community edition, not Vault Enterprise. If your existing cluster runs a newer Vault release, such as the current 2.x line, or uses Enterprise features, you must confirm compatibility with your own version and configuration before relying on that guide. Ask the implementation partner which Vault version and edition they tested against, and require a written list of any migration steps they could not reproduce.
Operational requirements: HA, disaster recovery, rotation and audit logging
This table lists the operational requirements a self-hosted OpenBao deployment must meet and the evidence to ask for against each one. Read the verification column as the test you run, not the claim you accept, because most secrets platforms fail during failover or restore rather than during initial design. The main takeaway is that HA, backup and rotation decisions must be tested under realistic conditions before the platform holds production secrets.
| Requirement | What to design | How to verify |
|---|---|---|
| High availability | An active node holds a lock in the data store and standby nodes forward or redirect requests. Size the cluster and place nodes across failure domains you control. | Stop the active node during a maintenance window and confirm a standby takes over, that clients reconnect, and that no secret reads fail beyond the expected window. |
| Storage backend | Integrated storage (Raft) or PostgreSQL are the officially supported HA backends for OpenBao. The storage documentation describes PostgreSQL as easier to operate safely than Raft, so weigh your team's database skills against Raft operations. | Confirm which backend is supported for your version, document the operator runbook for it, and test a node rebuild on that backend. |
| Read scaling | Since OpenBao 2.5.0, Raft standbys can serve read-only operations. OpenBao 2.7.0 extended this to PostgreSQL, which allows horizontal read scaling. | Confirm your target version includes the feature, then measure read latency on standbys under your expected client load before relying on it. |
| Backup and restore | Define what is backed up (storage snapshots, unseal material custody records, configuration and policies) and where copies are held, separate from the cluster's own failure domain. | Restore into a clean environment on a fixed schedule and confirm that secrets decrypt, policies apply and audit logging resumes. A backup that has never been restored is not evidence. |
| Disaster recovery replication | Vault Enterprise offers performance and disaster recovery replication, but it requires a license applied to the cluster. OpenBao's documentation should be checked for the replication features your version supports before you assume a replica exists. | Ask the vendor or partner to state in writing which replication features apply to your edition, then run a failover drill against the documented procedure. |
| Automated rotation | Rotate static secrets on a defined cadence through the platform where a target system supports it. Dynamic secrets with leases reduce the need to rotate long-lived database credentials. | List every secret type, its rotation method and its owner. Confirm that a rotated credential works in the consuming application before the old one is revoked. |
| Upgrade and patch process | Plan minor and patch upgrades with a staging cluster that mirrors production. Track the release line you run, because security fixes arrive in each line separately. | Run the upgrade in staging, confirm the migration guide steps apply to your exact versions, and keep a tested rollback path with a verified backup taken before the change. |
| Monitoring and alerting | Monitor seal status, active node health, leader changes, lease counts, request errors and storage capacity. Route alerts to the team that can unseal or fail over the cluster. | Trigger a test alert for a standby loss and a sealed node, and confirm the on-call engineer receives it and knows the runbook step. |
| Audit log retention | Send audit devices to a log store outside the OpenBao cluster, with retention set by your regulatory and internal policy. Control who can read or delete the logs. | Confirm an audit entry for a secret read reaches the SIEM, check the retention period against your rules, and test that a deleted or tampered log is detected. |
Why licensing and edition choice belong in the requirements
License and edition are functional requirements for a secrets platform, because they decide which features you can run, who supports them and what you can change later. Start by writing down the license terms your organization can accept, then map each required feature to the edition that includes it. OpenBao is licensed under MPL-2.0 and is hosted under the OpenSSF, a Linux Foundation project, with the repository led by a community run under open-governance principles. HashiCorp Vault 1.15.0 and later is licensed under the Business Source License 1.1 with IBM named as licensor, which is not an OSI-approved open source license. Infisical is licensed under MIT, but content in its ee directories carries a separate enterprise license, so the features you need may sit on the other side of that line.
The feature map matters as much as the license name. HashiCorp lists HSM support, performance and disaster recovery replication, FIPS compliance, control groups, Sentinel policy as code and MFA among its Enterprise features that need a license applied to the cluster. If your requirements call for an HSM, replication across sites or FIPS-validated operation, write each one into the requirements and ask the vendor or project which edition provides it, and whether that edition is open source or commercial. For OpenBao, confirm which of these capabilities exist in the release you plan to run, and do not assume parity with Vault Enterprise. The OpenBao migration guide was tested only against Vault 1.14.1 community edition, so a move from Enterprise features needs its own check.
Ask for licensing terms in writing before scope is agreed. Request the license text that applies to each component you will deploy, a list of features gated behind commercial licenses, the terms for redistribution and hosting inside your own network, and the duration and renewal conditions of any subscription. Also ask what happens to your deployment if the vendor changes the license of a future version. Pricing is not published on this page, and any figure you see should come from a written quote tied to a written scope, not from this page.
What buyers ask before hiring help on secrets management
How much effort does a secrets management rollout take?
Effort depends on how many applications, pipelines and servers read secrets today, and on which secret types must move under control. A deployment that covers static credentials for a handful of services is a different job from one that also issues dynamic database credentials, manages certificates and encryption keys, and runs a high availability cluster. Each application needs an authentication method, a policy that limits what it can read, and a tested way to receive and renew its secret. Hardware security module (HSM) requirements add procurement, integration and key ceremony work. Ask the partner for a written scope that lists each application, pipeline, secret type and environment, so the effort estimate can be checked against that list.
How long does a secrets management project take?
The schedule is set by the number of integrations, the change windows your teams can accept, and how many environments must be built before production, such as test, staging and disaster recovery. Discovery of secrets already held in code, configuration files and CI variables often takes longer than the platform build itself. Approvals for network changes, identity source connections and HSM access can also add waiting time that no vendor controls. Ask for a milestone plan that names the dependencies outside the partner's control, and for the acceptance tests that close each milestone.
What must our team provide before a partner can start?
A partner needs a secrets inventory, a named owner for each application and secret, a list of identity sources such as directories or existing single sign-on, and the environments where the platform will run. It also needs access to the teams that deploy pipelines and clusters, and the change windows in which production systems can be touched. Without an owner for each secret, rotation and access decisions have no one to approve them. Confirm in writing which of these items the client supplies, the date each is due, and what happens to the schedule if one arrives late.
Can our own team run a secrets platform without outside help?
A capable platform team can build and operate a secrets manager, but the work covers more than installing software. It includes designing the seal and recovery arrangements, testing high availability and restore procedures, writing auth method policies for each workload, and migrating credentials without outages. Teams that have not done these tasks before usually benefit from an outside review of the design and the runbooks, even if they operate the platform themselves. Check whether your staff have time for ongoing rotation, upgrades and on-call duties, since those tasks continue after go-live. DeployOpen offers fixed-scope implementation, and ongoing support is available as a retainer.
Which costs are one-time and which recur over time?
One-time costs include design, integration of each application and pipeline, migration of existing secrets, and the initial testing of backups and recovery. Recurring costs include the infrastructure that runs the cluster and its storage, the staff time for rotation and access reviews, upgrades, monitoring, and support. If an HSM is required, the hardware and its maintenance are also recurring. OpenBao is licensed under MPL-2.0, so the software itself carries no license fee, while HashiCorp Vault Enterprise and Infisical's enterprise directories are licensed separately. Ask any quote to separate these categories and to state which items are priced per year, per node or per engagement.
Should we choose OpenBao or HashiCorp Vault?
The choice depends on licensing terms, the features you need, and the migration path you already have. OpenBao is licensed under MPL-2.0 and is hosted under the OpenSSF, while Vault version 1.15.0 and later is licensed under the Business Source License 1.1 with IBM named as licensor. Vault Enterprise adds features such as performance replication, HSM support and namespaces, which need a license on the cluster. Check that any feature you depend on is available in the edition you select, and confirm the license terms with the vendor before you commit. Your legal team should review the Business Source License terms if you plan to offer a hosted service.
How is migration risk from existing secrets controlled?
Migration risk is controlled by inventory first, then by moving one secret group at a time with a rollback path. Teams should find secrets in source code, configuration files, CI variables and container images, then assign each one an owner and a target policy. Applications should be switched to read from the new store while the old copy remains available, and the old copy should be revoked only after the switch is confirmed. If you run Vault today, note that OpenBao's migration guide was tested against Vault 1.14.1 community edition, not Vault Enterprise, so test your own edition in a non-production environment first. Ask the partner for a written migration plan with rollback steps for each wave.
What should a written scope for secrets management include?
A written scope should list the secret types in use, the applications and pipelines to integrate, the authentication methods for each, and the high availability and disaster recovery design. It should also state the unseal and key custody model, whether an HSM is in scope, how audit logs are sent to your monitoring system, and how rotation is handled. Deliverables, acceptance tests, responsibilities and the client-supplied inputs should be listed separately. Ask for exclusions in writing too, such as applications not covered or environments not tested. A quote should follow directly from that scope.
How DeployOpen scopes and delivers secrets management selection and implementation
This sequence takes a requirements checklist from a written scope to a self-hosted OpenBao or Infisical deployment, with security testing and compliance evidence handed over before any ongoing support begins.
Agree the requirements in writing
DeployOpen works with your security, platform and application owners to turn the checklist into a written scope covering secret types, auth methods for apps and CI, unseal and key custody, HSM needs, high availability, disaster recovery, rotation, audit logging and migration of existing secrets. Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts. The step is complete when the scope document is signed off by the client.
Select OpenBao or Infisical for your context
Using the agreed requirements, DeployOpen compares OpenBao and Infisical against your secret types, auth needs, storage and licensing constraints, and confirms each capability you depend on in the current release rather than assuming it. The output is a short written decision record that names the platform, the features that need a license, and the items your team must verify with the vendor. The step is complete when the decision record is accepted.
Design architecture and key custody
DeployOpen designs the reference architecture inside your own cloud accounts, data centers or isolated networks, including storage backend, HA topology, unseal and recovery key custody, HSM integration where required, and backup and disaster recovery paths. Each design choice is traced back to a requirement in the scope. The step is complete when the architecture and key custody plan are documented and reviewed by your security owner.
Build and integrate the platform
DeployOpen installs and configures the chosen platform in your environment, sets up the agreed auth methods for applications, servers and CI jobs, defines access policies, and migrates secrets found in code, configuration files and existing stores under a documented migration plan. Work is performed in your infrastructure and your change process. The step is complete when the integrations listed in the scope are working and migrated secrets are removed from their original locations.
Harden and test the result
DeployOpen runs security testing against the deployed system, covering the secrets platform, its APIs, the surrounding infrastructure and the workflows that consume secrets, and reports findings with remediation owners. Testing also exercises failover, backup restore and rotation paths so that high availability and recovery claims are checked rather than assumed. The step is complete when agreed findings are fixed or formally accepted by the client.
Prepare compliance evidence
DeployOpen assembles the configuration records, access policies, audit log samples, rotation records, key custody documentation and test results that your assessors will request, mapped to the control areas in your scope. DeployOpen prepares these materials but does not issue audit reports, attestations or certifications; independent auditors and certification bodies make those determinations. The step is complete when the evidence pack is delivered and walked through with your compliance lead.
Hand over and train operators
DeployOpen delivers operating documentation, runbooks for unseal, recovery, upgrades and rotation, and a knowledge transfer session for the teams that will run the platform. The handover checklist confirms each written deliverable in the scope has been received. The step is complete when your operators can perform the runbook procedures without DeployOpen present.
Continue with an optional retainer
If you want continued support, DeployOpen offers retainers for ongoing support, upgrades and continuous testing, scoped separately from the implementation. Ask for the retainer scope, response expectations and upgrade approach in writing before committing. The step is complete when the retainer terms are agreed, or when you decide to run the platform in-house from the handover package. No price list is published, so a quote follows from the written scope for each stage.
