PQC Governance: Who Should Lead Your Post-Quantum Migration, and How to Structure the Program

Introduction

Every organization that begins a post-quantum cryptography (PQC) migration program hits the same question within the first month: who owns this?

I watched two financial services organizations answer that question wrong in the past week alone. Both had planned to begin their PQC programs in early 2026. Both have now pushed their start dates to the end of the year. The technical readiness was there in both cases, the budget was provisionally allocated, and senior leadership understood the regulatory deadlines. What was missing was governance clarity: no single executive owned the program, no one had authority to convene the cross-functional resources the program needed, and the result was months of internal committee discussions that produced nothing except a later start date.

I have built the PQC Migration Framework and worked with enterprises across financial services, telecommunications, defense, and critical infrastructure on PQC migration programs over the past years. Before PQC, I spent large part of my career leading large-scale technology and security transformations with program budgets reaching $500 million (including nation-level transformations). The governance dynamics are different in detail but identical in structure: programs with a single accountable executive who holds the mandate and resources to deliver will produce results. Programs where ownership is shared, contested, or left deliberately ambiguous will produce PowerPoints. I have not yet seen an exception to this.

This article lays out the governance model that works: a single accountable executive (typically the CISO, but not necessarily), a cross-functional steering committee, a dedicated program office, and specialist execution teams. It explains why this structure aligns with the regulatory consensus, what the accountable executive needs to succeed, and which failure patterns to avoid.

Where Regulators Place PQC

A governance model should align with the regulatory frameworks the organization must comply with. So where have regulators positioned PQC migration? The answer is consistent across every major jurisdiction: within cybersecurity and ICT risk governance, not in some new or separate domain.

In the United States, NIST released the initial public draft of CSWP 48 in August 2025. That document maps PQC migration capabilities directly to the NIST Cybersecurity Framework 2.0 and SP 800-53 Rev. 5 security controls, expressing PQC migration as auditable cybersecurity risk outcomes. NIST’s crypto-agility guidance (CSWP 39, finalized December 2025) defines crypto-agility as a capability integrated into enterprise cybersecurity risk management. The Quantum Computing Cybersecurity Preparedness Act is a cybersecurity law by name and by content. The Department of Defense CIO memo of November 2025 directed PQC migration leads to report through the CIO’s cybersecurity chain. CISA’s own PQC readiness guidance calls for CISOs to lead cryptographic inventory and migration planning.

In the European Union, DORA’s ICT risk management regulatory technical standards require financial entities to monitor cryptographic threats “including threats from quantum advancements” and update their cryptographic technology accordingly. A peer-reviewed analysis concluded that DORA encompasses PQC migration as part of ICT risk management, not as a separate category. The proposed NIS2 amendment (COM(2026) 13) would add PQC transition planning as a named obligation within Member States’ national cybersecurity strategies. IBM’s own DORA analysis maps PQC requirements to DORA Articles 8 and 9 on ICT risk management.

Singapore’s MAS Technology Risk Management Guidelines treat cryptographic risk as a component of technology risk management, placing quantum-related cryptographic threats within the same governance structures that manage other ICT risks.

Australia’s Cyber Security Act and SOCI framework govern PQC preparedness through critical infrastructure resilience requirements, and ASD/ACSC’s PQC planning guidance advises organizations to begin transitioning now, with traditional asymmetric cryptography ceasing by the end of 2030.

None of these frameworks carve out a separate “quantum risk” governance category. They consistently treat quantum-based cryptographic threats as a subset of cybersecurity and ICT risk.

I stress the regulatory alignment because the alternative is expensive. I have seen organizations waste months inventing bespoke PQC governance structures with no regulatory precedent. When their auditors, regulators, and insurance underwriters showed up expecting PQC to sit within existing cybersecurity risk management, the whole exercise had to be unwound. Aligning governance with regulatory expectations from the start avoids that detour.

The Governance Model

Every successful PQC program I have seen shares four structural features. I will spend the most time on the first, because it is where programs most often go wrong.

One Accountable Executive

Every program that delivered results had a single named executive who owned those results. In most organizations, this is the CISO or a direct report: a Deputy CISO, an enterprise security architect, or the head of security risk management. In some organizations with a strong CTO function, the CTO serves as executive sponsor with the CISO as primary program leader.

The title matters less than the accountability. Exactly one person must answer to the board for program outcomes, control the program budget, and have the authority to convene engineering, IT, procurement, legal, and business unit leaders when the program needs them. In my PQC program plan analysis, I call this a “PQC Migration Lead or PQC Czar, with authority across security, IT, engineering, procurement, and OT.” Without that role, cryptography remains embedded in every system and owned by nobody.

Why does this role map most naturally to the CISO? Because the CISO already owns the adjacent domains: cryptographic risk management, PKI operations, vulnerability management, vendor security assessment, regulatory cybersecurity compliance, incident response for cryptographic failures. PQC migration extends these existing responsibilities.

“But the CISO Is a Second-Line Function”

One objection I heard, particularly from people with strong risk governance backgrounds, is that assigning PQC migration to the CISO violates the Three Lines of Defence (3LoD) model. In this framing, the CISO is either a 1B function (providing policy and oversight within the first line, typically under the CIO) or a second-line function (sitting under the CRO with independent risk oversight authority). Either way, the argument goes, the CISO’s role is governance and policy, not operational delivery. Putting an oversight function in charge of a multi-year execution program compromises independence.

The framework is sound in theory. In practice, it assumes a single model of the CISO role that does not exist.

I have assessed technology risk governance structures across financial institutions on four continents, and the variation in how organizations position the CISO within the 3LoD is enormous. In one top-10 US bank, the CISO reported to both the CIO and a Chief Technology Risk Officer in the second line, operating as a pure oversight function. In a leading global custodian, the CISO sat in the second line but explicitly took on first-line operational responsibilities, with KPIs tied to security operations projects and budgets. In a global investment bank, there was effectively no second line for technology risk at all; the CISO operated entirely within the first line under the CIO. In a European universal bank that had suffered several large-scale breaches, the CIO reported to the CISO, who owned all infrastructure. That model was eventually reversed, but it illustrates how far the role can stretch. In yet another universal bank, federated business-unit CISOs reported to a Chief Information Risk Officer, who in turn reported to both the group CIO and group CRO. In an ASEAN bank, the CISO reported directly to the board.

And even where the org chart shows the CISO reporting to a CIO or CRO, the actual authority is often broader than the reporting line suggests. In several banks I have assessed, CISOs who formally sat under the CIO were also given the standing ability to convene the relevant board committee independently. That convening authority gave them a level of independence and executive access that their reporting line alone did not reflect. Anyone looking at the org chart would see a second-line function; anyone watching the CISO operate in practice would see someone with first-line operational authority and board-level reach.

Six banks, six completely different CISO positionings, and even those org charts understated the real authority the CISO exercised in practice. The CISO who runs PKI operations, manages HSM infrastructure, and oversees security engineering teams is not a pure second-line function. That CISO is already first-line for cryptographic infrastructure. Asking them to lead the PQC migration of that same infrastructure is an extension of existing operational ownership, not a governance violation.

The right response to a challenge that outgrows an existing role is to expand and enable the person best positioned to lead it, not to invent new positions that have no regulatory precedent, no governance framework behind them, and no institutional credibility. We don’t need a new chair. We need to give the right person a bigger table.

Think about how every major security transformation of the past decade was governed. When enterprises rushed to cloud adoption in the early 2010s, misconfigurations and data exposure were epidemic. The response was not to create a new “Chief Cloud Risk Officer” outside the CISO’s remit. It was to expand the CISO’s mandate, give them a seat in cloud platform decisions, and build cloud security engineering teams within the security organization. OT security integration followed the same playbook. DevSecOps required the same expansion of mandate. GDPR’s technical compliance requirements demanded it again. In each case, the CISO’s authority and resources expanded to match a new domain, because the alternative (creating a parallel security governance structure) introduces more problems than it solves.

A Cross-Functional Steering Committee

PQC migration touches network engineering, application development, cloud architecture, procurement, legal, compliance, operations, and often OT and IoT environments. No single function can execute it alone. The Steering Committee gives all of these functions a voice in decisions without diffusing accountability.

I recommend a committee chaired by the accountable executive, meeting monthly in early phases and quarterly once the program is running, with standing membership from the CIO, CTO, Chief Data Officer, General Counsel, a CFO delegate, and heads of engineering and operations. This committee approves scope, budget allocation, risk acceptance, and vendor strategy. It does not manage day-to-day execution.

The critical design principle is a strict division of authority: the Steering Committee approves the risk tolerance envelope, the funding allocation, and the scope boundaries. The accountable executive decides technical strategy, migration sequencing, and operational mandates within those boundaries. If the committee is debating which TLS library to migrate first or has veto power over execution mechanics, you have governance by consensus, and consensus is where multi-year programs go to die.

A Dedicated Program Office

PQC migration at enterprise scale involves thousands of dependencies, multi-year timelines, and coordination across every business unit. It requires a Program Management Office (PMO) with dedicated staff (typically 3-8 FTEs at peak for a large enterprise) who own the integrated master schedule, dependency tracking, status reporting, and board materials.

This cannot be an addition to someone’s existing job. If the “program office” is one person juggling PQC on Fridays between SOC escalations and vulnerability reviews, you do not have a program office. I have seen programs collapse because the designated “PQC lead” was simultaneously running the SOC, managing the vulnerability program, and handling incident response. A program with potentially over 120,000 discrete tasks needs dedicated program management capacity.

Specialist Execution Teams

Beneath the governance structure, four types of teams do the work.

A cryptographic engineering team owns the central PQC library, architecture standards, hybrid deployment strategy, and protocol design. These people are specialists in ML-KEM (formerly CRYSTALS-Kyber), ML-DSA (formerly CRYSTALS-Dilithium), and SLH-DSA (formerly SPHINCS+), the three finalized NIST PQC standards, as well as FN-DSA (formerly FALCON), which remains in the standardization pipeline. They are not SOC analysts or threat hunters repurposed for algorithm work. Organizations that lack this talent should hire or contract for it.

Real-world programs at scale are already validating this division of labor. Meta’s April 2026 PQC migration framework details a structured, multi-year program with explicit maturity levels, hybrid deployment strategies using ML-KEM and ML-DSA, and dedicated specialist teams for cryptographic engineering separate from standard application operations.

Federated application migration pods (small cross-functional teams combining developers, QA, and a security liaison) within business units handle their own system migrations on agreed timelines and standards, reporting progress to the PMO.

A vendor and supplier liaison function, embedded in procurement, manages vendor PQC readiness assessments, contractual requirements, and the vendor commitment register.

Internal audit and risk provides independent verification and reports to the audit committee.

What the Accountable Executive Needs

Assigning ownership is the first step, not the last. The executive who leads PQC migration needs four things that most organizations fail to provide.

Board-Level Mandate

The CISO (or whoever holds the role) must have board authorization to run PQC migration as a multi-year transformation program, with direct reporting to the board or risk committee on progress. Without this, competing priorities will continuously starve the program. The board mandate should reference specific regulatory timelines: CNSA 2.0’s January 2027 deadline for new National Security Systems (NSS) acquisitions, NIST’s FIPS 140-2 deprecation in September 2026 (now four months away), and the EU’s target of high-risk system migration by 2030.

A Dedicated Program Budget

This is where many programs stall. Traditional cybersecurity spending is largely operational expenditure: licenses, monitoring, staff, patching cycles. PQC migration requires significant capital expenditure: HSM upgrades, PKI infrastructure replacement, protocol re-engineering, application refactoring, potentially years of parallel hybrid operation.

The solution is a separate, ring-fenced budget with CapEx and OpEx components, approved by the board through the Steering Committee. I have written about how CISOs can frame the PQC business case by positioning quantum readiness as an opportunity to fix long-standing cryptographic debt, improve asset visibility, and demonstrate regulatory compliance readiness.

The budget challenge is real, but it is a budget problem, not a governance problem. You solve it by restructuring the budget to match the program’s needs, not by moving ownership to a different executive.

Cross-Functional Authority

The accountable executive needs authority (granted by the CEO or board) to convene engineering, IT operations, procurement, legal, and business unit leaders for PQC decisions. This authority flows through the Steering Committee, not through unilateral command. But it must be real authority. When the PQC program needs a change window, a vendor contract modification, or an application freeze for migration testing, the program lead must be able to obtain it without relitigating the program’s mandate each time.

Cryptographic Engineering Talent

PQC migration demands specialized knowledge that most security teams do not currently possess: lattice-based cryptography, hybrid protocol design, certificate lifecycle management at scale, performance engineering for larger key and signature sizes. I have written a detailed analysis of the skill stack needed for crypto-agility and quantum readiness.

A skills gap is solved by hiring and training, not by reassigning governance. The program governance role (strategic planning, stakeholder management, regulatory alignment, vendor management) maps well to existing CISO competencies. The cryptographic engineering roles are specialist positions that should be filled with dedicated talent. A CISO overseeing OT security does not personally configure PLCs. A CISO running a cloud security program does not write Terraform policies. The same model applies here: the CISO governs, the specialists execute.

How PQC Programs Actually Fail

The failure patterns in PQC programs are not new. I have seen every one of them before in other large-scale transformations: the nation-level payments program where three ministries shared ownership and none delivered, the electronic health records implementation where the vendor was expected to solve governance problems the client had not resolved, the security transformation that stalled for eighteen months because the board approved the budget but never named an accountable executive. PQC adds cryptographic complexity on top, but the governance failures are the same ones that have killed major programs for decades.

Four patterns repeat across industries. I spend the most space on the last because it is the one doing the most damage right now.

Treating PQC as a Vendor Problem

IBM’s “Secure the Post-Quantum Future” report found that 62% of executives were waiting for vendors to make them quantum-safe. As I detailed in why quantum readiness is not just a vendor problem, this mentality delegates accountability for an enterprise-wide transformation to parties with no visibility into your cryptographic estate and no incentive to prioritize your timeline.

Underfunding

Running PQC migration on the security operations budget is like funding a building renovation from the janitorial supplies line. The scope, timeline, and capital requirements are categorically different. If the board has not approved a dedicated multi-year budget, the program will never progress beyond the discovery phase.

Governance by Committee

When the CIO, CTO, and CISO all “share” PQC responsibility, none of them own it. Decisions require consensus among peers with competing priorities, and the program moves at the speed of the most reluctant participant. The two financial services organizations I mentioned at the top of this article were both stuck in exactly this pattern. Both had all three executives “engaged.” Neither had one executive accountable.

Governance Confusion: The “Not the CISO” Trap

As PQC migration attracts more money and executive attention, it has also attracted a wave of self-proclaimed transformation experts. Some bring genuine experience. A growing number are consultants and commentators who have repackaged AI-generated content into confident-sounding LinkedIn posts and slide decks without doing the basic work of reading the regulatory texts they cite, verifying the claims they repeat, or testing their governance recommendations against an actual enterprise program. Their audience (CISOs and board members trying in good faith to get PQC right) deserves better than secondhand analysis dressed up as expertise.

One piece of advice that keeps surfacing is that CISOs and cybersecurity teams should not lead PQC migration. The argument typically runs: cryptographic estates are in poor condition, CISOs presided over the decline, therefore CISOs should not lead the rebuild. Quantum risk is framed as categorically separate from cyber risk, with claims that major regulators treat the two as distinct governance domains. The recommended alternative is left vague or unspecified altogether.

The regulatory claim is wrong. As the analysis above shows, every major framework (NIST CSWP 48, DORA, the proposed NIS2 amendment, MAS, SOCI) places PQC squarely within cybersecurity and ICT risk governance. No regulator has created a separate “quantum risk” governance category. The people making this claim either have not read the regulatory texts or are misrepresenting them.

The logic is also flawed. Many organizations do have poor cryptographic hygiene: unmanaged keys, certificate sprawl, legacy protocols, hardcoded secrets, weak inventories. I have written about this at length. But concluding that “the people who managed the problem shouldn’t fix it” would, if applied consistently, paralyze every organization on earth. Improving that hygiene is precisely part of the expanded mandate the CISO role has absorbed in every prior major transformation. Software security was poor before DevSecOps. Cloud security was poor before cloud security teams were built. In each case, security leadership received better tools, expanded authority, and dedicated resources. That is how institutional capability improves.

The most damaging version of this advice tells organizations that PQC requires a new governance model without saying what that model should be. The board hears “this is bigger than cyber” and agrees. Then the question: who, then? The CTO? The CTO’s team manages technology platforms, not security risk. The CIO? IT operations and delivery. A Chief Transformation Officer? A newly created “Chief Cryptographic Officer”? None of these roles exist in standard corporate governance frameworks. None have institutional relationships with security vendors, cryptographic technology providers, or the regulatory bodies issuing PQC mandates.

The result, every time I have watched it play out: nobody owns it. The program enters limbo. Months pass. The organization has spent its time debating governance structures instead of running cryptographic discovery. Those two financial services organizations I opened with? Same dynamic. The governance ambiguity did not arise in a vacuum. People read advice like this and conclude that they need to “solve the governance question first” before they can start the actual work. So the work never starts.

My advice to CISOs and board members: when someone tells you not to let your CISO lead PQC, ask who should lead it instead. Ask for a specific name, title, mandate, and program structure. If the answer is vague, treat it accordingly.

Be cautious about PQC governance guidance from anyone who has not built and delivered a PQC migration program in a real enterprise. The sources worth trusting are national security agencies, regulators, and standards-setting bodies: NIST, CISA, NSA, ENISA, the UK NCSC, Singapore’s MAS. These organizations build their positions through years of structured expert consultation, multi-stakeholder review, and operational testing. Their consensus places PQC within cybersecurity governance. They did not arrive at that conclusion carelessly, and a LinkedIn post does not constitute a rebuttal.

Getting Started

For organizations beginning their PQC governance journey, the sequence below matters more than the pace. But do not artificially gate later steps on earlier ones. These can and should overlap.

Secure the board mandate. Brief the board or risk committee on regulatory deadlines and Harvest Now, Decrypt Later (HNDL) risk. Name the accountable executive. Secure the initial program budget.

Stand up governance. Form the Steering Committee. Define the program operating model and reporting cadence. Begin recruiting or contracting cryptographic engineering specialists.

Launch discovery. Start building the cryptographic inventory. Discovery can begin before the Steering Committee has its first meeting, and before you have hired your cryptographic engineering team. Discovery generates the data that makes every subsequent decision sharper, so starting it early compounds.

Build the roadmap. Complete the first-year plan as outlined in my practical steps guide. Begin vendor assessment. Initiate PKI and HSM evaluation.

The PQC Migration Framework provides the complete open-source methodology. My Getting Started Deep Dive series walks through each phase in detail. For organizational leaders who want a comprehensive resource on readiness strategy, Quantum Ready covers the full picture from governance through execution.