The 2035 deadline for post-quantum cryptography isn't nine years away. It started the moment someone began harvesting your encrypted data for future decryption. If you're managing an ISO/IEC 27001 Information Security Management System (ISMS), you already have the framework you need to address this threat. You just need to activate the right controls and extend them in specific ways.
Why This Matters Now
Quantum computers don't yet exist in a form that can break RSA encryption. However, mathematician Peter Shor proved it's theoretically possible in 1994. The Cloud Security Alliance estimates a cryptographically relevant quantum computer (CRQC) could arrive by 2035. That's the optimistic scenario.
The immediate threat is harvest now, decrypt later (HNDL). Adversaries are stealing encrypted data today, stockpiling it for future decryption. According to Europol's threat analysis, policymakers and governments face high HNDL risk, but high net-worth individuals are also sensitive targets. Your data's vulnerability depends on how long it retains value and how long it takes to build a working CRQC.
The UK's National Cyber Security Centre has set a 2028 milestone for organizations to define migration goals and complete data discovery. The US Treasury Department launched its Quantum-Readiness Task Force following Executive Order 14412 in June 2026. Both recognize that migrating cryptographic systems takes years, not months.
Here's the reality: an Entrust/Ponemon 2026 survey found only 43% of organizations report full visibility of their cryptographic estate, and only 26% have a fully implemented crypto agility strategy. The White House called industry approaches to cryptography discovery and management "often insufficient."
This isn't a future problem. It's a current gap in your ISMS that you can address with existing controls.
What You Need Before Starting
Before migrating to post-quantum cryptography, you need visibility and ownership:
Senior Sponsorship: Both the NCSC and Executive Order 14412 recommend a named senior sponsor. Under ISO/IEC 27001 clause 5.3, assign this as a defined information security role with explicit responsibilities for cryptographic readiness.
Asset Inventory Baseline: You can't protect what you don't know exists. Pull your current asset register (required by control A.5.9). You'll extend this, so start with what you have.
Supplier Relationship Documentation: Gather your vendor contracts, service agreements, and contact information for technical account managers. Much of your cryptography lives in vendor products, not systems you control directly.
Data Classification Scheme: Review your implementation of control A.5.12. You'll need to add data lifetime as a classification attribute.
Access to Cryptographic Dependencies: Identify where cryptography appears in your stack: TLS certificates, VPN configurations, database encryption, backup encryption, code signing, API authentication. Don't limit this to obvious places.
You don't need quantum physics expertise. You need structured information security management, which you're already doing.
Step-by-Step Implementation
Step 1: Extend Asset Management for Cryptographic Visibility (A.5.9)
Add these attributes to your asset inventory:
- Cryptographic algorithms in use (RSA-2048, AES-256, etc.)
- Key management system or service
- Vendor/product providing the cryptography
- Last cryptographic update date
- Upgrade pathway (vendor-managed, self-managed, unknown)
For each system in your asset register, document the cryptographic dependencies. If you use a CMDB, add custom fields. If you maintain spreadsheets, add columns. The format matters less than completeness.
Step 2: Classify Data by Lifetime and Adversary Value (A.5.12)
Extend your data classification scheme to include:
- Expected data lifetime (how long this data retains business value)
- Sensitivity to HNDL (high/medium/low based on adversary interest)
- Re-encryption priority (high/medium/low)
Long-lived, high-value data gets priority: multi-year contracts, personnel records, intellectual property, strategic plans. Transactional data with short business value gets lower priority.
Step 3: Create a Cryptographic Policy (A.8.24)
ISO/IEC 27001 control A.8.24 specifically addresses cryptography use. If you don't have a dedicated cryptographic policy, create one now. Include:
- Approved cryptographic algorithms (reference NIST or your national standards body)
- Key length requirements
- Key management procedures
- Crypto-agility principles (the ability to swap algorithms without redesigning systems)
- Post-quantum readiness objectives
Set a policy requirement that new systems must support algorithm agility. Don't hardcode cryptographic choices into application logic.
Step 4: Engage Suppliers on PQC Roadmaps (A.5.19-A.5.24)
For each vendor providing cryptographic functionality:
- Request their post-quantum cryptography roadmap in writing
- Ask for specific dates when PQC algorithms will be available
- Clarify whether upgrades require new licenses, hardware, or professional services
- Document this in your supplier review process (A.5.21)
Add PQC readiness dates to vendor agreements going forward (A.5.19). The IO State of Information Security Report 2025 found that 61% of respondents had a supplier-caused incident in the prior year. Don't let inadequate vendor PQC planning become your next incident.
Step 5: Build a Migration Plan
Using your extended asset inventory and data classification:
- Identify high-priority systems (long-lived data, high HNDL risk, vendor readiness confirmed)
- Map dependencies (which systems must migrate together)
- Establish a testing protocol for post-quantum algorithms
- Set internal milestones aligned with NCSC guidance: discovery complete by 2028, high-priority migrations by 2031, full migration by 2035
Document this as part of your operational planning and control (A.5.37). Treat it like any other multi-year security initiative.
Validation - How to Verify It Works
You can't wait until 2035 to test. Validate your readiness now:
Cryptographic Inventory Completeness: Audit a sample of systems. Can you identify every cryptographic dependency? If you find gaps, your inventory isn't complete.
Supplier Response Rate: Track how many vendors provided concrete PQC roadmaps versus vague assurances. Low response rates indicate you need stronger contract language.
Algorithm Agility Testing: Pick a non-production system and attempt to swap its cryptographic algorithm (for example, change a TLS configuration from RSA to ECDSA). If this requires application changes, you lack crypto-agility.
Classification Accuracy: Review your data lifetime estimates with business stakeholders. Technical teams often underestimate how long the business retains data.
Internal Audit: Add PQC readiness to your next internal audit scope (clause 9.2). Verify that assigned roles understand their responsibilities and that controls are operating as documented.
Maintenance / Ongoing Tasks
Post-quantum readiness isn't a project with an end date. Build it into your ISMS:
Quarterly Supplier Reviews: Check vendor PQC roadmap progress during regular supplier performance evaluations (A.5.21). Roadmaps slip. Track them.
Annual Cryptographic Inventory Updates: Technology changes. New systems get deployed. Review and update your cryptographic asset inventory at least annually, ideally as part of your management review (clause 9.3).
Policy Updates: As NIST and other standards bodies release new guidance, update your cryptographic policy (A.8.24). Subscribe to NIST's post-quantum cryptography updates and your national cyber security center's advisories.
New System Requirements: Every new system procurement or development project should include PQC readiness in its requirements. Make this part of your secure development lifecycle or procurement checklist.
Risk Treatment Plan Reviews: As quantum computing capabilities advance, reassess your risk treatment plans (clause 6.1.3). What's acceptable risk today may not be acceptable in 2030.
The G7 Cyber Expert Group on coordinated transitions to PQC in the financial sector points to ISO/IEC 27001 as a pivotal standard. You're not starting from scratch. You're extending controls you already maintain to address a specific, well-defined threat. The framework is ready. Your ISMS just needs to use it.
