NIS2 does not hand you a control list. It hands you ten risk-management measures and an incident-reporting clock, then expects your evidence to prove each one runs. The gap most teams hit is not understanding the directive; it is turning Article 21 into artifacts a national authority or auditor will accept. This checklist maps roughly 40 concrete controls to the evidence each one needs.
What does the NIS2 engineering checklist actually cover?
NIS2 (Directive (EU) 2022/2555) obliges essential and important entities to implement ten cybersecurity risk-management measures under Article 21 and to report significant incidents under Article 23. An engineering checklist translates those legal measures into concrete controls, each paired with the log, config, or artifact that proves the control operates.
The directive replaced the original 2016 NIS rules and widened scope across sectors such as energy, transport, health, digital infrastructure, ICT service management, public administration, manufacturing, and digital providers. Two facts drive the work:
- ▸Management is accountable. Article 20 makes the management body approve and oversee the measures, and holds it liable.
- ▸Evidence beats intent. Supervision is about proof, so every control needs a durable artifact, not a policy PDF describing good intentions.
For the wider backlog view, see NIS2 in 2026: Turning the Directive into an Engineering Backlog.
Which NIS2 article turns into which engineering control?
Article 20 becomes board sign-off and training records; Article 21(2)(a) to (j) becomes ten control families from risk analysis to MFA; Article 23 becomes your incident-reporting runbook and timestamps; Articles 24 to 25 push you toward harmonized standards such as ISO 27001 and, for some sectors, the technical implementing regulation.
The ten measures under Article 21(2) map cleanly to families:
- ▸(a) risk analysis and information-system security policy
- ▸(b) incident handling
- ▸(c) business continuity, backups, disaster recovery, crisis management
- ▸(d) supply-chain security
- ▸(e) secure acquisition, development, maintenance, and vulnerability handling and disclosure
- ▸(f) policies to assess the effectiveness of the measures
- ▸(g) basic cyber hygiene and training
- ▸(h) cryptography and, where appropriate, encryption
- ▸(i) human-resources security, access control, and asset management
- ▸(j) multi-factor or continuous authentication and secured communications
For certain digital sectors (DNS, cloud, data centres, managed service providers and others), Commission Implementing Regulation (EU) 2024/2690 spells out detailed technical requirements you can lift almost verbatim into controls.
What evidence does risk analysis and governance need?
For Articles 20 and 21(2)(a) and (f), authorities want a dated risk assessment, an approved information-security policy, an asset inventory, and proof management reviewed and signed off. Evidence is version-controlled documents, meeting minutes with named attendees, and a risk register showing treatment decisions, owners, and review dates.
Controls and the artifact each one produces:
- ▸Risk register using a methodology such as ISO 27005: exported register with scoring, owners, treatment, and change history.
- ▸Information-security policy: signed, versioned document with an approval date and a next-review date.
- ▸Asset inventory: a CMDB or tagged Terraform state, with a reconciliation report against live cloud accounts.
- ▸Management sign-off (Article 20): board or executive minutes that explicitly reference the cyber risk decisions.
- ▸Effectiveness reviews (Article 21(2)(f)): internal audit reports, control-test results, and remediation tickets.
How do you evidence incident handling and the 24 and 72-hour clock?
Article 23 sets a three-step clock for significant incidents: an early warning within 24 hours of becoming aware, a fuller incident notification within 72 hours, and a final report within one month. Evidence is a runbook mapping detection to those deadlines, plus timestamped tickets, CSIRT submission receipts, and a post-incident report that proves the timeline was met.
Controls and evidence:
- ▸Detection: a SIEM such as Wazuh or Elastic with tuned alert rules; evidence is alert-to-ticket linkage and detection timestamps.
- ▸Classification: significance criteria (users affected, downtime, cross-border impact) recorded as a decision.
- ▸Notification: submissions to the national CSIRT or authority portal; evidence is the receipt and its timestamp against the awareness time.
- ▸Forensic triage: acquisition with Velociraptor and KAPE; evidence is acquisition logs and chain-of-custody records.
Build the muscle before you need it with Incident Response Playbooks That Teams Actually Use.
What proves business continuity, backup, and DR controls?
Article 21(2)(c) covers business continuity, backup management, disaster recovery, and crisis management. Evidence is a tested BCP and DRP with defined RTO and RPO, immutable or offline backups, and dated restore-test reports that show you actually recovered data, not merely scheduled a job that reported success.
Controls and evidence:
- ▸Backups on a 3-2-1 pattern with object-lock immutability and encryption: job logs plus the retention and lock configuration.
- ▸Restore drills: a restore-test report with real timings measured against RTO and RPO.
- ▸Crisis communications: an out-of-band channel and contact tree, evidenced by tabletop notes.
- ▸BCP ownership: named continuity owners and a review date on the plan itself.
How do you evidence supply-chain and secure-development controls?
Articles 21(2)(d) and (e) require supply-chain security and secure acquisition, development, and vulnerability handling. Evidence is vendor risk assessments, contractual security clauses, an SBOM per release, build provenance, dependency-scan output, and a coordinated vulnerability disclosure policy with tracked remediation SLAs.
Controls and evidence:
- ▸Vendor due diligence: assessments, data-processing agreements, and security addenda per supplier.
- ▸SBOM: a CycloneDX or SPDX bill of materials generated per build and stored as an artifact.
- ▸Provenance: SLSA attestations and Sigstore signatures held in the registry.
- ▸Vulnerability handling: SCA with Trivy or Grype plus SAST, evidenced by scan reports and patch-SLA tracking.
- ▸Coordinated disclosure: a security.txt file and a published policy, evidenced by intake tickets and their resolution.
Go deeper on vendor scope in NIS2 Supply-Chain Security in 2026: Who Is in Scope, How to Vet Vendors, and How to Build Auditable Software.
What access control, MFA, and crypto evidence do auditors expect?
Articles 21(2)(h), (i), and (j) cover cryptography, access control, asset management, human-resources security, and multi-factor or continuous authentication. Evidence is IdP policy exports proving MFA is enforced, least-privilege role definitions, a TLS and key-management inventory, joiner-mover-leaver records, and encryption configuration for data at rest and in transit.
Controls and evidence:
- ▸MFA: phishing-resistant factors such as FIDO2 or passkeys, evidenced by a conditional-access policy export from the identity provider.
- ▸Access control: RBAC or ABAC with quarterly access reviews, evidenced by signed review attestations.
- ▸Cryptography: TLS 1.2 or 1.3 only, key rotation via a KMS or HashiCorp Vault, evidenced by a cipher scan and a key inventory.
- ▸Human-resources security: joiner, mover, and leaver workflows, evidenced by deprovisioning logs tied to HR events.
- ▸Cyber hygiene and training: phishing-simulation results and completion logs per employee.
How do you keep the evidence current without a compliance treadmill?
Treat evidence as code. Generate artifacts from the systems that already run the controls, store them with timestamps in version control, and schedule the ones that decay. Continuous evidence, from CI attestations to automated access reviews, beats a pre-audit scramble that reconstructs a snapshot nobody can reproduce.
Practical patterns:
- ▸Enforce controls in CI with policy-as-code (Open Policy Agent) and configuration scans (OpenSCAP), failing the build when a control regresses.
- ▸Push compliance artifacts into an object store with retention locks so timestamps are tamper-evident.
- ▸Put decay on a calendar: access reviews quarterly, restore drills and tabletops at least annually, risk assessment refreshed yearly or on major change.
The evidence-as-code mindset is worked through in ISO 27001 Evidence as Code: Building an ISMS Engineers Don't Hate, and the multi-regulation view sits in The 2026 SME Cybersecurity Checklist for GDPR, NIS2 and DORA.
How TuniCyberLabs helps
We map NIS2 Article 21 to a control set your engineers can actually operate, then wire the evidence generation into the pipelines and platforms you already run, so proof accumulates on its own instead of during a panic before supervision. That covers risk registers, incident runbooks tuned to the 24 and 72-hour clock, backup and restore validation, supply-chain provenance, and identity hardening, each with a durable artifact behind it.
Want a NIS2 control-to-evidence gap assessment for your stack? Talk to our security engineering team.