Self-hosted secrets management for ISO 27001

Auditors expect a written cryptography and key management policy that states which algorithms, key lengths and key types the organization approves, who owns each key class, and how the rules apply to the secrets manager. A.8.24 asks for these rules to be defined and implemented, so the policy must match what the platform actually does. Expect questions about key custody, the unseal and recovery key process, and how exceptions are handled. Keep the policy version-controlled, approved by management, and linked to the system configuration it describes. The evidence table on this page lists the document set auditors usually request.

Auditors check that each identity that reads secrets is authenticated by a method the organization has approved, and that access is limited to the paths it needs. For A.5.17, they will want to see the enabled auth methods, the policies bound to each role, and the rule that people use individual accounts with multi-factor login where applicable. OpenBao documents auth methods such as AppRole, JWT/OIDC, Kubernetes, LDAP and TLS certificates, and recommends Userpass for developer machines and AppRole for servers. Export the configuration as code, record who approved each change, and keep a dated review of role bindings. Confirm the exact method names and options against the vendor documentation for the version you run.

Auditors want records showing that passwords, tokens and certificates are rotated on a defined schedule or on a defined trigger, and that the rotation is produced by the system rather than by hand. Dynamic secrets issued with leases and automatic revocation generate their own history, which is often the strongest evidence. For static secrets, keep the rotation schedule, the job or pipeline logs that performed each change, and the tickets for any rotation that failed or was delayed. Show how personnel were advised on handling authentication information, since A.5.17 asks for that guidance to be part of the management process. Ask your partner which secrets are rotated automatically and which still depend on a person.

Auditors look for a trail covering the full key lifecycle: creation, activation, use, rotation, suspension, revocation and destruction. For a self-hosted OpenBao cluster, this means audit device logs that record every request to the key and encryption endpoints, along with the change history of key versions and the approvals behind manual actions. Logs should reach a central store that the operators cannot silently edit, and the retention period should match the policy. Check that the logs cover administrator actions such as unseal, policy edits and mount changes, not only application reads. Confirm with your partner how audit devices are configured and where their output is stored.

Auditors expect evidence that backups are taken on a schedule, stored separately from the primary cluster, and restored successfully in a test. A backup that has never been restored is weak evidence, so keep the dated restore test record, the environment used, the people involved and the time to recover as observed. For OpenBao, the storage backend determines the backup method: integrated storage (Raft) and PostgreSQL each need their own procedure. Also document how unseal and recovery material is backed up and who can use it, because a restored cluster without its keys is unusable. Ask your partner to run the restore test in a non-production environment and to hand over the record.

Auditors expect exceptions to be rare, documented and time-limited, with a named risk owner who accepts them. Each exception record should state the rule being waived, the system affected, the business reason, the compensating control such as tighter monitoring or shorter credential lifetime, the approver and the review date. Auditors will sample exceptions and check that the review happened and that the exception was closed or renewed with a fresh decision. Tie exceptions to the change process so that a policy edit in the secrets manager cannot bypass the approval. Confirm with the organization's own risk framework how exception approval is structured before the first audit.

Your own team can produce most of this evidence if it owns the policies, the configuration and the logs, and if the procedures are written down and followed. A partner adds value where the work is fixed-scope: documenting the configuration, setting up audit logging, building the restore test and preparing the evidence set before the certification body arrives. DeployOpen plans, implements, documents and supports self-hosted platforms in the client's own infrastructure, and prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications. The cost depends on the number of systems in scope, the state of existing documentation and whether an existing Vault deployment must migrate. Ask for a written scope that lists each evidence item and who maintains it after handover.

The cost follows the scope agreed in writing: how many applications, pipelines and databases will read secrets, how many certificate and encryption key types are in scope, how highly available the design must be, and how much policy work is needed. Each integration takes effort because every application needs its own authentication method and policy. One-time costs include design, deployment, hardening, migration of secrets already sitting in code and configuration, and the first control evidence set. Recurring costs include running the cluster, storage, backups, upgrades and periodic evidence collection. When requesting a quote, ask for the work broken down by these components, the assumed number of integrations, the HA topology, and which policy documents are included.

A small team can operate a self-hosted secrets manager if it has engineers who can run a Linux and container estate, manage backups and upgrades, and keep the audit trail reviewed. The harder part is the management process that ISO/IEC 27001:2022 Annex A control 5.17 expects for authentication information, and the key management rules under control 8.24, which must be written, approved and followed. Teams often underestimate the time for documenting ownership, rotation rules and exception handling. Ask any partner to state which parts they would deliver, which your staff would keep, and what knowledge transfer is included.

Three groups of people are usually needed. Asset owners confirm which systems hold secrets, which accounts they use and who depends on them. A named key custodian is accountable for unseal material, recovery keys and key rotation decisions, and this role should not be a shared mailbox. Application owners schedule change windows for switching applications from hard-coded or file-based credentials to the new store, and for restarts that pick up new values. Plan for review sessions during design and cutover, and for a standing change process after go-live. Ask the quote to list these roles, the number of hours expected from each, and the windows the plan assumes.

Duration depends on the scope agreed in writing, so no general figure applies. The main factors are the number of applications to onboard, whether high availability and backups must be tested before go-live, the state of existing secrets, and how quickly the internal approval chain can sign off policies. A narrow scope covering one platform and a few integrations can be planned very differently from a multi-environment estate. Ask for a schedule with milestones for design approval, build, integration waves, cutover, and evidence collection, and ask which dates depend on your decisions or staff availability.

The certification body issues the certificate. ISO does not certify organizations, and accredited ISMS certification bodies operate to ISO/IEC 17021-1:2015 with ISO/IEC 27006-1:2024. DeployOpen prepares systems, controls and evidence for the assessment, such as configuration records, access policies, rotation logs and audit log exports, but it does not issue audit reports, attestations or certifications. Confirm with your certification body which evidence formats it accepts and how often it samples. Also confirm the surveillance and recertification pattern, since a three-year cycle requires at least one audit in every calendar year.

The 2022 edition replaced the 2013 controls with a new Annex A of 93 controls in four themes. Two areas touch secrets directly. Control 5.17 Authentication information merges three 2013 controls on user secret authentication information, its use and password management systems. Control 8.24 Use of cryptography merges two 2013 controls on a cryptographic policy and key management. IAF MD 26:2023 records that each control now has attributes and a purpose, so evidence should map to the purpose of each control. All certifications to the 2013 edition had to expire or be withdrawn by 31 October 2025, so organizations assessed against the 2022 edition should confirm the mapping with their certification body early in the project.

Ask for a written scope listing the secret types, applications, pipelines and environments in scope, and the integration method for each. Request the HA design and backup approach, the assumed number of integrations, and what is delivered for policies covering 5.17 and 8.24. Confirm which items are one-time and which are recurring, what the retainer covers for upgrades and support, and which internal roles and change windows the plan assumes. Also ask what evidence is produced, in what format, and whether the certification body has reviewed the evidence list. Quotes should state exclusions clearly so the scope can be compared between bidders.