NIS2 Article 21(2): what counts as evidence

What Article 21 actually requires

Article 21(1) of Directive (EU) 2022/2555 requires essential and important entities to take appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of their network and information systems, and to prevent or minimise the impact of incidents. The standard is explicitly risk-based and all-hazards: proportionality is judged against the entity's exposure, size, and the societal and economic impact a serious incident would cause.

Article 21(2) then lists ten measures that those arrangements must, at minimum, be based on. The list is a floor rather than a ceiling, and it is written in the language of "policies and procedures" — which is where most organisations stop, and where assessments go wrong.

Two further paragraphs change the character of the obligation. Article 21(3) extends it into the supply chain, requiring entities to account for vulnerabilities specific to each direct supplier and the overall quality of their suppliers' security practices. Article 21(4) requires entities that discover they are not complying to take the necessary corrective measures without undue delay — which presupposes that non-compliance is something you are in a position to notice.

Around Article 21 sits the accountability that gives it teeth. Article 20 makes management bodies responsible for approving the measures and overseeing their implementation, and makes them liable for failures. Article 32 gives competent authorities supervisory powers over essential entities including inspections, targeted audits and requests for evidence. Article 34 sets administrative fines of up to €10 million or 2% of total worldwide annual turnover for essential entities, and up to €7 million or 1.4% for important entities — whichever is higher in each case.

Official text: Directive (EU) 2022/2555

The ten measures, in plain language

Article 21(2) requires that your measures be based on an all-hazards approach and include at least the following. The lettering matters: assessors, internal audit and evidence tooling all cite these subparagraphs, and mixing them up is a surprisingly common error.

Note (h) and (i) in particular. Cryptography is (h); human resources security, access control and asset management are (i). Citations that place cryptography at (i) are common in secondary material — and in our own product, until we corrected it. If a mapping you rely on gets this wrong, every report built on it inherits the error.

Why "we have a policy" is not evidence

Article 21(2) is phrased in terms of policies and procedures, so it is tempting to treat a signed document set as compliance. In practice, supervision asks a different question: was the measure operating during the period under review, and can you show it?

The distinction is the same one auditors have long drawn between design and operating effectiveness. A cryptography policy that mandates TLS 1.2 or better is a design control. Evidence that no service in your estate negotiated anything weaker for eleven months, that three exceptions were detected on specific dates, and that each was resolved within a defined window — that is operating effectiveness. Only the second survives a question like "show me".

Commission Implementing Regulation (EU) 2024/2690 sharpened this for a defined group of digital entities — DNS service providers, TLD name registries, cloud computing and data centre service providers, content delivery networks, managed service and managed security service providers, online marketplaces, online search engines, social networking platforms and trust service providers — by laying down technical and methodological requirements for their Article 21(2) measures. ENISA's accompanying Technical Implementation Guidance, published in June 2025, goes further still and pairs individual requirements with concrete examples of evidence an entity might produce.

Even if your entity falls outside that implementing regulation's scope, those examples are the clearest published signal of what "demonstrate it" is expected to look like. Read them as a target, because they describe artifacts — inventories, records, logs, measurements, test reports over time — not documents.

Official text: Implementing Regulation (EU) 2024/2690

What an assessor asks to see

Across the evidence examples, the same three properties keep recurring. They are a useful test to apply to anything you plan to submit.

For anything touching regulation, add a fourth: the record should state which version of a regulatory mapping it was produced against. Mappings are interpretations, and interpretations get corrected. A report that stamps its mapping version lets an assessor tell exactly which text a given conclusion was drawn from — and lets you correct future reports without silently rewriting past ones.

Which measures are externally observable

This is the part most compliance marketing skips. Of the ten measures, the substantial majority concern internal process and organisational arrangements. No outside-in monitoring tool — ours included — can see them, because they leave no trace on the public internet.

Incident handling (b) lives in your ticketing and on-call systems. Business continuity (c) is proven by restore tests, not by anything observable from outside. Supply chain security (d) is contractual and procedural. Human resources security, access control and asset management (i) are internal by definition. Multi-factor authentication (j) is a property of your identity provider, not of your public surface. Risk analysis (a) is an activity you perform; an external inventory can feed it but cannot substitute for it.

What is externally observable is narrower and more specific: the cryptography your public services negotiate in real handshakes, the certificates they serve, the trust signals your domains publish, and — over time — how quickly weaknesses in those things get fixed once detected. That last one is more valuable than it first appears, because it is the raw material for an effectiveness measurement under (f), which is otherwise one of the hardest measures to evidence at all.

So the honest claim for any outside-in tool is: direct evidence for a small number of measures, supporting evidence for a few more, and nothing at all for the rest. Anything broader should be read sceptically.

What SkyQon evidences, stated exactly

SkyQon's NIS2 evidence report maps to five of the ten measures, with the coverage level stated on the face of the report. These strings are rendered verbatim into the signed PDF, so what you read here is what an assessor reads there.

Direct means our telemetry is the primary evidence for that measure. Supporting means it is one input among several you will need. Input only means it feeds your process and is explicitly not claimed as covered — it appears in the report precisely so nobody mistakes an inventory for a risk analysis.

The report is signed by SkyQon's own certificate authority and carries a content hash that anyone can verify independently, without an account, against our public verifier. It stamps the version of the mapping it was generated against. And it is framed throughout as aligned to NIS2 Article 21(2) — never as certification, which SkyQon is not in a position to grant and no monitoring product is.

What it does not evidence

Five measures are outside the report entirely: incident handling (b), business continuity (c), supply chain security (d), human resources security and access control (i), and authentication measures (j). The report says so in as many words, because a gap an assessor discovers is worse than a gap you declared.

Two more limits, stated plainly. First, evidence about your externally reachable estate is not evidence about your internal network; a report covering public services is scoped to public services. Second, no artifact from any vendor discharges the obligation — Article 20 puts approval and oversight on your management body, and that cannot be outsourced to a PDF.

A practical sequence

If you are starting from policies and want to reach evidence, this order tends to waste the least effort.

• Fix the inventory first. Every later measure is scoped by it. Enumerate the domains, subdomains and public services you actually operate, including the ones inherited from acquisitions and abandoned projects. Coverage arguments are lost here, not in the analysis.
• Start the clock early. Evidence of continuity requires elapsed time, and it cannot be produced retroactively. A monitoring record that begins the week before your assessment demonstrates very little; the same record covering the preceding year is close to unarguable.
• Instrument the fix, not just the finding. Measure (e) and measure (f) both turn on time-to-resolution. If your process detects a weak certificate but the resolution lives in an email thread, you have a finding and no evidence. Record detection and resolution as dated events.
• Prefer signed artifacts. Where a record can be signed and hashed, sign it. It costs nothing at generation time and removes an entire category of dispute later.
• Map honestly and version the mapping. Claim direct coverage only where your artifact really is the primary evidence. Record which version of the mapping each report was built from, so a later correction does not cast doubt on everything you have already filed.
• Check your national transposition. NIS2 binds you through national law, and Member States have transposed at different speeds and with different detail. The Directive is the reference; your national implementing act is the operative text.

Scope, timing and the reporting duty

NIS2 applies to essential and important entities in the sectors listed in Annexes I and II, generally where the entity is at least medium-sized, with several categories in scope regardless of size. Classification matters: it determines both the supervisory regime and the fine ceiling. The transposition deadline for Member States was 17 October 2024, with national measures applying from 18 October 2024, though transposition has run late in a number of Member States.

Article 23 adds the reporting duty that most often catches entities out, because its clock is short: an early warning to the competent authority or CSIRT within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report within one month. Evidence that your monitoring detects incidents in time, with timestamps, is what puts those deadlines within reach.

Common questions