Post-Quantum Cryptography Migration with ISO 27001

The hum of the projector is the only sound in the boardroom. Sarah, the CISO, has just finished her quarterly risk update when the CEO lifts a printout from a financial news article. The headline is blunt: “The Quantum Countdown: Is Your Data Already Obsolete?”

“Sarah,” he says, less accusatory than genuinely worried, “we have spent millions on encryption. We are compliant. We are secure. This article says a powerful enough quantum computer could break it all. Are we exposed? What about the data we are encrypting and storing right now? Is it a ticking time bomb?”

This is the conversation now moving from security conferences into executive committees. The issue is no longer whether quantum computing is interesting to researchers. The issue is whether today’s cryptographic choices can protect tomorrow’s business obligations.

For many organizations, the honest answer is uncomfortable. Encryption is everywhere: TLS gateways, VPNs, customer portals, identity tokens, database backups, mobile applications, payment platforms, S/MIME, SSH, API integrations, SaaS services, hardware security modules, cloud key management services, firmware signing, code signing, and digital contracts.

That is the problem. Cryptography is everywhere, but ownership is often nowhere.

Post-quantum cryptography migration is not only about a future cryptographically relevant quantum computer. It is also about today’s harvest now, decrypt later risk, where adversaries capture encrypted data now and wait until future capabilities make decryption practical. If your organization stores personal data, health records, regulated financial data, trade secrets, legal communications, national infrastructure data, product firmware, or long-life intellectual property, the risk is already a lifecycle risk.

A quantum-ready cryptography migration plan is not a panic project. It is a structured governance, inventory, supplier, architecture, testing, and audit program. The practical question for CISOs is simple:

How do we build a post-quantum migration plan that is credible to executives, usable by engineers, and defensible to auditors?

The answer is to anchor the work in ISO/IEC 27001:2022, interpret controls through ISO/IEC 27002:2022, use NIST post-quantum cryptography standards as the technical compass, and create one evidence model that supports ISO 27001, NIST, COBIT 2019, GDPR, DORA, and NIS2 obligations.

Why post-quantum cryptography belongs inside the ISMS

A common mistake is to assign post-quantum migration only to cryptographic engineers. Engineers are essential, but they cannot solve the governance problem alone.

Post-quantum migration touches asset management, data classification, supplier management, secure architecture, key management, application development, cloud security, incident response, business continuity, legal risk, regulatory accountability, and audit evidence. These are ISMS topics.

ISO/IEC 27001:2022 gives the governance container. It requires the organization to understand context, interested parties, risk, objectives, responsibilities, competence, documented information, operational planning, performance evaluation, internal audit, management review, and continual improvement. ISO/IEC 27002:2022 then provides the control interpretation, especially around 8.24 Use of cryptography, 5.9 Inventory of information and other associated assets, 5.12 Classification of information, 5.21 Managing information security in the ICT supply chain, 5.23 Information security for use of cloud services, 8.25 Secure development life cycle, 8.8 Management of technical vulnerabilities, 8.16 Monitoring activities, and 5.30 ICT readiness for business continuity.

At Clarysec, this is why post-quantum readiness is treated as an ISMS-driven transformation, not as an isolated algorithm replacement.

As stated in Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap, Phase 2, Step 8, “Asset, dependency, and evidence scoping”:

“A control cannot be trusted until the organization can prove where it applies, who owns it, which evidence supports it, and which risk it reduces.”

That sentence is especially important for post-quantum cryptography. Before you replace algorithms, you must know where algorithms are used.

Clarysec’s Zenith Controls: The Cross-Compliance Guide frames cryptography as a connected evidence chain rather than a single technical setting:

“Cryptographic assurance is audited through the lifecycle of information: identification, classification, approved use, key protection, operational monitoring, supplier dependency, exception handling, and evidence retention.”

That lifecycle view prevents the most common failure: asking only, “Are we using quantum-safe algorithms?” The better questions are:

• Which systems need post-quantum migration first?
• Which data has a confidentiality lifetime longer than the quantum risk horizon?
• Which vendors control our encryption, signatures, certificates, or key management?
• Which applications are crypto-agile and which are hardcoded?
• Which compensating controls exist while migration is incomplete?
• Which evidence will prove that decisions were risk-based and reviewed?

From quantum threat to auditable business risk

A useful post-quantum plan begins with risk scenarios. Avoid vague statements such as “quantum computing may break encryption.” Instead, create auditable risk records that link business impact, threat, vulnerability, affected assets, current controls, residual risk, and treatment actions.

For example:

“Encrypted customer identity documents stored for seven years may be vulnerable to future decryption if backups are exfiltrated today and current public-key cryptography becomes breakable in the future.”

That scenario points to data retention, backup encryption, key management, access control, supplier hosting, monitoring, and migration priority.

Another example:

“Firmware signing for connected devices relies on signature schemes that may not remain trustworthy across the expected device lifecycle.”

That points to product security, secure update mechanisms, HSM capability, customer safety, supplier design assurance, and long-term operational resilience.

A third example:

“Archived legal communications encrypted today may require confidentiality for more than fifteen years, creating harvest now, decrypt later exposure.”

That points to classification, retention, cryptographic protection, legal hold, secure communications, and executive risk acceptance.

The risk is not just a future “Q-Day.” It includes three related concerns:

1. Harvest now, decrypt later, adversaries collect encrypted data today for future decryption.
2. Digital signature compromise, future attacks undermine trust in software updates, identity tokens, legal documents, firmware, and financial transactions.
3. Cryptographic concentration failure, a broad class of products, protocols, libraries, or suppliers becomes obsolete at the same time.

Clarysec’s Enterprise Policy, Cryptography and key management policy, clause 5.1, captures the governance requirement this way:

“Cryptographic controls shall be selected, implemented, reviewed, and retired based on the classification of information, the lifetime of protection required, approved cryptographic standards, key ownership, and documented risk treatment decisions.”

That clause is critical because protection lifetime becomes a prioritization factor. Short-lived session data and long-term medical records do not carry the same quantum risk. A code signing key that underpins device trust for fifteen years has a different risk profile than a short-lived internal test certificate.

The same policy family, referenced in Clarysec materials as the Cryptographic Controls Policy, can also formalize review expectations through language such as:

Clause 5.4: Algorithm and Key Length Standards
“All cryptographic algorithms and key lengths used within the organization must be selected from an approved list maintained by the Information Security team. This list shall be reviewed annually against industry best practices and guidance from national cybersecurity bodies (e.g., NIST, ENISA), with specific attention paid to the development of post-quantum cryptographic standards. A roadmap for migrating systems away from algorithms vulnerable to quantum-based attacks must be maintained as part of the cryptographic asset inventory.”

This does not require unsafe early adoption. It requires awareness, planning, review, and evidence.

Use NIST PQC standards as the technical compass

NIST’s post-quantum cryptography work gives organizations a credible technical direction. NIST has standardized ML-KEM for key establishment, ML-DSA for digital signatures, and SLH-DSA for stateless hash-based signatures. These standards give vendors and architects a basis for roadmaps and pilot designs.

For CISOs, the point is not to memorize algorithm details. The point is to create a migration pathway that can absorb approved cryptographic choices without breaking business services, compliance commitments, or audit traceability.

A NIST-aligned migration plan should include four tracks:

1. Discovery, identify where vulnerable public-key cryptography exists.
2. Prioritization, rank systems by data sensitivity, protection lifetime, exposure, integrity impact, and business criticality.
3. Transition architecture, define where hybrid, crypto-agile, or post-quantum mechanisms will be tested and adopted.
4. Assurance, produce evidence that decisions, exceptions, supplier dependencies, tests, and residual risks are controlled.

Crypto-agility deserves special attention. A crypto-agile system can change algorithms, key sizes, libraries, certificates, and protocols without major redesign. In the post-quantum era, crypto-agility is not a luxury. It is a resilience requirement.

If a payment API has hardcoded cryptographic libraries and no documented owner, it is not crypto-agile. If a mobile application pins certificates without a managed update pathway, migration may become expensive. If an IoT device has a fifteen-year field life and cannot support larger signatures or secure firmware updates, the risk is strategic.

Build the cryptographic inventory before choosing the migration path

Most organizations do not have a complete cryptographic inventory. They may have a certificate inventory, a key management spreadsheet, HSM records, a cloud KMS list, or CMDB entries. Rarely do they have a single view of cryptographic dependencies.

A post-quantum cryptography migration plan needs a cryptographic bill of materials, or CBOM. It does not need to be perfect on day one. It does need to be structured, owned, and continuously improved.

At minimum, capture the following fields:

An initial inventory might look like this:

This table immediately shows why inventory matters. AES-256 is not the same kind of quantum risk as RSA or ECC, but archived patient records may still depend on vulnerable key wrapping, certificates, identity systems, or backup transfer channels. Code signing may not protect confidentiality, but it protects software integrity and trust.

In Zenith Controls, cryptography is cross-referenced with supporting standards that add depth. ISO/IEC 27005 supports information security risk management and helps translate quantum uncertainty into structured risk scenarios. ISO/IEC 27017 supports cloud-specific security controls, which is essential when cryptographic services are delivered through cloud KMS, managed TLS, SaaS encryption, or platform certificates. ISO/IEC 27018 is relevant when personal data is processed in public cloud services. ISO 22301 is relevant where cryptographic failure could affect continuity of critical services. ISO/IEC 27036 supports supplier relationship security, which is crucial when vendors manage encryption, signatures, certificates, or secure communications on your behalf.

The lesson is simple: you cannot migrate what you cannot find.

Prioritize by sensitivity, lifetime, exposure, and migration difficulty

Once the CBOM exists, prioritization becomes evidence-based. The best starting point is a small number of critical systems, not an enterprise-wide perfection exercise.

Imagine a financial services company with three high-value systems:

• A customer document vault storing identity evidence for ten years
• A B2B API gateway supporting partner transactions
• A code signing platform for desktop software updates

Using Zenith Blueprint, Phase 2, Step 8, the team extracts assets from the CMDB, certificates from the certificate management platform, keys from the HSM and cloud KMS, data classes from the privacy register, and supplier dependencies from procurement records.

They then score the systems:

The customer document vault becomes a priority because of confidentiality lifetime. The code signing platform becomes a priority because signature trust affects software integrity and customer safety. The API gateway is high priority because of external exposure, but its retained data may have a shorter confidentiality lifetime.

The risk register should then link each scenario to treatment and evidence:

Clarysec’s Enterprise Policy, Secure development policy, clause 6.4, gives the software delivery angle:

“Security design reviews shall evaluate cryptographic dependencies, library lifecycle, algorithm agility, secrets handling, update mechanisms, and supplier-controlled components before production approval.”

That clause turns post-quantum readiness into an engineering requirement. It prevents teams from deploying new systems that cannot be migrated later.

Follow a 12-month roadmap auditors can understand

Post-quantum migration will take years for many organizations. The first year should move the organization from uncertainty to governed migration.

In the Zenith Blueprint, Phase 3, Step 14, “Risk treatment design and ownership,” the roadmap warns against unfunded security intentions:

“A treatment plan without an owner, evidence expectation, budget path, and review date is not a plan. It is an unresolved risk with better formatting.”

That is exactly how post-quantum programs fail. They produce awareness slides, but no owned remediation backlog. They discuss algorithms, but do not update supplier contracts. They document risk, but do not test migration patterns.

A credible roadmap creates decision records, owners, dependencies, evidence expectations, budgets, and review dates.

Bring suppliers into the program early

Many cryptographic dependencies are outsourced. Cloud providers terminate TLS. SaaS platforms encrypt records. Identity providers sign tokens. Payment processors manage certificates. Hardware vendors control firmware signing. Managed service providers operate VPNs and security gateways.

Even if your internal team is ready, your migration may be blocked by supplier capability.

Clarysec’s Enterprise Policy, Third-party and supplier security policy, clause 5.6, states:

“Suppliers providing security-relevant services shall disclose material dependencies, cryptographic responsibilities, assurance evidence, vulnerability handling processes, and roadmap changes that may affect the organization’s risk posture.”

For post-quantum readiness, ask critical suppliers:

• Which algorithms, protocols, certificates, and key management services protect our data or transactions?
• Do you maintain a cryptographic inventory or CBOM?
• What is your NIST post-quantum roadmap?
• Will you support hybrid key exchange, post-quantum signatures, or quantum-resistant key establishment?
• How will certificate, token, signing, and encryption changes be communicated?
• What customer action will be required?
• What testing environments will be available?
• How will performance, interoperability, and rollback be handled?
• Are cryptographic responsibilities defined in the contract or shared responsibility model?
• What exit or portability options exist if your roadmap does not meet our risk requirements?

Supplier answers should feed the risk register. Weak answers do not always mean immediate replacement, but they do require treatment. You may need compensating controls, contract amendments, notification clauses, exit planning, enhanced monitoring, or a revised sourcing strategy.

This is especially important under DORA and NIS2-style operational resilience expectations. DORA places emphasis on ICT risk management and ICT third-party risk management, including oversight of critical dependencies. NIS2 Article 21 requires appropriate and proportionate technical, operational, and organizational security risk management measures, including supply chain security, incident handling, business continuity, and cryptography where appropriate. GDPR Article 32 requires security appropriate to risk, including confidentiality, integrity, availability, resilience, and the ability to ensure ongoing protection of personal data.

The regulatory language differs, but the control logic is consistent: know your dependencies, manage the risk, preserve evidence, and act before resilience is compromised.

Cross-compliance mapping: one migration plan, many obligations

A strong post-quantum cryptography migration plan should avoid creating separate evidence packs for every framework. The same core evidence can support multiple obligations if it is structured correctly.

Zenith Controls maps the cryptography topic across ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIST, COBIT 2019, GDPR, DORA, and NIS2 by focusing on the purpose of control rather than the label used by each framework.

Evidence reuse is the key. A cryptographic inventory supports ISO asset management, NIST Identify outcomes, DORA ICT asset visibility, NIS2 risk management, and GDPR accountability. Supplier questionnaires support ISO supplier controls, DORA ICT third-party risk, NIS2 supply chain security, and COBIT vendor governance. Migration test results support secure change, resilience testing, audit readiness, and management review.

What auditors will ask

Post-quantum cryptography is still an emerging audit topic, but auditors already have enough control expectations to ask difficult questions.

An ISO/IEC 27001:2022 auditor will usually start with risk. They will ask whether quantum-related cryptographic risk is identified, assessed, treated, monitored, and reviewed within the ISMS. They will expect evidence that cryptographic controls are selected based on business risk and that responsibilities are defined.

A NIST-oriented assessor may focus on asset visibility, protection mechanisms, supply chain risk, vulnerability management, and governance outcomes. They may ask whether the organization has identified systems using vulnerable public-key cryptography and whether migration planning aligns with NIST direction.

A COBIT or ISACA auditor will often ask about governance. Who is accountable? How does the board receive reporting? Are investments prioritized? Are supplier dependencies managed? Are benefits, risks, and resources balanced?

A privacy auditor may focus on whether encryption and key management remain appropriate to the sensitivity and retention period of personal data.

A DORA or NIS2-focused reviewer will look at resilience, third-party ICT concentration, operational continuity, and incident readiness.

Zenith Controls recommends treating audit preparation as an evidence pathway. Do not wait for auditors to request screenshots and spreadsheets. Build a GRC workspace that connects each cryptographic risk to its owner, affected assets, suppliers, decisions, tests, exceptions, and review dates.

Update policies so the program becomes operational

Most cryptography policies were written for traditional confidentiality and integrity requirements. Post-quantum migration requires targeted additions.

Your cryptography and key management policy should address approved standards, review frequency, data classification, protection lifetime, algorithm agility, key generation, key storage, rotation, destruction, ownership, certificate lifecycle, HSM responsibility, cloud KMS responsibility, exception approval, supplier-controlled cryptography, and post-quantum transition monitoring.

Your secure development policy should address cryptographic library approval, no hardcoded algorithms without review, dependency tracking, secure update mechanisms, performance testing for larger keys or signatures, backward compatibility, rollback, and threat modeling for long-life products.

Your supplier security policy should address cryptographic transparency, post-quantum roadmap requests, contractual notification duties, shared responsibility for encryption and key management, exit planning, and portability.

Your asset management procedure should address cryptographic inventory fields, ownership, evidence sources, review frequency, and integration with CMDB, cloud inventory, certificate management, HSM records, and code repositories.

This is where Clarysec’s policy library helps organizations move faster. Instead of drafting from a blank page, teams can adapt policy clauses into procedures, registers, questionnaires, and audit evidence.

Avoid the most common post-quantum migration mistakes

The most dangerous mistakes are usually governance failures, not technical failures.

Starting with algorithms instead of assets. If you do not know where cryptography is used, algorithm selection will not help.

Ignoring data lifetime. Short-lived transactional data and long-life sensitive archives do not carry the same risk.

Treating suppliers as a later phase. Many cryptographic controls are supplier-managed. If suppliers are not included early, your plan may be unrealistic.

Forgetting signatures. Post-quantum planning is not only about encryption. Digital signatures, code signing, certificates, identity tokens, firmware updates, and document signing need attention.

Assuming cloud providers solve everything. Cloud platforms will play a major role, but responsibility remains shared. You still need to know which services, configurations, keys, regions, and integrations are affected.

Failing to create audit evidence. A migration plan that cannot be evidenced will not satisfy management, regulators, customers, or auditors.

Skipping performance and interoperability testing. Post-quantum algorithms may affect payload size, handshake behavior, latency, storage, embedded constraints, and compatibility.

Metrics the CISO should report to the board

Board reporting should be simple enough to understand and specific enough to drive action. Avoid deep algorithm debates. Focus on exposure, progress, decisions, and residual risk.

A useful board message might sound like this:

“We have completed cryptographic discovery for 72 percent of critical services. Two systems have critical long-life confidentiality exposure, and three suppliers have not yet provided post-quantum roadmaps. We have launched a code signing readiness project and a cloud KMS dependency review. No emergency replacement is recommended today, but supplier uncertainty remains the largest residual risk.”

That is the language of governed cyber risk.

A practical checklist to start this week

You do not need to wait for perfect certainty. Start with steps that improve visibility and governance immediately.

1. Appoint a post-quantum cryptography owner.
2. Add quantum-related cryptographic risk to the ISMS risk register.
3. Identify the top ten services with long-life sensitive data or high integrity impact.
4. Build a minimum viable CBOM for those services.
5. Ask critical suppliers for their post-quantum roadmap.
6. Review cryptography, secure development, supplier, and asset policies.
7. Identify systems with hardcoded algorithms, outdated libraries, manual certificate rotation, or weak ownership.
8. Select one low-risk pilot for crypto-agility testing.
9. Define board metrics and reporting frequency.
10. Schedule an internal audit focused on cryptographic governance and evidence.

The most important move is to convert uncertainty into managed work. Quantum risk may be future-facing, but cryptographic debt exists today.

Next steps with Clarysec

Post-quantum migration will be one of the most complex security transitions of the next decade because it touches identity, encryption, signatures, suppliers, cloud, software, devices, archives, and audit evidence. Organizations that start with governance and inventory will move faster than those that wait for a last-minute replacement cycle.

Clarysec can help you build a quantum-ready cryptography migration plan using:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap for phased implementation and audit readiness
• Zenith Controls: The Cross-Compliance Guide for ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIST, COBIT 2019, GDPR, DORA, and NIS2 mapping
• Cryptography and key management policy for governance-ready cryptographic rules
• Third-party and supplier security policy for supplier roadmap and assurance requirements
• Secure development policy for crypto-agile engineering practices

The best time to begin post-quantum planning is before a regulator, auditor, customer, or board member asks for evidence. Start with the inventory, connect it to risk, and build the migration path one controlled decision at a time.