How to Structure a Quantum Security Steering Committee

The organisations that are furthest ahead on post-quantum cryptography migration are not necessarily the ones that started earliest. They are the ones that resolved the governance question earliest. Who owns the algorithm selection decision? Who can approve an HSM replacement budget? Who signs off on the migration sequencing plan when engineering, legal, and procurement all have conflicting priorities? Without a defined governance structure, those questions get escalated or deferred indefinitely. A quantum security steering committee is the mechanism that resolves them.

This is not a theoretical governance exercise. FIPS 203, FIPS 204, and FIPS 205, the NIST-standardised post-quantum algorithms for key encapsulation and digital signatures, were finalised in August 2024. NIST IR 8547 IPD (November 2024) established 2030 as the deadline for ceasing new deployments of RSA, ECDH, and ECDSA, and 2035 as the point at which those algorithms become disallowed regardless of use case. NIS2 Article 21(2)(h) already requires cryptographic measures as part of the cybersecurity risk management framework for organisations in scope, with transposition required by October 2024. The standards are ready. The regulatory obligations are in force. What most large enterprises are missing is the governance structure that converts those obligations into a managed programme.

This guide sets out a reusable model: recommended composition, meeting cadence, RACI assignment, charter elements, and how to tie the committee's mandate to the regulatory deadlines already on the organisation's radar. Before a committee can be formed, the organisation needs a baseline view of its cryptographic exposure. The Quantum Threat Exposure Assessment provides that starting point.

Why a Steering Committee Is the Right Governance Mechanism

PQC migration cannot be owned by a single team. It touches every system that uses public-key cryptography: TLS endpoints, code signing pipelines, PKI infrastructure, VPN gateways, HSMs, SaaS integrations, and application-layer encryption. Across a typical enterprise, those systems span engineering, security, legal, procurement, and finance. No single team head holds authority across all five functions.

A steering committee provides three things a project team alone cannot.

Cross-functional decision authority. Budget approval for HSM replacement requires finance and procurement input that the CISO cannot unilaterally provide. Algorithm selection carries legal liability implications that General Counsel needs to review. A committee that seats all four functional leads removes the approval bottleneck that stalls most enterprise migration programmes in their early phases.

Executive accountability. An executive sponsor at CTO or CISO level ties the programme to strategic objectives and ensures it survives budget compression. NCSC's PQC migration guidance and NIST IR 8547 IPD both frame migration as a programme-level commitment that requires senior ownership, not a technical project that can be handled below the CISO waterline.

Board visibility. Quantum security risk has reached the threshold where boards need a line of sight to migration status and residual risk. A board liaison on the committee creates the reporting path without requiring the executive sponsor to personally brief the board on every technical milestone. The Board Quantum Security Business Case guide covers how to frame the investment case at that level.

Recommended Committee Composition

Five seats are the minimum. Extended composition for regulated sectors is covered below.

1. Executive sponsor: CTO or CISO (Chair). Owns the programme at executive level. Signs off on capital investment above the committee's approval threshold. Reports to the board or audit committee on migration status and residual risk. The CTO is the appropriate chair when the migration is primarily an infrastructure and engineering transformation. The CISO is appropriate when regulatory and security risk framing is the primary driver, as it is for most financial services and healthcare organisations. The CISO Quantum Security Investment Case 2026 covers the budget justification arguments the executive sponsor is most likely to need.

2. Regulatory and legal lead: General Counsel or Chief Compliance Officer. Translates regulatory obligations into programme scope. NIS2 Article 21(2)(h) requires that cybersecurity risk management measures address cryptographic requirements. DORA Article 6 addresses the ICT risk management framework, Article 9 addresses protection and prevention measures (including cryptographic controls), and Articles 24-27 govern advanced digital resilience testing (TLPT) for EU and EEA financial entities. DORA does not bind UK-only financial institutions; UK firms operate under FCA operational resilience requirements (PS21/3) and NCSC guidance. The UK Network and Information Systems (NIS) Regulations 2018 (SI 2018/506) impose equivalent obligations for UK operators of essential services. The regulatory lead must hold both the EU and UK positions clearly, because conflating them produces incorrect compliance conclusions.

3. Engineering lead: Head of Platform or Head of Cryptographic Infrastructure. Owns the technical inventory and migration sequencing. This role must have direct authority over the TLS certificate estate, PKI, HSM fleet, and key management infrastructure. Without an engineering lead who can make technical decisions and hold budget authority for platform changes, migration decisions cannot be implemented. A committee that decides to deploy ML-KEM without an engineering lead who controls the certificate management system will find the decision has no traction at the implementation layer.

4. Procurement lead. HSM replacement is typically the single largest cost component of a PQC migration at enterprise scale, estimated at 15 to 30% of total programme cost. The procurement lead manages vendor selection, RFP processes, and supply chain PQC readiness assessments. This role also owns CBOM (Cryptography Bill of Materials) vendor requirements, including the contractual language requiring vendors to disclose their cryptographic dependencies and migration roadmaps.

5. Board liaison. A non-executive director or designated board secretary who receives quarterly steering committee reports and escalates material risk disclosures to the full board. This is not a decision-making seat. Its value is the reporting pathway it creates: the board receives regular, structured updates rather than ad hoc escalations when something goes wrong.

Extended composition for regulated sectors. Financial services organisations operating under DORA should add a Chief Risk Officer to ensure integration with the operational risk framework under DORA Article 6. Healthcare organisations should add a Data Protection Officer to cover GDPR Article 32, which requires state-of-the-art cryptographic controls. Government and defence organisations should add a security vetting representative for classified system migration, where algorithm selection decisions intersect with national security guidance.

Meeting Cadence

The governance model requires two distinct meeting types with different functions.

Quarterly steering committee (2 hours). This is the decision-making body. The standing agenda should cover: migration programme status against milestones; cryptographic inventory update including new systems discovered and systems migrated; algorithm selection and vendor decisions requiring committee approval; budget review against plan and change requests; regulatory update covering new guidance and upcoming deadlines; and risk register review. The quarterly committee is where decisions are made, not where progress is reported. Keep the reporting brief and the decision time protected.

Monthly technical working group (90 minutes). This is the operational body. It does not make decisions; it prepares decisions for the quarterly committee. Standing agenda: discovery and inventory progress; library and system migration status; vendor engagement and PQC roadmap tracking; HSM replacement programme status; issues requiring escalation to the quarterly committee. The working group is where the engineering lead and their team report ground-level progress. Its outputs feed the quarterly committee's agenda.

The cadence distinction matters in practice. Weekly steering committees produce decision fatigue and distort programme governance by forcing premature decisions on questions that need more information. Quarterly committees without a monthly operational body lose visibility on ground-level progress and tend to be surprised by issues that have been building for three months. The quarterly and monthly split is standard practice for enterprise transformation programmes of this scale.

RACI Matrix Template

A minimal RACI for PQC migration assigns clear ownership for the decisions that most frequently create bottlenecks:

RACI key: R = Responsible (does the work), A = Accountable (owns the outcome), C = Consulted (input required), I = Informed (notified of outcome).

The algorithm selection row deserves particular attention. FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) are the NIST-standardised post-quantum algorithms finalised in August 2024. The committee's algorithm selection decisions should reference these standards explicitly. Decisions that reference only vendor product names without tracing back to the underlying FIPS standards create compliance documentation gaps that will matter when regulators or auditors review migration records.

Charter Elements

A quantum security steering committee charter must define four things explicitly. A charter that omits any of the four will produce governance gaps that surface as committee disputes rather than committee decisions.

1. Scope: the cryptographic estate definition. The charter must define what the committee oversees. At minimum: all systems using RSA, ECDH, ECDSA, or DSA (Category 2 per NIST IR 8547 IPD); all HSMs and key management infrastructure; all TLS-terminating endpoints; all code signing pipelines; all VPN gateways; all API authentication using PKI. SaaS and third-party systems should be in scope for vendor assessment even if they are not directly managed, because a SaaS provider's cryptographic architecture is part of the organisation's effective cryptographic estate.

2. Authority: budget approval thresholds. The charter must specify what the committee can approve versus what requires board or executive escalation. A typical enterprise threshold: the committee approves programme budget changes up to 20% variance or a defined absolute ceiling. Above that, escalation flows through the board liaison. Without explicit thresholds, every material budget change becomes a dispute about whether it requires escalation.

3. Key decisions. The charter must list which decisions the committee owns. Mandatory inclusions: algorithm selection (which FIPS-standardised algorithms to adopt and on what timeline); vendor selection for HSM replacement and PQC library adoption; migration sequencing (which systems migrate in which order and why); and the organisation's position on hybrid mode. Hybrid mode, running classical and post-quantum algorithms in parallel during the transition period, is the standard migration mechanism for TLS and IKEv2. For IKEv2, RFC 9370 (Multiple Key Exchanges in IKEv2, published May 2023) provides the standards basis for hybrid key exchange in VPN infrastructure. This is a published RFC, not a draft.

4. Escalation paths. The charter must define what triggers escalation outside the committee: a critical vulnerability in a deployed algorithm; a CRQC capability announcement from a credible source; a regulatory deadline with no migration plan in place; or a material HSM failure with no quantum-safe fallback. Escalation triggers should be pre-defined in the charter, not improvised when an incident occurs.

Connecting the Committee to Regulatory Deadlines

The committee's mandate is not open-ended. Regulatory deadlines provide the external forcing function that converts a well-intentioned governance structure into a programme with a completion date.

NCSC PQC migration milestones (UK). NCSC guidance establishes planning milestones with 2031 and 2035 as primary action points: high-priority migration for systems handling the most sensitive data should be underway by 2031 (with 2035 as the full migration deadline for all systems). These dates align with NSM-10, the US National Security Memorandum on quantum computing and cryptographic risk signed on 4 May 2022, and with the NIST IR 8547 deprecation timeline.

NIST IR 8547 IPD deprecation timeline. 2030: RSA, ECDH, ECDSA, and DSA deprecated for new systems. 2035: all Category 2 algorithms disallowed regardless of use case. The committee's migration sequencing should be traceable to these specific milestones. A committee that cannot demonstrate a credible path to the 2030 milestone, meaning no new Category 2 deployments after 2030, is not meeting the regulatory intent expressed in NIS2 and DORA.

DORA Article 28 covers ICT third-party risk management for EU and EEA financial entities. SaaS and cloud providers' PQC readiness directly affects the organisation's cryptographic estate boundary. The committee's procurement lead should own the vendor assessment process for third-party cryptographic dependencies, and the committee's regulatory lead should ensure DORA Article 28 compliance requirements are reflected in vendor contracts.

To understand how urgency varies by data type and migration timeline before the committee formalises its programme structure, use the Q-Day Timeline Calculator. The tool makes the Mosca inequality visible for the organisation's specific data profile and migration plan, and gives the committee a defensible quantitative basis for sequencing decisions.

Common Misconceptions

This is an IT security project, not a board-level issue. PQC migration requires capital allocation for HSM replacement, significant engineering resource, and regulatory compliance delivery. At enterprise scale, those decisions need board-level visibility. The committee structure is the mechanism for ensuring they receive it.

The existing security governance committee can handle this. Standard security governance committees do not have the cross-functional decision authority or the algorithm selection expertise that PQC migration requires. The decisions are different in kind, not just in scale. A dedicated committee is the appropriate structure.

DORA means our UK bank has to comply. DORA applies to EU and EEA financial entities. UK financial institutions operate under FCA operational resilience requirements and NCSC guidance. The two frameworks have overlapping intent but different scope and enforcement mechanisms. UK firms should not assume DORA compliance covers their UK regulatory obligations.

The standards need to mature before governance can be established. FIPS 203, 204, and 205 were finalised in August 2024. The standards are ready. Waiting for further standardisation activity before establishing governance adds programme delay without reducing technical risk. The governance structure can and should be established now, with algorithm selection decisions referenced to the current FIPS standards.