Which NIS2 Article 21 evidence can be collected automatically?

Which tools collect evidence automatically for NIS2 Article 21?

Three kinds of tool do. Compliance automation platforms connect to your cloud accounts, identity provider, device management and HR systems and run scheduled checks against their settings. Operational platforms (ITSM, on-call, monitoring and live dependency maps) record incidents, changes and the inventory of what you run as the work happens. And the source systems themselves, such as cloud audit logs, backup tools and vulnerability scanners, keep records a tool can read.

No single tool covers all ten measures of Article 21(2) of Directive (EU) 2022/2555, and none can collect the evidence that only people produce: an approved policy, a risk decision or a board review. A realistic target is to collect operational evidence automatically for most of points (b), (c), (e), (h), (i) and (j), partly for (d), (f) and (g), and to keep (a) as a human process with automated reminders.

What counts as evidence for Article 21?

Supervisors can ask for 'evidence of implementation of cybersecurity policies', including the results of security audits and the underlying evidence (Article 32(2)(g) for essential entities, Article 33(2)(f) for important entities). A policy shows what you intend; evidence shows that the measure ran.

ENISA's NIS2 Technical Implementation Guidance (June 2025) lists examples of evidence for each requirement in the Annex to Commission Implementing Regulation (EU) 2024/2690. The regulation binds only certain digital entities, such as cloud, data centre and managed service providers, but its Annex and the ENISA examples are the most detailed public description of what each measure looks like in practice.

Good evidence has three properties whether a person or a tool collects it:

• Dated: it shows when the control was in place, not only that it exists today.
• Attributable: it names the system it came from and, for decisions, the person who made them.
• Traceable: an auditor can follow it back to the source record, such as a ticket, a log entry or a configuration read from an API.

What can be collected automatically, measure by measure?

The split below assumes read-only connections to the tools a typical mid-sized organisation runs. 'Automatic' means a tool can read or receive the record without anyone exporting it.

• (a) Risk analysis and security policies: mostly human. Policies, the risk method and risk decisions are written and approved by people. A tool can track approval dates and review deadlines, and link each risk to the systems it affects.
• (b) Incident handling: largely automatic. On-call and ITSM tools record detection time, responders, actions and closure. A dependency map adds which services and customers were affected, which is also what you need to judge whether the Article 23 clock has started.
• (c) Business continuity and backups: partly automatic. Backup job results, retention settings and copies held in another region can be read from cloud and backup tools. Restore tests can be recorded automatically when they are scripted. The business impact analysis and the recovery plan are human work.
• (d) Supply chain security: partly automatic. Cloud billing, single sign-on application lists and connected integrations reveal which suppliers you actually use, and a dependency map shows what each one touches. Assessing a supplier and agreeing contract terms stay human.
• (e) Acquisition, development and maintenance: largely automatic. Change records with requester, approver and implementation time come from ITSM tools; code review and merge records come from GitHub, GitLab or Bitbucket; patch levels and open vulnerabilities come from scanners and device management.
• (f) Assessing effectiveness: partly automatic. Metrics such as time to fix critical vulnerabilities, the share of changes approved before release and time to restore after incidents can be calculated from the records above. The management review of those numbers is human.
• (g) Cyber hygiene and training: partly automatic. Device compliance comes from mobile device management, and training completion from the learning or awareness platform. Choosing the training and running phishing exercises stay with people.
• (h) Cryptography: largely automatic for the technical side. Encryption-at-rest settings on storage and databases, TLS settings on public endpoints and certificate expiry dates can be read from cloud APIs. The cryptography policy and key management decisions are human.
• (i) HR security, access control and asset management: largely automatic. The asset inventory can be built and kept current from cloud, monitoring and ITSM tools. Accounts, groups and leavers come from the identity provider and HR system. The decision in an access review is human, but the data for it need not be gathered by hand.
• (j) Multi-factor authentication and secured communications: largely automatic. Identity provider policies and sign-in logs show where MFA is enforced and used. The emergency communication plan and its exercise record are human.

How does automated evidence collection work?

Most tools combine four mechanisms. Knowing which one produced a piece of evidence tells you how far to trust it.

• Scheduled configuration checks: the tool reads a setting through an API (is MFA enforced, is this bucket encrypted, is backup retention 30 days) and records the result with a timestamp. This proves the state at each check, not in between.
• Event capture: incident, change and code tools send each event as it happens, usually by webhook. This gives a complete timeline rather than a sample.
• Inventory reconciliation: assets and their dependencies are read from several sources, matched into one record per system and kept current, with conflicts flagged rather than overwritten.
• Mapping: each record is linked to the measure, and ideally the Annex point, it supports, so an auditor can start from a requirement and find the evidence.

What can automation not do for Article 21?

• Approve anything. Article 20(1) requires the management body to approve the measures and oversee their implementation. A tool can record that approval; it cannot give it.
• Decide proportionality. Article 21(1) asks for measures appropriate to your risks, so the reasoning behind each level of control has to be written by people.
• Decide whether an incident is significant. A tool can apply the thresholds and start a clock, but the classification under Article 23(3) is a judgement your incident lead makes and owns.
• See what it is not connected to. A system with no connector, an unmanaged laptop or a supplier outside single sign-on is invisible to every tool. Good tools show that gap as missing data instead of a pass.
• Fix the control. Evidence that MFA is off on an admin account is useful only if someone turns it on. Article 21(4) requires corrective measures without undue delay.

How do you judge an evidence tool?

A green dashboard is not evidence. Ask these questions in a demo, with your own systems connected if you can:

• For any item, can you see the source system, the time it was collected and when it was last confirmed?
• When a connector stops working, does the item turn stale or missing, or does it stay green?
• Is the evidence continuous (every event) or periodic (a daily check)? Both are fine if the tool says which.
• Is the record tamper-evident, for example hash-chained or write-once, so you can show nobody edited it after the fact?
• Can you export evidence in a form your auditor or national authority accepts, such as dated PDFs or CSV files with source references?
• Does it map to Article 21(2), and to the Annex of Implementing Regulation 2024/2690 if you are one of the digital entities it covers?
• Does it need write access to your systems? Read-only access is enough to collect evidence.
• Where is the evidence stored and processed? For EU entities, EU hosting keeps the GDPR picture simple.

Compliance automation platforms or operational evidence?

They answer different parts of Article 21, and many organisations use both. Compliance automation platforms are strong at policies, configuration checks across cloud and identity, supplier questionnaires and the auditor workflow, and most support several frameworks at once, such as ISO/IEC 27001 and SOC 2 as well as NIS2.

Operational platforms hold the records that points (b), (c), (e) and (i) depend on: what happened during an incident, what changed and who approved it, and what you run and what depends on it. Those records are created by the people doing the work, so they are hard to recreate before an audit if they were never kept. Our guide on how to choose NIS2 compliance software compares the categories in more detail.

A 30-day plan to automate Article 21 evidence

• Week 1: list the systems in NIS2 scope and the tools that already hold records about them: cloud accounts, identity provider, ITSM, on-call, monitoring, code hosting, backup and device management.
• Week 2: connect read-only to the sources for points (b), (e) and (i) first, because incident, change and asset records cannot be rebuilt afterwards. Confirm every incident and change links to the systems it touched.
• Week 3: add configuration checks for (c), (h) and (j): backup retention, encryption at rest, TLS and certificate expiry, and MFA enforcement. Decide how often each is checked and who is told when one fails.
• Week 4: map what you collect to the ten measures, mark the gaps, and give each gap an owner and a date. Put the human artefacts for (a), (d), (f) and (g) on a review calendar, and show the management body the result.

How Alexus AI helps

Alexus AI is a Dublin-built operational intelligence platform. It connects read-only to the cloud, monitoring, ITSM and code tools you already run (status on the connectors page), keeps a live map of what you run and what depends on it, and turns the same data into Article 21 evidence.

It scores readiness across all ten measures and shows the evidence behind each score. It is strongest where evidence is operational: incident timelines for point (b), change records with requester and approver for point (e), the asset inventory and dependency map for point (i), and encryption and backup settings read from AWS for points (c) and (h). Records go into a hash-chained audit trail you can verify on demand, and where Alexus cannot see something, the scorecard says 'no data' rather than guessing.

Identity provider connectors (Microsoft Entra ID and Okta) are on the roadmap, so MFA evidence for point (j) comes from your identity provider or compliance platform today. Policies, risk decisions and training records stay in your GRC tool. Alexus does not make you compliant; it provides the operational evidence. It is early-stage and working with design partners. See how it works for NIS2 and the ten Article 21 measures. This guide is general guidance, not legal advice.

Frequently asked questions

Can NIS2 compliance be fully automated?

No. Tools can collect much of the operational evidence for Article 21, such as incident timelines, change approvals, asset inventories, backup settings and MFA enforcement. But NIS2 also requires things only people can do: the management body approving and overseeing the measures under Article 20, risk decisions, proportionality reasoning, supplier assessments and deciding whether an incident is significant. Automation removes the evidence gathering, not the accountability.

Which Article 21 measures are easiest to evidence automatically?

Incident handling (point (b)), change and vulnerability records under point (e), the asset inventory under point (i), multi-factor authentication under point (j) and the technical side of cryptography under point (h). The records already exist in ITSM, on-call, code, cloud and identity tools, so a read-only connection can collect them continuously. Policies under point (a) are the hardest, because they are human decisions by design.

Is a screenshot acceptable evidence for NIS2?

It can be, but it is weak. A screenshot shows one moment, is easy to edit and rarely shows where it came from. Records read directly from the source system with a timestamp, or exported from it, are stronger, and a record in a tamper-evident log is stronger still. ENISA's NIS2 Technical Implementation Guidance gives examples of evidence per requirement, and most are records and documents rather than screenshots.

Do we need a compliance automation platform for NIS2?

Not necessarily. NIS2 does not require any particular tool. A compliance automation platform helps most when you manage several frameworks, many policies and many suppliers. If your gaps are in operational records, such as incidents, changes and an up-to-date asset inventory, fixing how those records are kept may matter more. Many organisations use a compliance platform for policies and audits alongside operational tools for the evidence.

How often should Article 21 evidence be collected?

Continuously for events and frequently for settings. Incidents and changes should be captured as they happen, because they cannot be reconstructed reliably later. Configuration settings, such as MFA enforcement or backup retention, are usually checked hourly or daily. Human artefacts follow a calendar: Implementing Regulation 2024/2690 expects the digital entities it covers to review their security policy and risk assessment at least annually.

Sources

• Directive (EU) 2022/2555 (NIS2 Directive), EUR-Lex
• Commission Implementing Regulation (EU) 2024/2690, EUR-Lex
• ENISA, NIS2 Technical Implementation Guidance (June 2025)