Quantum Security Governance: Building a Board-Level Framework

Quantum risk briefings are now common at board level in large organisations. Governance is not. A briefing tells the board that a threat exists. Governance creates a standing risk item, assigns named accountability, defines a reporting schedule, and gives the board the authority to approve material decisions. The gap between "we have briefed the board" and "we have a governance framework" is the gap between awareness and control. For organisations subject to NIS2, the gap also carries personal liability.

This article sets out the framework structure using NIST Cybersecurity Framework 2.0 (CSF 2.0, February 2024) as the primary governance architecture: Govern, Identify, Protect, Detect, Respond, Recover. CSF 2.0's Govern function is the correct vehicle for cryptographic risk governance, and its six-function structure maps directly onto a quantum security programme. For organisations that have already built AI governance programmes under the NIST AI Risk Management Framework (AI RMF), the four AI RMF functions (Govern, Map, Measure, Manage) offer a useful structural analogy for the Govern and Identify layers; the analogy is noted where relevant below. The AI RMF is not the primary architecture for a cryptographic governance programme.

For the CISO board presentation context that supports this framework, see our companion piece on the quantum risk board agenda for CISOs. For the financial case that informs the Measure function, see the CISO quantum security investment case for 2026.

Why a Briefing Is Not a Framework

The National Association of Corporate Directors (NACD) Cyber Risk Director's Handbook specifies that board oversight of cybersecurity requires structured, documented governance: defined risk ownership, regular reporting cadences, and board authority over material programme decisions. A single briefing satisfies none of those requirements.

NIST IR 8547 (November 2024) changes the governance calculation. By deprecating RSA (all key sizes), ECDH, ECDSA, DSA, and finite-field DH/DSA for new systems by 2030, with full retirement by 2035, NIST has attached external compliance deadlines to the quantum security risk. The board can no longer treat this as a speculative future threat to monitor. There is a regulatory timeline. There is a defined scope of deprecated algorithms. That requires a programme with oversight, a budget, and a reporting structure, not periodic awareness briefings.

NIST CSF 2.0 (February 2024) formalised Govern as a first-class function alongside Identify, Protect, Detect, Respond, and Recover. Quantum security governance maps directly onto all six. CSF 2.0 is also the governance vocabulary that aligns with SEC 17 CFR 229.106 cyber disclosure requirements. For organisations that have built AI governance programmes under the NIST AI RMF 1.0, the AI RMF's Govern, Map, Measure, and Manage functions provide an analogous pattern for the accountability and risk-scoping layers; the CSF 2.0 Govern and Identify functions cover the same ground and are the correct reference for cryptographic programme governance.

Govern: Ownership and Accountability

A quantum security governance framework requires named accountability at three levels. At board level: a nominated director or audit committee chair who owns the risk item and has authority to approve programme budget and escalation decisions. At executive level: the CISO as programme owner, with a direct reporting line to the board-level owner. At operational level: a designated Quantum Security Programme Manager who owns day-to-day execution, vendor management, and the cryptographic inventory.

Without named accountability at all three levels, the programme stalls at coordination points. Budget approvals sit unclaimed. Vendor contract sign-offs wait for the person who has authority. Regulatory notification decisions escalate without a clear decision-maker. The three levels are not hierarchy for its own sake.

ISO 27001:2022 Clause 5.1 requires top management to demonstrate leadership and commitment to the information security management system. For quantum security specifically, this means the board cannot delegate risk ownership entirely to the CISO. Three board-level approvals create the documented governance record an auditor can assess:

• Approval of the quantum security risk item on the corporate risk register (establishing that the risk has been formally identified at board level)
• Approval of the risk treatment plan under Clause 8.3 (authorising the migration programme and its budget envelope)
• Approval of information security objectives under Clause 6.2 (setting measurable programme targets that the CISO reports against)

For organisations subject to NIS2, the governance obligation goes further than ISO 27001 best practice. NIS2 Directive Article 20 requires that the management bodies of essential and important entities approve the entity's cybersecurity risk management measures and oversee their implementation. Article 20(2) creates personal liability for management body members for infringements. The quantum security risk treatment plan must be approved at management body level. This is a statutory requirement, not a governance recommendation.

Map: What the Framework Must Cover

A quantum security governance framework needs a defined scope: the set of systems, data categories, and third-party relationships within the programme boundary. The minimum scope for most organisations includes four categories:

• All public-key cryptographic infrastructure: PKI, certificate authorities, TLS termination points, and any system that issues or validates digital signatures
• All key management systems: KMS platforms, HSMs, key escrow services, and any system that generates, stores, or distributes cryptographic keys
• All data stores classified as long-lived sensitive data: data whose required confidentiality lifetime extends beyond the organisation's estimated quantum migration window
• Third-party and supply chain cryptographic dependencies: SaaS vendors, cloud providers, and critical suppliers with access to sensitive data, whose cryptographic posture the organisation cannot directly control but whose failures would affect the organisation

A scope that excludes supply chain dependencies will be incomplete for most organisations. The majority of HNDL-relevant data exposures travel through third-party interfaces that the organisation encrypts but does not operate. Applying Mosca's inequality to scope decisions: if the time to complete migration (X) plus the confidentiality lifetime of the data a supplier handles (Z) exceeds the time to CRQC capability (Y), that supplier relationship is within the programme boundary regardless of whether the organisation controls the supplier's cryptographic infrastructure.

The Cryptographic Bill of Materials (CBOM) is the Map function deliverable. NIST NCCoE SP 1800-38B (2024) defines the CBOM methodology: a structured inventory of all cryptographic algorithms in use, key sizes, modes, versions, the systems they protect, and the libraries implementing them. The board's approval of the quantum risk programme should include approval of CBOM resourcing as the first programme deliverable. The CBOM is not a later step in the migration programme. It is the prerequisite for knowing what the programme scope actually is.

Measure: Board-Level Metrics

Board-level metrics must translate programme execution into indicators that a director who is not a cryptographer can read and act on. Four lagging indicators provide the core dashboard:

1. CBOM coverage rate: Percentage of in-scope systems with a completed cryptographic inventory. At programme start this is 0%. The first governance cycle should show measurable progress.
2. Hybrid deployment rate: Percentage of highest-risk data flows (as classified by the CBOM) with hybrid key exchange deployed: X25519 combined with ML-KEM-768 for commercial TLS (IETF RFC 9496), or ECDH P-384 combined with ML-KEM-1024 for National Security System environments.
3. Legacy algorithm retirement rate: Percentage of in-scope systems where RSA or ECC key establishment has been replaced by ML-KEM (FIPS 203).
4. Supplier PQC roadmap coverage: Percentage of critical suppliers with a confirmed, documented PQC migration timeline that the organisation has reviewed and accepted.

Three leading indicators should sit alongside the lagging metrics. Programme schedule variance shows whether the migration is tracking against the internal roadmap. A regulatory watch item flags new guidance from NIST, NSA, NCSC, ENISA, or sector regulators that changes programme scope or timeline; NIST IR 8547 was published November 2024 and further guidance is expected as the NIST PQC programme continues. An incident signal tracks any quantum-adjacent event in the sector: cryptographic weakness exploited, KMS vendor compromise, nation-state signals collection activity reported by a peer organisation.

Risk quantification for budget approval decisions requires a financial frame. The relevant ratio is migration programme cost versus expected loss from failure to complete migration before Q-Day. The probability component uses the GRI 2024 estimate of meaningful CRQC probability from 2030 onwards, with the 2030 to 2037 range covering the primary expert window. The exposure component is the commercial, reputational, or regulatory cost of HNDL-collected data being decrypted. For most organisations with material volumes of long-lived sensitive data, the expected loss calculation substantially exceeds the programme cost. That ratio is the basis for the board's budget approval decision.

Manage: Cadence and Escalation

Governance cadence for a quantum security programme should follow this schedule:

• Board or audit committee: Quarterly in the first two years of the programme (while the CBOM is being completed and initial hybrid deployments are underway), then annual once the programme is in steady-state execution. The quarterly schedule reflects the rate of regulatory change and the pace of early programme decision-making.
• CISO to board: Progress against the four lagging indicators plus any regulatory updates at each quarterly cycle. The format should be consistent across cycles so that trend visibility is clear.

Four escalation triggers require immediate board notification outside the standard reporting cycle:

1. Discovery of an HNDL-relevant data exposure not previously captured in the programme scope
2. Confirmation that a critical supplier's key management system has been compromised
3. Regulatory enforcement action in the sector related to cryptographic posture
4. Material programme delay exceeding 12 months against the approved roadmap

The audit committee has a specific role distinct from full board oversight. It should oversee the CBOM as a financial reporting risk (cryptographic posture affects the organisation's ability to protect material non-public information and financial transaction integrity); receive and assess the annual third-party assessment of the quantum security programme; and confirm that quantum risk appears in the enterprise risk register with current probability, impact, and mitigation status.

Regulatory Obligations by Jurisdiction

The five-element governance framework satisfies the minimum regulatory requirements across three major jurisdictions without requiring jurisdiction-specific customisation.

United Kingdom. The NCSC published phased PQC migration timelines in March 2025, recommending that organisations begin migration planning now and complete high-risk system migration by 2031. Organisations subject to the NIS Regulations 2018 (CNI operators and relevant digital service providers) have proportionality obligations under those regulations that the quantum risk programme must address. The programme charter and board approval process create the documented evidence posture for NIS assessment.

European Union. NIS2 Directive Article 21(1) requires appropriate and proportionate technical and organisational measures for managing risks to network and information systems. Commission Implementing Regulation (EU) 2024/2690 specifies risk management measures for essential entities in more detail, including requirements for cryptographic policies. For DORA-regulated financial entities, Article 9 requires ICT security policies that encompass cryptographic controls. The board-approved risk treatment plan and the CBOM are the primary evidence documents for NIS2 and DORA assessment.

United States. The SEC cyber disclosure rule (17 CFR 229.106, effective December 2023) requires public companies to describe their cybersecurity risk management processes and governance in annual 10-K filings. A board without a documented quantum security governance framework carries disclosure risk if this gap is identified in an audit or external assessment. NIST CSF 2.0 (February 2024), which introduced the Govern function as a first-class element of the framework, provides the governance vocabulary that aligns with SEC disclosure requirements.

The Five-Element Checklist

A board-level quantum security governance framework requires five elements. Each maps to one or more regulatory obligations. An organisation with all five in place has a defensible governance posture against NIS2 Article 20, ISO 27001 Clause 5, and SEC 17 CFR 229.106.

The checklist is designed to be presented directly in a board governance paper. Each element is independently verifiable: either the risk register entry exists or it does not; either accountability is named in writing or it is not. The five-element assessment takes a board secretary approximately two hours against existing documentation. That gap assessment is the starting point for the programme charter.