What should banks prove to regulators about quantum preparedness?

What regulators need banks to show about quantum risk

Regulators are unlikely to be satisfied by a theoretical roadmap alone. Banks need to show a defensible inventory of where public-key cryptography is used, which data remains sensitive over long retention periods, and which systems, counterparties, or service paths can still reach it. The point is to prove that the exposure is understood, not just acknowledged.

That evidence matters because quantum preparedness is partly a cryptography problem and partly a data-path governance problem. A bank can have a migration plan on paper and still fail the test if it cannot identify where long-lived sensitive data sits today, who can access it, and where monitoring would catch abnormal movement or misuse.

Why migration planning alone is not enough

Migration planning is necessary, but by itself it only proves intention. A credible regulatory response needs a sequence, ownership, and prioritisation model that shows which cryptographic dependencies will be retired first, which systems can tolerate delay, and where compensating controls are required while older cryptography is still in use.

That usually means separating the inventory into practical buckets: externally exposed services, internal high-value systems, archival data with long confidentiality life, and embedded dependencies in third-party or infrastructure components. Banks should be able to explain why some paths move first and how they reduce the longest-lived exposure before full cryptographic replacement is complete.

Good evidence also distinguishes between cryptographic migration and business continuity. If a system cannot be upgraded quickly, the bank should still be able to show the interim controls that reduce exposure, such as limiting who can reach the data, tightening segmentation, shortening retention, or increasing monitoring on the paths that matter most.

How to prove exposure visibility in practice

Exposure visibility is the more demanding part of the test because it requires evidence, not aspiration. Banks should be able to identify where public-key cryptography is used, map sensitive data sets that must stay protected for years, and demonstrate that unusual movement across those paths is detected and investigated.

That means regulators will expect more than a policy statement. They will look for asset and data inventories, dependency maps, access paths, monitoring coverage, and incident-ready reporting that ties cryptographic risk to actual systems. If the bank cannot show where the risky paths are, it will struggle to show that it can govern them.

For many institutions, the hardest issue is not the crypto algorithm itself but the surrounding operational reality. Sensitive data often persists in backups, archives, logs, analytics stores, or replicated environments long after the original transaction has closed, so preparedness has to include visibility into where that data can still be reached and how anomalous access would be surfaced.

Risk and Threat Considerations

Quantum risk creates a long-tail exposure problem: the data that matters most is often the data that must remain confidential for the longest time. If a bank cannot identify those data flows and the systems that protect them, an attacker or future decryptor can turn today's collection into tomorrow's compromise.

Failure mechanism: The organisation underestimates which cryptographic dependencies protect long-lived sensitive data, leaving archives, backups, replicated stores, or privileged access paths outside the migration plan and outside monitoring.

Impact: When cryptographic assumptions weaken, previously collected data may become readable, and the bank may discover too late that the exposure was persistent, widespread, and insufficiently governed.

Practitioner Guidance

What to verify: Regulators will respond better to a precise inventory than to a general programme update. Prove which business systems depend on public-key cryptography, which data sets require confidentiality beyond the near term, and which access paths would create the largest blast radius if they were abused.

Decision rule: If a dataset has long retention, high regulatory sensitivity, or high business value, treat its cryptographic exposure as a prioritised migration case even if the surrounding application is not customer-facing. If you cannot map the data path end to end, assume the exposure is bigger than the current inventory suggests.

What practitioners underestimate: The regulator is not only asking whether you have a quantum programme. It is asking whether you can govern the present-day cryptographic estate well enough to survive a future transition, including the detection of unusual movement through sensitive paths before the migration is finished.

Practitioner takeaway: The strongest regulatory proof is a live risk picture, not a slide deck, one that connects cryptographic dependencies, long-lived data, access paths, and monitoring into a governed migration sequence.

Related resources from NHI Mgmt Group

• What should security teams do about secrets hidden in SharePoint?
• How should security teams think about a compromised integration like Drift?
• Which identity controls do regulators expect banks to prove across RBI, FFIEC, MAS, and DORA?
• How should iGaming operators prove their responsible gambling controls actually work when banks and regulators increase scrutiny?