Policy & principles
Set organisational expectations for cryptographic protection, risk ownership, compliance, lifecycle management and transition.
Why governance matters
Strong algorithms do not create strong governance.
An organisation can use modern cryptography and still carry significant risk if ownership is unclear, standards are inconsistent, exceptions are unmanaged, keys and certificates lack lifecycle controls, or teams cannot respond when requirements change.
Governance creates the decision framework around cryptography: what is permitted, who is accountable, how deviations are assessed, how change is prioritised and how leadership gains confidence that material exposure is understood.
Risk lens
Cryptographic governance is not about centralising every technical decision. It is about making sure the organisation knows which decisions require control, who can make them, what evidence supports them and when they must be revisited.
Governance model
What needs to be governed?
The exact operating model will vary, but effective cryptography governance usually needs several connected capabilities.
Standards & baselines
Define approved and restricted algorithms, protocols, key strengths, certificate practices, key-management expectations and implementation baselines.
Roles & accountability
Clarify responsibilities across security, architecture, PKI, IAM, engineering, infrastructure, risk, procurement, business owners and suppliers.
Risk & exceptions
Provide a controlled route for deviations: documented rationale, exposure, compensating controls, accountable risk acceptance, expiry and remediation.
Lifecycle oversight
Govern cryptography from design and procurement through operation, renewal, algorithm transition, decommissioning and secure key destruction.
Change & transition
Translate deprecation, vulnerabilities, standards changes and PQC requirements into prioritised, owned and measurable transformation plans.
Third-party governance
Set expectations for vendor cryptography, transparency, supportability, transition capability, contractual obligations and remediation timelines.
Assurance & reporting
Use evidence, metrics, testing and risk reporting to determine whether governance expectations are operating effectively.
Policy hierarchy
Separate direction from implementation detail.
A useful governance structure avoids putting every algorithm choice into a high-level policy. Requirements can be layered so they remain maintainable as technology changes.
StrategicCryptography Policy
Why cryptography is governed, scope, principles, accountability, risk expectations and mandatory organisational outcomes.
ControlCryptographic Standards
Approved or prohibited algorithms, protocols, key strengths, certificate requirements, key-management controls and transition rules.
OperationalProcedures & Patterns
How teams implement requirements in specific platforms, services, development patterns and lifecycle processes.
DecisionExceptions & Risk Acceptance
How temporary deviations are assessed, approved, monitored, time-bounded and ultimately remediated.
Decision rights
Ownership should exist at more than one level.
Policy ownerMaintains the organisation-wide cryptography governance framework and ensures alignment with security and risk strategy.
Technical authoritiesDefine specialist standards and patterns for areas such as PKI, key management, protocols, architecture and approved implementations.
System / service ownerUnderstands cryptographic dependencies in the service and is accountable for remediation and lifecycle decisions within that environment.
Risk ownerAccepts material residual risk where remediation cannot meet the required standard, within delegated authority and risk appetite.
Risk management / assuranceChallenges evidence, assesses exposure, tracks exceptions and provides an independent view of whether risk is being managed appropriately.
Role names and organisational placement differ. The important outcome is explicit accountability and understood decision authority — not a universal RACI template.
Exception governance
An exception should be a risk decision, not a permanent workaround.
“Legacy system cannot support the required cryptographic standard.”
Governance asks: What is exposed? Why can it not comply? What protects it today? Who owns the residual risk? What is the remediation path? When does the decision expire?
Business justificationWhy the deviation is currently necessary.
Risk assessmentThreat, vulnerability, data sensitivity, exposure, criticality and likely impact.
Compensating controlsMeasures reducing exposure while the exception remains open.
Named accountabilitySystem owner, remediation owner and authorised risk owner.
Remediation planTarget state, dependencies, milestones and blockers.
Expiry / review dateA trigger for reassessment rather than indefinite acceptance.
Risk management evidence
What should Information Security Risk Management expect to see?
Governance becomes credible when policy statements can be connected to evidence. Depending on scope and maturity, useful evidence may include:
Approved cryptographic policy and standardsCurrent ownership, approval, review cycle and traceable requirements.
Cryptographic inventory coverageEvidence that material systems and cryptographic dependencies are being identified and maintained.
Standards compliance viewKnown use of approved, transitional, deprecated or prohibited cryptography.
Exception registerOpen deviations, risk owners, expiry dates, compensating controls and remediation status.
Lifecycle indicatorsCertificate expiry exposure, key rotation status, unsupported components and other material lifecycle conditions.
Transition portfolioPrioritised remediation for algorithm deprecation, platform change and post-quantum migration.
Third-party evidenceSupplier capabilities, contractual commitments, roadmap dependencies and unresolved cryptographic risks.
Management reportingMetrics and risk narratives that show exposure, trend, concentration and decisions requiring escalation.
Metrics & KRIs
Measure exposure and decision quality — not activity alone.
Counts can help, but a large inventory or number of completed scans does not itself demonstrate resilience. Metrics should support risk decisions.
CoveragePercentage of critical services with validated cryptographic inventory and named ownership.
Standards exposureCritical dependencies using deprecated, prohibited or soon-to-be-disallowed cryptography.
Exception healthOpen, overdue and repeatedly renewed exceptions; concentration by critical service or technology.
Remediation progressMaterial cryptographic risks with funded plans, milestones and accountable delivery owners.
Change readinessCritical services where cryptographic replacement is constrained by architecture, vendors, hardware or unsupported platforms.
Connection to resilience
Governance turns cryptographic change into a managed capability.
Algorithms and standards will continue to change. NIST's crypto-agility work frames agility as the capability to replace and adapt cryptographic algorithms while preserving security and ongoing operations.
Governance provides the policy, accountability, risk decisions and transition mechanisms that allow that technical capability to operate consistently across an organisation.
Authoritative sources
Further reading
NISTCybersecurity Framework (CSF) 2.0 — GovernNIST CSRCCSWP 39upd1 — Considerations for Achieving Crypto AgilityNIST CSRCCrypto Agility ProjectNIST CSRCSP 800-57 Part 2 Rev. 1 — Key Management Organizations
This page synthesises public guidance through a cryptography risk-governance lens. Organisations should adapt governance to their legal, regulatory, risk and technology context and consult source publications directly for normative or implementation-specific requirements.