The CISO’s Role in PQC Migration: Organizational Models, Three Lines of Defence, and the Authority Question

Introduction

Shortly after publishing my PQC governance overview, I received a detailed response from a transformation leader arguing that the CISO should not lead PQC migration because the role is a second-line oversight function, not an operational delivery function. Under the Three Lines of Defence (3LoD) model, she argued, assigning PQC migration to the CISO confuses governance with execution.

Her framework was sound. Her premise was wrong. Not because the 3LoD model is flawed, but because it assumes a single version of the CISO role that does not exist in practice.

This article maps the actual variation in how organizations position the CISO, explains why that variation matters for PQC governance, and provides a decision framework for determining who should lead PQC migration in your organization. It is part of the PQC Program Delivery Deep Dive series.

The CISO Role Is Not One Role

The IANS Research and Artico Search 2026 State of the CISO Benchmark Report found that 64% of CISOs still report into IT (typically the CIO or CTO). Just 11% report to the CEO, with the remainder split across the CFO (5%), CRO (5%), general counsel (5%), and other business roles. Those percentages describe reporting lines, but they say almost nothing about what the CISO actually does.

A CISO reporting to a CIO at a mid-market manufacturer may manage a team of 12, oversee vulnerability scanning and incident response, and have no authority over infrastructure decisions. A CISO reporting to a CIO at a global bank may manage 2,000 people, own PKI operations, run HSM infrastructure, lead security engineering, and have a standing invitation to the board risk committee. Same reporting line. Completely different role, authority, and operational scope.

The 3LoD model adds another layer of variation. Organizations position the CISO anywhere from pure first line (operating security controls under the CIO) to pure second line (setting policy under the CRO) to a hybrid “1.5 LoD” model that EY describes as positioning the CISO between IT and Risk with dual reporting. European regulators in some jurisdictions actively discourage CISOs from reporting to the CIO, pushing toward second-line positioning under the CRO, while US financial regulators have been more permissive about reporting structures as long as independence can be demonstrated.

Anyone making a blanket statement about whether the CISO should or should not lead PQC migration is talking about a role they have defined in the abstract, not the role as it exists in any specific organization. The question cannot be answered generically. It depends on which CISO, in which organizational structure, with which authority, operating under which governance model.

Six Real-World Models

I have assessed technology risk governance structures across financial institutions on four continents, and the variation in CISO positioning is far wider than any theoretical framework suggests. Here are six models I have encountered, anonymized but structurally accurate.

Model 1: Pure Second-Line CISO

Structure: At a top-10 US bank, the CISO reported to both the CIO and a Chief Technology Risk Officer (CTRO) in the second line. The CISO operated as a pure oversight and policy function. Security operations (SOC, vulnerability management, incident response) sat under the CIO’s first-line technology organization. The CISO set standards, reviewed compliance, and reported risk, but did not operate security infrastructure.

PQC implication: In this model, the CISO should not lead PQC migration execution. They do not own the infrastructure being migrated. The CIO or CTO owns the first-line cryptographic operations (PKI, HSMs, network encryption), and PQC migration is an operational delivery program that belongs in the first line. The CISO’s role is oversight: validating that the migration meets security standards, that the PQC algorithms are correctly implemented, and that the risk posture improves as migration progresses.

Who leads PQC: The CIO or CTO, with the CISO providing second-line assurance and the CTRO integrating quantum risk into the enterprise risk framework.

Model 2: Hybrid 1A/1B CISO

Structure: At a leading global custodian bank, the CISO sat formally in the second line but explicitly took on first-line operational responsibilities. The CISO had KPIs tied to security operations projects and budgets, ran the security engineering function, and operated the PKI infrastructure. The reporting line said “second line.” The operational reality was a hybrid: policy and oversight functions coexisted with direct operational control over security infrastructure.

PQC implication: This CISO already owns the cryptographic infrastructure. Asking them to lead the PQC migration of systems they already operate is an extension of existing responsibility. The 3LoD model says this should not work. In practice, it works well because the person with the most intimate knowledge of the cryptographic estate is also the person with the authority to change it.

Who leads PQC: The CISO, with the enterprise risk function providing independent oversight and the CIO’s application teams handling their own migration pods under the CISO’s program governance.

Model 3: Pure First-Line CISO

Structure: At a global investment bank, there was effectively no second line for technology risk. The CISO operated entirely within the first line under the CIO. Security operations, security engineering, PKI, HSMs, incident response, and security architecture all reported to the CISO, who reported to the CIO. The CRO’s organization handled market risk, credit risk, and operational risk at the enterprise level, but technology risk was the CIO’s domain.

PQC implication: This is the most straightforward model for PQC governance. The CISO owns both security infrastructure and security operations. PQC migration is a natural extension. The risk is that without second-line independence, the CISO may face pressure to cut corners on migration quality to meet the CIO’s delivery timelines. An independent assurance function (internal audit or a dedicated technology risk team) should provide a quality check.

Who leads PQC: The CISO, reporting through the CIO, with internal audit providing independent assurance.

Model 4: Infrastructure CISO (CIO Reports to CISO)

Structure: At a European universal bank that had suffered several large-scale security breaches, the board restructured the organization so that the CIO reported to the CISO. The CISO owned all technology infrastructure, including systems that would normally sit under a CIO. This model was eventually reversed, but for the period it was in place, the CISO had authority over everything from network infrastructure to application platforms to security operations.

PQC implication: This CISO has more authority than a PQC migration program would ever require. The question is not whether they can lead PQC, but whether they have the bandwidth given they also own all of IT infrastructure. A dedicated program office (as described in the governance overview) is essential to prevent PQC from competing with the CISO’s broader infrastructure responsibilities.

Who leads PQC: The CISO, with a strong PMO that shields the program from competing infrastructure priorities.

Model 5: Federated BISO Model

Structure: At another universal bank, federated business-unit CISOs (BISOs) reported to a Chief Information Risk Officer (CIRO), who in turn reported to both the group CIO and the group CRO. Each BISO owned security operations for their business unit. The CIRO set enterprise-wide security strategy and standards. PKI and HSM infrastructure was shared across business units but managed by a central security engineering team under the CIRO.

PQC implication: This model is well-suited to large, complex organizations. The CIRO sets the PQC migration standards and timeline. Each BISO owns their business unit’s application-layer migration. The central security engineering team handles the shared infrastructure layer (PKI, HSMs, network encryption). The challenge, as IBM’s Antti Ropponen noted in discussing the governance overview, is ensuring that LOB engagement happens early and that BISOs have seats on the steering committee.

Who leads PQC: The CIRO at the enterprise level, with BISOs leading business-unit execution and the central engineering team handling shared infrastructure.

Model 6: Board-Reporting CISO

Structure: At an ASEAN bank, the CISO reported directly to the board. The CISO had no intermediate reporting layer between their function and the board risk committee. This gave the CISO complete independence from the CIO’s organization and direct access to board-level decision-making authority.

PQC implication: This CISO has the strongest possible mandate for PQC migration. Board-level reporting means the CISO can escalate resource conflicts, vendor dependency issues, and business-unit resistance directly to the board without filtering through a CIO or CRO who may have competing priorities. The risk is that without a strong operational relationship with the CIO’s technology organization, the CISO may struggle to drive the technical execution that PQC requires.

Who leads PQC: The CISO, with explicit CIO operational partnership formalized in the steering committee charter.

The Authority Gap: Formal vs. Actual

The six models above describe formal reporting structures. The actual authority CISOs exercise often exceeds what the org chart 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. This convening authority was not visible in the organizational chart. It was documented in the board committee charter or in a letter from the board chair. In practice, it meant the CISO could escalate any issue directly to the board without the CIO’s permission, approval, or even knowledge.

Anyone looking at the org chart in those organizations would see a first-line CISO reporting to the CIO. Anyone watching the CISO operate in practice would see someone with independent board access, the ability to override CIO decisions on security grounds, and de facto authority over cryptographic infrastructure decisions. The formal 3LoD positioning and the actual authority were completely different things.

This matters for PQC governance because the question “does the CISO have sufficient authority to lead PQC migration?” cannot be answered by looking at the org chart. It can only be answered by examining the CISO’s actual decision rights: budget authority, convening authority, escalation authority, and the ability to compel cross-functional participation.

When CTO-Led Programs Work Better

The governance overview argues that the CISO is the natural owner of PQC migration in most organizations. That “most” qualifier matters. There are organizational structures where the CTO is the better choice, and CISOs should not take offense at that observation. The goal is program delivery, not title defense.

CTO-led PQC programs work well when three conditions are met.

First, the CTO owns the cryptographic operational estate. If PKI, HSMs, certificate lifecycle management, and key management systems sit under the CTO’s organization (rather than the CISO’s), the CTO has the infrastructure ownership that makes migration operationally straightforward. Asking a CISO who does not operate PKI to lead a PKI migration creates an authority gap that the steering committee will spend months trying to bridge.

Second, the CTO has demonstrated enterprise-wide transformation capability. PQC migration requires the ability to drive change across business units, negotiate vendor dependencies, and force application teams to prioritize migration work alongside their business-as-usual delivery. Not every CTO has this organizational muscle. The ones who have delivered large-scale platform migrations, cloud transformations, or enterprise architecture overhauls have the institutional credibility to drive PQC.

Third, the CISO provides strong second-line oversight. In a CTO-led model, the CISO’s role shifts to validation and assurance: confirming that PQC implementations meet security standards, that the algorithm choices align with regulatory requirements, that the hybrid deployment strategy does not introduce new vulnerabilities, and that the migration does not create gaps in the existing security posture during the transition period.

The worst configuration is assigning PQC to a CISO who does not own the cryptographic infrastructure and lacks the organizational authority to compel the CTO’s teams to execute. That creates accountability without authority, which is how programs produce governance artifacts instead of migrated systems.

A Decision Framework

For organizations deciding who should lead PQC migration, three questions determine the answer.

Question 1: Where does the cryptographic operational estate sit? If PKI, HSMs, certificate lifecycle management, and key management are under the CISO, the CISO leads. If they are under the CTO or CIO, that executive leads (or co-leads with the CISO). If they are split, the executive who owns the largest share of the infrastructure leads, with the other providing execution support and oversight.

Question 2: Does the designated leader have cross-functional transformation authority? Can they convene engineering, application teams, procurement, legal, and business units? Can they compel participation, not just request it? If not, the steering committee charter must grant this authority explicitly, and the board must back it.

Question 3: Is there a credible oversight function? If the CISO leads (first-line role), who provides independent second-line assurance that the migration is being done correctly? If the CTO leads, the CISO fills this role. If the CISO leads, the enterprise risk function or internal audit fills it. Someone must be positioned to challenge the program without being part of the program.

The answers to these three questions will point to a specific governance configuration. In most organizations (particularly those where the CISO operates the security infrastructure), the CISO leads and the CTO’s application teams execute. In organizations with a pure second-line CISO, the CTO leads and the CISO provides assurance. In federated models, a CIRO or equivalent enterprise security executive leads with BISOs driving business-unit execution.

The “Bigger Table” Principle

One argument I keep encountering is that PQC migration is so large, so cross-functional, and so far beyond normal cybersecurity operations that it requires a new kind of executive leadership: a Chief Cryptographic Officer, a dedicated transformation lead reporting to the board, or some other role that does not currently exist in any governance framework.

I understand the instinct. PQC is a massive program. In my 120,000 Tasks analysis, I described it as potentially the largest cryptographic transformation in enterprise history. It touches every system, every protocol, every vendor relationship, and every assumption about how digital trust works. It is bigger than any typical cybersecurity project.

But when a challenge outgrows an existing role, the right response 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.

Every major security transformation of the past decade followed this pattern. Cloud security did not require a Chief Cloud Security Officer. It required expanding the CISO’s mandate to include cloud architecture. OT security did not require a separate OT Risk Executive. It required giving the CISO authority over operational technology environments and hiring OT security specialists to execute. DevSecOps did not require creating a new executive position. It required embedding security into development pipelines under the CISO’s governance.

PQC migration is bigger than any of those transformations. The governance response should be proportionally bigger: a larger program office, a more powerful steering committee, a bigger budget, deeper specialist talent, and a broader mandate. But the structural model (one accountable executive with the authority and resources to deliver) is the same model that has worked for every other transformation. Inventing a new governance structure from scratch delays the program by a year while the new structure establishes credibility that the CISO (or CTO) already has.

Practical Steps for CISOs

For CISOs reading this and preparing to take on PQC migration leadership, four actions will determine whether you succeed.

Map your actual authority, not your org chart. Document your budget authority, your convening authority (can you independently convene the risk committee?), your escalation path to the board, and your ability to compel cross-functional participation. If any of these are weaker than PQC migration requires, address them before launching the program. The governance overview describes what the accountable executive needs: board mandate, dedicated budget, cross-functional authority, and cryptographic engineering talent.

Assess whether you own the cryptographic estate. If PKI, HSMs, and certificate lifecycle management report to you, you have a strong starting position. If they report to the CIO or CTO, you need an explicit partnership agreement documented in the steering committee charter. The infrastructure-vs-application authority split matters: you may own the infrastructure layer directly and need the steering committee’s backing for the application layer.

Build the specialist team before you need it. PQC migration demands cryptographic engineering expertise that most security teams do not possess. I have written a detailed analysis of the skill stack needed for crypto-agility and quantum readiness. Start recruiting or contracting now. A CISO who announces a PQC program and then spends six months trying to hire a cryptographic architect has lost half a year of program momentum.

Set realistic expectations with the board. Use the KRI framework to establish measurable milestones. Frame PQC as a multi-year transformation, not a 12-month sprint. Present the cost estimation reality honestly: you can estimate discovery with confidence, but total program cost will only become clear after discovery is complete. Boards respect honesty about uncertainty. They do not respect optimistic projections that have to be revised upward every quarter.

The PQC Migration Framework provides the full methodology. Quantum Ready covers the complete readiness strategy. The governance model works. The question is whether you have the authority and resources to execute it.