Cryptographic Key Management Policy Template twelve sections for lifecycle, HSM and KMS storage, cryptoperiods, algorithm sunsets, compromise response, and a defensible sign-off
A free, copy-ready cryptographic key management policy template for internal security, AppSec, product security, platform engineering, cloud security, vulnerability management, and GRC teams that need to publish a defensible rule for how the organisation generates, distributes, stores, uses, rotates, archives, and destroys cryptographic keys across data-at-rest encryption, data-in-transit encryption, signing, authentication, and integrity workloads. Twelve structured sections covering policy charter and authority, scope and key classification by tier, roles responsibilities and the custodian roster, generation issuance and key ceremonies, storage and distribution across HSM and KMS and BYOK, cryptoperiods and rotation triggers, NIST SP 800-57 lifecycle states, compromise response and the rotation cascade, algorithm sunsets and post-quantum readiness, logging monitoring and audit evidence, review revision and acknowledgement, and framework crosswalk plus signatures. Aligned with PCI DSS 4.x Requirements 3.6 and 3.7, SOC 2 CC6.1 and CC6.6, ISO/IEC 27001 Annex A 8.24, NIST SP 800-57 Parts 1 to 3, NIST SP 800-53 SC-12 and SC-13 and SC-17, NIST SP 800-131A, FIPS 140-3, OWASP ASVS V6 and V9, NIS2 Article 21, DORA Articles 8 and 9, and the CISA Secure Software Development Attestation.
Run the key lifecycle on the live record, not on a side runbook
SecPortal carries cryptographic findings on a workspace engagement record with the detection scan, the triage rationale, the suspension event, the replacement reference, the cascade completion, 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 cryptographic key handling into a defensible policy
A cryptographic key management policy is the rule a security or platform function publishes to declare how the organisation generates, distributes, stores, uses, rotates, archives, and destroys cryptographic keys across data-at-rest encryption, data-in-transit encryption, signing, authentication, and integrity workloads. The discipline matters because cryptographic incidents (compromised root keys, expired algorithm portfolios, leaked signing keys, weak primitives still in production, missing destruction evidence) are a recurring incident category, a recurring audit finding category, and a recurring regulatory finding category across PCI DSS 3.6 and 3.7, SOC 2 CC6.1 and CC6.6, ISO/IEC 27001 Annex A 8.24, NIST SP 800-57, NIST SP 800-53 SC-12 and SC-13 and SC-17, NIST SP 800-131A, FIPS 140-3, OWASP ASVS V6, 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 secrets management policy template for the credential-class sibling policy that governs how the programme treats leaked credentials that are not in scope as cryptographic keys, the vulnerability management policy template for the umbrella programme rule the cryptographic finding 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 or unreplaceable keys, the risk acceptance form template for the per-decision artefact behind every exception, the audit evidence retention policy template for the retention rule that governs the ceremony, custody, and destruction evidence, 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 data classification policy template for the parent rule that names the tier of the data the cryptographic keys protect, the handling requirements per tier across storage and transmission and disposal, and the tier-driven assurance level that the storage-tier rule in Section 5 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 cryptographic key management policy sits one level below the umbrella ISMS policy and one level above the operational HSM runbook, the cloud KMS configuration, the key ceremony script, and the certificate lifecycle workflow. The charter answers the first audit question (what programme exists, who signed it) before the policy moves into operational rules.
Policy title: Cryptographic Key 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 cryptographic key through a controlled process that records the key class, the cryptographic algorithm, the key length, the named custodian, the issuance event, and the intended cryptoperiod.
- Store every key under the assurance tier the key class requires (HSM-resident for root keys and master signing keys, FIPS-validated cloud KMS for the next tier, software keystores only for non-production or documented low-tier use).
- Distribute keys to consuming workloads through ambient identity (cloud KMS workload identity, HSM client identity, mTLS service mesh identity) where the platform supports it, with scoped retrieval where it does not.
- Rotate keys on a published cryptoperiod per key class with named triggers for off-cycle rotation.
- Track every key through the NIST SP 800-57 lifecycle states (preactive, active, suspended, deactivated, compromised, destroyed) with the transition authority and the evidence required at each transition.
- Sunset algorithms on a published schedule that runs ahead of the cryptanalytic break threshold rather than after it.
- Maintain an audit-readable evidence chain for key issuance, distribution, rotation, suspension, deactivation, compromise response, and destruction.
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:
- Secrets Management Policy (governs operational credentials that are not in scope as cryptographic keys).
- Vulnerability Management Policy (governs the wider finding lifecycle this policy plugs into).
- Vulnerability Remediation SLA Policy (governs the SLA windows for cryptographic findings).
- Security Exception Register Policy (governs the residual-risk path for unrotatable or unreplaceable keys).
- Risk Acceptance Policy (governs the per-decision artefact behind every exception).
- Audit Evidence Retention Policy (governs the retention of key custody, ceremony, and destruction evidence).
- Identity and Access Management Policy (governs human-credential management adjacent to authentication keys).
- Acceptable Use Policy (governs developer-machine handling of keys).
- Vendor and Third-Party Security Policy (governs third-party cryptographic dependencies and BYOK arrangements).
- Encryption Standard (the technical companion that names approved algorithms, modes, parameter choices, and library implementations).
Frameworks the policy evidences (map your scope into Section 12):
- PCI DSS 4.x Requirements 3.6 and 3.7.
- SOC 2 Common Criteria CC6.1 and CC6.6.
- ISO/IEC 27001 Annex A 5.34, A 8.5, A 8.24.
- NIST SP 800-57 Parts 1 to 3.
- NIST SP 800-53 IA-5, SC-12, SC-13, SC-17.
- NIST SP 800-131A (transitions for cryptographic algorithms and key lengths).
- NIST SP 800-175B (cryptographic mechanisms guideline).
- FIPS 140-3 (cryptographic module assurance).
- FIPS 197 (AES), FIPS 180-4 (SHA), FIPS 186-5 (digital signatures), FIPS 203 and FIPS 204 (post-quantum standards as they enter scope).
- OWASP ASVS V6 (Stored Cryptography) and V9 (Communications).
- NIS2 Article 21.
- DORA Articles 8 and 9.
- CISA Secure Software Development Attestation (cryptographic controls).
- HIPAA Security Rule 45 CFR 164.312 (technical safeguards).
- Internal policy: {{INTERNAL_POLICY_REFERENCES}}
2. Scope and key classification
Scope is the contested part of the policy at audit. Name what counts as a cryptographic key, where it can live, who can issue it, and how it is classified. Tier keys the way the rest of the security programme tiers assets so the cryptoperiod, the storage assurance, and the exception path scale with the underlying sensitivity.
In-scope key classes (carry the full policy):
- HSM-resident root keys and master keys.
- Key encryption keys (KEKs) and wrapping keys.
- Symmetric data encryption keys (DEKs) for data-at-rest in production datastores.
- Symmetric session keys for data-in-transit where the firm holds the key.
- Asymmetric signing key pairs (code signing, container image signing, JWT signing, SAML signing, document signing, attestation signing).
- TLS private keys for first-party endpoints and customer-pinned mTLS keys.
- Certificate Authority signing keys where the firm operates an internal PKI.
- SSH host and client keys used by automation and by privileged operators.
- OpenPGP and S/MIME keys where used for signed or encrypted messaging.
- Customer-managed keys (CMK) and bring-your-own-key (BYOK) material held under the firm or under the customer.
- Encryption-at-rest keys for backups, archive media, and exported support bundles.
- {{ADDITIONAL_IN_SCOPE_KEY_CLASSES}}
Out-of-scope or modified-scope items:
- Operational credentials governed by the Secrets Management Policy (API keys, OAuth client secrets, passwords, personal access tokens) where the credential is not itself a cryptographic key.
- End-user passwords governed by the Identity and Access Management Policy.
- Customer-owned keys where the firm acts only as a passthrough and never sees the plaintext key material.
- Personal cryptographic keys engineers use for personal accounts outside company systems.
- {{ADDITIONAL_OUT_OF_SCOPE_BOUNDARIES}}
Key tiers (the policy applies cryptoperiod and storage assurance per tier):
- Tier 1 critical: keys whose compromise authorises broad cryptographic forgery, decrypts protected production data, or breaks the trust anchor for first-party signing. Examples: HSM root keys, KEKs and master keys, PKI CA signing keys, code signing keys for production releases, BYOK wrapping keys, signing keys for payment material, encryption keys for regulated data classes.
- Tier 2 important: keys that protect production data but with bounded blast radius, or keys that sign artefacts with bounded authority. Examples: per-tenant DEKs wrapped by a Tier 1 KEK, scoped signing keys for non-production artefacts, TLS private keys for production customer-facing endpoints, mTLS service mesh keys.
- Tier 3 standard: keys that protect non-production data, sandbox environments, or low-blast-radius systems. Examples: development encryption keys, test TLS keys, signing keys for sandboxed environments, ephemeral keys issued by ambient identity for short-lived workloads.
Environments in scope: {{IN_SCOPE_ENVIRONMENTS}}
Surfaces in scope (the policy applies to keys found on any of these surfaces):
- HSM key stores and HSM partition configurations.
- Cloud KMS (AWS KMS, Google Cloud KMS, Azure Key Vault, Azure Managed HSM, OCI Vault) key inventories.
- Software keystores (Java JCEKS, BouncyCastle keystores, encrypted file-based keys) where permitted by tier.
- Application configuration files that reference key identifiers (never key values).
- Certificate stores (operating system trust stores, application certificate stores, container image truststores).
- Source code repositories (only key identifiers and ceremony scripts; key values are prohibited).
- Container images and image manifests (only key references; key values are prohibited).
- Build pipeline configuration and pipeline logs (only key references; key values are prohibited).
- Backup archives, exported support bundles, and forensic images (encrypted at rest with audit-readable evidence).
Asset tagging:
- Every key records the key class, the key tier, the algorithm and key length, the cryptoperiod, the lifecycle state, the storage location (HSM identifier, KMS key identifier), the named custodian, the issuance event reference, the next rotation date, and the linked engagement record where applicable.
- The tagging lives in the KMS or HSM metadata rather than in tribal knowledge; the key identifier (never the value) is recorded on the engagement record when the key 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, key compromise incidents stall at the question of who should rotate. Without a named Approver per exception band, exceptions accumulate without a defensible decision trail. PCI DSS 3.7.6 in particular reads against the named custodian roster.
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 cryptographic key management programme.
- Owns the HSM and KMS configuration, the rotation cadence schedule, the algorithm sunset schedule, the suppression rule maintenance, and the operational metrics.
- Reports programme performance into the wider vulnerability management programme review cycle.
Key custodians (named individuals or role holders authorised to operate keys at the most sensitive tiers):
- HSM root key custodians: {{HSM_ROOT_KEY_CUSTODIANS}} (m-of-n requirement: {{HSM_ROOT_KEY_QUORUM}}).
- PKI CA signing key custodians: {{PKI_CA_CUSTODIANS}} (m-of-n requirement: {{PKI_CA_QUORUM}}).
- Code signing key custodians: {{CODE_SIGNING_CUSTODIANS}}.
- BYOK wrapping key custodians (where applicable): {{BYOK_CUSTODIANS}}.
Per-lifecycle-step responsibility:
- Generate: HSM or KMS through a controlled process (key ceremony for Tier 1 keys; automated provisioning for Tier 2 and Tier 3 where the platform supports it).
- Store: HSM for Tier 1, FIPS-validated cloud KMS for Tier 2, KMS or compliant software keystore for Tier 3 within the documented constraint.
- Distribute: workload identity layer (ambient identity where supported) or scoped retrieval (the workload retrieves the key through least-privilege access; baked-in key values are prohibited).
- Use: consuming workload through the authorised cryptographic library and the authorised parameter set published in the Encryption Standard.
- Rotate: scheduled rotation engine in the KMS where supported, or named operator role where manual rotation is required (with custodian quorum for Tier 1).
- Suspend: named operator with documented rationale recorded on the key custody record.
- Deactivate: named operator with documented rationale and the archive cryptoperiod recorded on the key custody record.
- Respond to compromise: incident response function with named cryptography lead, immediate revocation authority, and replacement key issuance authority.
- Destroy: named custodian quorum where the tier requires it; named operator otherwise; destruction evidence retained per the audit evidence retention policy.
- 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 cryptographic finding: head of vulnerability management with rationale recorded on the finding.
- Exception filing for an unrotatable key 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.
- Algorithm sunset extension beyond the published deadline: CISO sign-off with rationale recorded against the key portfolio.
- 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: cryptography subject-matter expert, platform engineering for ambient identity availability, identity and access management for federation interfaces, GRC for framework crosswalk, internal audit for evidence design, legal where customer-pinned keys imply contractual responsibilities.
- Informed: business unit heads with material cryptographic dependencies, engineering leadership, audit committee at quarterly cadence, customers whose BYOK arrangements are affected by policy changes.
4. Generation, issuance, and key ceremonies
Generation is the moment the policy applies to a new key. If the key exists outside the controlled issuance process at creation, the rest of the lifecycle is unenforceable. Name the issuance channel per key class so the team knows which path is sanctioned. For Tier 1 keys the issuance is a key ceremony with recorded evidence.
Generation rule: every in-scope key is generated through a controlled process that records the key class, the algorithm and key length, the named custodian, the consumer system, the scope, the tier classification, the cryptoperiod, and the storage location.
Approved generation channels per key class:
- HSM root keys and PKI CA signing keys: key ceremony per the published ceremony script with named custodian quorum, recorded ceremony evidence, and audit witness where the tier requires it.
- KEKs and master keys: HSM-resident generation through the HSM administrative interface with named operator and recorded issuance evidence.
- Symmetric data encryption keys (DEKs): generated by the KMS through the KMS API; envelope-encrypted by a KEK at the next tier up; the wrapped DEK is what the workload stores.
- TLS certificate private keys: generated through the ACME automation, the commercial CA portal, or the internal PKI per the certificate lifecycle workflow.
- Code signing keys: HSM-resident generation through the signing platform with named custodian quorum; the public component is published; the private component never leaves the HSM.
- mTLS client keys for service-to-service authentication: generated through the workload identity layer or the service mesh; ephemeral where the platform supports it.
- SSH keys for automation: generated through the automation platform with the public key registered against the consumer system and the private key stored in the secrets manager under the operational credential policy where the SSH key is also an operational credential.
- BYOK material from a customer: imported through the documented BYOK interface with the customer issuance evidence recorded on the customer record and on the key custody record.
- Ephemeral keys for short-lived workloads: issued by ambient identity at runtime with lifetime in minutes to hours; no manual generation discipline because the issuance is the ephemeral generation itself.
Key ceremony requirements for Tier 1 keys:
- Published ceremony script with each step initialled by the named custodians at the moment of execution.
- Named custodian quorum at the m-of-n threshold the key class requires (typically 2-of-3 or 3-of-5).
- Recorded evidence retained per the audit evidence retention policy (signed attestations from each custodian, written ceremony log, recorded video where the firm operates a video evidence model, retained ceremony scripts).
- Audit witness where the framework scope requires it (PCI DSS for cardholder-data keys, customer audit for BYOK wrapping keys).
- Smoke test before the new key transitions to active state (test signature verifies, test encryption decrypts, test decryption matches expected plaintext).
- Issuance event recorded against the key custody record with the timestamp, the named custodians, the ceremony reference, the algorithm and key length, the cryptoperiod, and the next scheduled rotation.
Prohibited generation patterns:
- Manual generation in shells with no tagging, storage, or custody record.
- Generation of Tier 1 keys outside an HSM.
- Generation of cryptographic material from a non-cryptographically-secure random source (Math.random, java.util.Random, time-based seeds, predictable seeds).
- Re-use of a key from a previous engagement or a previous incident without explicit re-issuance.
- Issuance of a key with broader scope than the consumer system requires.
- Issuance of a static long-lived key where the platform supports short-lived ephemeral cryptographic material through ambient identity.
Issuance record (recorded on the KMS or HSM metadata or the key custody register):
- Key identifier (never the key value).
- Key class.
- Key tier.
- Algorithm and key length.
- Cryptoperiod.
- Storage location (HSM identifier and partition, KMS key identifier).
- Issuance event (ceremony reference for Tier 1, automated provisioning reference otherwise).
- Issuance timestamp.
- Named custodian or operator.
- Consumer system or scope.
- Lifecycle state (preactive at issuance; active after smoke test and transition authority).
- Next scheduled rotation date.
- Linked engagement record reference where the key supports a tracked workflow.
5. Storage and distribution
Storage and distribution are where most cryptographic material leaks. The policy names the sanctioned storage tier per key 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:
- Hardware Security Modules for Tier 1 keys: {{HSM_INVENTORY}} with the published FIPS 140-3 assurance level per device.
- FIPS-validated cloud KMS for Tier 2 keys: {{CLOUD_KMS_INVENTORY_FIPS}}.
- Standard cloud KMS for permitted Tier 2 and Tier 3 keys within the documented constraint: {{CLOUD_KMS_INVENTORY_STANDARD}}.
- Internal PKI infrastructure for certificate and CA signing material: {{INTERNAL_PKI_INVENTORY}}.
- Approved software keystores for non-production or low-tier use within the documented constraint: {{SOFTWARE_KEYSTORE_INVENTORY}}.
- Customer BYOK arrangements per the documented BYOK interface: {{BYOK_INVENTORY}}.
Prohibited storage locations:
- Source code repositories (production code, infrastructure-as-code, configuration-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 keys that authenticate to production systems.
- Developer machine plaintext files outside an approved local secret store.
- Backup archives and exported support bundles where the key material has not been wrapped or removed.
- Hardware tokens issued to engineers held outside the documented offboarding workflow.
Distribution mechanisms (in order of preference):
1. Ambient identity (cloud KMS workload identity, HSM client identity, cloud IAM workload identity for KMS-protected operations, mTLS for service-to-service in a service mesh). The workload authenticates as itself and the platform mediates cryptographic operations without exposing the key value.
2. Envelope encryption (the consumer workload receives a wrapped DEK from the KMS; the KMS holds the KEK and never exposes the plaintext DEK in process memory longer than the operation requires).
3. Scoped retrieval from the KMS or HSM client at runtime through an approved SDK with caching disabled or strictly time-bounded.
4. Per-developer fetch from the development KMS through CLI for development environment use, scoped to non-production, never to production.
Prohibited distribution mechanisms:
- Sharing a key value over chat, email, ticket comment, or video call.
- Hardcoding a key value into a script or a container image for any reason.
- Storing a key value in an environment variable in a Dockerfile rather than supplying it at runtime through orchestration.
- Copying a production key to staging or to a developer machine.
- Exporting key material from an HSM where the HSM was configured non-extractable.
Encryption-at-rest requirements:
- Keys at rest in any approved store are encrypted with an algorithm and key length consistent with the published Encryption Standard and the NIST SP 800-131A transition schedule.
- Tier 1 keys are protected by a hardware boundary (HSM) where the framework scope requires it.
- Tier 2 keys are protected by KMS envelope encryption at minimum.
- Tier 3 keys follow the documented software keystore protection requirement.
Encryption-in-transit requirements:
- Keys in transit between the store and the consumer use TLS at the version and cipher suite the firm Encryption Standard requires.
- Key wrapping in transit uses an algorithm consistent with NIST SP 800-38F or the published equivalent.
- Keys in process memory are not logged, not serialised into telemetry, not exported into error reports unless explicitly wrapped or zeroised on use.
6. Cryptoperiods, rotation cadence, and triggers
Rotation is the discipline that bounds a compromised key from being a perpetual liability. Publish the cryptoperiod per key 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. NIST SP 800-57 Part 1 Section 5.3 is the canonical reference for cryptoperiod selection.
Default cryptoperiod per key class (tune per tier and per data-volume risk):
- Tier 1 HSM root keys: multi-year cryptoperiod aligned to the key ceremony cadence and the algorithm strength (typically three to five years for RSA 2048 and ECC equivalent, longer for RSA 4096 and stronger ECC curves) with a published key ceremony for replacement.
- Tier 1 KEKs and master keys: multi-year cryptoperiod with re-wrap of every key under the KEK on rotation; rotation cadence aligned to the operational impact of re-wrapping.
- Tier 1 PKI CA signing keys: multi-year cryptoperiod aligned to the CA certificate lifetime with transition window before retirement so existing signatures remain verifiable.
- Tier 1 code signing keys: one to two year cryptoperiod with transition window so existing signed artefacts remain verifiable.
- Tier 2 symmetric data encryption keys (DEKs): operational cryptoperiod typically one year for high-volume keys, longer for lower-volume keys, with an archive cryptoperiod for decryption-only retention recorded on the key custody record.
- Tier 2 signing keys (JWT, SAML, attestation): one year operational with transition window so existing tokens validate during the window.
- Tier 2 TLS certificate private keys: per the certificate lifecycle workflow (90 days for ACME, one year for commercial CA) with key rotation on certificate renewal.
- Tier 2 mTLS service mesh keys: 90 days where the platform supports rotation, ephemeral where ambient identity issues them.
- Tier 3 development encryption keys and signing keys: one year operational; ephemeral where ambient identity issues them.
- Ephemeral keys for short-lived workloads: continuously, with lifetime in minutes to hours; no manual rotation discipline because rotation is the issuance pattern itself.
Off-cycle rotation triggers (rotation happens immediately rather than waiting for the scheduled date):
- Suspected or confirmed compromise of the key value.
- Departure or role change of a named key custodian.
- Change of ownership of the consumer system.
- Scope change of the key (the key now authorises more or fewer cryptographic operations than at issuance).
- Compromise of an upstream system in the key delivery chain (the KMS itself, the HSM, the cloud provider control plane).
- Cryptanalytic break or material weakening of the algorithm the key uses.
- Algorithm sunset reaching the published deadline for keys still on the sunset algorithm.
- Termination of a vendor relationship where the firm is the consumer of a vendor-issued cryptographic dependency.
- Termination of a customer relationship where the firm is the issuer of a customer-pinned key.
- Detection of key exposure through a third-party threat intelligence feed or public paste-site monitoring.
- An incident response decision recorded on the incident record.
Rotation evidence (recorded on the key custody record for every rotation event):
- Prior key identifier.
- New key identifier.
- Rotation timestamp.
- Named operator (with custodian quorum where the tier requires it).
- Rotation reason (scheduled, off-cycle, compromise, sunset, scope change, custodian event, vendor change, customer change, threat intelligence, incident).
- Verification step (test signature verifies under the new key, test encryption decrypts under the new key, test decryption matches expected plaintext, downstream consumer health check).
- Linked finding identifier where rotation was triggered by a finding.
Re-wrap cascade on KEK rotation:
- When a KEK rotates, every DEK wrapped by the prior KEK is re-wrapped under the new KEK on a scheduled cascade or on next-touch (the consumer workload re-wraps the DEK when it next accesses the data).
- The cascade is tracked on the key custody record with the completion timestamp per DEK.
- Cascades that miss their completion deadline are findings on the engagement record with the named owner and the SLA tier.
Failure to rotate is a finding:
- A key that misses its scheduled rotation date is treated as a finding on the engagement record with severity tiered by the key tier and the named owner, and an SLA window aligned to the vulnerability remediation SLA policy.
- A key still in active use on an algorithm past its published sunset date is a finding with the same lifecycle.
7. Lifecycle states and transitions
NIST SP 800-57 Part 1 Section 7.3 defines the key state model. Name the state transitions a key can take, the named authority for each transition, the evidence required at each transition, and the timestamp recorded on the key custody record. An auditor reading a closure on a leaked-key incident wants to read the prior state, the transition history, and the destruction evidence on one record.
Key state model (every in-scope key occupies exactly one state at any moment):
- Preactive: the key has been generated but is not yet authorised for cryptographic operations. The preactive state ends when the gating criteria (registration, custodian acknowledgement, distribution to consumer systems, smoke test, transition authority sign-off) are recorded on the key custody record.
- Active: the key is authorised for its intended cryptographic operations within the published scope. The operational cryptoperiod runs against the active state.
- Suspended: the key is temporarily withdrawn from active use because of a suspected compromise, a custodian event, or a scheduled operational pause. Suspension is reversible to active or terminal to deactivated. The reason and the expected resolution are recorded on the key custody record.
- Deactivated: the key is withdrawn from cryptographic protection use (encryption, signing) but may still be needed for decryption or verification of artefacts produced when the key was active. The archive cryptoperiod runs against the deactivated state and ends with destruction.
- Compromised: the key has been confirmed or strongly suspected to be exposed to an unauthorised party. The compromise event triggers immediate replacement, revocation of any active certificate that the key signed, and the incident response workflow.
- Destroyed: the key has been removed from every storage location with documented evidence of destruction. Destruction is terminal and starts the audit evidence retention period for the destruction record.
State transition authorities (the named role authorised to move a key between states):
- Preactive to active: named transition authority per key tier (custodian quorum for Tier 1, operational owner for Tier 2 and Tier 3) after smoke test and registration.
- Active to suspended: operational owner or incident response lead with rationale recorded.
- Suspended to active: operational owner after resolution recorded; restoration is gated on the same smoke test the original activation required.
- Active or suspended to deactivated: operational owner with rationale recorded; the archive cryptoperiod starts.
- Any state to compromised: incident response lead or operational owner on confirmation; the compromise notification flows per the incident response runbook.
- Deactivated to destroyed: custodian quorum for Tier 1 keys, operational owner for Tier 2 and Tier 3, with destruction evidence recorded.
Required evidence per transition:
- Preactive to active: smoke test result, transition authority sign-off, distribution confirmation, named custodian or operator, timestamp.
- Active to suspended: rationale, suspension authority, expected resolution timeline, timestamp.
- Active or suspended to deactivated: rationale, deactivation authority, archive cryptoperiod end date, timestamp.
- Any state to compromised: compromise confirmation, named incident response lead, exposure scope assessment, replacement key reference, timestamp.
- Deactivated to destroyed: destruction method (HSM zeroisation command, cryptographic erase of the storage medium, physical destruction of the storage medium where required), named operator (custodian quorum for Tier 1), destruction evidence (signed attestation, photograph or video where the firm operates a physical evidence model, retained destruction script output), timestamp.
State register:
- The key custody record carries the current state, the transition history, the timestamps, and the linked evidence per transition.
- The state register reports against the key portfolio at the operational dashboard cadence so a reviewer can see how many keys are in each state, how many keys have been in suspended state longer than the documented threshold (a tail of unresolved suspensions is a control weakness), and how many keys are approaching the deactivated to destroyed transition.
8. Compromise response and the rotation cascade
Compromise response is the longest section in the policy because it is the section the audit reads when reviewing a cryptographic incident. Name the order of operations explicitly. Programmes that get rotation and revocation order wrong produce closed incidents that leave the compromised key authoritative for hours or days.
Detection triggers (the inbound channels that classify a key as suspected or confirmed compromised):
- Code scan detection of the key value in a public surface (commit, container image, build log).
- Threat intelligence feed reporting the key in a public paste, a public repository, or a public credential dump.
- Internal staff report through the secure reporting channel.
- Inbound report through the vulnerability disclosure programme.
- Anomalous use detection from the KMS or HSM access logs (a key used outside its scope, at an unusual time, by an unusual workload, from an unusual location).
- Custodian event that violates the dual control or split knowledge requirement.
- Vendor or platform notification of a supply chain incident affecting the key delivery chain.
- Cryptanalytic announcement that materially weakens the algorithm the key uses.
Classification at detection:
- Confirmed compromise: the key value is verified exposed and the issuing system has confirmed unauthorised use is possible; severity critical or high per the key tier.
- Suspected compromise: the evidence indicates exposure is plausible but verification is in progress; severity high or medium per the key tier and the elapsed time to verification.
- Anomalous use: the key has been used outside its scope but no exposure is confirmed; severity medium pending investigation.
- False positive: the apparent detection was a similar-looking value, a documented test fixture, or a sample; suppression filed with rationale.
Remediation order for confirmed compromise (the rule the policy enforces):
1. Suspend the key at the issuing system to stop authorised use under the compromised key. The suspension is recorded on the key custody record with the named operator and the timestamp.
2. Issue a replacement key through the standard generation channel for the key class (custodian quorum for Tier 1, automated provisioning for Tier 2 and Tier 3 where the platform supports it). The new key identifier is recorded on the key custody record.
3. Revoke any certificate that the compromised key signed and publish the revocation through the CRL or OCSP responder so verifiers see the revocation.
4. Roll the new key out to the consumer system through the standard distribution mechanism in Section 5 (ambient identity, envelope encryption, scoped retrieval).
5. Re-wrap any DEKs that depended on a compromised KEK and any artefacts that need re-signing under the new signing key, on a scheduled cascade tracked against the key custody record.
6. Move the compromised key to the compromised state with the exposure scope assessment and the replacement key reference recorded.
7. Run a positive verification that the new key works in the consumer system (test signature verifies, test encryption decrypts, downstream health check passes). The verification evidence lands on the key custody record.
8. Notify downstream parties where applicable (the customer if the compromised key signed customer-facing artefacts, the regulator if the compromise triggers a notification obligation under PCI DSS, NIS2, DORA, HIPAA, or a privacy regime, the third-party platform if the compromise originated through the platform, the certificate authority if the compromised key was issued or backed by the CA).
9. Schedule the destruction of the compromised key per the destruction procedure in Section 7 after the archive cryptoperiod completes for any artefacts that still need decryption or verification under the compromised key.
10. Close the incident on evidence (the named operator, the verification result, the cascade completion, the notification evidence, the destruction schedule). The closure is logged on the incident record and the key custody record.
Re-wrap cascade for compromised KEKs:
- Every DEK wrapped by the compromised KEK is re-wrapped under a freshly-issued KEK on a scheduled cascade.
- Cascades are tracked on the key custody record with the per-DEK completion timestamp.
- Cascades that miss their completion deadline are findings on the engagement record with the named owner and the SLA tier.
- The cascade cannot use a temporary KEK that is itself out of compliance with the policy; the replacement KEK is generated through the standard Tier 1 generation channel.
Exception path for unreplaceable keys:
- Some keys cannot be replaced on the published cadence: a customer-pinned BYOK key the customer must rotate, a long-lived signing key whose signed artefacts the firm cannot regenerate, 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 key portfolio is reported in the programme quarterly review.
Prohibited shortcuts (these are the patterns that produce closed incidents on top of live compromise):
- Closing an incident because the new key is in place without confirming the compromised key is no longer authoritative at the issuing system.
- Replacing the key without revoking the certificate the prior key signed.
- Issuing a temporary key that is out of compliance with the algorithm or storage tier requirements.
- Skipping the verification step on the consumer system.
- Filing an exception to avoid replacement on a key that the platform supports replacing.
- Suppressing a detection without rationale.
9. Algorithm sunsets and post-quantum readiness
Algorithm choice is a scheduled discipline. The policy publishes the current sunset list, the next anticipated sunsets, and the post-quantum transition plan so the algorithm portfolio runs ahead of the cryptanalytic break threshold rather than after it. NIST SP 800-131A is the canonical transition reference.
Currently sunset algorithms (prohibited for new issuance and scheduled for retirement from active use):
- MD5 for any cryptographic purpose.
- SHA-1 for signing and integrity (SHA-1 inside HMAC remains permitted only where the framework scope still allows it and the migration to SHA-256 HMAC is scheduled).
- DES and 3DES.
- RC4.
- AES in ECB mode.
- RSA below 2048 bits for new issuance.
- ECC below 224 bits.
- TLS below 1.2.
- Static Diffie-Hellman without forward secrecy.
Algorithms scheduled for next-cycle sunset (transition plan documented per algorithm):
- RSA 2048 for keys with multi-year cryptoperiods that will outlast the published RSA 2048 retirement horizon; transition to RSA 3072 or to ECC at equivalent strength per the schedule.
- SHA-256 for signature algorithms in environments preparing for the post-quantum migration; transition through hybrid mode where the platform supports it.
- TLS 1.2 in environments targeting TLS 1.3 by a published date.
Post-quantum cryptography transition:
- Tracked NIST post-quantum standards: CRYSTALS-Kyber (FIPS 203) for key encapsulation, CRYSTALS-Dilithium (FIPS 204) for digital signatures, SPHINCS+ (FIPS 205) where the firm has set a hash-based signature path, FALCON (FIPS 206 candidate or finalised) where applicable.
- Hybrid mode (classical plus post-quantum in parallel) is the transition path where the platform supports it; the policy publishes the hybrid mode acceptance criteria per consumer system.
- Data classes that require post-quantum protection earliest (recorded against the key portfolio): long-lived encrypted data with multi-year confidentiality requirements, signing keys with multi-year cryptoperiods, customer-pinned cryptographic material where the customer has set a post-quantum migration deadline.
- Published target year for full post-quantum migration: {{POST_QUANTUM_MIGRATION_TARGET_YEAR}}.
Algorithm portfolio tracking:
- Every key records the algorithm and key length on the key custody record.
- The portfolio dashboard reports the count of keys per algorithm, the count of keys on sunset algorithms, the count of keys on algorithms scheduled for next-cycle sunset, and the count of keys past their algorithm sunset deadline.
- Keys past their algorithm sunset deadline are findings on the engagement record with the named owner and the SLA tier; the residual count is reported at the quarterly governance review.
Hash function and primitive selection (referenced from the Encryption Standard companion document):
- Password hashing: bcrypt, scrypt, or Argon2id with parameters tuned to the published guidance.
- Key derivation: HKDF, PBKDF2 with appropriate iteration counts, or Argon2id where applicable.
- Authenticated encryption: AES-256-GCM, ChaCha20-Poly1305, or AES-256-CBC with HMAC-SHA-256 using separate keys.
- Signature: RSASSA-PSS, ECDSA, EdDSA (Ed25519 or Ed448), or post-quantum signature per the transition plan.
- Random number generation: cryptographically secure pseudorandom number generators only (crypto.getRandomValues, SecureRandom, /dev/urandom, RandomNumberGenerator.Create, BCryptGenRandom, KMS-issued random where the framework scope requires it).
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 key compromise incident closable on evidence rather than on assertion. PCI DSS 3.7.5 in particular reads against the key custody evidence chain.
Required logs (each item generates audit-readable evidence retained per the audit evidence retention policy):
- Key issuance events with the key identifier (never the value), algorithm, key length, tier, named custodian or operator, ceremony reference where applicable, and timestamp.
- Key state transition events with the prior state, the new state, the transition authority, the rationale, the evidence reference, and the timestamp.
- Key rotation events with the prior identifier, the new identifier, rotation reason, named operator (with custodian quorum where required), verification step, and timestamp.
- Key suspension and reactivation events with the rationale, the named authority, and the timestamps.
- KMS and HSM access events with the key identifier, retriever identity, operation type, scope, and timestamp.
- Cryptographic finding events with the file path or asset reference, primitive category, scanner confidence, scan reference, and timestamp.
- Triage decisions with the classification (confirmed compromise, suspected compromise, anomalous use, false positive), the named triager, the rationale, and the timestamp.
- Compromise response events with the named operator chain, the suspension timestamp, the replacement key reference, the revocation references, the cascade completion timestamps, and the verification result.
- Exception events with the residual rating, the approver, the compensating control, the rationale, the expiry, and the timestamp.
- Algorithm sunset events with the key class, the sunset deadline, the migration plan, the named owner, and the completion timestamp.
- Destruction events with the key identifier, the destruction method, the named operator (with custodian quorum where required), the destruction evidence reference, 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).
- Key ceremony evidence (signed attestations, ceremony scripts, video records where applicable) is retained for the longer of the operational log retention or the regulatory record retention.
- Destruction evidence is retained per the destruction record retention rule the audit evidence retention policy publishes (typically the longer of seven years or the regulatory record retention).
- Closure evidence on compromise incidents 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.
- Retrieval of key metadata for audit (never the value) is itself logged.
- Custodian credentials and ceremony evidence access is restricted to the named custodian roster and the audit function.
Reporting:
- Operational dashboards (open finding count by severity and tier, key portfolio by algorithm and lifecycle state, rotation lapse count, sunset algorithm count, exception count, suppression rate) refresh on the cadence the programme owner publishes (typically weekly).
- Governance dashboards (programme trend, framework coverage, exception accumulation, residual cryptographic risk, algorithm sunset progression, post-quantum migration progression) 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, sunset progression) refreshes at the quarterly governance review.
- Board read (residual risk from cryptographic exposure, post-quantum migration trajectory, programme maturity progression) refreshes annually or on material change.
11. Review, revision, and acknowledgement
Policy review is what keeps the rule current with the cryptanalytic state of the art, the regulatory horizon, and the operational estate. 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 and the cryptography subject-matter expert, 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 effective date, NIS2 transposition status, EU AI Act cryptographic expectations, a US state privacy law, a sectoral cryptographic rule).
- A NIST update to SP 800-57, SP 800-131A, SP 800-175B, or an adjacent SP that materially changes the cryptographic guidance.
- A new FIPS 140-3 module level or specification cycle that affects the assurance the policy points at.
- A new HSM or cloud KMS adoption or migration.
- A new PKI deployment or migration.
- A new BYOK customer arrangement.
- A cryptographic compromise incident that surfaces a question the policy should have answered.
- An acquisition that adds inherited cryptographic practices.
- The public emergence of a cryptanalytic result against a primitive the policy permits.
- The entry into operational standards of a post-quantum algorithm the firm is committing to.
- A customer audit or third-party audit that requires the firm to demonstrate stricter cryptographic discipline.
- A material change to the operational owner role or the CISO role with a different policy interpretation.
Revision process:
1. Policy owner drafts revision; redline against current version with input from the cryptography subject-matter expert.
2. Operational owner reviews operational impact across HSM, KMS, PKI, and consumer systems.
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}}.
- Cryptography subject-matter expert: {{CRYPTOGRAPHY_SME_ACKNOWLEDGEMENT}}.
- 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 cryptographic dependencies and BYOK arrangements): {{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.6 (cryptographic keys protecting stored account data) and 3.7 (key management procedures): Sections 2, 4, 5, 6, 7, 8, 10.
- SOC 2 Common Criteria CC6.1 (logical access), CC6.6 (encryption): Sections 2, 3, 5, 6, 7, 10.
- ISO/IEC 27001 Annex A 5.34 (privacy and PII), A 8.5 (secure authentication), A 8.24 (use of cryptography): Sections 2, 4, 5, 6, 7, 9.
- NIST SP 800-57 Parts 1 to 3 (cryptographic key management): Sections 2, 4, 5, 6, 7, 8.
- NIST SP 800-53 IA-5 (authenticator management), SC-12 (cryptographic key establishment and management), SC-13 (cryptographic protection), SC-17 (PKI certificates): Sections 4, 5, 6, 7, 8, 10.
- NIST SP 800-131A (transitions for cryptographic algorithms and key lengths): Section 9.
- FIPS 140-3 (cryptographic module assurance): Sections 2, 5.
- FIPS 197, FIPS 180-4, FIPS 186-5, FIPS 203, FIPS 204 (algorithm standards): Section 9.
- OWASP ASVS V6 (Stored Cryptography), V9 (Communications): Sections 5, 6, 9.
- NIS2 Article 21 (cybersecurity risk management including cryptography): Sections 2, 5, 6, 7, 8, 10.
- DORA Article 8 (ICT risk management) and Article 9 (protection of ICT assets including cryptographic material): Sections 2, 5, 7, 8, 10.
- CISA Secure Software Development Attestation (cryptographic controls): Sections 5, 9.
- 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}}
Cryptography subject-matter expert (where the firm operates a named SME role)
- Name: {{CRYPTOGRAPHY_SME_SIGNATURE_NAME}}
- Role: {{CRYPTOGRAPHY_SME_SIGNATURE_ROLE}}
- Date: {{CRYPTOGRAPHY_SME_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 cryptographic key 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.
Keys live in code or in configuration because the policy never said where they should live
The team commits cryptographic keys 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 tier per key class and the prohibited storage list named explicitly so the rule has a citable source.
Cryptoperiods are implied rather than published
The programme rotates keys when someone remembers to. There is no published cryptoperiod per key class, no tiered rule, no off-cycle trigger list. Keys that should have rotated annually run for three years; KEKs that should have triggered a re-wrap cascade quietly accumulate compromise exposure. The fix is to publish the cryptoperiod per key tier and the off-cycle trigger list so rotation is a scheduled discipline rather than a memory exercise.
Tier 1 keys live outside an HSM because the storage tier rule is unwritten
Root keys, KEKs, and PKI CA signing keys end up in software keystores because the policy never named the storage tier requirement per key class. A reviewer reading the key portfolio sees Tier 1 keys protected by the same assurance as Tier 3 keys. The fix is the explicit storage tier rule in Section 5 paired with the HSM inventory, the cloud KMS inventory, and the prohibited software keystore use cases.
Compromise response gets the rotation cascade order wrong
The team replaces the compromised key but forgets to revoke the certificate the prior key signed, or rolls out the new key but skips the verification step on the consumer system, or destroys the compromised key before the archive cryptoperiod completes for artefacts that still need decryption. The fix is the suspend-replace-revoke-roll-cascade-verify-notify-destroy order in Section 8 codified as the policy rule so every compromise incident follows the same defensible sequence.
Algorithm sunsets accumulate past their published deadline
MD5 password hashes, AES-ECB encrypted blobs, and RSA 1024 signing keys persist in production years after the sunset deadline because the algorithm portfolio is not tracked against the schedule. The audit reads the sunset overflow as a control weakness; the customer audit reads it as a contractual breach. The fix is the algorithm portfolio tracking in Section 9 with sunset overflow treated as a finding on the engagement record with the named owner and the SLA tier.
Custodian roster has not been reviewed since publication
A named HSM root key custodian left two years ago; the roster still names them. A new custodian was added without the dual control or the recorded attestation. PCI DSS 3.7.6 reads the custodian roster directly; the auditor finds the gap immediately. The fix is the annual custodian roster review in Section 11 paired with the offboarding flow that removes departed custodians and the onboarding flow that records replacement custodian attestations.
BYOK arrangements run without a published interface
Customer-managed key arrangements are agreed bilaterally without a published BYOK interface, a published rotation cadence the customer can request, or a published operational impact of customer-initiated revocation. Each customer arrangement is a one-off; the audit cannot read the pattern; the operational team cannot plan capacity. The fix is the published BYOK section in Section 6 with the supported BYOK shape, the customer responsibilities, the firm responsibilities, and the cascade impact named explicitly.
Destruction evidence is implicit rather than recorded
Keys move to a deactivated state and never reach destroyed, or destruction happens without recorded evidence of the destruction method, the named operator, or the destruction timestamp. A reviewer cannot tell whether the key is destroyed or merely forgotten. The fix is the destruction record requirement in Section 7 with the destruction method, the custodian quorum for Tier 1, and the retained destruction evidence per the audit evidence retention policy.
Ten questions the quarterly governance review has to answer
Operational review keeps the programme on top of cryptographic findings, rotation lapses, and exception flow. Governance review answers whether the policy is delivering durable cryptographic 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 cryptographic findings per key 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, custodian-unavailability, exception-pending), and what is the structural fix landing.
3.How many active exceptions are in the register for unrotatable or unreplaceable keys, broken down by residual rating, and how many are approaching expiry within 60 days.
4.What is the rotation lapse count per key tier and per algorithm, and is the underlying scheduling discipline holding.
5.How many keys are still on a sunset algorithm past the published deadline, broken down by tier and by data class, and what is the migration plan for each.
6.How is the post-quantum migration trajectory tracking against the published target year, and which data classes have transitioned to hybrid or to post-quantum primary mode.
7.How many cryptographic compromise incidents occurred in the period, what was the median time to suspension, what was the median time to replacement, and what was the median time to cascade completion.
8.How many keys transitioned through each lifecycle state in the period, and is the count of keys in suspended state longer than the documented threshold within tolerance.
9.How many key ceremonies happened in the period, did each ceremony record the required custodian quorum and the recorded evidence, and were any ceremony deviations recorded with rationale.
10.Has any framework, regulation, HSM, cloud KMS, PKI, BYOK, threat environment, or cryptanalytic announcement 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 cryptographic finding 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 suspension event, the replacement key reference, the cascade completion, the verification result, 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 against connected repositories with rules that detect cryptographic API misuse (hardcoded IVs, AES-ECB usage, MD5 and SHA-1 for sensitive purposes, Math.random for security tokens, predictable seed values, short key lengths in code, broken hash functions in password handling) so the detection surface the policy declares in Section 8 is observable rather than asserted. The repository connections feature carries the encrypted git provider tokens that authorise the scan.
The finding overrides primitive holds the suppression decisions for documentation samples, vetted test fixtures, and false positives with rationale and an expiry on accepted-risk decisions, so the suppression 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, suspension, replacement, cascade, verification, and destruction is observable rather than asserted. The continuous monitoring feature schedules the recurring code scan so cryptographic misuse introduced after policy publication is detected on the published cadence rather than the next manual run.
The document management feature retains the policy file, the key ceremony evidence, the algorithm sunset schedule, the destruction records, and the revision history alongside the operational record, so the policy version and the ceremony evidence in force at any reporting cycle are 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 key custody metadata trail. The compliance tracking feature maps cryptographic 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 and audit 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 operate the HSM itself, does not operate the cloud KMS plane, does not generate keys, does not issue keys, does not rotate keys at the issuing system, does not run a PKI Certificate Authority, does not operate a key ceremony orchestration platform, does not host BYOK material, and does not integrate with Jira, ServiceNow, Slack, SIEM, or SOAR. The cryptographic key issuance, storage, and lifecycle live in the HSM, the cloud KMS, and the PKI; SecPortal carries the operational evidence and the finding lifecycle the policy runs against.