SOC 2 secrets management for credentials and API keys

Does SOC 2 require a secrets management system for API keys?

SOC 2 does not name a secrets management tool, but it expects you to control who and what can use API keys, database passwords and service credentials. The relevant controls sit mainly under CC6.6, which covers restricting access, protecting authentication credentials and boundary protection, with related support from CC6.1 on logical access security. Your organization owns these controls and designs how they work. An independent CPA firm tests them and issues the report, and no implementation partner or tool vendor can issue that opinion.

How much a dedicated secrets system matters depends on your architecture. A team with one application, one cloud account and a handful of credentials stored in a managed service may satisfy the criteria with well-documented access rules and rotation. A company with many microservices, several cloud accounts, CI/CD pipelines and third-party integrations usually has credentials scattered across configuration files, pipeline variables and developer laptops, which is hard to inventory and hard to revoke. Ask yourself how credentials are issued today, who can read them, how a departing engineer's access is removed, and whether you could list every active key within a day. If those answers depend on memory or spreadsheets, an auditor is likely to test the gap. Evidence matters as much as the mechanism. Before your observation period starts, confirm with your auditor which records they will request, such as a credential inventory, access approvals, rotation history and revocation tickets, and whether a vault audit log counts as sufficient for your design. Self-hosted tools such as OpenBao can centralize secrets and produce detailed request logs, but the design decisions and the operating evidence remain yours. Scope any implementation partner work in writing, and expect the auditor to test whether the controls actually operated, not merely whether the tool was installed.

Which evidence shows credentials are controlled

An auditor testing secrets management under a Type 2 report does not accept a policy alone. They sample records across the observation period and check that the controls operated each time. The cards below cover the artifacts that usually answer those samples and what each one proves.

Inventory of secret stores

A current list of every place secrets live: the OpenBao cluster, CI/CD variables, configuration files, and any legacy vaults or cloud secret managers still in use. The auditor compares this inventory against the system description and the network diagram to confirm nothing sits outside the boundary. Ask the team to show how the list is kept current, such as a dated export reviewed on a set cadence, and to explain how a new store gets added to it.

Access policies per service

Policies that define which identity can read, write or issue each secret path, typically one policy per application or service. The auditor checks that each service holds only the paths it needs and that human access to production paths is restricted to named roles. Confirm that policy changes go through the same approval flow as code changes and that the policy files themselves are version controlled.

Issuance and revocation logs

Audit device logs that record each request to the secret store, including denied attempts and errors. OpenBao audit devices write a JSON entry for every API request and response, with most sensitive values hashed using HMAC-SHA256. The auditor samples entries across the period to confirm that issuance and revocation happened as the process describes, and that logs are forwarded to storage the platform team cannot silently edit.

Rotation and lease records

For dynamic credentials, the lease history shows that short-lived secrets were issued and expired or were revoked on schedule. For static credentials that cannot be dynamic, the record is the rotation ticket or pipeline run showing the old value was replaced and the old one stopped working. Ask which static secrets exist, who owns each rotation, and what evidence the team keeps when a rotation is skipped or fails.

Repository scan results and remediation tickets

Outputs from secret detection jobs on repositories, such as the GitLab pipeline report written as a job artifact, paired with tickets showing each finding was triaged, the credential was rotated, and the code was fixed. A clean scan on one day does not prove much on its own, so the auditor looks at how findings were handled over the period. Confirm that scan jobs run on every merge request or on the default branch, and that exceptions are approved and dated.

Access review sign-offs

Periodic reviews where an owner confirms that each human and service identity with access to secret paths still needs it. The auditor checks the review date, the reviewer, the population reviewed and any removals made as a result. Confirm the reviews cover service accounts and break-glass identities as well as employees, and that the sign-off is retained as a dated record rather than an informal message.

How OpenBao produces short-lived credentials and audit logs

OpenBao gives an assessor two things to test for credentials: where secrets live and how long they stay valid. OpenBao is an open-source secrets manager licensed under MPL-2.0. It stores secrets encrypted in one place, so application teams stop copying database passwords and API keys into configuration files, wikis and build variables. For CC6.6, the protection of identification and authentication credentials, that single store is the control point you describe in your system narrative and test against your access policy. Confirm in your own environment which storage backend you run, how the unseal process is held and who can read or change policies, because those settings decide how strong the protection actually is.

The more useful feature for the examination is dynamic credentials. OpenBao can generate short-lived credentials for systems such as databases, so a service receives a credential that exists only for a set period instead of a long-lived shared password. Each credential is attached to a lease, and the lease revokes the secret automatically when it expires. OpenBao can also revoke a single secret or a whole tree of credentials, which matters when an engineer leaves, a service is retired or a key may have been exposed. Decide before the audit period starts which lease durations apply to each system, who may request credentials, and which runbook covers mass revocation, then test one revocation end to end and keep the result as evidence.

Audit devices supply the evidence trail. According to the OpenBao audit devices documentation, an enabled audit device writes a detailed JSON log of every API request and response, including errors, and hashes most sensitive values with HMAC-SHA256 so the log does not reveal the secrets themselves. Ship these logs to storage that engineers cannot edit, set a retention period that matches your log policy, and confirm with your auditor how they want samples pulled. Because hashing is a default behavior you should verify rather than assume, check a sample entry before relying on it. Pair this with the CC7 logging design in your own pipeline so that credential events are reviewed, not only stored.

Who owns the secrets controls and who prepares the evidence

The organization owns its SOC 2 controls for secrets, including the decisions an auditor will ask about. Those decisions sit with management and cannot be handed to a vendor or an implementation partner. Management must define the policy, name the people accountable for each control, and show that the controls run every day, not only on the day of the examination.

Policy and scope: Write the secrets management policy, define which credentials are in scope (application secrets, API keys, service accounts, CI/CD tokens) and who approves exceptions.
Access approvals: Decide who may read, create or revoke secrets in OpenBao, and keep a record of each approval.
Rotation decisions: Set rotation expectations for static credentials that cannot be made dynamic, and record when and why they were rotated.
Incident response: Define what happens when a secret is exposed, including revocation, investigation and customer communication.
Ongoing review: Review audit logs and scanning findings on a schedule and keep the evidence of that review.

Before engaging anyone, confirm with your own leadership which named owner signs off on each of these items and where the resulting records will be kept.

How a secrets program moves from inventory to audit evidence

The sequence turns scattered credentials into a governed, logged and scanned secrets practice, and each phase leaves an artifact that an auditor can sample across the observation period.

Inventory credentials and API keys
The engineering and platform leads list every place a secret lives: application configuration, CI/CD variables, service accounts, database users, third-party API keys and certificates in use. Each entry records the system, the credential type, the workload that uses it and whether it is static or already dynamic. The output is a credential register that the team reviews against the infrastructure inventory. The step is done when someone can trace each production credential to a system and an owner, and when unexplained entries have been investigated or removed.
Define owners and access policy
Management assigns an owning team to each credential class and writes a short policy on who may request, read, rotate and revoke secrets, and which secrets may be used by humans versus workloads. The policy links to the access control procedures already used for production access. The output is a signed policy, an owner field on every register entry, and an approval path for new credentials. Auditors will later ask for this document to test whether the design under CC6.6 is current and followed.
Deploy the secret store for priority systems
Platform engineers install OpenBao in the organization's own infrastructure, configure its storage backend, set up authentication for workloads and operators, and enable dynamic secret engines for the highest-risk systems, such as production databases. Access policies grant each workload only the paths it needs. The output is a running store, documented policies and a test showing that a workload can obtain a credential it is entitled to and cannot read another team's path. Confirm the storage, high availability and backup design against your own environment before go-live.
Migrate static secrets to the store
Teams move the remaining static secrets from configuration files, environment variables and CI/CD settings into the store in priority order, and change application code or deployment templates to read them at runtime. Old copies are removed from repositories and build variables, and the rotation or revocation of each migrated secret is recorded. The output is a migration tracker that matches the credential register, with each entry marked as migrated, retired or exempted with a documented reason. Exceptions need an owner and a review date.
Enable audit devices and log retention
Platform engineers enable an OpenBao audit device so that every API request and response is written to a JSON log, with sensitive values hashed. They route these logs to a central location that operators cannot silently edit, and they set a retention period the organization chooses and documents. The output is a sample log entry, a configuration record showing the audit device is enabled, and a retention rule approved by management. Confirm that the log destination meets your integrity and access requirements.
Add repository secret scanning
Developers and platform engineers add a pipeline job that scans committed and pushed changes for exposed secrets. With GitLab Community Edition, pipeline secret detection writes its findings to a gl-secret-detection-report.json artifact in each run. The team defines who triages findings, how a confirmed secret is revoked in the store, and how false positives are recorded. The output is a passing pipeline configuration, a sample report, and a triage record for at least one finding or a documented test that proves detection works.
Collect evidence for the observation period
For a Type 2 examination, the team keeps the policy, register, migration tracker, audit logs, scanning reports, revocation records and access reviews running throughout the observation period, and files them by control with dates. The auditor samples items from this record, so gaps matter more than volume. The output is a dated evidence set that maps each artifact to CC6.6 or a related criterion and shows that the process operated consistently. Ask your auditor which samples they will request and in what format before the period begins.

Where secrets programs stall or fail an audit

Most secrets programs fail on process, not technology. The pitfalls below are the places where credentials outlive their purpose, changes go unrecorded, or findings and logs go unchecked, and each one is the kind of gap an assessor tests for under the common criteria.

Static secrets left in old CI variables

Long-lived database passwords and cloud keys often remain in CI/CD variables after the pipeline that used them has been replaced. Under CC6.6, an assessor will ask where every credential is stored and who can read it. Check for variables that no active job references, and move remaining credentials into OpenBao so that they are issued on demand instead of copied into pipeline settings.

Shared service accounts

A single service account used by several applications or engineers makes it impossible to tell who did what. Assessors look for an identifiable owner and a traceable action for each credential. Issue one identity per workload, and use OpenBao's audit log to tie each request to the identity that made it.

Secrets rotated without records

Rotating a credential is only evidence if the rotation is written down. A key that changed in a vault with no ticket, approval or timestamp leaves the auditor with an unverifiable claim. Record each rotation with its trigger, owner and date, and sample those records during fieldwork.

Scan findings never closed

Pipeline secret detection can flag a committed key in every merge, but a report that nobody triages is a finding that stays open. Assessors compare detected secrets against remediation tickets to see whether they were revoked and rotated. Route each entry in the gl-secret-detection-report.json artifact to a named owner with a closure date.

Audit logs not retained or reviewed

OpenBao audit devices record every API request and response, but logs that are never retained, reviewed or protected lose their value as evidence. Set a retention period in your policy, forward logs to storage the platform team cannot edit, and document who reviews access to secrets and how often. Confirm the retention setting with your own log pipeline.

Type 2 period starting before controls operate

A Type 2 report tests operating effectiveness over a period, so a secrets control that is deployed the week before the window opens has little history to show. Assessors sample activity across the whole period. Before the observation period begins, run rotation, revocation and scanning at least once so the first samples exist, and confirm the start date with your CPA firm.

Questions about SOC 2 and secrets management

Does SOC 2 require OpenBao or any other specific secrets tool?

No. SOC 2 does not name a product. The 2017 Trust Services Criteria ask the organization to restrict access and protect authentication credentials under CC6.6, and the auditor tests whether the controls you chose do that and work over the audit period. OpenBao is one open-source option (MPL-2.0) that stores secrets encrypted in one place, issues dynamic short-lived credentials and keeps detailed audit logs. A managed cloud secrets service or a well-run vault with documented controls can meet the same criterion. What matters is that your design is written down, matches your actual systems and produces evidence. Check the AICPA 2017 Trust Services Criteria for the CC6.6 points of focus before you choose.

How much effort does secrets management add to a SOC 2 and what drives it?

The effort depends mostly on how many systems hold credentials today and how many of them are hard-coded in code, configuration files or CI variables. Moving a service to dynamic credentials means changing how it authenticates, testing that change and removing the old static secret. Costs recur as you add services, rotate leases and review access. Ask any provider for a written scope that lists the systems in scope, the secret types, the number of integrations and who maintains the platform after handover. DeployOpen does not publish prices; a quote follows from that written scope. Your internal engineering time is the largest cost in most cases and is easy to underestimate.

Can our team do secrets management for SOC 2 without outside help?

Often yes, if the team has someone who owns identity and infrastructure and time to document the design. The work includes inventorying secrets, choosing storage and access policies, integrating applications, setting up audit logging, writing procedures and collecting evidence across the observation period. Teams usually struggle with the inventory and the evidence trail, not the tool installation. An implementation partner can prepare systems and evidence, but the organization still owns its controls, and only an independent CPA firm issues the SOC 2 report. Outside help is most useful when the team lacks capacity or has never run an audit before.

What will the auditor ask for about secrets and API keys?

Auditors usually request a description of how credentials are created, stored, distributed, rotated and revoked, plus a list of the systems and accounts that hold them. For a Type 2 engagement they sample events across the period, so expect requests such as access approvals for the secret store, samples of audit log entries, evidence that leases expired or secrets were revoked when an employee or service left, and records of exceptions and how they were resolved. Auditors also check that the secret store itself is restricted and monitored. Prepare a control matrix that maps each criterion to the artifact that shows it operating. Confirm the exact sample sizes and evidence formats with your auditor, because they vary by firm and engagement.

Does secret detection in our pipeline alone satisfy CC6.6?

No. Scanning for committed secrets is a useful detective control, but CC6.6 is about restricting access and protecting credentials in general, not only in repositories. GitLab Community Edition (MIT) pipeline secret detection scans files committed and pushed to the repository in a CI/CD job and writes results to a gl-secret-detection-report.json artifact, and that capability is available in every tier. The scan does not stop secrets from living in running systems, chat tools or shared spreadsheets, and it does not revoke a leaked key. Pair it with a central store, access restrictions, rotation or revocation procedures, and a documented response when a finding appears. Confirm the scanner's coverage and rule set in the GitLab documentation for your version.

How do secrets controls interact with the SOC 2 Type 2 observation period?

A Type 2 report covers operating effectiveness over a period, so the secrets controls must run consistently for the whole window, not only on the day you set them up. Changes made mid-period should be recorded and their effect on the controls explained to the auditor. Audit logs from OpenBao audit devices, which record each API request and response with most sensitive values hashed using HMAC-SHA256, can serve as evidence if you retain them and can show they are complete. Plan the cutover before the period begins, because switching from static to dynamic credentials during the window creates exceptions that need explanation. Ask your CPA firm how they will handle system changes before fieldwork.

How DeployOpen prepares secrets controls and evidence for your audit

DeployOpen plans, implements and documents self-hosted secrets management inside your own infrastructure, so the credential controls an auditor tests are in place before the observation period begins. We prepare the systems and evidence; your organization owns the controls, and only an independent CPA firm issues the SOC 2 report.

How we scope

The written scope names which applications, pipelines, databases and cloud accounts hold credentials and API keys in the examination.
We list each secret type, its owner, and where it is stored today, so gaps are visible before any build work starts.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins; ongoing support is available as a retainer.

How we build

We deploy OpenBao in your environment, configure its storage and access policies, and restrict who can read or write secrets.
We move static credentials toward dynamic, short-lived credentials with leases, and set revocation procedures for compromised values.
We enable audit devices and add GitLab pipeline secret detection so committed secrets are flagged and recorded as job artifacts.

How we hand over

You receive a control matrix mapping each credential control to CC6.6 and related criteria, with the owner and evidence source for each.
Runbooks cover secret rotation, revocation, break-glass access and responding to a detected secret in a repository.
Evidence exports from OpenBao audit logs and pipeline reports are documented so your CPA firm can sample them during fieldwork.

How we support

Before fieldwork, we test that controls operate as documented and record exceptions so your team can correct them in time.
Upgrades, backups and configuration reviews can run under a retainer, keeping the secrets platform current during the observation period.
Confirm with your auditor which evidence format and sampling approach they expect before we finalize the evidence pack.