Preparing for Regulatory Audits

1. Establish the audit scope before testing controls

Start by recording the audit’s jurisdiction, regulator or contracting authority, in-scope entities, systems, services, data, locations, suppliers, reporting period, and applicable document versions. Do not assume that a standard, regulator publication, or government recommendation automatically creates a universal obligation. The source set includes U.S. federal standards, U.K. guidance, German guidance, an ETSI technical report, NSA resources, and ENISA material; these sources have different roles and jurisdictions. A preparation file should therefore identify which source is binding for the audited entity and which source is being used as supporting good practice or technical context.1

Preserve source status and dates in the audit record. FIPS 203, FIPS 204, and FIPS 205 are final NIST publications dated 13 August 2024. ETSI TR 103 966 V1.1.1 is final and dated October 2024. The NCSC migration guidance is current and was published on 20 March 2025. The NSA resource is identified as current, while the BSI and ENISA sources in the cited source set are also identified as current. These labels matter: an auditor should be able to see whether a control was evaluated against a final standard, current guidance, or an earlier technical recommendation.234516

2. Build an evidence model an auditor can follow

Organise evidence around a simple chain: obligation, risk, asset, control, implementation, test, owner, exception, and review. For every material cryptographic dependency, retain the source requirement or rationale, the affected asset, the responsible owner, the selected mechanism or protocol, the validation or test result, and the decision date. This makes the audit trail understandable even where migration is incomplete or a technology is subject to change.1

• Maintain a register of applicable laws, regulatory requirements, contractual obligations, standards, guidance, and internal policies, with jurisdiction and status.
• Map each requirement to a control objective and an evidence owner.
• Record the system, application, service, data class, algorithm or protocol, key material, implementation, supplier, environment, and lifecycle state.
• Retain design reviews, test plans, test results, approvals, risk acceptances, remediation actions, and review dates.
• Version the evidence set so that an auditor can distinguish current evidence from superseded designs or configurations.

An audit should also explain limitations. FIPS 203 states that conformance does not ensure that a particular implementation is secure, and that using a conforming product does not guarantee the security of the overall system. FIPS 204 and FIPS 205 make the same broader point for digital-signature implementations. Consequently, a certificate, product claim, or standards reference should be accompanied by implementation assurance, secure configuration evidence, key-management evidence, and system-level testing.234

3. Perform a complete cryptographic discovery exercise

A defensible audit preparation process begins with a clear understanding of the current estate. The NCSC recommends identifying key services and applications, recording the data held—including expected lifetime and value to an adversary—and identifying how data is protected in transit and at rest. The discovery should map the systems that operate those services and the systems through which data is processed. It should include software and hardware asset-management processes, not only application source code.1

For each discovered dependency, capture both confidentiality and authentication or integrity use cases. NIST’s context for FIPS 203 explains that large-scale quantum computing could put commonly used public-key key-establishment and digital-signature schemes at risk. The BSI material highlights an immediate concern for information with long secrecy periods: data exchanged for key negotiation may be collected in advance and decrypted later. That risk rationale should be recorded explicitly where it affects prioritisation, without presenting the forecast availability of a cryptographically relevant quantum computer as a known date.724

• Services and applications that use public-key cryptography.
• Data with long retention or secrecy periods and data whose value could attract future decryption attempts.
• Protection of data in transit and at rest, including certificate and key dependencies.
• Cryptographic modules, libraries, firmware, devices, operating technology, industrial control systems, and proprietary protocols.
• Third-party services and products whose cryptographic capabilities, upgrade paths, or validation status affect the control.
• Dependencies that are difficult to replace, resource-constrained, embedded, remote, or not upgradeable.

4. Assess standards, implementation, and system security separately

NIST FIPS 203 defines ML-KEM, a module-lattice-based key-encapsulation mechanism standard. Its implementation provisions include protection of sensitive values such as randomness, decapsulation keys, and shared secret keys. FIPS 203 also states that its three ML-KEM parameter sets provide different trade-offs between security strength and performance and that the parameter sets are approved to protect sensitive, nonclassified communications systems of the U.S. federal government. These facts may be relevant to a particular U.S. federal scope, but they do not establish that every organisation or every use case must deploy ML-KEM.2

FIPS 204 defines a module-lattice-based digital-signature scheme, and FIPS 205 defines a stateless hash-based digital-signature scheme. Both standards describe signing and verification functions and require additional assurance around implementation security. FIPS 204 specifies, among other requirements, a fresh random seed generated using an approved random-bit generator with at least 192 bits of security strength for the stated ML-DSA key-generation process. FIPS 205 states that SLH-DSA is designed to resist attacks from a large-scale quantum computer and that digital signatures still require assurances such as identity and private-key possession.34

Separate four audit questions: whether the selected algorithm or protocol is within the applicable standard or approved profile; whether the cryptographic module is implemented and configured correctly; whether keys, randomness, identities, certificates, and lifecycle processes are controlled; and whether the overall system provides an acceptable level of security. The FIPS qualifications expressly place responsibility on the implementer and, for the cited federal context, the responsible authority. A standards citation answers only part of the audit question.234

5. Review hybrid designs as security decisions, not shortcuts

ETSI TR 103 966 V1.1.1 explains that deploying post-quantum cryptography alongside traditional algorithms in a hybrid scheme or protocol can mitigate vulnerabilities in post-quantum implementations or provide backward compatibility during migration. It also warns that hybrid designs increase protocol, implementation, and key-management complexity. Bandwidth, computation, and latency overheads may be reduced by pairing a post-quantum algorithm with a traditional elliptic-curve algorithm, but the resulting security properties depend on the particular design and use case.5

For audit purposes, record whether a hybrid design is intended to provide hybrid security, hybrid interoperability, or both. Test algorithm negotiation and downgrade protection. Document what security guarantee remains if one component fails, how keys are combined, how certificates and identities are bound, and how traditional-only clients are handled. ETSI cautions that inappropriate hybrid schemes can be less secure than a non-hybrid post-quantum mode and that the requirements may differ for confidentiality and authentication.5

Do not approve an unstandardised or insufficiently analysed post-quantum algorithm merely because it appears in a hybrid construction. ETSI advises against deploying post-quantum algorithms that have not gone through standardisation or received sufficient analysis. It also describes protocol constraints: for example, large post-quantum key exchanges can create fragmentation issues in IKEv2, while accreditation or module-validation requirements may constrain the permitted algorithms. Record those constraints, the compensating controls, and the decision owner.5

6. Demonstrate governance, cryptoagility, and operational readiness

Cryptoagility should be treated as an architectural and governance control: systems should be able to respond to developments, implement future recommendations and standards, and replace mechanisms that no longer provide the desired security level. The BSI guidance presents cryptoagility as important not only because of quantum computing but also because classical attacks can evolve and previously acceptable algorithms or key lengths can become obsolete. Evidence can include approved architecture patterns, algorithm-selection indirection, dependency inventories, replacement procedures, test environments, supplier commitments, and exercises of the change process.1

Migration planning must account for physical infrastructure, operating technology, and industrial control systems. The NCSC notes that changes to physical infrastructure need significant planning and should, where possible, coincide with maintenance and improvement work. In industrial control environments, remote access channels need secure authentication, and integrity can be critical even where confidentiality of sensor data is less demanding. Industrial IoT devices may be resource-constrained, difficult to service, embedded in larger products, non-replaceable, proprietary, or not yet compatible with post-quantum protocols.1

1. Assign an accountable risk owner and technical owner for each cryptographic control.
2. Prioritise by data lifetime, adversary value, exposure, dependency complexity, and replacement difficulty.
3. Define migration goals and an initial plan before selecting individual product changes.
4. Use controlled pilots and interoperability testing for protocols, certificates, modules, and key-management systems.
5. Track residual risk, exceptions, compensating controls, target review dates, and evidence of closure.
6. Reassess the plan when standards, regulator guidance, protocol support, or system constraints change.

7. Prepare the audit conversation and remediation record

Auditors commonly need a coherent explanation rather than a collection of disconnected documents. Prepare a short control narrative for each material area: what the organisation protects, why the control applies, how the control is implemented, how it is tested, who reviews it, and what remains unresolved. Cross-reference the narrative to system inventories, architecture diagrams, configuration records, supplier evidence, test outputs, approvals, and risk acceptances.1

When a control is not yet complete, state the limitation precisely. Explain whether the gap is caused by an unavailable protocol, an unupgradeable device, a validation constraint, a supplier dependency, a performance issue, or a deliberate risk-based sequencing decision. Avoid claiming that a hybrid design, a conforming module, or a standards adoption decision eliminates risk. The evidence supports a more cautious conclusion: standards and guidance provide technical direction, while the organisation remains responsible for implementation and system-level assurance.23415

Conclusion

Preparing for a regulatory audit is an exercise in scope control, evidence quality, and honest treatment of uncertainty. Establish the applicable jurisdiction and document status; discover the cryptographic estate; map data lifetime and protection; separate standards conformance from implementation and system security; test hybrid designs and downgrade resistance; and maintain ownership, exceptions, cryptoagility, and review records. The cited sources support proactive planning for post-quantum risks, but they do not support one universal deadline or a conclusion that any single standard or product guarantees overall security.1234