About this program
NIS2 applies to “essential” and “important” entities across the EU and brings real teeth: penalties up to €10M or 2% of global turnover and personal liability for management. This 12-question check covers Article 21 risk-management measures and Article 23 incident reporting. After each answer you can expand an “Auditor’s view” with how the control is tested, what evidence to collect, and the ideal response.
Controls (12)
-
Have you confirmed whether your organisation is in scope as an Essential or Important entity under NIS2?
MediumHave you confirmed whether your organisation is in scope as an Essential or Important entity under NIS2?
How to test + evidence
Risk: Without a documented scoping decision and regulator registration, the rest of your NIS2 work is built on a guess.
Testing procedure: Map your sectors, sub-sectors and entity size against Annexes I and II of the directive. Confirm classification (Essential vs Important) with the national competent authority where required.
Evidence to collect: Scoping memo with sector/sub-sector mapping Headcount + turnover thresholds documented Registration confirmation with the national CSIRT (where required)
-
Is there a written information security policy approved by management and reviewed at least annually (Art 21.2.a)?
MediumIs there a written information security policy approved by management and reviewed at least annually (Art 21.2.a)?
How to test + evidence
Risk: Board-level approval anchors accountability under Article 20 — the personal liability provisions for management.
Testing procedure: Inspect the IS policy. Verify a board/management approval signature, an effective date within the audit period, and a documented annual review.
Evidence to collect: IS policy with version history and approval signatures Board minutes showing approval and annual review Communication record showing policy distributed to all staff
-
Has management been formally trained on cyber risks and approved your risk-management measures (Art 20)?
MediumHas management been formally trained on cyber risks and approved your risk-management measures (Art 20)?
How to test + evidence
Risk: Article 20 makes management personally liable. Auditors and regulators will want hard evidence that training and sign-off actually happened.
Testing procedure: Request training records for board / executive members and the formal sign-off of risk management measures.
Evidence to collect: Training completion records for management with dates Signed approval of NIS2 risk management measures Board minutes referencing cyber as a recurring agenda item
-
Do you maintain a cyber risk register reviewed quarterly with senior leadership (Art 21.2.a)?
MediumDo you maintain a cyber risk register reviewed quarterly with senior leadership (Art 21.2.a)?
How to test + evidence
Risk: Quantified risk + quarterly review forces real conversation. Annual or qualitative-only registers produce noise that doesn't inform decisions.
Testing procedure: Pull the current risk register and the last four quarterly review records. Verify each risk has an owner, a treatment decision, and a review date.
Evidence to collect: Risk register snapshot (current + 4 historical) Quarterly review minutes/notes Risk treatment plans with owners + dates
-
Is multi-factor authentication enforced on all admin and remote access (Art 21.2.j)?
MediumIs multi-factor authentication enforced on all admin and remote access (Art 21.2.j)?
How to test + evidence
Risk: Phishing-resistant factors (FIDO2, passkeys) eliminate adversary-in-the-middle attacks that defeat OTP-based MFA.
Testing procedure: Pull a sample of admin and remote-access user logins from the IDP audit log. Verify each had a second factor and that legacy auth protocols are blocked.
Evidence to collect: Conditional Access / MFA enforcement policy export Sample login records showing MFA challenge + success Configuration showing legacy auth blocked
-
Are policies and use of cryptography (encryption, key management) documented and applied (Art 21.2.h)?
MediumAre policies and use of cryptography (encryption, key management) documented and applied (Art 21.2.h)?
How to test + evidence
Risk: A KMS with rotation gives you the demonstrable lifecycle controls auditors want — and breaks the chain when a key leaks.
Testing procedure: Inspect the cryptography policy and inventory of cryptographic keys. Verify key rotation schedules and KMS access controls.
Evidence to collect: Cryptography policy document Key inventory + rotation schedule KMS access logs showing controlled access Sample of TLS / disk encryption configurations
-
Do you have backups + disaster recovery + crisis management capability (Art 21.2.c)?
MediumDo you have backups + disaster recovery + crisis management capability (Art 21.2.c)?
How to test + evidence
Risk: Immutable backups defeat ransomware's most damaging move — encrypting the backups too.
Testing procedure: Verify backup configuration (immutability, off-site copy), DR plan (with RTO/RPO), and the most recent test report.
Evidence to collect: Backup job logs showing daily success DR plan with named RTO/RPO Last DR test report + lessons learned Crisis communication plan
-
Is cybersecurity training delivered to all staff annually with role-based content (Art 21.2.g)?
MediumIs cybersecurity training delivered to all staff annually with role-based content (Art 21.2.g)?
How to test + evidence
Risk: Annual training is necessary but insufficient. Continuous reinforcement + simulations is what changes behaviour.
Testing procedure: Pull training completion records for the audit period. Verify role-based content for high-risk roles (finance, IT admins, executives) and that simulated phishing is tracked with metrics.
Evidence to collect: Training matrix per role Completion percentages with reminders Simulated phishing campaign reports (click + report rates)
-
Do you have a documented incident response plan tested at least annually (Art 21.2.b)?
MediumDo you have a documented incident response plan tested at least annually (Art 21.2.b)?
How to test + evidence
Risk: A generic plan rarely survives contact with a specific scenario. Scenario playbooks force the right pre-decisions to be made on a calm Tuesday afternoon.
Testing procedure: Inspect the IR plan for scenario coverage (ransomware, BEC, data exfil, DDoS, supply chain). Verify the most recent tabletop after-action report and tracked actions.
Evidence to collect: IR plan with version + approval Scenario-specific playbooks Latest tabletop after-action report Actions tracker with completion status
-
Are you ready to file an early warning to the CSIRT/competent authority within 24 hours of a significant incident (Art 23)?
MediumAre you ready to file an early warning to the CSIRT/competent authority within 24 hours of a significant incident (Art 23)?
How to test + evidence
Risk: The 24h clock starts whether you're ready or not. Untested processes consistently miss the deadline because the right person is on holiday or the regulator portal credentials don't work.
Testing procedure: Inspect the runbook for the 24h early warning. Verify named roles, contact details, and a recent walkthrough/tabletop that exercised the notification.
Evidence to collect: 24h notification runbook with template content Named roles + contact details for the responsible regulator Tabletop minutes that exercised the 24h path
-
Do you assess and contractually require cybersecurity practices from your direct suppliers and service providers (Art 21.2.d)?
MediumDo you assess and contractually require cybersecurity practices from your direct suppliers and service providers (Art 21.2.d)?
How to test + evidence
Risk: Most breaches now arrive via the supply chain. NIS2 explicitly calls for continuous, not point-in-time, supplier assurance.
Testing procedure: Sample 25 suppliers (weighted to critical ones). Verify each has a security questionnaire on file, contractual clauses for IS, and ongoing monitoring (security ratings, periodic re-assessment).
Evidence to collect: Supplier register with criticality + scope Onboarding security questionnaires Contractual IS clauses (template + executed examples) Continuous monitoring tooling output
-
Is there a process for handling and disclosing vulnerabilities (Art 21.2.e + coordinated disclosure)?
MediumIs there a process for handling and disclosing vulnerabilities (Art 21.2.e + coordinated disclosure)?
How to test + evidence
Risk: Coordinated disclosure builds trust with researchers and gives you a structured channel — the alternative is finding out about a vuln from a tweet.
Testing procedure: Inspect the published vulnerability disclosure policy (security.txt or /security page) and the internal patch SLA. Verify the SLA is met for a sample of CVEs in the audit period.
Evidence to collect: Public vulnerability disclosure policy / security.txt Patch SLA per severity (e.g. critical 7d / high 30d) Sample of vulnerabilities + patch dates showing SLA met Records of researcher reports + responses