Secrets Management Policy Template twelve sections for classification, storage, rotation, leak detection, remediation, and a defensible sign-off
A free, copy-ready secrets management policy template for internal security, AppSec, product security, platform engineering, DevSecOps, cloud security, vulnerability management, and GRC teams that need to publish a defensible rule for how the organisation generates, stores, distributes, rotates, audits, and destroys the credentials systems use to talk to each other. Twelve structured sections covering policy charter and authority, scope and credential classification, roles responsibilities and the approval ladder, generation and issuance, storage and distribution, rotation cadence and triggers, leak detection and intake, the remediation lifecycle for confirmed leaks (rotate, revoke, clean, verify), developer machines and personal access tokens, logging monitoring and audit evidence, review revision and acknowledgement, and framework crosswalk plus signatures. Aligned with PCI DSS 4.x Requirements 3.5 and 8.2, SOC 2 CC6.1, ISO/IEC 27001 Annex A 5.17 and A 8.24, NIST SP 800-53 IA-5 and SC-12, NIST SP 800-57, NIST SSDF PW.8, OWASP ASVS V2.10, NIS2 Article 21, DORA Articles 8 and 9, and the CISA Secure Software Development Attestation.
Run the leaked-secret lifecycle on the live record, not on a side runbook
SecPortal carries leaked-secret findings on a workspace engagement record with the detection scan, the triage rationale, the rotation evidence, the cleanup decision, the verification scan, and the closure timestamp on one audit-readable record. Free plan available.
No credit card required. Free plan available forever.
Twelve sections that turn secrets handling into a defensible policy
A secrets management policy is the rule a security or platform function publishes to declare how the organisation generates, stores, distributes, rotates, audits, and destroys the credentials systems use to talk to each other. The discipline matters because secrets leaks (hardcoded API keys, leaked cloud IAM keys, exposed signing keys, committed database credentials, pasted webhook secrets) are a recurring incident category, a recurring audit finding category, and a recurring regulatory finding category across PCI DSS 3.5 and 8.2, SOC 2 CC6.1, ISO/IEC 27001 Annex A 5.17 and A 8.24, NIST SP 800-57, NIST SSDF PW.8, OWASP ASVS V2.10, NIST SP 800-53 IA-5 and SC-12, NIS2 Article 21, DORA Articles 8 and 9, and the CISA Secure Software Development Attestation. The twelve sections below cover the durable shape of the artefact. Copy the section that fits your stage and paste the rest as you go.
The policy is not a substitute for the operational artefacts the programme runs against. Pair it with the vulnerability management policy template for the umbrella programme rule the leaked-secret lifecycle plugs into, the vulnerability remediation SLA policy template for the SLA windows that govern triage and closure timing, the security exception register template for the aggregate ledger of accepted risk on unrotatable credentials, the risk acceptance form template for the per-decision artefact behind every exception, the vulnerability remediation worksheet for the per-finding work on a confirmed leak, the audit evidence retention policy template for the retention rule that governs the credential and rotation logs, the vulnerability disclosure policy template for the inbound researcher channel that may report leaked credentials, and the vulnerability management RACI matrix template for the operating-model artefact that names the Accountable role per lifecycle step referenced from Section 3, and the cryptographic key management policy template for the sibling policy that governs the cryptographic lifecycle (HSM-resident keys, KMS-protected keys, signing keys, TLS private keys, BYOK arrangements) for the credentials that are also cryptographic material rather than only operational secrets, and the data classification policy template for the parent rule that names the tier of the data the secrets authenticate to, the handling requirements per tier across storage and transmission and sharing, and the third-party processor discipline the credential lifecycle inherits scope from.
Copy the full policy (all twelve sections) as one block.
1. Policy charter and authority
Open the policy with the firm intent and the executive authority. A reviewer reading the first paragraph should know who publishes the rule, which estate it covers, which executive signed it, and when it went into effect. ISO/IEC 27001 Clause 5.2 expects documented information security policies with named authority; the secrets management policy sits one level below the umbrella ISMS policy and one level above the operational secrets vault runbook and the code-scan triage workflow. The charter answers the first audit question (what programme exists, who signed it) before the policy moves into operational rules.
Policy title: Secrets Management Policy
Policy version: {{POLICY_VERSION}}
Effective date: {{EFFECTIVE_DATE}}
Last review date: {{LAST_REVIEW_DATE}}
Next review date: {{NEXT_REVIEW_DATE}}
Policy purpose:
{{PLAIN_LANGUAGE_PURPOSE_PARAGRAPH}}
Policy objectives (the rule the audit reads against):
- Generate every operational secret through a controlled process that records the issuer, the consumer, and the scope.
- Store every operational secret in a managed secrets store rather than in source code, build scripts, configuration files, container images, deployment manifests, build logs, ticket comments, chat threads, or wikis.
- Distribute secrets to workloads through ambient identity (cloud IAM, workload identity, service mesh, OIDC federation) where the platform supports it, and through scoped store retrieval where it does not.
- Rotate secrets on a published cadence per credential class with named triggers for off-cycle rotation.
- Detect leaked secrets through code scanning on every connected repository and through runtime telemetry where the platform produces it.
- Treat each leak detection as a finding that flows through the standard remediation lifecycle (detect, classify, rotate, revoke, clean, verify) with audit-readable evidence at every step.
- Maintain an audit-readable evidence chain for credential issuance, rotation, leak detection, remediation, exception, and disposition.
Programme sponsor (executive authority that publishes the policy):
- Name: {{EXECUTIVE_SPONSOR_NAME}}
- Role: {{EXECUTIVE_SPONSOR_ROLE}}
Approving authority: {{APPROVING_AUTHORITY_NAME_AND_ROLE}}
Approval date: {{APPROVAL_DATE}}
Policy hierarchy:
- Parent policy: Information Security Policy / Information Security Management System.
- Sibling policies referenced by this policy:
- Vulnerability Management Policy (governs the wider finding lifecycle this policy plugs into).
- Vulnerability Remediation SLA Policy (governs the SLA windows for leaked-secret findings).
- Security Exception Register Policy (governs the residual-risk path for unrotated or unrotatable credentials).
- Risk Acceptance Policy (governs the per-decision artefact behind every exception).
- Audit Evidence Retention Policy (governs the retention of credential and rotation evidence).
- Cryptographic Key Management Policy (governs the keys and certificates that fall under cryptographic lifecycle rather than service-credential lifecycle).
- Identity and Access Management Policy (governs the human-credential side).
- Acceptable Use Policy (governs developer-machine handling of credentials).
- Vendor and Third-Party Security Policy (governs third-party tokens issued to vendors or consumed from vendors).
Frameworks the policy evidences (map your scope into Section 12):
- PCI DSS 4.x Requirements 3.5, 3.6, 3.7, 8.2.
- SOC 2 Common Criteria CC6.1, CC6.6, CC6.7, CC6.8.
- ISO/IEC 27001 Annex A 5.17, A 5.34, A 8.5, A 8.24.
- NIST SP 800-53 IA-5, SC-12, SC-13, SC-17.
- NIST SP 800-57 Parts 1 to 3.
- NIST SSDF PW.8.
- OWASP ASVS V2.10 and V6.
- NIS2 Article 21.
- DORA Articles 8 and 9.
- CISA Secure Software Development Attestation (secrets-in-code controls).
- HIPAA Security Rule 45 CFR 164.312(a)(2)(iv) and 164.312(e)(2)(ii) for encrypted credentials in PHI environments.
- Internal policy: {{INTERNAL_POLICY_REFERENCES}}
2. Scope and credential classification
Scope is the contested part of the policy at audit. Name what counts as a secret, where it can live, who can issue it, and how it is classified. Tier secrets the way the rest of the security programme tiers assets so the rotation cadence, the storage requirement, and the exception path scale with the underlying sensitivity.
In-scope credential classes (carry the full policy):
- Service account API keys for first-party and third-party platforms.
- Database connection strings (read, write, admin) for production and pre-production datastores.
- Cloud platform credentials (AWS access keys, GCP service account keys, Azure service principal secrets, OCI API keys) where short-lived alternatives are not available.
- Cryptographic signing keys (JWT signing keys, SAML signing keys, container image signing keys, code signing certificates).
- TLS private keys for first-party endpoints and customer-pinned mTLS keys.
- SSH private keys used by automation and by privileged operators.
- OAuth client secrets for the platforms the firm operates as a consumer or as a provider.
- Webhook signing secrets for inbound integrations.
- Encryption keys (data-at-rest keys, envelope keys, KMS keys where the firm holds the wrapping key).
- Personal access tokens on third-party platforms (GitHub PAT, GitLab PAT, Bitbucket app password) issued to engineers and to automation.
- Password vault contents for shared service accounts that cannot yet be replaced by ambient identity.
- {{ADDITIONAL_IN_SCOPE_CREDENTIAL_CLASSES}}
Out-of-scope or modified-scope items:
- End-user passwords governed by the Identity and Access Management Policy rather than this policy (the two policies reference each other).
- Personal credentials engineers use for their personal accounts outside company systems.
- Customer credentials the firm holds as a service provider on behalf of a customer (governed by the customer data handling policy).
- {{ADDITIONAL_OUT_OF_SCOPE_BOUNDARIES}}
Credential tiers (the policy applies cadence and storage requirements per tier):
- Tier 1 critical: credentials with production write or admin authority, with cross-tenant or cross-service blast radius, or with direct customer data access. Examples: production database admin credentials, cloud organisation admin credentials, signing keys for production releases, KMS root keys, payment processor live keys.
- Tier 2 important: credentials with production read authority, with scoped service authority, or with non-production write authority. Examples: production read-only database credentials, scoped service-to-service tokens, deployment pipeline credentials for a single service, third-party API credentials with billing impact.
- Tier 3 standard: credentials with non-production read authority, with sandboxed scope, or with documented low blast radius. Examples: staging database credentials, non-production third-party API credentials, read-only telemetry tokens.
Environments in scope: {{IN_SCOPE_ENVIRONMENTS}}
Surfaces in scope (the policy applies to credentials found on any of these surfaces):
- Source code repositories (production code, infrastructure-as-code, configuration-as-code, scripts, fixtures, tests).
- Container images and image manifests.
- Build pipeline configuration and pipeline logs.
- Deployment manifests (Kubernetes manifests, Helm charts, Terraform state files where stored unencrypted).
- Runtime environment variables, process memory, and container metadata services.
- Documentation, ticket comments, chat threads, wikis, internal portals, and shared notes.
- Backup files, debug logs, crash dumps, and exported support bundles.
- Developer machine local storage (environment files, IDE credential stores, keychain entries).
Asset tagging:
- Every credential records the credential class, the credential tier, the issuer, the consumer service, the named owner, and the lifecycle state (active, rotated, revoked).
- The credential tagging lives in the secrets manager metadata rather than in tribal knowledge; the credential identifier (never the value) is recorded on the engagement record when the credential is referenced from a finding.
3. Roles, responsibilities, and the approval ladder
Name the roles so the policy is enforceable rather than aspirational. Without a named Responsible role per lifecycle step, leaked-secret incidents stall at the question of who should rotate. Without a named Approver per exception band, exceptions accumulate without a defensible decision trail.
Policy owner: {{POLICY_OWNER_ROLE}}
- Maintains the policy text, schedules the annual review, drives material revisions.
- Sole authority to publish a new version after approval.
Operational owner (programme function that operates the policy day to day): {{OPERATIONAL_OWNER_ROLE}}
- Operates the secrets management programme.
- Owns the secrets manager itself, the rotation cadence schedule, the leak-detection scanner configuration, the suppression rule maintenance, and the operational metrics.
- Reports programme performance into the wider vulnerability management programme review cycle.
Per-lifecycle-step responsibility:
- Generate: secrets manager or issuing platform (the secret is generated through a controlled process; manual generation in shells is prohibited for in-scope credentials).
- Store: secrets manager (the value lives in the managed store; copies in code, configuration, tickets, or chat are prohibited).
- Distribute: workload identity layer (ambient identity where supported) or scoped store retrieval (the workload retrieves the value at runtime through least-privilege access; baked-in values are prohibited).
- Rotate: scheduled rotation engine in the secrets manager where supported, or named operator role where manual rotation is required.
- Detect leaks: code scanning function (Semgrep p/secrets ruleset on every connected repository at the cadence published in Section 6) plus runtime telemetry where the platform supplies it.
- Triage leaks: vulnerability management triage function with the secrets-specific classification rule from Section 8.
- Rotate at issuing system after a confirmed leak: named operator with credential-issuer access (cloud IAM admin, database admin, third-party API admin, signing key holder).
- Clean up the working tree and the history: development team with platform engineering and security engineering review where history rewriting is required.
- Verify closure: code scanning function plus vulnerability management closure on evidence.
- Approve exceptions: tiered approval ladder per residual rating (see Section 8).
Approval ladder for severity overrides and exception decisions:
- Severity downgrade or upgrade on a leaked-secret finding: head of vulnerability management with rationale recorded on the finding.
- Exception filing for an unrotatable credential (a third-party platform that does not support rotation, a customer-pinned credential the customer must rotate, a legacy system in decommissioning) at residual rating low or medium: vulnerability management programme owner.
- Exception at residual rating high: CISO or delegated head of security with compensating control documented.
- Exception at residual rating critical: CISO and executive sponsor with compensating control documented and a hard expiry that does not exceed 90 days without renewed approval.
- Policy revision: policy owner, operational owner, CISO sign-off, audit committee notification.
RACI summary (referenced from the operating model documentation):
- Responsible per step: see the lifecycle responsibility list above.
- Accountable end to end: CISO or delegated head of security.
- Consulted: platform engineering for ambient identity availability, identity and access management for federation interfaces, GRC for framework crosswalk, internal audit for evidence design.
- Informed: business unit heads with material credential exposure in their service portfolio, engineering leadership, audit committee at quarterly cadence.
4. Generation and issuance
Generation is the moment the policy applies to a new credential. If the credential exists outside the controlled issuance process at creation, the rest of the lifecycle is unenforceable. Name the issuance channel per credential class so the team knows which path is sanctioned.
Generation rule: every in-scope credential is generated through a controlled process that records the issuer, the consumer service, the scope, the tier classification, the rotation cadence, and the named owner.
Approved generation channels per credential class:
- Cloud platform credentials: generated through cloud IAM consoles or APIs with the credential identifier (not the value) recorded in the secrets manager metadata; the value itself is delivered directly to the consumer service or stored in the secrets manager if no ambient identity alternative exists.
- Database credentials: generated through the database admin console or a dedicated provisioning script with the credential identifier recorded in the secrets manager metadata; the value is stored in the secrets manager.
- Service-to-service tokens (first-party): generated through the firm authorisation service with named subject, named audience, scoped permissions, and bounded lifetime; long-lived static service tokens are deprecated in favour of short-lived rotation through workload identity.
- Third-party API credentials: generated through the vendor admin console; the issuance event is recorded with the issuing engineer, the consumer service, the scope, the rotation cadence, and the named owner.
- Cryptographic signing keys: generated through a key ceremony per the cryptographic key management policy with the ceremony evidence retained per the audit evidence retention policy.
- TLS private keys: generated through the ACME automation, the commercial CA portal, or the internal CA per the cryptographic key management policy and the certificate lifecycle workflow.
- OAuth client secrets: generated through the issuer admin console with the credential identifier recorded in the secrets manager.
- Webhook signing secrets: generated through a cryptographically random source with sufficient entropy and recorded in the secrets manager.
- Personal access tokens for engineers: generated by the named engineer on the platform with the minimum scope required, the maximum allowed lifetime (90 days where the platform supports expiry), and recorded on the engineer record for offboarding revocation.
Prohibited generation patterns:
- Manual generation in shells with no tagging or storage.
- Sharing a generated credential through chat or email without subsequent storage in the secrets manager and removal from the chat or email channel.
- Re-using a credential from a previous engagement or a previous incident without explicit re-issuance.
- Issuing a credential with broader scope than the consumer service requires.
- Issuing a static long-lived credential where the platform supports short-lived workload identity.
Issuance record (recorded on the secrets manager metadata or the credential register, whichever the firm operates):
- Credential identifier (never the value).
- Credential class.
- Credential tier.
- Issuer (the platform or service that minted the credential).
- Consumer (the service or human that the credential authorises).
- Scope and permissions.
- Issuance date.
- Rotation cadence.
- Next scheduled rotation date.
- Named owner.
- Linked engagement record reference where the credential supports a tracked workflow.
5. Storage and distribution
Storage and distribution are where most secrets leak. The policy names the sanctioned storage location per credential class and the sanctioned distribution mechanism so the team has a clear rule rather than an implied convention. Prohibited storage locations are listed explicitly because implied prohibitions are routinely ignored.
Sanctioned storage:
- Managed secrets manager: {{PRIMARY_SECRETS_MANAGER}}.
- Fallback or alternative secrets manager: {{SECONDARY_SECRETS_MANAGER}}.
- Cloud-native secret stores per provider: {{CLOUD_NATIVE_SECRET_STORES}}.
- Hardware security modules for cryptographic root keys: {{HSM_INVENTORY}}.
- CI/CD platform secret stores for pipeline-bound credentials: {{CI_CD_SECRET_STORES}}.
- Password manager for shared service accounts that cannot yet be replaced by ambient identity: {{SHARED_ACCOUNT_PASSWORD_MANAGER}}.
Prohibited storage locations:
- Source code repositories (production code, infrastructure-as-code, scripts, tests, fixtures, documentation).
- Container images, image layers, and image metadata.
- Deployment manifests, environment files, configuration files in the repository or in shared drives.
- Build pipeline configuration files committed to the repository.
- Build logs, deployment logs, and crash dumps.
- Ticket tracker comments, chat channels, video call recordings, document collaboration tools.
- Personal notes, wikis, internal portals, shared drives.
- Email attachments and email body text.
- Browser-saved credential lists for production credentials.
- Developer machine plaintext files outside an approved local secret store.
- Backup archives and exported support bundles where the secret has not been redacted.
Distribution mechanisms (in order of preference):
1. Ambient identity (cloud IAM workload identity, GKE workload identity, AKS workload identity, EKS Pod Identity, OIDC federation to cloud providers from CI/CD, mTLS for service-to-service in a service mesh). The workload authenticates as itself and the platform issues short-lived credentials at runtime; no static value is stored in the workload.
2. Scoped retrieval from the secrets manager at runtime through an SDK with caching disabled or strictly time-bounded; the workload retrieves the value through its workload identity and the secrets manager logs the retrieval.
3. CI/CD platform secret injection for build-time and deploy-time credentials with masking enabled in logs.
4. Per-developer fetch from the secrets manager through CLI for developer-machine use, scoped to the development environment, never to production.
Prohibited distribution mechanisms:
- Sharing a value over chat, email, ticket comment, or video call without immediate revocation and re-issuance.
- Hardcoding a value into a script or a container image for any reason.
- Storing a value in an environment variable in a Dockerfile rather than supplying it at runtime through orchestration.
- Copying a value from production to staging or to a developer machine.
Encryption requirements:
- Secrets at rest in any approved store are encrypted with an algorithm and key length consistent with the cryptographic key management policy.
- Secrets in transit between the store and the consumer use TLS at the version and cipher suite the firm cryptographic policy requires.
- Secrets in process memory are not logged, not serialised into telemetry, not exported into error reports unless explicitly redacted.
6. Rotation cadence and triggers
Rotation is the discipline that keeps a leaked secret from being a perpetual liability. Publish the cadence per credential class so the schedule is defensible at audit. Publish the trigger list so off-cycle rotation has a documented basis rather than being a panic response.
Default rotation cadence per credential class (tune per tier):
- Tier 1 critical static credentials: 90 days maximum, ideally 30 to 60 days through automated rotation in the secrets manager.
- Tier 2 important static credentials: 180 days maximum, ideally 90 days through automated rotation.
- Tier 3 standard static credentials: 365 days maximum, ideally 180 days through automated rotation.
- Short-lived workload credentials issued through ambient identity: continuously, with lifetime in minutes to hours, no manual rotation discipline because rotation is the issuance pattern itself.
- Cryptographic signing keys: per the key ceremony cadence in the cryptographic key management policy, typically multi-year aligned to algorithm and key length.
- TLS certificates: per the certificate lifecycle workflow, typically 90 days for ACME-issued certificates and 365 days for commercial CA certificates with renewal scheduled before expiry.
- Personal access tokens for engineers: maximum 90 days where the platform supports expiry, renewed only where the workflow still requires the token.
Note on human passwords (governed by the Identity and Access Management Policy rather than this policy): NIST SP 800-63B Section 5.1.1.2 explicitly recommends against arbitrary periodic password rotation and instead requires rotation on evidence of compromise. The human-credential policy applies its own rule; this policy does not duplicate it.
Off-cycle rotation triggers (rotation happens immediately rather than waiting for the scheduled date):
- Suspected or confirmed leak of the credential value.
- Departure or role change of a privileged engineer who held access to the credential.
- Change of ownership of the consumer system.
- Scope change of the credential (the credential now authorises more or fewer resources than at issuance).
- Compromise of an upstream system in the credential delivery chain (the secrets manager itself, the cloud provider, the CI/CD platform).
- Termination of a vendor relationship where the firm is the consumer.
- Termination of a customer relationship where the firm is the issuer.
- Detection of credential exposure through a third-party threat intelligence feed or public paste-site monitoring.
- An incident response decision recorded on the incident record.
Rotation evidence:
- Every rotation event records the prior credential identifier, the new credential identifier, the rotation timestamp, the named operator, the rotation reason, and the verification step.
- Where rotation is automated through the secrets manager, the rotation engine logs the event and the verification step.
- Where rotation is manual, the operator records the rotation on the engagement record or the credential register with the same fields.
Failure to rotate is a finding:
- A credential that misses its scheduled rotation date is treated as a finding on the engagement record with severity tiered by the credential tier and the named owner, and an SLA window aligned to the vulnerability remediation SLA policy.
7. Leak detection and intake
Detection produces the inbound side of the lifecycle. Name the channels, the cadence, and the intake rule so a detection on any channel reaches the same engagement record as a tracked finding. Detections that land outside a tracked record become tribal-knowledge backlog that the on-call rotation never owns.
Detection channels:
- Code scanning on every connected repository through the Semgrep p/secrets ruleset (run on every commit through CI hook and on the scheduled cadence published in the continuous monitoring configuration).
- Pre-commit hook scanning on developer machines (recommended; published in the developer onboarding documentation).
- Runtime telemetry where the platform supplies it (cloud provider secrets leak detection, third-party platform leak alerts).
- Public paste-site monitoring through a third-party intelligence provider where the firm subscribes.
- Inbound reports through the vulnerability disclosure programme (a researcher reports a credential found in a public surface).
- Internal staff reports through the secure reporting channel.
Scan cadence:
- Every commit to a connected repository runs the secrets scan through CI.
- Every connected repository runs the secrets scan on the continuous monitoring cadence published in the secrets management runbook (default weekly for repositories with no commit activity, daily for active repositories).
- Every new repository connected to the platform runs an immediate baseline scan.
Intake rule:
- Every detection lands on the engagement record as a finding with severity tiered by credential class and credential tier from Section 2.
- Every detection carries the file path, the line number, the secret category from the scanner, and the scanner confidence indicator.
- Every detection records the discovery timestamp, the discovery source, and the discovery scan reference for the audit trail.
- Detections that match an active suppression rule (a documented false positive or a documented fixture with rationale recorded) inherit the suppression with the inheritance flag set so the triager can review the suppression rather than waiting for a fresh decision.
Severity classification at intake:
- Live secret with production scope on a Tier 1 credential class: critical, immediate triage SLA per the vulnerability remediation SLA policy.
- Live secret on a Tier 2 credential class: high, triage SLA per the SLA policy.
- Live secret on a Tier 3 credential class: medium.
- Documentation sample or test fixture with no live authority: low, follow the suppression rule path with rationale.
- False positive (no actual credential): suppression filed with rationale, no remediation step.
Stop-the-clock conditions on the triage SLA:
- The owner of the issuing system is unavailable for the rotation step because of a documented incident, an active customer-impacting event, or a documented platform outage. Stop-the-clock is recorded on the finding with timestamp and rationale; the clock resumes when the condition clears.
8. Remediation lifecycle (the operational rule the policy enforces)
This is the longest section in the policy because it is the section the audit reads when reviewing a leaked-secret incident. Name the order of operations explicitly. Programmes that get rotation and cleanup order wrong produce closed findings that leave the leaked value live in production for hours or days.
Triage classification (recorded on the finding by the named triager with rationale and timestamp):
- Live secret: the value authenticates against a live issuing system today.
- Documentation sample: the value is a real-looking string used in documentation, a test fixture, or a sample configuration that is not accepted by any live issuing system.
- False positive: the scanner pattern matched a high-entropy string that is not a credential.
Remediation order for confirmed live secrets (the rule the policy enforces):
1. Rotate at the issuing system first. The new credential identifier is recorded on the finding by the named operator with the rotation timestamp. The leaked value is no longer accepted by the issuing system after this step. Rotation is the step that removes the attacker advantage.
2. Revoke the previous credential at the issuing system. Some platforms separate rotation from revocation; on those platforms the previous credential is explicitly revoked rather than left in a grace window.
3. Verify revocation through a positive test that the previous credential is no longer accepted by the issuing system. The verification timestamp lands on the finding.
4. Roll the new credential out to the consumer service through the standard distribution mechanism in Section 5 (ambient identity, scoped retrieval, or CI/CD secret store).
5. Remove the secret from the working tree and commit the cleanup against the appropriate branch.
6. Apply a deliberate decision on the git history: full rewrite with git filter-repo or BFG Repo-Cleaner where the repository is public or shared with third parties; partial cleanup with rationale where the rewrite would break dependent automation; accepted history where the credential is revoked and the repository is private with documented rationale. The decision is recorded on the finding for the audit trail.
7. Run a follow-up code scan against the cleaned branch and confirm the scanner no longer reports the secret. The verification scan reference lands on the finding.
8. Move the finding to verified closed with the closure timestamp, the named verifier, and the verification scan reference.
9. Notify downstream parties where applicable (the customer if the credential authorised a customer-facing interface, the regulator if the credential exposure triggers a notification obligation under PCI DSS, NIS2, DORA, HIPAA, or a privacy regime, the third-party platform if the leak originated through the platform).
Remediation for documentation samples and test fixtures:
- File a permanent suppression rule scoped to the file path and the pattern with rationale recorded so future scans do not re-detect the same fixture.
- Annotate the file with a fixture banner so a future reader understands the string is a sample rather than a live credential.
- Where the fixture is in a public repository, prefer to replace the sample with an obviously-fake value to remove the false-positive surface.
Remediation for false positives:
- File a permanent suppression rule scoped to the pattern with rationale recorded.
- Where the false-positive rate from a specific ruleset is consistently high, route a programme-level review to the operational owner to decide whether the rule should be tuned or replaced.
Prohibited shortcuts (these are the patterns that produce closed findings on top of live leaks):
- Closing a finding because the developer reported they fixed it without a verification scan.
- Removing the secret from the working tree before rotating at the issuing system.
- Rotating at the issuing system without confirming the new credential rolled out to the consumer service (the service breaks at the next call but the finding looks closed).
- Filing an exception to avoid rotation on a credential that the issuing system supports rotating.
- Suppressing a detection without rationale.
Exception path for unrotatable credentials:
- Some credentials cannot rotate on the published cadence: a third-party platform that does not support rotation, a customer-pinned credential the customer must rotate, a legacy system in active decommissioning. The exception is filed on the engagement record with the compensating control (scope reduction, network restriction, additional monitoring, customer notification, decommissioning timeline), the residual rating, the approver, the rationale, and a hard expiry.
- Exception expiry triggers automatic review; renewal requires fresh approval at the same residual rating ladder.
- Exception accumulation across the credential portfolio is reported in the programme quarterly review.
9. Developer machines and personal access tokens
Developer machines are a parallel surface because the operator is a human at a laptop rather than a workload in a data centre. The rule scales differently. Name what counts as production credential on a developer machine so the engineer knows the boundary.
Production credentials on developer machines:
- Production credentials are never copied to a developer machine for any reason.
- Production access from a developer machine is mediated through a controlled access path: a bastion, a VPN with MFA, a privileged access management workflow, or a just-in-time elevation path that issues short-lived credentials scoped to the action.
- A developer who needs to read production data for debugging follows the documented production data access workflow with the named approver and the recorded purpose, never by copying production credentials to the developer machine.
Local development credentials:
- Local development uses a personal sandbox project or a per-developer test tenant with separate credentials that have no production scope.
- The personal sandbox credentials are stored in the local secrets manager or in environment files outside the repository.
- Per-developer test credentials do not share the same value across developers.
Personal access tokens issued to engineers:
- Personal access tokens on third-party platforms (GitHub PAT, GitLab PAT, Bitbucket app password, vendor admin tokens) carry the minimum scope required for the workflow.
- Maximum allowed lifetime is 90 days where the platform supports expiry; tokens without expiry support are inventoried on the engineer record and renewed on a 90-day manual review.
- Personal access tokens are revoked as part of offboarding within the same change window as the identity provider deprovisioning step.
- Personal access tokens are revoked on role change where the new role no longer requires the access.
Endpoint hygiene:
- Developer machines comply with the endpoint security policy (disk encryption, OS update cadence, MDM enrolment, EDR coverage).
- Local secrets stores (keychain, credential vault, password manager) follow the encryption-at-rest rule the endpoint policy requires.
- Code editor extensions that handle secrets are limited to vetted publishers and reviewed for credential exfiltration risk.
- Personal cloud accounts are out of scope for company credentials; mixing personal and company credentials in the same vault is prohibited unless the vault enforces separate organisations or workspaces.
Offboarding:
- A departing engineer carries no live production credentials at the moment of departure.
- Offboarding includes a recorded revocation step for every credential associated with the engineer record.
- Shared credentials the engineer held access to are rotated as part of the offboarding flow.
- Personal access tokens issued to the engineer are revoked at the issuing platform.
10. Logging, monitoring, and audit evidence
The policy is defensible at audit only if the operational record is. Name the evidence the programme retains, the retention period, and the access controls. The audit trail is what makes a leaked-secret incident closable on evidence rather than on assertion.
Required logs (each item generates audit-readable evidence retained per the audit evidence retention policy):
- Credential issuance events with the credential identifier, issuer, consumer, scope, tier, owner, and timestamp.
- Credential rotation events with the prior identifier, new identifier, rotation reason, named operator, and timestamp.
- Credential revocation events with the credential identifier, revocation reason, named operator, and timestamp.
- Secrets manager access events with the credential identifier, retriever identity, scope, and timestamp.
- Leak detection events with the file path, line number, secret category, scanner confidence, scan reference, and timestamp.
- Triage decisions with the classification (live, fixture, false positive), the named triager, the rationale, and the timestamp.
- Remediation step events with the named operator, the step, the rationale, and the timestamp.
- Exception events with the residual rating, the approver, the compensating control, the rationale, the expiry, and the timestamp.
- Suppression rule events with the scope, the rationale, the named filer, the expiry where applicable, and the timestamp.
- Policy revision events with the version, the summary, the approver, the rationale, and the timestamp.
Retention:
- Operational logs are retained for the period the audit evidence retention policy requires for the relevant framework scope (typically a minimum of one year, often three years for ISO 27001 programmes, often seven years for financial-services and healthcare programmes).
- Closure evidence (the rotation evidence, the verification scan reference, the named operator chain) is retained for the longer of the operational log retention or the regulatory record retention.
Access controls on the audit evidence:
- The logs themselves are stored append-only.
- Access to the logs is scoped through the team management RBAC and gated by MFA.
- The retrieval of credential metadata for audit (never the value) is logged.
Reporting:
- Operational dashboards (open finding count by severity and tier, breach posture, rotation lapse count, exception count, suppression rate) refresh on the cadence the programme owner publishes (typically weekly).
- Governance dashboards (programme trend, framework coverage, exception accumulation, residual risk) refresh at the cadence the wider vulnerability management programme reports (typically monthly with a quarterly governance pack).
- Audit committee read (programme performance against the policy, exception trend, control coverage) refreshes at the quarterly governance review.
- Board read (residual risk from secrets exposure, programme maturity progression) refreshes annually or on material change.
11. Review, revision, and acknowledgement
Policy review is what keeps the rule current with the threat environment and the framework expectation. Name the review cadence, the revision triggers, and the acknowledgement obligation so the policy is not a publication-time artefact that drifts past its first six months.
Review cadence:
- Annual minimum review by the policy owner with the operational owner, with the review outcome recorded as a revision (new version) or a no-change confirmation (current version reaffirmed with the next review date advanced).
- Material change review on the trigger list below.
Material change triggers (revision is filed off-cycle):
- A new regulation or framework in scope (DORA, NIS2, EU AI Act, a US state privacy law, a sectoral rule).
- A new secrets manager adoption or migration.
- A new CI/CD platform adoption.
- A new cloud platform adoption or material change to the cloud platform's workload identity surface.
- A leaked-secret incident that surfaces a question the policy should have answered.
- An acquisition that adds inherited credential practices.
- A customer audit or third-party audit that requires the company to demonstrate stricter discipline.
- A material change to the operational owner role or the CISO role with a different policy interpretation.
- A material change to the threat environment (new attacker technique, new supply-chain attack pattern, new public exposure of a credential class).
Revision process:
1. Policy owner drafts revision; redline against current version.
2. Operational owner reviews operational impact.
3. CISO or delegated head of security signs the revision.
4. Audit committee notified of the revision summary at the next governance cycle.
5. Revised policy distributed to the published distribution list.
6. Effective date set with appropriate notice (default 30 days; emergency revisions effective immediately with documented rationale).
7. Revision logged in the document control history with version, date, summary, approver, rationale.
8. Prior version archived per the audit evidence retention policy.
Acknowledgement (recorded for stakeholder groups; renewed at material revision):
- Engineering leadership: {{ENGINEERING_LEADERSHIP_ACKNOWLEDGEMENTS}}.
- Platform engineering and infrastructure leadership: {{PLATFORM_LEADERSHIP_ACKNOWLEDGEMENTS}}.
- Security engineering and AppSec leadership: {{SECURITY_LEADERSHIP_ACKNOWLEDGEMENTS}}.
- Vulnerability management programme owner: {{VM_PROGRAMME_OWNER_ACKNOWLEDGEMENT}}.
- GRC and compliance function: {{GRC_ACKNOWLEDGEMENT}}.
- Internal audit function: {{INTERNAL_AUDIT_ACKNOWLEDGEMENT}}.
- Procurement and vendor management (for third-party tokens): {{PROCUREMENT_ACKNOWLEDGEMENT}}.
- All engineers as part of onboarding and annual security awareness training.
Document control:
- Storage location: {{POLICY_STORAGE_LOCATION}}.
- Access controls: {{POLICY_ACCESS_CONTROLS}}.
- Retention: {{POLICY_RETENTION_PERIOD}} (typically aligned to firm record retention).
- Distribution list: {{POLICY_DISTRIBUTION_LIST}}.
12. Framework crosswalk and signatures
Close the policy with the explicit crosswalk so the auditor can read the rule against the relevant control. The signature trail makes the policy defensible at the moment of publication and at every material revision. An unsigned policy is treated as a draft regardless of how widely it is followed.
Framework crosswalk (map each in-scope framework to the sections that evidence it):
- PCI DSS Requirements 3.5, 3.6, 3.7 (cryptographic key management), 8.2 (authentication factors): Sections 2, 4, 5, 6, 8, 10.
- SOC 2 Common Criteria CC6.1 (logical access), CC6.6 (encryption), CC6.7 (transmission), CC6.8 (authentication factors): Sections 2, 3, 5, 6, 7, 8, 10.
- ISO/IEC 27001 Annex A 5.17 (authentication information), A 5.34 (privacy and PII), A 8.5 (secure authentication), A 8.24 (use of cryptography): Sections 2, 4, 5, 6, 8.
- NIST SP 800-53 IA-5 (authenticator management), SC-12 (cryptographic key establishment and management), SC-13 (cryptographic protection), SC-17 (public key infrastructure certificates): Sections 4, 5, 6, 8, 10.
- NIST SP 800-57 Parts 1 to 3 (cryptographic key management): Sections 4, 5, 6.
- NIST SSDF PW.8 (secrets in code controls): Sections 7, 8.
- OWASP ASVS V2.10 (service authentication), V6 (stored cryptography): Sections 2, 4, 5, 6.
- NIS2 Article 21 (cybersecurity risk management measures including cryptography and credential management): Sections 2, 4, 5, 6, 8, 10.
- DORA Article 8 (ICT risk management) and Article 9 (protection of ICT assets including credentials): Sections 2, 5, 6, 8, 10.
- CISA Secure Software Development Attestation (secrets-in-code controls): Sections 7, 8.
- HIPAA Security Rule 45 CFR 164.312 (technical safeguards): Sections 5, 6, 8.
- {{ADDITIONAL_FRAMEWORK_REFERENCES}}.
Approval signatures (required at publication and at every material revision):
Policy owner
- Name: {{POLICY_OWNER_SIGNATURE_NAME}}
- Role: {{POLICY_OWNER_SIGNATURE_ROLE}}
- Date: {{POLICY_OWNER_SIGNATURE_DATE}}
Operational owner
- Name: {{OPERATIONAL_OWNER_SIGNATURE_NAME}}
- Role: {{OPERATIONAL_OWNER_SIGNATURE_ROLE}}
- Date: {{OPERATIONAL_OWNER_SIGNATURE_DATE}}
CISO or delegated head of security
- Name: {{CISO_SIGNATURE_NAME}}
- Role: {{CISO_SIGNATURE_ROLE}}
- Date: {{CISO_SIGNATURE_DATE}}
Audit committee notification reference: {{AUDIT_COMMITTEE_REFERENCE}}
Effective date once all signatures are collected: {{EFFECTIVE_DATE_FINAL}}
Revision history table (maintained on the policy):
| Version | Date | Summary | Approver | Rationale |
| {{V1_VERSION}} | {{V1_DATE}} | {{V1_SUMMARY}} | {{V1_APPROVER}} | {{V1_RATIONALE}} |
Eight failure modes the policy has to design against
The secrets management policy fails the audit read in recognisable patterns. Each failure has a structural fix the template above is designed to enforce. Read this list before you customise the template so the customisation does not weaken the discipline that makes the policy defensible.
Secrets live in code because the policy never said where they should live
The team checks credentials into the repository because no one ever published the rule against it in a signed document. Code scanning surfaces the leaks but the triage queue has no policy reference to point to during remediation. The fix is a published policy with the sanctioned storage list and the prohibited storage list named explicitly so the rule has a citable source.
Rotation cadence is implied rather than published
The programme rotates credentials when someone remembers to. There is no published cadence, no tiered rule, no off-cycle trigger list. Leaks that should have triggered immediate rotation wait for the next manual cycle. The fix is to publish the rotation cadence per credential tier and the off-cycle trigger list so rotation is a scheduled discipline rather than a memory exercise.
Remediation order is wrong
The team removes the secret from the working tree first and rotates the credential later. The leaked value remains live in production for hours or days while the cleanup commit propagates. An attacker who already had the value continues to authenticate. The fix is the rotate-revoke-clean-verify order in Section 8 codified as the policy rule so every leaked-secret incident follows the same defensible sequence.
Closures happen on plan rather than on evidence
The triager moves the finding to closed because the developer reported they cleaned it up. No follow-up scan ran. The next scheduled scan re-detects the same secret because the cleanup commit landed on the wrong branch or got reverted. The reopen rate climbs and the audit reads closure-on-plan as a control weakness. The fix is the verification scan requirement in Section 8 enforced by the operational tooling.
Exceptions accumulate past their expiry
Exceptions for unrotatable credentials get filed and approved, then sit in the register past their original expiry while the underlying remediation is not delivered. The exception count grows; the residual risk grows; the leadership read of programme performance does not reflect the underlying picture. The fix is the hard expiry per residual rating in Section 8 with renewal requiring fresh evidence and fresh approval.
Developer machines hold production credentials by default
Engineers copy production credentials to local environment files to debug a production incident and never delete them. The credential lives on the developer machine for the rest of the engineer tenure. Offboarding does not catch the file because it is not in the credential register. The fix is the developer-machine rule in Section 9 paired with the prohibition on copying production credentials to developer machines and the controlled access path for production debugging.
CI/CD pipeline secrets sprawl across configurations
Pipeline credentials are stored in repository configuration files, in environment variables baked into Dockerfiles, in shared scripts. A repository rename, a fork, or a public open-sourcing event leaks the entire credential portfolio for the pipeline. The fix is the CI/CD platform secret store rule in Section 5 with masking enabled and OIDC federation to cloud providers preferred over static keys.
Suppression rules cover real findings because the rationale was never recorded
A triager files a suppression rule to silence a high-volume false positive without recording why. A subsequent real leak in the same code path inherits the suppression and never reaches the triage queue. The fix is the rationale-mandatory rule in Section 8 plus periodic programme review of suppression rules to confirm the rationale still holds against the current code base.
Ten questions the quarterly governance review has to answer
Operational review keeps the programme on top of leak detections, rotation lapses, and exception flow. Governance review answers whether the policy is delivering durable credential discipline or accumulating residual risk the audit will read as policy drift. Run these ten questions at every quarterly review and capture the answers in the governance record.
1.What is the closure rate on leaked-secret findings per credential tier over the rolling twelve months, and is the trend line up, flat, or down.
2.How many findings breached the SLA in the period, what was the breach reason distribution (capacity, dependency, exception-pending, owner unavailability), and what is the structural fix landing.
3.How many active exceptions are in the register for unrotatable credentials, broken down by residual rating, and how many are approaching expiry within 60 days.
4.What is the rotation lapse count per credential tier, and is the underlying scheduling discipline holding.
5.How many suppression rules are active, what is the median age of a suppression rule, and is the suppression rule rationale still valid against the current code base.
6.How is identification coverage tracking (code scan coverage percent of in-scope repositories, scan cadence adherence).
7.How many leaked-secret findings re-opened in the period, what was the reopen rate, and is verification discipline adequate to support closure on evidence.
8.How many secrets transitioned from static long-lived credentials to ambient identity in the period, and what is the residual long-lived static credential count.
9.How many third-party platform tokens with no expiry support are inventoried on the engineer records, and is the manual 90-day review cadence holding.
10.Has any framework, regulation, secrets manager, CI/CD platform, cloud platform, or threat environment change in the period triggered policy review, and is the review on schedule.
How the policy pairs with SecPortal
The template above is copy-ready as a standalone artefact. If your team already runs finding tracking, remediation, and compliance evidence on a workspace, the leaked-secret lifecycle becomes the byproduct of the work rather than a separate spreadsheet. SecPortal pairs every detection to an engagement record through findings management, so the triage classification, the rotation evidence, the cleanup decision, the verification scan reference, and the closure timestamp live on one record rather than across tickets, chat threads, and a closed-out runbook. The code scanning feature runs Semgrep with the p/secrets ruleset against connected repositories so the detection surface the policy declares in Section 7 is observable rather than asserted. The repository connections feature carries the encrypted git provider tokens that authorise the scan; the tokens themselves follow the secrets handling pattern this policy publishes for tokens that touch external systems.
The finding overrides primitive holds the suppression decisions for documentation samples and false positives with rationale and an expiry on accepted-risk decisions, so the suppression rule audit in Section 8 is queryable rather than reconstructible. The activity log captures the timestamped chain of state changes by user, so the elapsed time between detection, classification, rotation, revocation, cleanup, and verification is observable rather than asserted. The continuous monitoring feature schedules the recurring code scan so leaks introduced after policy publication are detected on the published cadence rather than the next manual run.
The document management feature retains the policy file and the revision history alongside the operational record, so the policy version in force at any reporting cycle is reconstructible from one record. The team management feature carries role-based access control that gates the severity override path, the exception approval ladder, and the policy publishing authority referenced from Section 3. The multi-factor authentication enforcement at the workspace boundary protects access to the operational record that carries the credential metadata trail. The compliance tracking feature maps leaked-secret findings and the surrounding controls to ISO 27001, SOC 2, PCI DSS, and NIST frameworks with CSV export, so the framework crosswalk in Section 12 reads against the live record rather than a separate evidence spreadsheet. The AI report generation workflow produces leadership summaries from the same engagement data so the audit committee read and the operational read are the same record.
Explicit honest scope: SecPortal does not replace the secrets manager itself (HashiCorp Vault, AWS Secrets Manager, Google Secret Manager, Azure Key Vault, CyberArk Conjur, Doppler, 1Password, Bitwarden, Akeyless, Infisical), does not replace the cloud IAM workload identity layer, does not issue or rotate credentials at the issuing system, does not replace the CI/CD platform secret store, and does not integrate with Jira, ServiceNow, Slack, SIEM, or SOAR. The platform carries the operational record the policy runs against; the credential issuance, storage, and rotation discipline still lives in the secrets manager and the cloud platform.