In the first quarter of 2026, French organisations recorded 54,000 security incidents, 37% more than in the first quarter of 2025 (i-leadconsulting.com, Q1 2026 data). Between two annual audits, your exposed perimeter has changed: a new supplier integrated without a security review, an administration account still active after a departure, an application deployed in an emergency. Last year's audit tells you what your organisation was. It does not tell you what it is.
The annual audit model and its implicit assumptions
The annual audit rests on an implicit assumption: the level of compliance observed on one day a year is stable enough to be representative of the rest of the year. This assumption was defensible when the regulations themselves operated on annual cycles. It no longer is.
NIS2 requires an early warning within 24 hours. DORA requires a structured programme of continuous testing. The GDPR sets the accountability principle, which obliges the controller to demonstrate compliance with the principles at all times. These three texts share one feature: they measure your posture against the time of the incident, not the time of the audit. This gap creates an exposure that most current GRC programmes do not cover.
What NIS2 actually requires
Article 23 of the NIS2 Directive requires notification of a significant incident within 24 hours (early warning), 72 hours (full notification) and one month (final report). These deadlines create a direct operational constraint: to notify within 24 hours, you must have detected the incident within a few hours, assessed whether it is significant within the meaning of Implementing Regulation (EU) 2024/2690, and identified the assets affected.
This process presupposes a permanent state of knowledge of your perimeter. An organisation that audited its security posture in January and has not actively monitored its perimeter since cannot, in practice, meet Article 23. The ability to notify within 24 hours is a process architecture constraint as much as a technical security one.
The same reasoning applies to entities waiting for the French Resilience Law. The text's examination in the National Assembly has been postponed several times, but the substantive NIS2 obligations, particularly on the management of cyber risks (Article 21), can be directly invoked by ANSSI (France's national cybersecurity agency) under its existing powers. Waiting for transposition before adapting your programme is a strategy with growing risk.
What DORA requires in terms of continuity
DORA is explicit about the continuous nature of digital operational resilience. Article 3(4) defines digital operational resilience as the capacity of a financial entity to build, assure and review its operational integrity and reliability. The verbs are in the present and continuous tense.
Institutions subject to the regulation must maintain a continuous testing programme (Article 25), conduct threat-led penetration testing (TLPT, Article 26) on a three-year cycle, and keep a register of ICT third parties that is permanently updated (Article 28). The first eighteen-month review reveals that the most common gaps lie not in the documentation of policies, but in keeping them updated as organisational and technological changes occur (see the analysis of persistent gaps in ICT governance under DORA). An ICT third-party register kept up to date for the January audit but never revised since does not satisfy the obligation of Article 28. Here, compliance is a dynamic property, not a fixed state.
The GDPR accountability principle as a forerunner
The GDPR anticipated this shift in paradigm. Article 5(2) sets the accountability principle: the controller must be able to demonstrate compliance with the principles of the regulation, at any time, to any supervisory authority that asks. Not at the time of a planned audit. At any time.
The EUR 500,000 fine imposed by the French data protection authority (CNIL) on a hospital in the Pays de la Loire region on 3 September 2026, for lack of multi-factor authentication, illustrates this logic. The failing was not revealed by a GDPR audit. It was revealed by an incident. What was probably in the establishment's security plans had not been implemented in practice. Article 32 GDPR requires appropriate technical measures. The CNIL judges appropriateness not on the basis of plans, but on the controls actually in place at the moment the incident occurs.
What "continuous evidence" concretely means
Moving to a continuous compliance programme does not require rebuilding your information system. It requires four changes in practice.
The first is the filing of evidence as a continuous flow, not as a year-end campaign. An access control policy documented in January and never updated until the next cycle does not prove that you complied with the obligation in July. Every policy change, every access review and every test carried out must be archived with a timestamp at the moment it is produced.
The second is a living map of your perimeter. Your GDPR processing registers, your NIS2 asset inventory and your DORA third-party register need to be updated at every significant change, not once a year. Shadow IT takes root precisely in the gaps between two manual reviews.
The third is the normalisation of alerts on deviations. A continuous compliance programme generates signals when a planned control was not carried out on time, when a third party has not responded to an assessment request, or when an approved policy has not yet been deployed on the systems concerned. These signals show that the programme is working, not that it has failed.
The fourth is cross-mapping of evidence between frameworks. A penetration test produced for NIS2 probably satisfies an equivalent requirement in ISO 27001 and DORA. Without an explicit mapping managed in your GRC tool, your teams produce the same evidence several times in different formats. The operational cost rises without real coverage improving.
The gap you need to close
In September 2026, the ENISA reporting platform for the CRA has been operational for five days. Organisations subject to NIS2, DORA and the CRA are simultaneously managing three notification clocks, the shortest of which are counted in hours. None of these clocks aligns with the timetable of your next audit.
The question to put to your GRC programme is not: "Would we pass an audit if we ran one today?" It is: "Could we prove our compliance tomorrow morning, if an incident forced us to before ten o'clock?" The answer to that question determines whether your programme is designed for your auditor or for your real resilience.