Continuous compliance: from the annual audit to permanent control

Continuous compliance means checking all the time, or at a pace set according to risk, that your security measures are in place and working, instead of finding out once a year during an audit. Each control has its own frequency, evidence is collected as you go, automatically where possible, and every gap triggers a fix. ISO 27001, NIS 2 and DORA do not always use the term, but their requirements lead to it. This article in our GRC Ops series explains what the texts say, which controls to automate and how to get started.

The idea is simple: compliance is not a state observed on a given date, it is a level that moves every day. An administrator account created without multi-factor authentication, a backup that fails silently, a forgotten critical patch: each of these gaps lowers the real level without anyone noticing.

Three related terms are often mixed up:

• Continuous control monitoring is the means: collecting data (configurations, logs, tickets, tool exports) to check each control at regular intervals.
• Continuous compliance is the goal: staying compliant between two audits, and being able to prove it at any time.
• Continuous auditing usually refers to internal auditors using recurring data analysis to form their opinion. It relies on monitoring but is not the same thing: auditors remain independent from those who operate the controls.

The US National Institute of Standards and Technology (NIST) gave a useful definition back in 2011 in SP 800-137: continuous monitoring means maintaining ongoing awareness of security, vulnerabilities and threats to support risk management decisions. Above all, it makes clear that “continuous” does not mean “every second”: each control is assessed at a frequency sufficient to support risk-based decisions. That is the right lens: continuous compliance is the right frequency for each control, not a permanent alarm.

The annual audit remains essential, but it only shows a moment in time. The diagram below compares two ways of tracking the same compliance level over a year.

The diagram highlights three weaknesses of the point-in-time approach:

• Drift stays invisible. Between two audits, configurations change, accounts are created, providers come on board. Nothing measures the widening gap.
• Catch-up happens just before the audit. Evidence is gathered in a rush, visible issues are fixed, and the audit records a level that did not exist for the rest of the year.
• The cost is concentrated and repeated. Every year, the same teams take the same screenshots and run the same extracts, for a result that is out of date the next day.

The context has changed too. Regulators now require management bodies to approve and oversee security measures (Article 20 of NIS 2, Article 5 of DORA), which means showing them an up-to-date picture rather than a ten-month-old report. And customers, themselves subject to these laws, send their third-party risk questionnaires all year round.

ISO 27001: monitor, audit, improve

ISO/IEC 27001:2022, the basis of your ISMS, contains three clauses that together form a continuous compliance loop:

• Clause 9.1, monitoring, measurement, analysis and evaluation: the organisation determines what needs to be monitored and measured, including security controls, the methods to use, when, by whom, and when results are analysed. Results must be comparable and reproducible.
• Clause 9.2, internal audit, at planned intervals, and clause 9.3, management review.
• Clause 10: deal with nonconformities through corrective action (10.2) and continually improve the system (10.1).

Certification itself follows a three-year cycle with surveillance audits at least once a year, under ISO/IEC 17021-1, which governs certification bodies. The standard does not set a measurement frequency per control: it is up to you to define and justify it.

NIS 2: assess the effectiveness of measures

Article 21 of the NIS 2 Directive lists minimum risk management measures. Point (f) covers “policies and procedures to assess the effectiveness of cybersecurity risk-management measures”. Putting a measure in place is not enough: you must check that it works. Article 20 makes management bodies responsible for approving these measures and overseeing their implementation (see our articles From NIS to NIS 2 and on penalties).

For the digital providers it covers (cloud computing, data centres, managed services, etc.), Implementing Regulation (EU) 2024/2690 goes further. Its annex requires compliance monitoring “at planned intervals” and after significant incidents or changes (point 2.2), an independent review (point 2.3), automated monitoring of systems carried out continuously or at regular intervals (point 3.2), and a procedure that sets, like ISO 27001, what to measure, how, when and by whom (point 7). ENISA's implementation guidance, published in June 2025, recommends that this monitoring and reporting to management take place at least once a year.

In France, the transposition law had still not been adopted as of 7 October 2026: the National Assembly debate was postponed again on 6 October. ANSSI published its ReCyF framework of recommended measures in March 2026 as a working document. The principles above do not depend on that timetable.

DORA: monitor continuously, review every year

The DORA Regulation, applicable to financial entities since 17 January 2025, is the most explicit:

• Article 6: the ICT risk management framework is documented and reviewed at least once a year, and after major incidents; it is continuously improved based on lessons from implementation and monitoring. It is subject to regular internal audit, followed by a formal process to address critical findings.
• Article 8: functions, assets and risk sources are identified and reviewed at least yearly, and a risk assessment is carried out after every major change in the infrastructure.
• Article 9: entities must “continuously monitor and control the security and functioning” of ICT systems and tools.
• Article 13: lessons from testing and incidents are incorporated into the risk assessment on a continuous basis.

And the GDPR

Article 32 of the GDPR requires, among security measures, a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures. The principle has been the same since 2018.

A control lends itself to continuous monitoring when its outcome can be read from reliable data: a configuration, a log, a tool export. That is true of most technical measures. Controls that require judgement (is the policy still fit for purpose? is this supplier acceptable?) stay with people; you can only automate reminders, deadlines and the collection of documents. The table below gives orders of magnitude, to adjust to your risk analysis.

Measures from the business continuity plan, third-party assessments and residual risk acceptance therefore keep a yearly or event-driven pace. What changes is that they are scheduled in the same calendar as automated controls, with the same traceability. Moving from configuration to automatic evidence is at the heart of GRC Engineering, which treats controls as code.

For each control, four questions are enough to pick a pace you can defend in front of an auditor:

1. How serious is a failure? Multi-factor authentication disabled on an admin account exposes the whole information system; it justifies a daily check.
2. How fast does the control drift? Accounts and configurations change every day; a security policy, a few times a year.
3. What does a measurement cost? If the evidence can be read through an application programming interface (API), checking daily costs almost nothing; if it requires an interview, space it out.
4. Does a text set a pace? DORA requires a yearly review of the framework and an assessment after every major change; your contracts or accreditation may set other deadlines.

Record the chosen frequency and its rationale in the control's description. That is exactly what ISO 27001 clause 9.1 and point 7 of the annex to Regulation 2024/2690 ask for: being able to say when you measure, and why.

A continuous compliance dashboard answers three questions: where do we stand, since when, and how fast do we fix things? A handful of indicators will do:

• Rate of compliant controls, by framework and by scope, as of today.
• Evidence age: share of controls whose latest evidence is older than the planned frequency. This is the indicator that exposes “window-dressing” compliance.
• Time to detect a drift: time between the gap appearing and the alert.
• Time to fix, compared with a target set by severity.
• Number of accepted exceptions and their expiry date: an exception without an end date is a risk accepted without saying so.
• Coverage: share of the scope (subsidiaries, applications, sites) actually monitored.

Present them to management at a fixed pace, quarterly for example: this gives concrete content to the oversight duty in Article 20 of NIS 2.

1. Start from a common set of controls shared by your frameworks, rather than one list per text. Our article on compliance management covers this mapping between frameworks.
2. Describe each control: objective, owner, expected evidence, tolerance threshold, frequency.
3. Connect data sources for technical controls, starting with those that matter most: privileged accounts, patches, backups.
4. Schedule manual controls in the same calendar, with reminders and due dates.
5. Link every gap to an action: an owner, a date, a closure check. An alert that does not lead to action is just more noise.
6. Report and adjust: indicators for management, yearly review of frequencies and thresholds in light of incidents.

Start small: five to ten well-chosen controls monitored continuously are worth more than a catalogue of two hundred requirements assessed once a year.