PQC War Rooms: The Global Enterprise Risk Transformation CISOs Cannot Outsource

Post-quantum cryptography is still being treated by too many organisations as an algorithm migration.

That is the wrong frame.

PQC is becoming a trigger for a much broader enterprise risk transformation.

The algorithms are being standardised. The harder problem sits around them: discovering where cryptography actually exists, identifying who owns it, understanding which suppliers control critical dependencies, determining which data cannot afford to remain exposed, and creating an operating model capable of moving thousands of systems through a controlled transition.

The pressure is now global.

The United States is accelerating federal PQC execution. The UK has established a clear migration trajectory towards 2035. Europe is approaching the issue through cybersecurity, operational resilience and national guidance rather than one single enterprise-wide deadline. Across Asia-Pacific, governments and regulators are developing their own approaches, with Singapore, Japan and Australia publishing increasingly concrete quantum-safe guidance.

For a multinational enterprise, this creates a governance problem that a conventional project team cannot solve.

One cryptographic estate.

Multiple regulatory clocks.

Hundreds of dependencies.

No single owner of all of them.

That is why enterprises need a PQC War Room.

Not another project team.

A standing, cross-functional operating cell that converts quantum risk into an executable campaign with governance, visibility, prioritisation and decision-making authority.

PQC is a transformation lever, not just a migration

PQC reaches far beyond encryption libraries.

It affects:

• TLS and network infrastructure

• IAM and authentication

• PKI and certificate hierarchies

• HSMs and key management

• Code and firmware signing

• Applications and APIs

• Cloud platforms

• Data protection

• Software supply chains

• Third-party services

• Long-lived confidential information

That makes PQC a cross-business problem.

The CISO may own the risk, but the CISO does not own every dependency.

Infrastructure does not own the applications.

Application teams do not own the PKI.

Procurement does not own a supplier's cryptographic architecture.

And suppliers may not have complete visibility of their own dependencies.

This is where the conventional migration model starts to fail.

A project plan can schedule activities.

It cannot create accountability across hundreds of interconnected dependencies.

A War Room can.

The global regulatory picture

There is no single global PQC deadline.

That matters.

United States

The US is creating some of the strongest external pressure.

NIST has finalised FIPS 203, FIPS 204 and FIPS 205, establishing the initial federal cryptographic standards for ML-KEM, ML-DSA and SLH-DSA.

For federal agencies, OMB M-23-02 established the foundation for post-quantum migration planning. OMB M-26-15 moves the federal programme further into execution, establishing a phased migration programme extending to 2035 and requiring agencies to develop implementation plans.

For National Security Systems, NSA's CNSA 2.0 establishes a separate security-driven transition path.

These instruments do not create a universal corporate deadline.

They establish direction.

PQC has moved from research into standards, procurement, architecture and execution.

For organisations supplying government, critical infrastructure or highly regulated markets, evidence of cryptographic readiness is likely to become an increasingly important commercial and risk consideration.

United Kingdom

The UK's National Cyber Security Centre has established a clear migration trajectory:

2028: complete discovery and develop migration plans.

2031: complete migration of the highest-priority systems.

2035: complete migration across systems, services and products.

The important lesson is not simply the dates.

It is the sequence.

Discovery comes first.

Prioritisation follows.

Migration comes after that.

You cannot migrate what you cannot see.

For global organisations operating in the UK, those milestones should be treated as serious planning signals even where the organisation is not directly subject to a government mandate.

Europe

Europe requires more nuance.

There is no single EU-wide PQC deadline equivalent to a universal enterprise mandate.

Instead, organisations are dealing with a combination of cybersecurity regulation, digital operational resilience requirements, national cybersecurity guidance and sector-specific supervisory expectations.

For financial services, DORA is particularly relevant. Its requirements around ICT risk management and third-party ICT risk do not constitute a PQC regulation, but they create a resilience and dependency-management framework into which cryptographic transition increasingly fits.

NIS2 similarly strengthens expectations around cybersecurity risk management and supply-chain security.

European organisations should therefore not wait for a dedicated PQC regulation before acting.

The regulatory environment is already moving towards stronger expectations around resilience, dependency management, supplier assurance and demonstrable risk management.

PQC increasingly sits inside that existing control environment.

Asia-Pacific

Asia-Pacific should not be treated as one market.

Singapore's Cyber Security Agency has published a Quantum-Safe Handbook and Quantum Readiness Index, giving organisations a structured way to assess readiness and plan migration.

Japan's CRYPTREC has published post-quantum cryptography guidance, while Japan's cybersecurity strategy establishes a 2035 target in principle for government agencies and related organisations to transition to PQC.

Australia has gone further in establishing concrete transition planning expectations. Australian Signals Directorate guidance calls for organisations to develop transition plans, begin critical-system and data migration by 2028, and complete the transition by 2030.

The mechanisms differ.

The direction does not.

For multinational organisations, the answer is not a separate PQC programme for every geography.

It is one global cryptographic transformation framework with jurisdiction-specific overlays.

Global architecture.

Global governance.

Local regulatory execution.

The PQC War Room

The War Room is the operating mechanism that makes this possible.

Its purpose is not to manage every technical migration personally.

Its purpose is to create the visibility, authority and decision rights required to manage the transformation.

The cadence is straightforward:

Daily: delivery and dependency stand-up.

Weekly: risk, blockers and migration decisions.

Monthly: executive risk and progress review.

Quarterly: board-level exposure, residual risk and regulatory position.

The War Room should own the migration sequence, exception approvals, supplier escalation paths and the evidence package presented to executives, boards and regulators.

That makes it a decision body, not another meeting.

1. Governance that actually works

The programme needs executive sponsorship.

Sponsorship without authority is not governance.

Create a central programme function with representation from:

• Security

• Enterprise architecture

• Infrastructure

• Networking

• IAM

• PKI

• Application engineering

• Cloud

• Data

• Procurement

• Legal and compliance

• Third-party risk

• Internal audit where appropriate

Appoint a single accountable migration leader.

Give that person authority to establish cryptographic standards, define migration gates, challenge business-unit exceptions and escalate unresolved dependencies.

The objective is not centralisation for its own sake.

It is to stop every business unit inventing its own PQC strategy.

2. Build a living cryptographic evidence layer

The enterprise needs to know where cryptography exists.

Not where someone believes it exists.

The CBOM should become the War Room's cryptographic source of truth.

Discovery needs to extend beyond application code.

Look across:

• Endpoints

• Servers

• Network infrastructure

• PKI

• Certificate authorities

• HSMs

• Containers

• Cloud services

• Code repositories

• APIs

• Authentication systems

• Embedded systems

• Third-party dependencies

Every meaningful cryptographic dependency should ultimately connect to an owner, business service, technology, algorithm, parameter set, certificate or key lifecycle, data sensitivity and migration status.

A spreadsheet produced once a year is not a CBOM strategy.

The CBOM must be a living, queryable evidence layer that feeds risk registers, audit responses and migration-wave decisions.

3. Prioritise risk, not algorithms

The first question should not be:

Where can we deploy ML-KEM?

It should be:

Which cryptographic dependencies create the greatest business risk if they cannot be transitioned in time?

Prioritisation should consider:

• Data confidentiality lifetime

• HNDL exposure

• Business criticality

• Internet exposure

• Authentication dependency

• Certificate dependency

• Software and firmware signing

• Supply-chain concentration

• Cryptographic centrality

• Technology replacement cycles

• Regulatory importance

• Migration complexity

This produces a risk-based migration sequence.

Some organisations will need to prioritise key establishment.

Others will find that signing infrastructure, PKI or long-lived software represents the more urgent exposure.

There is no universal enterprise sequence.

There is only evidence-based prioritisation.

4. Treat HNDL as a present-day risk

Harvest Now, Decrypt Later changes the timeline.

The threat does not require a cryptographically relevant quantum computer to exist today.

An attacker can acquire encrypted information now and attempt to decrypt it later.

That makes confidentiality lifetime critical.

Information with a five-, ten- or twenty-year confidentiality requirement cannot be assessed solely against today's cryptographic threat environment.

Data classification and retention policy therefore need to connect directly to cryptographic risk.

If information must remain confidential for ten years, its protection needs to be assessed against a ten-year threat horizon.

The War Room needs to identify that information and determine whether its existing protection remains acceptable throughout the required confidentiality period.

That is a business-risk decision.

Not simply a cryptographic one.

5. Build hybrid capability without pretending the migration is finished

PQC migration will not happen as a single switch.

Organisations will operate through transition states.

Hybrid approaches may therefore be appropriate while systems, suppliers and standards mature.

But pilots need measurable objectives.

Test:

• Handshake performance

• Certificate-chain size

• Latency

• Bandwidth

• HSM throughput

• Memory requirements

• Application compatibility

• Interoperability

• Failure behaviour

• Monitoring capability

The objective of a pilot is not to prove that PQC works.

It is to discover where your enterprise breaks when PQC enters the environment.

That is the information required to sequence a production migration responsibly.

6. Make supplier risk part of the migration

This is where many enterprise programmes will fail.

Your organisation may be ready.

Your supplier may not be.

Your cloud provider may support one capability but not another.

Your CDN may have one roadmap.

Your HSM supplier another.

Your PKI platform another.

Your software vendor may not provide sufficient visibility into its cryptographic dependencies.

Procurement and third-party risk therefore need a formal place inside the War Room.

Ask suppliers:

• What cryptography do you use?

• Where is it used?

• What is your PQC roadmap?

• What dependencies remain?

• Do you maintain a CBOM?

• Which components can be upgraded?

• Which require replacement?

• What are your migration milestones?

• What evidence can you provide?

Where critical suppliers cannot provide a credible roadmap or sufficient evidence, the organisation needs options.

Contractual remedies.

Alternative suppliers.

Architectural decoupling.

Or explicit risk acceptance at the appropriate level.

Moving responsibility to a managed service may reduce direct migration scope.

It does not remove the risk.

The assurance burden moves into supplier governance, contractual dependency and concentration risk.

7. The skills bottleneck is real

There is another constraint that rarely appears in PQC migration plans.

People.

An enterprise may have cybersecurity specialists, PKI engineers, enterprise architects and procurement professionals.

That does not mean it has enough people who understand the intersection of cryptography, infrastructure, application dependencies, supplier contracts and regulatory requirements.

The bottleneck will not simply be hiring cryptographers.

It will be developing teams capable of translating cryptographic evidence into business decisions.

That means training existing architecture, security, engineering, procurement and risk teams while developing a smaller pool of genuine cryptographic specialists.

The War Room therefore needs a skills strategy alongside its migration strategy.

8. The budget is part of the risk decision

PQC migration will not be funded entirely from an existing security operating budget.

Legacy platforms will need upgrading.

Applications will require engineering work.

PKI and HSM infrastructure may need replacement.

Suppliers may need to change.

Testing environments will require investment.

Specialist skills will cost money.

The board therefore needs to see PQC as a capital and transformation decision, not another security project competing for a limited operational budget.

The question is not simply:

What will PQC cost?

It is:

What is the cost of delaying the decisions that determine the migration path?

9. Create a global framework with regional overlays

This is essential for multinational organisations.

Do not create separate cryptographic strategies for every geography.

Create one global control framework covering:

• Cryptographic inventory

• Risk classification

• Ownership

• Migration gates

• Supplier assurance

• Exception management

• Evidence requirements

• Architecture standards

• Testing

• Reporting

Then apply jurisdictional overlays covering:

• Regulatory requirements

• Government milestones

• Critical-infrastructure expectations

• Sector requirements

• Data residency

• Supplier requirements

• National cryptographic policy

• Evidence and reporting obligations

The architecture remains global.

The governance remains global.

The execution reflects local requirements.

That is scalable.

The 90-day activation sprint

Days 1–30

Stand up the War Room.

Define governance and accountability.

Establish the global control framework and jurisdictional overlays.

Begin cryptographic discovery.

Produce the first CBOM.

Identify crown-jewel systems and HNDL-sensitive information.

Identify the highest-risk suppliers.

Days 31–60

Risk-score the cryptographic estate.

Map dependencies.

Select representative pilot workloads.

Assess PKI and HSM readiness.

Establish supplier engagement.

Define migration waves.

Begin testing hybrid configurations where technically appropriate.

Days 61–90

Execute pilots.

Measure performance.

Validate interoperability.

Identify architectural blockers.

Refine migration sequencing.

Publish the first migration waves.

Establish executive telemetry.

Document residual risk.

Then make the decisions the project team has been postponing:

Which systems enter Wave 1?

Which exceptions are accepted?

Which suppliers are escalated?

Which risks remain open?

The metrics that matter

Boards do not need a list of algorithms.

They need evidence of risk reduction.

Visibility

Percentage of cryptographic assets discovered.

Percentage mapped to business owners.

Percentage with known migration status.

Exposure

Percentage of high-value HNDL-sensitive data flows identified.

Percentage of critical cryptographic dependencies with an approved migration path.

Velocity

Workloads migrated per wave.

Time from discovery to migration decision.

Time from migration decision to implementation.

Agility

Percentage of new systems using crypto-agile architecture.

Percentage of strategic suppliers providing meaningful PQC evidence.

Resilience

Percentage of critical services tested against PQC-related changes.

Number of unresolved cryptographic single points of failure.

Number of systems dependent on unsupported or non-agile cryptographic components.

Governance

Open risk exceptions.

Overdue migration decisions.

Supplier remediation status.

Audit evidence completeness.

That is what turns PQC from a technology programme into an enterprise risk dashboard.

The transformation killers

Inventory without decisions

A large inventory is useless if assets have no owner, priority or migration path.

Algorithm-first thinking

Selecting algorithms before understanding business exposure and dependency chains.

PKI tunnel vision

Treating PQC as a certificate replacement programme.

Supplier complacency

Assuming vendors will solve the problem without contractual accountability or evidence.

Regional fragmentation

Building separate migration strategies for every geography.

Technology optimism

Assuming a vendor roadmap is the same thing as an enterprise migration plan.

Talent denial

Assuming existing teams have sufficient cryptographic and transformation capability.

Budget denial

Expecting a multi-year technology transformation to fit inside an existing security operating budget.

No telemetry

Migrating systems without knowing whether risk is actually decreasing.

The real transformation

The biggest mistake is treating PQC as an event.

It is not.

It is a multi-year transformation of the enterprise's cryptographic control environment.

The organisations that handle it well will not necessarily be the ones that deploy PQC first.

They will be the ones that can answer, with evidence:

Where is our cryptography?

Who owns it?

Which dependencies matter most?

Which data cannot wait?

Which suppliers can actually deliver?

Which systems can migrate now?

Where are we accepting residual risk?

And most importantly:

Are we getting safer every quarter?

That is the purpose of the PQC War Room.

Not another committee.

Not another project plan.

A permanent operating mechanism for turning cryptographic uncertainty into governed enterprise action.

The quantum problem may eventually be solved by mathematics and engineering.

The enterprise problem will be solved by governance, evidence, accountability and execution.

If you cannot produce a defensible cryptographic inventory, identify its business owners, demonstrate its risk priorities and show which exposures are being reduced, you do not yet have a PQC programme.

You have a PowerPoint.

PQC Discovery Sprint | Sitg-Consulting

authored by Kantima Meewaew and Brian Couzens

email: info@sitg-consulting.com