Your organization isn't defending against nation-states. You're not a defense contractor, you don't hold classified data, and your threat model focuses on ransomware groups and opportunistic attackers. So when your CISO brings up post-quantum cryptography (PQC), it's tempting to punt the decision to 2030.
That's a mistake. This checklist helps you evaluate your actual exposure and start making defensible decisions now, before quantum-capable adversaries force your hand.
What This Checklist Covers
This checklist addresses PQC readiness from a compliance and risk management perspective. It's designed for organizations pursuing or maintaining ISO/IEC 27001 or SOC 2, where cryptographic controls underpin multiple requirements. You'll assess your current cryptographic inventory, evaluate quantum-related risk, and establish a transition roadmap that satisfies both auditors and your board.
The goal isn't to migrate everything tomorrow. It's to document a rational, risk-based approach that acknowledges the threat timeline and positions your organization ahead of regulatory mandates.
Prerequisites
Before you start this checklist, you need:
- Current cryptographic inventory: A documented list of where asymmetric encryption (RSA, ECC) protects data at rest, data in transit, or authentication mechanisms.
- Data classification scheme: Understanding which information assets would cause material harm if exposed, even years from now.
- Risk register access: Ability to add and track emerging technology risks.
- Budget authority or escalation path: PQC isn't free; someone needs to approve the investment.
If you're missing these prerequisites, pause here. You can't make informed PQC decisions without knowing what you're protecting and how.
Checklist Items
1. Identify cryptographic dependencies in scope systems
Document every system component that relies on RSA, ECC, or similar asymmetric algorithms. Include TLS connections, VPNs, code signing certificates, database encryption, and authentication tokens.
Good looks like: A spreadsheet listing each system, the algorithm in use, the key size, the vendor or library providing it, and the system owner. You can answer "where do we use RSA 2048?" in under five minutes.
2. Classify data by quantum exposure window
For each cryptographic implementation, determine how long the protected data remains sensitive. Intellectual property might matter for a decade; session tokens expire in hours.
Good looks like: Each data classification tier has a documented sensitivity window. You've flagged any data that would cause harm if decrypted five or ten years from now, acknowledging the "harvest now, decrypt later" threat.
3. Map cryptographic controls to ISO/IEC 27001 or SOC 2 requirements
Identify which framework controls depend on your current cryptographic implementations. In ISO/IEC 27001, this includes controls in Annex A 8.24 (Use of cryptography). For SOC 2, examine CC6.1 (logical and physical access controls) and CC6.7 (encryption of data in transit and at rest).
Good looks like: A control-to-system mapping that shows which compliance obligations would fail if quantum computers break your current encryption. Your auditor can trace from control to implementation.
4. Assess vendor and cloud provider PQC roadmaps
Contact your cloud providers, SaaS vendors, and infrastructure suppliers. Ask when they plan to support NIST FIPS 203-205 algorithms and whether migration will be transparent or require configuration changes.
Good looks like: Documented responses from each critical vendor, including timelines. You know which systems will upgrade automatically and which require manual intervention. You've noted any vendors with no PQC plan.
5. Evaluate quantum risk in your risk register
Add quantum computing as a distinct risk. Assign impact based on your data classification (Step 2) and likelihood based on credible timelines. Google claims quantum computers may break modern cryptographic systems as soon as 2029; use that as your upper bound for likelihood assessment.
Good looks like: A risk entry with defined impact and likelihood scores, documented assumptions, and a risk owner. The entry explicitly addresses nation-state threat actors and harvest-now-decrypt-later scenarios. Your risk treatment plan references this assessment.
6. Prioritize systems for PQC migration
Rank your cryptographic implementations by exposure: systems protecting long-lived sensitive data go first, especially if they're accessible to external parties. Consider operational constraints and vendor dependencies.
Good looks like: A prioritized migration list with justification for each ranking. High-priority systems have target migration dates. You can defend the order to an auditor or executive.
7. Establish a crypto-agility plan
Document how you'll switch algorithms if vulnerabilities emerge in current PQC standards. This includes configuration management processes, testing protocols, and rollback procedures.
Good looks like: A documented procedure for algorithm changes that doesn't require rewriting applications. You've tested key rotation on at least one non-production system. Your change management process (ISO/IEC 27001 Annex A 8.32) explicitly covers cryptographic updates.
8. Define interim key-size upgrades
For systems that can't migrate to PQC immediately, document plans to increase key sizes. Move RSA 2048 to RSA 4096; upgrade AES-128 to AES-256 where feasible.
Good looks like: A list of systems receiving interim upgrades, with completion dates and responsible parties. You've confirmed that hardware and software can support larger keys without performance degradation.
9. Review regulatory and contractual obligations
Check whether your industry faces incoming PQC mandates. Executive Order EO 14412 establishes more rapid adoption of PQC systems within the Federal government; if you're a government contractor, you're affected. Review customer contracts for cryptographic requirements.
Good looks like: A summary of applicable mandates with compliance deadlines. You've identified any contractual obligations that reference specific algorithms or key sizes. Your legal or compliance team has reviewed the analysis.
10. Brief your board or risk committee
Present your quantum risk assessment, migration plan, and budget requirements to decision-makers. Frame it as a strategic investment, not just a technical upgrade.
Good looks like: A board presentation that connects quantum risk to business objectives, includes cost estimates and timelines, and requests explicit approval for the migration roadmap. Meeting minutes document the decision and any conditions.
Common Mistakes
Assuming quantum is only a nation-state problem: Even if you're not currently targeted, quantum access could enable state-sponsored economic espionage or open doors for aligned hacking groups. Your IP might be worth stealing.
Waiting for perfect information: You won't know the exact threat timeline. Make decisions based on reasonable scenarios, not certainty. Document your assumptions and revisit them annually.
Ignoring cloud provider migrations: If your cloud provider switches to PQC by default, you might inherit the change without testing. Understand their roadmap and ensure your applications remain compatible.
Treating PQC as a one-time project: Cryptographic systems evolve. Build ongoing review into your ISO/IEC 27001 management review (Clause 9.3) or SOC 2 monitoring controls.
Skipping the risk register: If quantum risk isn't documented, it doesn't exist in your compliance program. Auditors will ask why you migrated without a formal risk assessment.
Next Steps
Complete this checklist within the next quarter. Assign a single owner for the PQC transition program and schedule quarterly reviews.
If you're pursuing ISO/IEC 27001 certification or recertification, ensure your Statement of Applicability addresses cryptographic controls with reference to your PQC roadmap. For SOC 2, include PQC planning in your control environment documentation and risk assessment.
Your next compliance audit should show documented progress: an updated risk register, vendor discussions, and a board-approved migration plan. That's the evidence auditors need to see you're managing emerging threats, not ignoring them.
