Harvest-now/decrypt-later is easy to exaggerate and easy to dismiss. A good risk-committee briefing should do neither. The immediate risk is not that a cryptographically relevant quantum computer is breaking production TLS today. The immediate risk is that encrypted traffic and files can be collected today and decrypted later if their protection still depends on vulnerable public-key algorithms.
Separate capture risk from decryption timing
Risk committees need a clean split between two facts. First, capable adversaries can archive encrypted material now at low cost. Second, the future date when large-scale quantum decryption becomes practical remains uncertain. The business question sits between those facts: which captured material would still matter if decrypted during its retention lifetime?
Use ranges, not prophecy
Avoid presenting a single “Q-Day” date. Public guidance from NIST, NSA, BSI, ENISA, and other agencies points to migration readiness rather than a precise countdown. A better briefing uses planning ranges, shows sensitivity to earlier and later scenarios, and asks whether the organisation can complete inventory, testing, procurement, rollout, and exception handling inside those ranges.
Turn the topic into decisions
The committee does not need to approve every algorithm choice. It should approve a policy baseline: which data classes require post-quantum readiness first, which legacy systems may receive risk exceptions, which vendors must provide migration evidence, and which metrics will be reviewed quarterly. This moves the discussion from abstract quantum timelines to accountable programme governance.
Keep the language auditable
Good HNDL reporting avoids claims such as “quantum-proof” or “future-proof”. Use terms like standards-aligned, hybrid, mapped, readiness, and migration path. Those terms are less dramatic, but they are easier to defend in procurement records, regulatory conversations, and audit evidence packets.