The advice seems solid. CISA, the Australian Signals Directorate's Australian Cyber Security Centre, and the National Security Agency have released joint guidance and a quick-reference list to help organizations assess vendor readiness for post-quantum cryptography (PQC). Ask your vendors the right questions early, and your transition will follow. Many Chief Privacy Officers will read that and send a questionnaire to every supplier by next quarter.
That's a mistake if the questionnaire is your first move.
The Conventional Wisdom
The logic appears sound. Organizations rely on third parties for managed services, cloud capabilities, and other cryptography-dependent products. Cryptography is embedded in systems that are hard to update, tied to long asset lifecycles, and dependent on vendor support or replacement. Industrial control systems and Internet of Things devices are clear examples. If your vendors aren't ready, you can't be ready. The guidance provides vendor-neutral questions to test whether a supplier understands quantum-related risk, is transparent about its cryptographic implementations, and can support a secure, cost-effective, and timely transition.
The premise is credible, and early engagement beats late scrambling.
Why the Questionnaire-First Approach Is Incomplete
A vendor questionnaire measures the vendor. It doesn't measure you. You can't interpret the answers without knowing three things about your own environment.
What you're protecting. Asking "do you support PQC?" tells you little if you haven't established which of your data flows actually need it. The guidance frames the threat as widely used public-key cryptography becoming vulnerable to cryptographically relevant quantum computers (CRQCs). That's an Asymmetric Encryption and Digital Signature problem. Your Symmetric Encryption exposure is a different conversation. If you send a blanket questionnaire, you'll collect answers that don't map to your risk.
Where the vendor sits in your data lifecycle. Your obligations under Article 32 of the GDPR (and the UK General Data Protection Regulation) require Technical and Organisational Measures appropriate to the risk, considering the state of the art. Article 28 puts processor assurance on you as the controller. A vendor that touches Restricted Data with a long Retention Period is different from one that processes short-lived operational data. Without that context, you'll treat a payroll processor and a marketing widget the same.
What you can do with the answers. A questionnaire creates a paper trail. If you can't act on a "no" or a vague "on our roadmap," you've documented a gap without closing it. For a privacy function, an unactioned known gap is worse than an unknown one.
The Evidence
Look at what the guidance itself emphasizes. It stresses that vendors must support a transition before CRQCs become available. It also flags that legacy systems and devices are tied to long asset lifecycles. Those two points interact. A long lifecycle means the cryptography you deploy today may still be running when the threat matures. That's a problem you diagnose internally, by asset and data class, before a vendor ever replies.
Consider a team that sends a standard questionnaire to every supplier and receives forty responses of varying quality. Some vendors answer confidently. Some give marketing language. A few don't reply. The team now has a pile of inconsistent claims and no way to rank them because it never defined which systems matter most. Compare that with a team that first identifies its handful of systems holding long-lived Restricted Data, then sends targeted questions only to those vendors. The second team spends less effort and gets answers it can use.
The guidance's emphasis on transparency over cryptographic implementations points the same way. You can only evaluate transparency if you know what you'd expect to see. That requires your own inventory.
What to Do Instead
Sequence the work so the questionnaire is step three, not step one.
- Build a cryptographic inventory through Data Discovery. Map where public-key cryptography protects your data, and tie each instance to a data class and a Retention Period. Data Labeling helps here. If your labels already distinguish Restricted Data, you can filter on them.
- Rank by exposure and replaceability. Prioritize systems where data must stay confidential for many years and where the vendor controls the update path. Embedded and hard-to-update assets rank high because you can't patch your way out. Systems you control directly can wait.
- Send targeted questions to the top tier. Use the vendor-neutral questions in the joint guidance, but scope them to the vendors your ranking surfaced. Ask each one whether it understands quantum-related risk, how transparent it is about its cryptographic implementations, and what its timeline and cost model look like for transition.
- Write the answers into contracts. Fold PQC commitments into your Article 28 processor terms and your renewal calendar. A promise outside the contract won't survive a procurement cycle.
- Record decisions in your risk register. Document why you accepted, deferred, or escalated each vendor. That's your Defensible Disposal of the question, and it supports your Article 5(2) accountability duty.
When the Conventional Wisdom Is Right
There are cases where going straight to the vendor is correct. If a supplier controls a product you can't inspect, such as a managed service or an embedded device, you have no internal inventory to build. Their disclosure is your only source of truth. In those cases, send the questions early.
It's also right when contract renewal is close. Negotiating leverage disappears after signature, so don't wait for a perfect inventory if a renewal window is closing. Ask first, and refine later.
And the guidance is right on the central point: your transition depends on vendor readiness. We're not arguing against vendor engagement. We're arguing that engagement without self-knowledge produces noise. Know your own exposure, then ask pointed questions of the vendors that matter most. That's how you turn a quick-reference list into a program you can defend.
