Copyable templates for post-quantum readiness

Three working templates from the Quantum Readiness for Banking Professionals guide, ready to copy into a spreadsheet or document. Each one comes with an example, instructions and its limits. Copying puts plain text on your clipboard; nothing is downloaded, stored or sent anywhere.

These are starting points, not validated instruments. The example values come from Larkfield Bank, a fictional bank used throughout the guide, and the scoring weights haven't been tested against real institutions. Adapt them to your own risk framework and data classification.

1. Cryptographic inventory record

One row per use of cryptography. Start with the core fields: asset, job, quantum status, what it protects, how long it must stay secret, owner, third party and confidence. Add the rest as you learn more. Chapter 3 explains each field and how to fill it in.

Field	What to record	Example
Asset	A name people recognise	Payments hub to messaging interface connection
Where it lives	System, and which of the eight surfaces in Chapter 2: source code and configuration, data in transit, certificates and PKI, key stores and HSMs, data at rest, third parties, firmware and hardware, or identity and tokens	Data in transit, payments platform
Job	Key agreement, signature, key custody, encryption or integrity	Key agreement and machine identity
Algorithm	What it uses today	Elliptic-curve key exchange, RSA certificates
Quantum status	Vulnerable, check key size, or not affected, as defined in Chapter 1	Vulnerable
What it protects	The data or process at stake	Outgoing payment instructions
How long it must stay secret	From data classification and retention policy	Seven years or more
Depends on / depended on by	Upstream and downstream links	Payments hub, messaging interface, internal certificate authority
Owner	A named team, not "IT"	Payments platform team
Third party?	Who controls it, if not you	Partly: messaging interface vendor
Ease of change	Configurable, pinned in settings, or hard-coded	Pinned in configuration
Confidence	Documented or inferred, with a note	Inferred: from a network scan, owner to confirm
Discovery method	Network scan, code scan, configuration review or supplier statement	Network scan
Last confirmed	Date and by whom	Not yet confirmed
Disposition	Migrate, upgrade, replace, isolate, accept temporarily with risk approval, or investigate	Investigate, then migrate

2. Supplier post-quantum questionnaire

For critical suppliers first: HSMs, core platforms, card processing and payment network connectivity. Ask for dates and evidence, not general statements. Chapter 6 covers tiering suppliers, judging the answers and contract clauses.

1. Which public-key algorithms does your product use today, and for which functions (key agreement, signatures, certificates, key storage)?
2. Which of the NIST post-quantum standards (ML-KEM, ML-DSA, SLH-DSA) do you support now, in which software or firmware version (and, for HSMs, which validated module version), and which are on your roadmap, with dates?
3. Will support come through a software or firmware update, or will it require new hardware or a new version? Has it been tested in an architecture like ours?
4. Do you support hybrid operation, running current and post-quantum algorithms together?
5. Can algorithms be changed by configuration, or does each change need a new release from you?
6. How do the larger post-quantum keys and signatures affect performance, storage or message sizes in your product?
7. How are you managing post-quantum readiness in your own suppliers and in the libraries your product uses?
8. Can you provide a cryptographic inventory, or a CBOM, for the product?
9. Who is your named contact for post-quantum questions, and how will you notify us of roadmap changes?
10. Are your stated dates committed, planned or aspirational?

Record each capability in one of four states, because each is a different planning input: announced, released, tested in your architecture and approved for production. Then rate the response Ready, On track, Unclear or At risk.

3. Prioritisation worksheet

Score each inventory item from 1 (low) to 3 (high) on four factors, then rank. Exposure counts double because it carries the irreversible harm: Priority score = (2 × exposure) + blast radius + dependency order + lead time, out of 15. Chapter 4 explains the factors and why scores rank but lead times schedule.

• Exposure: how sensitive the protected data or process is, and for how long. This is Mosca's X; the Mosca calculator helps with it.
• Blast radius: how much depends on this item.
• Dependency order: whether other items are waiting for this one to change first.
• Lead time: how long the change will take, including suppliers, networks and counterparties.

Using them well

• Inventory first. The worksheet and questionnaire both draw on inventory fields; without them, scores are guesses.
• Keep evidence. A score or rating should point to the document, scan or supplier answer behind it.
• Revisit regularly. Supplier dates slip and standards change; record a review date with every entry.