Governance, Compliance, and the Executive Report

Post-quantum migration is not a patch weekend. It touches identity, networks, applications, cloud platforms, suppliers, certificates, signing systems, archives, and data protection rules. Work that broad does not succeed because engineers understand lattice cryptography. It succeeds because leaders keep funding it, owners keep making trade-offs, auditors can see evidence, and the board can tell whether risk is going down. Governance is the bridge between a hard technical transition and an organisation that can actually complete it.

Treat governance as part of the control

Governance is often described as meetings, reports, and approvals. In a post-quantum programme, it is more than that. It is the mechanism that decides what moves first, what can wait, who accepts residual risk, and how the organisation proves that progress is real.

The core problem is that quantum risk is uneven. A public website session that protects data for a few minutes is not the same as a medical archive, a citizen identity record, a design file, or a root signing key that must remain trustworthy for decades. Without governance, teams tend to migrate what is visible or easy. With governance, they migrate what matters most.

The programme needs a named owner who runs the work, an executive sponsor who can secure funding and remove blockers, and a small steering group that can make decisions across security, technology, legal, compliance, procurement, and business lines. Those roles should not be ceremonial. They should control priorities, exceptions, and escalation.

Anchor decisions in risk, not in cryptographic taste

Post-quantum cryptography, usually shortened to PQC, means cryptographic algorithms designed to resist attacks by both classical computers and future cryptographically relevant quantum computers. The important governance question is not which algorithm sounds most elegant. It is which systems expose the organisation to the most time-sensitive risk.

That is why every major decision should link back to a risk register. The risk register should record the asset, the data or trust function it protects, the cryptography in use, the expected lifetime of the data or signature, the business owner, the migration dependency, the planned treatment, and any accepted exception.

This keeps priorities defensible. If a team asks why its certificate service is scheduled before a less critical application, the answer should not be “security said so.” The answer should be visible in the risk record: longer data confidentiality period, stronger regulatory impact, harder migration path, or greater blast radius if trust fails.

Use the maturity model from the readiness assessment as the board-level progress measure. A zero-to-five score is imperfect, but useful. It turns many technical details into a trend that non-specialists can follow: discovery improving, ownership improving, pilots becoming standards, and isolated migrations becoming repeatable change.

• Record why each system is in scope, not just that it is in scope.
• Link every exception to an owner, an expiry date, and a compensating control.
• Use the maturity score as a trend, not as a trophy.
• Keep the cryptographic inventory alive; a one-time spreadsheet will decay quickly.
• Revisit priorities when standards, vendors, business plans, or threat timelines change.

Use the three executive lenses: risk, cost, and time

Executives do not need a lecture on key encapsulation mechanisms or digital signature schemes before they can make a funding decision. They need to know the risk being reduced, the cost of reducing it, and the timeline on which action is required.

The risk story should start with harvest now, decrypt later. Adversaries can copy encrypted traffic or stored encrypted data today and keep it until a future quantum computer can break the vulnerable public-key protection that helped secure it. That makes some quantum risk present tense. The breach may occur now, even if the decryption happens later.

The cost story should compare a planned migration with two worse alternatives: a rushed migration under deadline pressure, or a breach and compliance failure involving long-shelf-life data. Build the programme budget from roadmap waves: people, testing, tooling, supplier work, platform upgrades, and operational change. Then compare it with a reasoned exposure estimate for the most sensitive data and trust services.

The time story should show that waiting is also a decision. A migration across applications, identities, network devices, cloud services, suppliers, and signing infrastructure can take years. If leadership waits until quantum computers are visibly capable, the organisation may have no practical path to finish in time.

Make the deadline concrete with Mosca’s inequality

Mosca’s inequality is a simple planning test often used in quantum-risk discussions. Let X be the number of years the data must remain confidential. Let Y be the number of years needed to migrate the relevant systems. Let Z be the number of years until a quantum computer can break the vulnerable cryptography. If X + Y is greater than Z, the organisation is already inside the danger window.

This framing is powerful because it turns an abstract future threat into a scheduling problem. If a record must stay secret for fifteen years, and the migration will take five years, then the organisation needs twenty years of safety from the current cryptography. If leadership believes a capable quantum computer could plausibly arrive sooner than that, delay increases exposure.

The inequality does not require false precision. You can present ranges. Some data may have X measured in months. Some regulated, personal, defence, health, intellectual property, or financial data may have X measured in decades. Some systems can migrate in one release cycle. Others depend on vendor firmware, embedded devices, old protocols, certificate authorities, or partner integrations and may take years.

The useful leadership conversation is not “what exact year will quantum arrive?” It is “which of our assets already have a confidentiality or trust lifetime longer than our realistic migration runway?”

Map the roadmap to compliance drivers

Compliance does not replace risk management, but it changes the executive conversation. A technical recommendation may be debated for years. A regulatory deadline, audit finding, customer requirement, or government procurement condition quickly becomes a business obligation.

The National Institute of Standards and Technology, or NIST, has published post-quantum standards and transition guidance, including NIST Internal Report 8547, often written as NIST IR 8547. Current public guidance signals a transition period in which vulnerable public-key algorithms are deprecated around 2030 and disallowed after 2035. The exact applicability depends on jurisdiction, sector, and system type, so organisations should confirm current obligations with qualified legal and compliance teams.

Deprecated and disallowed are different states. Deprecated means the algorithm is still permitted in some contexts but officially discouraged and likely to draw audit attention. Disallowed means it should no longer be used to apply new cryptographic protection in the covered context. The period between those states is the migration window, not a reason to wait.

The National Security Agency, or NSA, has also published the Commercial National Security Algorithm Suite 2.0, known as CNSA 2.0, for United States national-security systems. Its timelines include post-quantum requirements for areas such as software and firmware signing by 2030 and broader adoption across systems by 2035. Even organisations outside that scope should pay attention because such guidance often influences suppliers, assurance expectations, and customer questionnaires.

Sector regulators in finance, healthcare, and critical infrastructure are increasingly asking about quantum readiness. A questionnaire is an early signal. It tells you the topic is moving from research discussion to supervised control. Map each question or requirement to a roadmap item: inventory, classification, migration wave, supplier engagement, testing evidence, or exception handling.

The decisions leaders and practitioners actually face

Governance becomes real at the point of choice. Leaders must decide how much to fund now, which risks to reduce first, which vendors to pressure, and which deadlines to accept. Practitioners must decide how to discover cryptography, how to test hybrid or post-quantum modes, how to handle legacy systems, and how to avoid breaking interoperability.

A useful steering meeting should therefore focus on decisions, not status theatre. The questions should be concrete: Which data classes have the longest confidentiality lifetime? Which certificate chains or signing keys create the largest trust dependency? Which systems cannot support post-quantum algorithms without vendor change? Which contracts need new cryptographic requirements? Which exceptions are becoming unsafe?

The most difficult choices often sit between security and operational risk. Replacing cryptography too quickly can break systems. Replacing it too slowly can leave long-lived data exposed or create a compliance gap. Good governance does not pretend this tension disappears. It makes the trade-off visible, records the decision, and revisits it when facts change.

For budget holders, the practical decision is usually phased funding. Early waves should reduce the largest risk for the least disruption: discovery, cryptographic inventory, data classification, supplier commitments, pilot implementations, and upgrades to platforms that many systems depend on. Later waves can handle complex legacy estates and remaining edge cases with better evidence and stronger patterns.

• Approve discovery funding before demanding exact migration costs; you cannot price what you have not found.
• Prioritise long-shelf-life data and high-trust systems before low-impact encryption changes.
• Build supplier requirements into renewals and procurements early.
• Treat exceptions as temporary risk decisions, not permanent architecture.
• Reserve capacity for testing, because interoperability failures are migration risks too.

Build the one-page executive report

Executives may support a programme for years, but they will not read a technical appendix every month. The standing report should fit on one page and should be refreshed on a predictable cadence. Its job is to show whether exposure is falling, whether the plan is on track, what decision is needed, and what happens if the decision is deferred.

The first line is the situation: quantum computing will break today’s widely used vulnerable public-key cryptography, and some encrypted data may already be collected for later decryption. The second line is exposure: name the highest-risk data classes, systems, certificate services, signing processes, or supplier dependencies. Avoid vague labels such as “sensitive systems” when you can name the top few.

The third line is current posture: the maturity score from zero to five, the target for the current phase, and the trend since the last report. The fourth line is the plan: the current wave, the next wave, and the dates that matter. The fifth line is the ask: money, people, executive decision, supplier escalation, policy approval, or risk acceptance. The sixth line is cost of inaction: breach exposure, compliance deadline, audit issue, customer impact, or forced-migration cost.

Use plain language. A board report should not require prior knowledge of Rivest-Shamir-Adleman, known as RSA, elliptic curve cryptography, known as ECC, public key infrastructure, known as PKI, or Transport Layer Security, known as TLS. Those details matter in the workstream. The executive page should translate them into business impact.

Keep the programme alive after the first approval

The first funding approval is only the start. A multi-year migration will outlast budget cycles, architecture changes, vendor roadmaps, staff turnover, and new guidance. The governance design must assume change.

Set a reporting rhythm. Monthly may be right for delivery teams, while quarterly may be enough for the board or risk committee. Keep a stable set of measures: maturity score, inventory coverage, percentage of high-risk assets assessed, number of systems migrated or piloted, supplier readiness, open exceptions, and compliance milestones. Do not add metrics merely because they are easy to count.

Refresh the inventory continuously. New applications, certificates, application programming interfaces, cloud services, managed services, devices, and suppliers can introduce vulnerable cryptography after the programme has begun. Procurement, architecture review, and change management should all ask whether a new system is quantum-safe or at least crypto-agile.

Crypto-agility means the ability to change cryptographic algorithms, key sizes, protocols, and providers without redesigning the whole system. It is one of the most important long-term outcomes of the programme. Even after the first post-quantum migration, algorithms, standards, implementations, and attacks will continue to evolve. The organisation should become better at changing cryptography, not merely better at this one change.

When governance works, the board does not need to understand every primitive. It understands the direction of risk, the deadlines, the money, the accountable owners, and the decisions in front of it. That is enough to keep attention where it belongs and to turn a deeply technical transition into completed organisational change.

Glossary

Post-quantum cryptography

Cryptographic algorithms designed to resist attacks by both classical computers and future quantum computers.

Harvest now, decrypt later

An attack pattern in which encrypted data is stolen today and stored until future technology can decrypt it.

Risk register

A maintained record of risks, owners, decisions, treatments, exceptions, and review dates.

Maturity score

A simple rating that shows how developed and repeatable an organisation’s post-quantum readiness practices are.

Mosca’s inequality

A planning rule that warns of risk when the required secrecy lifetime plus migration time is longer than the time until a capable quantum computer.

Deprecated

Still allowed in some contexts but officially discouraged and likely to attract audit or transition pressure.

Disallowed

No longer permitted for applying new cryptographic protection in the covered context.

Crypto-agility

The ability to replace or reconfigure cryptographic algorithms and protocols without redesigning the whole system.

Executive sponsor

A senior leader who secures funding, removes blockers, and accepts or escalates major risk decisions.