Continuous compliance: from annual audits to continuous control monitoring

Annual audits show how controls looked on the day of the audit. Continuous control monitoring shows whether they work the rest of the year, provided you are clear about what automation can and cannot prove.

For many organisations, compliance still runs on an annual cycle: prepare for the audit, pass the audit, then return to normal work until the next one. That model was always fragile, and European regulation is making it harder to sustain. NIS2, DORA and ISO/IEC 27001 all expect organisations to know whether their controls work throughout the year, not only during audit season. This article explains what continuous compliance means in practice, where evidence automation helps, where it does not, and how to stop implementing the same control three times for three frameworks.

What “continuous” actually means

The term is often misread as “real-time monitoring of everything”. NIST’s definition of information security continuous monitoring is more modest and more useful: maintaining ongoing awareness of information security, vulnerabilities and threats to support risk management decisions ^[1]. NIST adds that “continuous” means controls and risks are assessed at a frequency sufficient to support risk-based decisions ^[1].

In other words, a firewall configuration might be checked daily, access reviews quarterly and a business continuity plan annually. The point is that the frequency is chosen deliberately and matches the risk, rather than being dictated by the audit calendar.

What the frameworks expect

• NIS2 requires “policies and procedures to assess the effectiveness of cybersecurity risk-management measures” (Article 21(2)(f)) ^[2].
• DORA requires financial entities to document their ICT risk management framework and review it at least once a year, as well as after major ICT-related incidents (Article 6(5)) ^[3].
• ISO/IEC 27001:2022 requires the organisation to determine what needs to be monitored and measured, how and when, and to run internal audits and management reviews at planned intervals (clauses 9.1 to 9.3) ^[4].

None of these texts uses the phrase “continuous compliance”, but all of them assume ongoing oversight rather than a once-a-year snapshot.

Automation can tell you that a control ran; it cannot tell you that it was the right control.

The limits of the annual audit

An external audit is a sample taken at a point in time. It answers the question “did the auditor find sufficient evidence that controls were designed and operating during the period sampled?” It does not tell management whether a control failed last Tuesday.

This creates three common problems:

1. Drift: configurations, access rights and supplier relationships change constantly. A control that was effective in March may not be in September.
2. Evidence scramble: teams spend weeks collecting screenshots and exports before each audit, often recreating evidence that already exists elsewhere.
3. Late discovery: weaknesses surface during the audit, when there is little time to fix them properly.

What evidence automation can do

Automated evidence collection connects to systems such as identity providers, cloud platforms, endpoint management, ticketing and HR tools, and records the state of a control at regular intervals. Done well, it offers clear benefits.

Strong use cases

• Configuration checks: encryption settings, logging enabled, multi-factor authentication enforced, backup jobs completed.
• Population data: lists of users, devices or systems that a control should cover, so you can spot gaps.
• Timeliness tests: whether vulnerabilities were patched within the agreed window, or whether leavers lost access within the agreed period.
• Evidence history: a dated trail showing the state of a control over time, which is more convincing to an auditor than a single screenshot.

What evidence automation cannot do

Automation can tell you that a control ran; it cannot tell you that it was the right control. Several aspects of compliance remain matters of human judgement.

• Design adequacy: whether a policy or control is appropriate for your risks. A tool can confirm a policy document exists; it cannot judge whether it is fit for purpose.
• Risk decisions: accepting a risk, choosing a treatment or setting an appetite are management decisions. NIS2 places explicit responsibility on management bodies for approving and overseeing risk-management measures (Article 20) ^[2].
• Process controls: incident handling, supplier due diligence, awareness training effectiveness and crisis exercises are mostly evidenced through records of people doing things, not system states.
• Context and exceptions: an alert that MFA is disabled for an account may be a failure or an approved service account exception. Someone needs to decide.
• Coverage: automation only sees systems it is connected to. Shadow IT, paper processes and suppliers outside the integration remain blind spots.

A sensible target is to automate the technical evidence that is repetitive and objective, and to keep structured, dated records for the judgement-based controls. Both should feed the same control record.

Design controls once: unified control sets

Most organisations in scope for NIS2 also have ISO/IEC 27001 certification, GDPR obligations and, in financial services, DORA. Many requirements overlap: access control, logging, incident management, backup, supplier security and training appear in all of them.

How control mapping works

A unified control set (sometimes called a common control framework) defines each control once, in your own words, with an owner, a frequency and the evidence it produces. Each control is then mapped to the requirements it satisfies in each framework.

For example, a single control “privileged access is reviewed quarterly by system owners” might map to ISO/IEC 27001 Annex A access controls, NIS2 Article 21(2)(i) on access control policies ^[2] and DORA’s ICT risk management requirements ^[3]. One review, one piece of evidence, three frameworks.

Public mappings help. NIST’s National Online Informative References (OLIR) programme publishes structured relationships between the NIST Cybersecurity Framework and other standards ^[5]. ENISA’s NIS2 Technical Implementation Guidance includes a mapping table alongside its examples of evidence ^[6].

Practical design rules

• Write controls as testable statements: who does what, how often, and what record it leaves.
• Map many-to-many, but document the rationale: a mapping is a claim that an auditor may test. Note where a control only partially covers a requirement.
• Keep framework-specific gaps visible: DORA’s register of information or NIS2’s incident reporting deadlines may need dedicated controls that have no ISO equivalent.
• Version your mappings: frameworks change. CyberFundamentals moved to a 2025 version and NIST released CSF 2.0 in 2024. Re-map when sources change, and keep the history.

A phased approach

1. Inventory: list your frameworks, current controls and where evidence lives today.
2. Rationalise: merge duplicate controls into a single set and map them to each framework.
3. Set frequencies: assign a monitoring frequency to each control based on risk.
4. Automate selectively: start with high-volume technical controls where integration is straightforward.
5. Close the loop: route failures to owners, track remediation and report trends to management.
6. Prepare audits from the same record: auditors should see the same controls and evidence that management sees during the year.

Conclusion

Continuous compliance is not a product feature or a dashboard. It is an operating model in which controls are defined once, monitored at a deliberate frequency, and evidenced as a by-product of normal work. Automation makes that cheaper for technical controls; human judgement remains essential for design, risk and process.

Secrato helps organisations manage frameworks such as NIS2, DORA and ISO 27001 in one EU-hosted platform, with shared controls, evidence and audit trails.