“Member States should consider migrating their current digital infrastructures and services for public administrations and other critical infrastructures to Post-Quantum Cryptography as soon as possible, inducing a fundamental shift in cryptographic algorithms, protocols and systems.”Comisia Europeană · Recomandarea (UE) 2024/1101 privind o foaie de parcurs coordonată de punere în aplicare a tranziției la criptografia post-cuantică · 2024 · Recomandarea (UE) 2024/1101 a Comisiei din 11 aprilie 2024, considerentul (5) — migrarea la criptografia post-cuantică
A control that produces its own evidence is audited once and reported into several frameworks.
Three lines are already visible. First: evidence collects itself. A control described as prose and checked once a year is replaced by a control expressed as an executable rule that produces the record that it worked; the auditor reads a history, not a screenshot. Second: the supply chain. Controls 5.19-5.23 of Annex A and Article 21(2)(d) of NIS2 ask the same thing — know what your suppliers risk, and write it into the contract. The threat landscape published in 2025 by the European cybersecurity agency analysed 4,875 incidents between July 2024 and June 2025, with phishing the dominant intrusion vector, in 60% of cases. Third: post-quantum cryptography. The coordinated roadmap of June 2025 asks that the transition start by the end of 2026 and that critical infrastructures migrate no later than the end of 2030, onto the algorithms standardised in August 2024 by the American institute of standards and technology.
Continuous evidence changes the order of work. Before, you built the file when the audit arrived. Now the control is written as a rule, the rule runs daily, and it leaves traces. The shift is not technological but about timing: the question is no longer what you did in December, but what happened on Tuesday at three. A concrete case: an admin account password expires automatically after ninety days. The rule enforces it on its own and records the enforcement. The auditor sees in the history that no password lived longer. The same history then serves NIS2, ISO, or a customer's requirements, with no rework. Next step: what happens when two frameworks demand the same control, worded differently.
The next step is mapping. Each framework has its own language, but the requirements overlap. For example, supplier risk management appears both in Annex A, in the controls about supplier relationships, and in NIS2, in the article on supply chain security. The content is nearly identical: know what your suppliers can affect and put that into contracts. If you write the control once, as an executable rule, then tag it with the references from each framework, one collection feeds several answers. A concrete case: a major client's yearly questionnaire asks for supplier policies; you pull them from the same history that already serves the auditor, instead of rebuilding them. Here the limit appears: some requirements, like migrating to post-quantum cryptography, cannot be reduced to one shared control. Next step: what a control does when the requirement is a transition, not a state.
Why it matters Evidence produced once and read by several frameworks is the only way the number of audits can grow without the effort growing with it.