Secrets Management Policy Template: Rules for Storing, Rotating and Revoking Secrets

Most leaked credentials are not stolen from a vault: they are found in source code, CI logs, chat messages and configuration files because nobody wrote down where secrets are allowed to live and who must act when one escapes. This template sets the rules for which vaults are approved, what counts as a secret, how secrets are created, scoped, rotated and revoked, how code and pipelines are scanned, and what happens in the first hour after a leak. It is written for CISOs, platform and DevOps leads and application owners who need a policy they can adopt with light editing and audit against. The Secrets Management Guide explains the discipline and the tooling; this page is the policy document that makes it mandatory.

How to use this template

• Replace text in square brackets, such as [Organisation], [Head of Platform Engineering], [approved vault] and [90 days], with your own terms. Bracketed values are suggested defaults, not external requirements.
• "Must" is mandatory. "Should" is recommended practice where a documented exception may be justified.
• Keep the list of approved vaults and the rotation table (sections 4.2 and 4.5) as a separately versioned standard, so platform teams can update them without re-approving the policy.
• Human passwords are governed by your password or authentication policy. This policy covers secrets used by machines, workloads, pipelines and AI agents, and shared administrative credentials.
• Place this policy beneath your top-level information security policy and next to your access control and cryptography policies.

1. Purpose

This policy sets the requirements for creating, storing, distributing, using, rotating and revoking secrets at [Organisation], so that a secret is only ever available to the workload or person that needs it, for the shortest practical time, from an approved store, with every access logged. Its aim is that a leaked secret is detected quickly, can be revoked within minutes without an outage, and grants as little as possible while it is valid.

2. Scope

For this policy, a secret is any value that grants access to a system or data, or protects data cryptographically. This includes:

• API keys, access keys and personal access tokens for cloud, SaaS and developer platforms.
• Passwords and connection strings for service accounts, databases, message queues and directories.
• OAuth client secrets, refresh tokens and signing keys for identity providers and applications.
• Private keys for TLS, SSH, code signing and document signing, and symmetric encryption keys.
• Webhook signing secrets, CI/CD variables, Kubernetes Secrets and credentials held by AI agents and automation platforms.
• Shared administrative and break-glass credentials.

It applies to all environments (production, staging, development and test), all code repositories and pipelines, and all staff, contractors and service providers who build or operate systems for [Organisation].

3. Roles and responsibilities

4. Policy statements

4.1 General principles

1. Every secret must have a named owner, a documented purpose, a list of the workloads allowed to use it, a creation date and a rotation date, recorded in the vault's metadata or [the NHI inventory]. OWASP's Secrets Management Cheat Sheet lists this metadata as the minimum needed to manage or move a secret.
2. Where the platform supports it, workloads must authenticate with their own identity (workload identity federation, managed identities, instance roles or short-lived tokens) instead of a stored static secret. A static secret is the exception, not the default. See the Dynamic Secrets and Ephemeral Credentials Guide.
3. Each secret must be scoped to the least privilege its workload needs and must not be shared between applications, environments or tenants.
4. Production secrets must never be used in development or test environments.

4.2 Approved storage

1. Secrets must be stored only in an approved secrets store: [list approved vaults, for example the cloud provider's secrets manager in each account, a central enterprise vault, and the approved team password manager for human-held shared credentials].
2. Secrets must be encrypted at rest by the store, transmitted only over TLS, and retrieved at runtime or injected by the platform. They must not be baked into container images, virtual machine images or build artefacts.
3. Secrets must not be stored in: source code or configuration files committed to version control; infrastructure-as-code state without encryption; tickets, wikis, chat, email or spreadsheets; CI/CD logs; AI prompts, agent memory or model context; or unencrypted environment files on shared hosts. See Environment Variables and .env Files.
4. Access to secrets in the store must be granted per secret or per path to named workload identities and roles. Human read access to production secrets must be by exception, time-bound and logged.
5. The vault's own root, unseal and recovery credentials must be held outside the vault they protect, split between [two or more] custodians, and tested at least [annually].

4.3 Creation and distribution

1. Secrets must be generated by the vault, the issuing platform or an approved cryptographic library, never chosen by a person. Passwords for service accounts must be at least [32] random characters where the target system allows.
2. Expiry must be set at creation wherever the issuing platform supports it. Personal access tokens and API keys must not be created with "no expiry".
3. Secrets must be delivered to their consumer by the vault integration. Where a person must hand a secret over, it must be shared through [the approved password manager's sharing feature], never in plain text.

4.4 Code, pipelines and scanning

1. All repositories must have secret scanning enabled, and push protection (blocking commits that contain detected secrets) must be enabled for all repositories that support it. Bypassing a block must require a reason and should be limited to [named reviewers] through delegated bypass where the platform offers it.
2. Developers should run a pre-commit secret scan locally. Pipelines must scan code, container images and build logs before release.
3. CI/CD pipelines must obtain cloud and deployment credentials through short-lived federation (for example OIDC) where supported, and must mask secrets in logs.
4. Test fixtures must use [Organisation]'s standard dummy secrets so scanners can ignore them without broad exclusions.
5. [Organisation] should monitor public code platforms and paste sites for its own secret formats and domains. See the Git Secret Scanning Guide.

4.5 Rotation and expiry

1. Rotation must be automated for all Tier 1 services by [date]. Manual rotation must follow a documented runbook that names upstream and downstream dependencies.
2. Every secret must also be rotated immediately when it is suspected to be exposed, when a person who could read it leaves or changes role, or when the system it protects is compromised.
3. Rotation is complete only when the old value has been revoked at the issuing system, not merely replaced in the vault. See Incomplete rotation breaches.

4.6 Logging and monitoring

1. Approved vaults must log, at minimum: who or what requested each secret and for which system; whether the request was approved or denied; secret creation, update, rotation and deletion; authentication and authorisation failures; attempts to use expired or revoked secrets; and all administrative actions. This follows the minimum audit list in the OWASP cheat sheet.
2. Vault audit logs must be forwarded to [the SIEM], protected from tampering, and retained for [12 months].
3. Applications must never write secret values to logs, error messages or telemetry.

4.7 Leak response

1. Anyone who finds or suspects an exposed secret must report it to [security operations contact] at once and must not test the secret.
2. The secret owner and security operations must, in this order: revoke or disable the secret at the issuing system; issue and deploy a replacement; remove the value from where it was exposed (code, logs, tickets); and review the issuing system's logs for use of the secret across the whole exposure window, not only since discovery.
3. Target times: revocation within [1 hour] of a confirmed exposure in a public location, and within [24 hours] for internal-only exposure.
4. Removing a secret from git history does not make it safe; revocation does. History rewrites are optional and must be co-ordinated because they break existing clones and links.
5. [Organisation] must publish a way for outside researchers to report exposed secrets, such as a security.txt file or vulnerability disclosure page. In the Home Depot token exposure, a GitHub token published online stayed valid for more than a year and was revoked only after a journalist contacted the company. See the Leaked Credential Response Playbook.

4.8 Backup, availability and break-glass

1. Vaults must be backed up automatically, with encrypted backups held under restricted access, and restores tested at least [twice a year].
2. Applications should cache secrets in memory and tolerate a short vault outage, so vault maintenance does not cause service outages.
3. Break-glass credentials needed to recover the vault or identity provider must be held in a secondary location and tested on a schedule.

5. Exceptions

1. Systems that cannot read from a vault or rotate secrets (for example legacy or OT systems, or third-party products with fixed keys) must be recorded in [the exception register] with compensating controls: network restriction, monitoring of use, and the shortest lifetime the system allows.
2. Exceptions are approved by [CISO] and expire after no more than [12 months].

6. Compliance and monitoring

1. The [Head of Platform Engineering] must report [quarterly] on:
   • Percentage of secrets in approved stores with a named owner and expiry date.
   • Secrets past their rotation date, by tier.
   • Repositories with secret scanning and push protection enabled.
   • Secrets detected in code or logs, push protection bypasses, and median time from detection to revocation.
   • Workloads moved from static secrets to workload identity or federation.
2. Breaches of this policy are handled under [the disciplinary or contractor management process]. Compliance is subject to internal audit at least [annually].

7. Review and approval

Implementation guidance

Rollout

1. Find what exists: scan all repositories, including history, plus CI logs and container registries in report-only mode. Treat every live secret found as exposed and rotate it.
2. Turn on prevention: enable push protection organisation-wide. On GitHub, repository push protection is off by default and, by default, anyone with write access can bypass a block by giving a reason; configure delegated bypass if you want reviews.
3. Stand up the vault pattern per platform: one approved store per cloud plus a central vault for cross-platform secrets, with templates teams can copy.
4. Migrate by tier: move Tier 1 services first, replacing static secrets with workload identity where possible and automating rotation where not. AWS Secrets Manager, for example, supports automatic rotation as often as every four hours with single-user or alternating-users strategies.
5. Test revocation: rotate one secret per service in a game day and confirm nothing breaks. If it does, the rotation runbook is the fix, not a longer lifetime.
6. Roll back safely: keep the old secret valid for a short, defined overlap during migration, then revoke it; never leave both valid indefinitely.

Framework mapping

Sources for the default values

• OWASP: Secrets Management Cheat Sheet
• GitHub Docs: About push protection
• AWS: Secrets Manager best practices
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Secrets Management Guide · Credential Rotation at Scale · Secrets Management Maturity Model · Secrets Management RFP Template · API Key Management Guide