Two meanings of "continuous"
"Continuous" is one of the most used words in compliance marketing, and it covers two different activities:
- Control monitoring: automated, repeated checks that the security controls you documented are still in place and still working.
- Threat monitoring: watching systems in real time for signs that someone is attacking them.
Both are continuous. They answer different questions, use different tools and need different people.
Control monitoring asks: is multifactor authentication still enforced for every account, is every laptop still encrypted and running endpoint protection, did last night's backup complete, has anyone who left the company still got access? Threat monitoring asks: is that login from an unusual country a real employee, why is a server sending data to an address it has never contacted, is that process encrypting files?
Vendors blur the two because each one sounds like the other. A compliance platform that checks configurations every hour can describe itself as continuous monitoring. A SOC that watches alerts around the clock can describe itself the same way. A company that buys one may believe it has both. This article is about the first kind, what it covers and where it stops, and why certification needs the second as well.
What control drift looks like
Controls rarely fail on the day they are implemented. They drift. A setting changes, a new system arrives without the standard configuration, a process quietly stops running, and nothing alerts anyone because nothing is broken from the user's point of view. By the next audit, a control that was in place for the previous one no longer is.
The examples are mundane, which is why they go unnoticed:
- Authentication. A service account is exempted from multifactor authentication to make an integration work and the exemption is never removed.
- Endpoints. A new laptop is handed to an employee before the management agent is installed, so it has no disk encryption and no endpoint protection.
- Access. A contractor's access to the production environment outlives the contract by months because nobody owns the leaver process for contractors.
- Backups. A backup job starts failing after a storage change and the error goes to a mailbox nobody reads.
- Cloud. A storage bucket is made public for a quick test and never closed.
- Reviews. The quarterly access review is skipped once during a busy period, then twice.
None of these is an attack, but each one weakens a control the certificate depends on, and some of them are exactly how attacks succeed later. An auditor sampling evidence will find them as nonconformities. Our article on what a certification audit actually tests explains why a control that exists on paper and a control that operates are judged differently.
How automated control checks work
Continuous compliance monitoring replaces periodic manual checking with automated tests that run against the systems themselves. It is not magic, and it is worth understanding how it works before relying on it.
Integrations and tests
A compliance platform connects to the systems where controls live: the identity provider, the cloud accounts, device management, the code repository, the HR system, the ticketing tool. Through those integrations it reads configuration and activity, and runs tests against each control. Is MFA enforced for all users in the identity provider? Are all devices in device management encrypted? Is logging enabled on every cloud account? Does every employee in the HR system have a completed security training record?
Each test maps to one or more controls in one or more frameworks. A single check that every laptop is encrypted can serve ISO 27001, the ENS and SOC 2 at once, which is why the same evidence does not have to be collected three times. Our article on how a compliance platform collects and traces evidence covers that mapping and the audit trail in detail.
Thresholds, owners and alerting
A test that fails silently is no better than no test. Useful control monitoring defines what counts as a failure, who owns each control, and what happens when a test fails. A failing encryption check on one laptop should open a task for the IT owner with a deadline. A public storage bucket holding customer data should escalate immediately.
The owner matters more than the tool. In many companies the platform flags drift accurately and the finding sits in a dashboard for weeks because nobody's job is to act on it. Assigning each control to a named person, with a target time to fix failures, turns monitoring into maintenance.
What cannot be automated
Some controls cannot be tested by reading a configuration. These need people, interviews, records and judgement:
- whether a risk assessment reflects the business;
- whether a supplier review was meaningful;
- whether staff understood their training;
- whether physical access to an office is controlled;
- whether the incident response plan would work under pressure.
Automation should cover what it can test reliably and free people for what it cannot. A programme that measures only what is easy to automate ends up with green dashboards and gaps in the controls that matter most.
What the standards require
None of the main frameworks uses the phrase "continuous compliance monitoring". All of them require organisations to check that their controls work, and all of them make periodic manual checking hard to defend as the only method.
ISO 27001
ISO 27001 has three requirements that apply directly:
- Clause 9.1 requires the organisation to determine what needs to be monitored and measured, the methods, when the monitoring is performed, who performs it and when the results are analysed and evaluated.
- Clause 10.2 requires nonconformities to be reacted to, corrected and their causes addressed.
- Annex A control 5.36 requires compliance with the organisation's security policies and standards to be reviewed regularly.
Automated control checks are a direct way to meet clause 9.1 for technical controls, as long as the organisation has decided what to measure and someone reviews the results. A failed check that is fixed, recorded and analysed for its cause is also evidence for clause 10.2.
The ENS
The ENS, regulated by Real Decreto 311/2022, states the principle explicitly. Article 10.2 says that permanent evaluation of the security state of assets makes it possible to measure its evolution, detect vulnerabilities and identify configuration deficiencies. Article 21.2 requires permanent evaluation and monitoring so that the security state of systems keeps pace with configuration deficiencies, vulnerabilities and the updates that affect them.
Annex II then turns the principle into measures:
- op.mon.2 requires a system of security metrics, with reinforcements at higher categories.
- op.exp.3 requires security configuration to be managed so that systems stay in their approved configuration.
For an ENS system, configuration drift is not just an operational nuisance; it is a deviation from measures the certificate rests on.
NIS2
Article 21(2)(f) of Directive (EU) 2022/2555 requires essential and important entities to have policies and procedures to assess the effectiveness of their cybersecurity risk management measures. Assessing effectiveness once a year against a static checklist is a weak answer to that requirement. Ongoing checks with recorded results are a much stronger one, and they are the kind of evidence a supervisory authority asks for.
Article 21(4) adds the other half: an entity that finds it does not comply with the measures must take the necessary corrective measures without undue delay. Article 21(5) lists DNS, cloud, data centre and managed service providers, among other digital providers. For them, Implementing Regulation (EU) 2024/2690 sets the technical requirements in more detail. In both cases the expectation is the same as in the ENS: find the deviation and correct it, rather than discover it at the next review.
SOC 2
The Trust Services Criteria behind SOC 2 include criterion CC4.1. It requires the entity to select, develop and perform ongoing or separate evaluations to ascertain whether the components of internal control are present and functioning. In a Type II report, the auditor tests whether controls operated throughout the observation period. A control that drifted for two months and was fixed before the audit still appears as an exception.
Criterion CC4.2 then requires deficiencies to be evaluated and communicated in a timely manner to the people responsible for corrective action. Continuous control checks give both criteria something concrete to point to: the evaluation runs on a schedule, and a failed check reaches its owner the same day instead of waiting for a quarterly review.
Why most audit findings start as drift
Certification audits rarely find that a company never implemented a control. More often they find that a control was implemented and then stopped working somewhere between audits. The pattern is consistent across frameworks.
In the months after a certification audit, attention moves elsewhere. The project team returns to its normal work. New hires, new suppliers, new systems and new features arrive at the normal pace of the business. Each change has a small chance of bypassing a control. Over a year, those small chances add up to a set of findings:
- unencrypted devices;
- stale access;
- missing reviews;
- unpatched systems;
- suppliers never assessed.
The surveillance audit then becomes a scramble to reconstruct evidence and fix what drifted, often discovered only when the auditor's sample request arrives. Continuous control monitoring changes the timing: the drift is found when it happens, while it is small and cheap to fix, rather than months later. For ENS certificates, our guide to keeping ENS certification valid between audits lists the measures that have to keep running every day.
Where threat monitoring takes over
A company can pass every control check and still be under attack. Control monitoring confirms that MFA is enforced; it does not notice that an attacker approved a push notification sent to a tired employee at midnight. It confirms that endpoint protection is installed; it does not investigate the alert that endpoint protection raised.
That second job belongs to threat monitoring: collecting security events, correlating them and having analysts investigate and respond. It runs on different tools, typically EDR, a SIEM or an XDR platform, and on people. Our article on EDR, XDR and MDR explains what each layer does and why an alert without someone to act on it protects nobody.
The two kinds of monitoring also feed each other. Threat monitoring depends on controls being in place: an unmonitored laptop without endpoint protection is invisible to the SOC. Control monitoring depends on threat monitoring to show whether controls actually stop attacks. A compliance platform without operated security leaves the second half undone, which is the argument we make in what a compliance platform does not do.
Where to start
Monitoring everything at once is neither realistic nor necessary. Start with the controls that drift most often and whose failure matters most. In most companies those are:
- identity (MFA, privileged accounts, leavers);
- endpoints (encryption, endpoint protection, updates);
- cloud configuration (public storage, logging, exposed services);
- access reviews;
- backups.
The first step is not a tool but an inventory. A control check is only as good as the list of things it checks: if a laptop, a cloud account or a SaaS application is not in the inventory, no automated test will ever look at it. Connecting the identity provider, device management and cloud accounts usually surfaces assets nobody had recorded, which is a finding in itself.
Then decide the frequency for each control. Some checks make sense daily or hourly, such as public storage or disabled MFA. Others are naturally periodic, such as the quarterly access review, where the useful automated check is whether the review happened on time. Writing those decisions down is exactly what ISO 27001 clause 9.1 asks for.
Running both as one programme
The practical goal is a single programme in which control monitoring and threat monitoring share an inventory, owners and a reporting line, rather than two tools bought separately and reviewed by different people.
That starts with ownership. Every control has an owner who receives its failed checks. Every alert has an analyst responsible for triage. Both sets of results feed the same incident and nonconformity records. A missing control found by a check and a real incident found by the SOC are then handled through the same process, and both count as evidence.
It continues with review. A short monthly look at failed checks, time to fix, open alerts and incidents gives management the information ISO 27001 clause 9.3 expects at management review. It also gives the ENS metrics measure something real to report. Over time those figures show whether the programme is getting healthier or quietly drifting.
This is how Qalea is built. The Qalea platform runs automated checks against the systems where controls live and maps each result to the frameworks it supports, while EDR, a SIEM and a SOC provide the threat monitoring layer underneath. Qalea's team guides the follow up on what both layers find, so drift is fixed while it is small and the evidence is ready when the auditor asks. The compliance operations topic page collects our other articles on running compliance day to day.
