How do organisations get started with Quantum Risk Assessment?

What a quantum risk assessment is actually trying to expose

A practical quantum risk assessment is less about predicting a “quantum event” and more about finding where cryptography assumptions could fail first. The key question is which systems, data and trust relationships still depend on algorithms that may become vulnerable, hard to migrate, or expensive to replace before the business can adapt.

That means the assessment has to be wider than a certificate review. It should cover applications, data flows, identities, third parties and long-lived secrets, because the business impact usually comes from what those keys, tokens and certificates protect, not from the cryptographic algorithm in isolation.

The most useful output is a ranked view of exposure: where the organisation has high-value data, long retention periods, external dependencies, or systems that cannot be changed quickly. For a migration-oriented view of this problem, organisations often pair the assessment with a Post-Quantum Cryptography Migration Guide so the inventory feeds directly into a transition plan.

How to scope the inventory without making it too broad or too shallow

Start by inventorying cryptographic use across the places where risk accumulates, not just where encryption is obvious. Look at data-at-rest, data-in-transit, signing, authentication, key exchange, certificate chains, API access, service-to-service trust and third-party integrations. In parallel, record where those protections are embedded in code, appliances, managed services or vendor platforms.

Then map each cryptographic dependency to business context: what it protects, how long the protected asset must remain confidential or trustworthy, and how difficult it would be to swap the algorithm, certificate chain or key management approach. A short-lived low-value workflow is rarely the same priority as archived customer data, signing keys, or identity systems that must keep working for years.

It is also worth separating direct cryptographic exposure from dependency exposure. A system may not store sensitive data itself, but if it anchors authentication, code signing, or vendor trust, its migration difficulty can be a major driver of quantum risk. This is where owners, dependencies and technical constraints should be documented together, not as separate registers.

How to turn findings into a remediation plan leaders can fund

The first useful prioritisation lens is business impact, not cryptographic elegance. Rank the items that protect the most valuable data, the longest-lived secrets, and the most difficult-to-change trust paths. Then factor in migration effort, because a low-complexity fix that can be delivered quickly often reduces more risk than a perfect solution that sits in design for months.

A sensible plan usually separates three classes of work: quick wins, medium-term transitions, and hard cases that need exception handling or architecture change. Quick wins might include inventory cleanup, dependency discovery, and reducing unnecessary crypto sprawl. Medium-term work often covers hybrid approaches, vendor readiness, and certificate or protocol upgrades. Hard cases are legacy systems, embedded devices, and externally governed services where the organisation may need compensating controls until replacement is realistic.

Third-party exposure deserves explicit treatment. If a vendor, SaaS platform or managed service controls the cryptography, the assessment must capture who owns the migration decision, who supplies the timetable, and what evidence exists that the supplier is moving. For organisations that need a structured way to assess this dependency, the Third-Party Risk Management Guide gives a useful companion model for vendor ownership, monitoring and exit planning.

Risk and Threat Considerations

The main risk is not “quantum breaking everything at once”, but sensitive data being collected now and decrypted later, or trust systems becoming brittle before migration is complete. Long-lived secrets, archived records, signing keys and identity dependencies are the most important places to look because they create the longest exposure window.

Failure mechanism: Public-key algorithms remain embedded in authentication, key exchange or signing paths longer than the organisation can replace them, while protected data or credentials outlive the assumed security margin.

Impact: Confidentiality loss can arrive retroactively for stored data, trust can degrade if signing or authentication chains are not migrated cleanly, and remediation costs rise sharply when the organisation must react under time pressure.

Practitioner Guidance

What to prioritise: Start with systems that combine long data retention, critical business trust, and difficult migration paths. Those are the places where quantum exposure is most likely to become material before the rest of the estate.

What to verify: Make sure each item in the inventory names the owner, the algorithm family, the dependency it supports, the vendor or platform involved, and the realistic migration constraint. If you cannot answer those four questions, the risk ranking is still too vague to use.

Decision rule: If a system protects data or trust that must remain secure for years, treat it as a near-term planning item even if it is not urgent operationally today. If the cryptography is externalised to a supplier, the assessment should move from technical discovery to contractual and roadmap verification immediately.

Practitioner takeaway: The best starting point is a cryptography inventory tied to business value and change difficulty, because that is what turns “quantum risk” from an abstract concern into a defensible remediation queue.

Related resources from NHI Mgmt Group

• How do organisations get started with privacy risk assessment?
• How do organisations get started with Privacy Risk Assessment Methodology (PRAM)?
• How do organisations get started with supply chain risk assessment?
• When should organisations treat an NHI as a high-priority risk?