Publish a governance model that puts post-quantum migration under the chief information security officer and the same objection comes back within a day: the CISO is a second-line oversight function, and a multi-year delivery program is first-line work. The objection reasons from where the CISO reports. Reporting lines are the easiest thing to measure about the role and the least informative about it.
The objection is sound as governance theory, and it rests on a premise that doesn’t hold. It assumes one version of the CISO role. One CISO reports to the CIO, runs vulnerability scanning and incident response with a small team, and has no vote on infrastructure decisions. Another reports to the CIO, runs security engineering, operates the certificate and key infrastructure for the entire group, and holds a standing seat on the board risk committee. Same line on the chart, different job.
What the Three Lines Actually Divide
The Three Lines of Defense model comes from the Institute of Internal Auditors, which updated it in 2020 as the Three Lines Model, and it divides accountability rather than headcount. The first line owns and operates the control. The second line sets policy and risk appetite, then challenges how the first line is doing. The third line, internal audit, gives the board independent assurance about both.
Read the model closely and it assigns activities to lines, not people to lines. One executive can hold first-line and second-line work at the same time, and in mid-sized organizations most security leaders already do.
Post-quantum cryptography (PQC) migration is first-line work everywhere. Someone has to inventory the cryptography in use, replace certificates, rotate keys, test ML-KEM and ML-DSA, formerly CRYSTALS-Kyber and CRYSTALS-Dilithium, against production traffic, and ship the change through the same release process as everything else. The governance question is which executive holds that work, and whether anyone independent is positioned to challenge the result.
Start With the Cryptographic Estate
We use cryptographic estate to mean the set of things a migration actually changes: the public key infrastructure (PKI) and the certificate authorities inside it, the fleet of hardware security modules (HSMs) that generate and hold keys, certificate lifecycle management tooling, key management systems, and the cryptographic code and configuration sitting inside applications, firmware, and purchased products – the part almost nobody has inventoried.
Whoever operates that estate is in the first line for it, whatever the title says. Three configurations cover most of the organizations we work with.
Estate Under the CISO
Security engineering reports to the CISO and operates PKI, the HSM fleet, and certificate lifecycle management. The CISO leads the migration, and the person with the most detailed knowledge of the estate is also the person who can change it. This is the configuration the second-line objection describes. Name the challenger and the objection is answered: enterprise risk or internal audit reviews algorithm selection, tests the inventory for completeness, and reports its own view of progress straight to the board.
Estate Under the CTO or CIO
The CISO sets policy and reviews compliance, and PKI, HSMs, and key management sit inside infrastructure engineering. The CTO or CIO leads the migration. The CISO validates algorithm choice against regulatory requirements, hybrid deployment (running a classical and a post-quantum algorithm together so a break in either one still leaves the connection protected), key-management changes, and the security posture across the years the estate is half migrated. This is the cleanest fit to the model, and it works when the technology executive has already delivered a transformation at enterprise scale.
Estate Federated Across Business Units
Business information security officers, or BISOs, sit inside each business unit and report to a group-level security executive. Central engineering runs shared PKI and HSM infrastructure. The group executive sets the standard, the deadline, and the reporting format. Central engineering migrates the shared layer, and each BISO owns application-layer migration inside their unit. Give the BISOs seats on the steering committee at the start, rather than an invitation once the plan is written.
The Split Estate
Most large enterprises don’t match any of the three cleanly. The CISO operates the HSMs and the internal certificate authority. The CIO owns the application platforms, the middleware, and the vendor contracts that carry most of the cryptography in daily use. Neither one controls the whole estate.
The failure mode is well known and cheap to avoid. An accountable executive is named, controls perhaps a third of the estate, and you’ll then watch them negotiate for the rest release by release. Accountability without authority produces steering committee minutes instead of migrated systems.
Three things close the gap, and all three belong in the steering committee charter rather than in a slide. Write down which layer each executive owns, infrastructure and application, in exactly that language. Take delivery commitments with dates from the executive who owns the application layer, not statements of support. Name one escalation route with a decision deadline attached, so a stalled dependency reaches the accountable executive in a week rather than a quarter.
Authority the Org Chart Doesn’t Show
Four decision rights determine whether an executive can run this program, and none of them appear on an organization chart.
- Budget authority. Can they fund discovery and the first migration wave without building a competing business case every quarter?
- Convening authority. Can they call the risk committee, or do they need someone else’s agenda slot?
- Escalation authority. Can they reach the board directly when a business unit refuses to schedule the work?
- Compulsion. Can they require participation from application teams, procurement, and legal, or only request it?
Formal position and actual authority diverge in both directions. A CISO who sits under the CIO on paper may carry an independent right to convene the board risk committee, documented in a committee charter or a letter from the chair rather than in the reporting structure. Another CISO with a textbook second-line reporting line may control no budget at all. Test the four rights directly, and if any of them is weaker than the program needs, fix it before launch. Fixing it later means asking the board to correct a structure it already approved.
Why the Answer Isn’t a New Executive Title
A recurring proposal is to create a role for this: a chief cryptographic officer, or a transformation lead reporting directly to the board, on the grounds that the migration is too large for any existing mandate. The instinct is understandable, and the precedent runs the other way. Cloud security expanded the CISO’s mandate to cover cloud architecture. Operational technology security expanded it again, with specialist hires underneath. DevSecOps embedded security into delivery pipelines under existing governance. None of the three produced a new C-level office.
A new office spends its first year building the credibility and the working relationships an existing one already has – a year the migration timeline rarely has spare. Scale the resources instead. A dedicated program office, a multi-year budget line, cryptographic engineering talent hired or contracted before the first wave, and a steering committee with the standing to break ties.
Four Things to Settle Before Launch
- Where the estate sits. Map PKI, HSMs, certificate lifecycle management, and key management to their operating owners. The executive who operates the largest share leads. If ownership is split, write the split into the charter in layer language.
- Whether the leader holds the four rights. Budget, convening, escalation, compulsion. Document what exists today, and ask the board to grant what doesn’t.
- Who challenges. If the CISO leads, enterprise risk or internal audit challenges. If the CTO leads, the CISO challenges. The challenger reports to the board on its own cadence, and that cadence goes in the charter.
- Who has actually done the cryptography. Migration demands skills most security teams don’t hold: cryptographic architecture, inventory tooling, protocol-level testing. Recruiting a cryptographic architect after the program is announced costs months of momentum the timeline can rarely absorb.
Building the Capability
Each of those four decisions rests on people who understand what the migration changes at the protocol and key-management level, not only at the program level. The structure is defensible on paper, and nobody in the room can say whether the proposed hybrid deployment leaves the certificate chain protected through the transition.
For the underlying migration methodology, the PQC Migration Framework sets out the phases and the deliverables. For a longer treatment of how these reporting structures behave in practice, including six real organizational models, see the governance analysis on PostQuantum.com.
Quantum Academy’s governance and leadership training is built for the executives and GRC teams who have to make these calls, and covers estate mapping, decision rights, and assurance design in working detail. Browse the current programs at quantumacademy.com/.