← Guide overview

Readiness self-assessment

Quantum Readiness for Banking Professionals: all chapters

• 1. What quantum threatens in a bank, and what it doesn't
• 2. Where cryptography lives in a payments estate
• 3. Building a cryptographic inventory
• 4. Deciding what to fix first
• 5. Crypto-agility first
• 6. Vendors and third parties
• 7. Governance and the regulatory map
• 8. A phased roadmap
• Readiness self-assessment
• Glossary

Twenty questions, grouped by the topics in this guide. They produce an indicative readiness profile, not a validated maturity rating: the scoring hasn't been benchmarked against other banks, so use it to decide where to look next, not to compare yourself with peers. Your answers stay in your browser: nothing is stored or sent anywhere, and the results disappear when you leave the page. The site uses cookie-free page-view analytics; your answers are not included.

Answer from documented evidence, not assumptions. Before answering "Yes", you should be able to point to an artifact, an owner, a date or a test result. A supplier's announced roadmap isn't the same as a capability that's delivered, tested and approved for production.

Each "Yes" scores 2, "Partly" scores 1 and "No" or "Don't know" scores 0. "Don't know" counts as no on purpose: if nobody can answer, the capability probably isn't there.

Ownership and governance (Chapter 7)

There is a single named owner for post-quantum readiness, and an executive sponsor.

Quantum risk is recorded on the technology or cyber risk register.

Progress is reported regularly to a senior committee using specific measures.

We can state precisely which regulatory sources apply to us, and which only signal direction.

Inventory (Chapter 3)

At least one critical business flow has a cryptographic inventory, end to end.

Inventory records capture what each item protects and how long that data must stay secret.

Each record is labelled as confirmed or inferred, with an owner.

The inventory has an owner and is refreshed on a regular cycle.

Prioritisation (Chapter 4)

We separate confidentiality exposure (key agreement) from signature exposure in our planning.

We have identified our longest-lived sensitive data and the connections that carry it.

We have a documented, challengeable method for ranking what to fix first.

We know which items block others, such as HSMs and certificate authorities.

Crypto-agility (Chapter 5)

New systems are not allowed to hard-code cryptographic algorithms.

Most of our certificates are issued and renewed automatically.

Our HSMs support the NIST post-quantum standards in a specific, tested firmware or module version, or have a confirmed, dated path to it.

Design reviews consider the larger size of post-quantum keys and signatures.

Suppliers and networks (Chapter 6)

Our critical suppliers have given us post-quantum roadmaps with dates.

Post-quantum requirements are included in procurement and contract templates.

We track the post-quantum plans of the payment networks we depend on.

Hybrid key agreement is in use, or piloted, on at least one high-exposure connection.

See my results Start again

How to read your result

Start with your weakest area, not the total. A high total can hide a single weakness that stalls everything: a bank with a strong inventory but no supplier engagement will still be blocked by its suppliers' timetables. The results show the weakest area first, why it matters, a recommended next step, the evidence to collect, and when to escalate.

The total and its band are a rough summary only:

• 0–13, Getting started. Foundations are missing. Chapter 8's first 100 days is designed for this starting point.
• 14–27, Building. Some foundations exist. Focus on the weakest area and on starting the long-lead items: HSMs, certificate authorities and suppliers.
• 28–40, Advanced. Most capabilities are reported in place. Check that each "Yes" is backed by evidence, keep the inventory current and watch the critical path.