NIS2 Compliance Checklist: 10 Measures You Need in 2026

NIS2 audits are starting in 2026 across EU member states that have transposed the directive. Germany alone pulled 29,500 entities into scope. If you are still treating NIS2 as a future concern, you are already behind.

The good news: the requirements are specific and actionable. Article 21 defines exactly 10 cybersecurity measures every in-scope company must implement. The challenge is not understanding what NIS2 wants. It is producing the evidence that you are actually doing it.

This checklist maps each requirement to concrete actions, highlights where most companies have gaps, and shows how device intelligence and bot detection close several of them at once.

Before you start: confirm you are in scope

NIS2 applies automatically based on sector and size. There is no application process and no opt-out.

You are in scope if:

• Your company operates in one of the 18 covered sectors (energy, transport, health, digital infrastructure, manufacturing, food production, and more)
• You have 50+ employees, or your annual turnover exceeds EUR 10 million

You are in scope regardless of size if you are:

• A DNS service provider, TLD name registry, or trust service provider
• A provider of public electronic communications networks or services
• A central government entity
• The sole provider of an essential service in your member state

If you are unsure, check Annex I and Annex II of Directive 2022/2555. If your sector appears, check your employee count and revenue against the thresholds.

The 10 Article 21 measures: your compliance checklist

Each measure below includes what NIS2 expects, what auditors will look for, and practical steps to get there.

1. Risk analysis and information system security

What NIS2 expects: Formal, documented risk assessments covering your IT and OT infrastructure. Identification of threats, vulnerabilities, and their likelihood of exploitation.

What auditors will look for: A documented risk register, regular review cycles (not just annual), and evidence that risk assessments inform actual security decisions.

Action items:

• Inventory all systems that support your operations, including web applications, APIs, databases, and third-party integrations
• Assess automated traffic risk. If your application receives web traffic, bots are a threat category. Over half of all internet traffic is automated (Imperva, 2024). A risk analysis that ignores this is incomplete.
• Deploy continuous risk scoring. Static assessments go stale. Device-level risk scoring on every session provides real-time risk data that auditors can verify.
• Document everything. Risk assessments must be retrievable, dated, and linked to specific systems.

Guardian’s device intelligence scores every session in real time based on 70+ device signals. That is auditable evidence of continuous risk analysis on every access, not a quarterly spreadsheet.

2. Incident handling

What NIS2 expects: Documented procedures for prevention, detection, analysis, containment, response, and recovery from cybersecurity incidents.

What auditors will look for: Written incident response plans, evidence of drills or tabletop exercises, detection tooling with logs, and records of past incidents and how they were handled.

Action items:

• Build detection-first. You cannot handle incidents you do not see. Deploy monitoring that catches threats in real time.
• Define severity levels that map to NIS2’s “significant incident” threshold (severe operational disruption or financial loss)
• Establish escalation paths with named owners who can authorize the 24-hour early warning notification
• Run tabletop exercises quarterly, simulating scenarios like credential stuffing campaigns, DDoS attacks, and data exfiltration

For web applications, automated threats are the most common incident source. Bot detection provides the early warning layer that catches credential stuffing, account takeover, and scraping before they cross the “significant incident” threshold.

3. Business continuity and disaster recovery

What NIS2 expects: Plans for maintaining operations during major cyber incidents. Verified backup procedures, system restoration sequences, and crisis management protocols.

What auditors will look for: Documented BCP/DR plans, evidence of backup testing (not just backups existing, but verified restores), crisis communication templates, and a named crisis response team.

Action items:

• Test your backups. Schedule verified restores quarterly. Document the results.
• Define recovery time objectives (RTOs) for each critical system
• Create a crisis communication plan with pre-drafted templates for customers, regulators, and the press
• Establish an alternate operating procedure for core business functions if primary systems are unavailable

4. Supply chain security

What NIS2 expects: Assessment and management of cybersecurity risks from your direct suppliers and service providers. Contractual security requirements for vendors.

What auditors will look for: Vendor risk assessments, contractual clauses covering cybersecurity obligations, incident reporting requirements in vendor contracts, and periodic reassessment evidence.

Action items:

• Map your critical suppliers. Which vendors have access to your systems, data, or infrastructure?
• Assess their security posture. Use questionnaires, certifications (SOC 2, ISO 27001), and where appropriate, on-site assessments.
• Add NIS2 clauses to contracts. Require incident notification, audit rights, and specific security standards from vendors.
• Monitor continuously. Supplier risk is not static. Build in periodic reassessment triggers.

The reverse angle matters too. If your NIS2-covered customers embed your product in their stack, they need to prove you are not a weak link. Having device intelligence and bot detection embedded in your platform gives them auditable proof that your product actively manages automated threats. That is not just your compliance. It is your customers’ compliance, and it becomes a sales differentiator.

5. Security in system acquisition, development, and maintenance

What NIS2 expects: Secure development lifecycle practices, vulnerability handling, and responsible disclosure procedures.

What auditors will look for: Documented SDLC policies, code review practices, dependency scanning, vulnerability management workflows, and disclosure procedures.

Action items:

• Integrate security into CI/CD. Automated SAST/DAST scanning on every build.
• Track dependencies. Monitor for vulnerabilities in third-party libraries.
• Define a vulnerability disclosure process. Have a security contact, response SLA, and coordinated disclosure workflow.
• Patch within defined SLAs. Critical vulnerabilities should have documented maximum remediation timelines.

6. Effectiveness assessment

What NIS2 expects: Ongoing policies and procedures to regularly test, audit, and review the effectiveness of your cybersecurity measures.

What auditors will look for: Penetration test reports, security audit findings, continuous monitoring dashboards, and evidence that findings led to improvements.

Action items:

• Conduct regular penetration testing. Annual at minimum, with retesting after significant changes.
• Deploy continuous monitoring. Real-time dashboards that show threat trends, detection rates, and security posture over time.
• Track metrics. Mean time to detect (MTTD), mean time to respond (MTTR), false positive rates, and blocked threat volumes.
• Close the loop. Document how assessment findings translate into security improvements.

Guardian’s dashboard provides continuous visibility into your threat landscape: bot traffic volumes, device risk distributions, blocked threats, and anomaly trends. That is the kind of ongoing effectiveness evidence NIS2 demands.

7. Cybersecurity training and basic cyber hygiene

What NIS2 expects: Regular staff awareness programs and security training. Special emphasis on management body training (Article 20 explicitly requires it).

What auditors will look for: Training records with dates and attendance, management training certificates, phishing simulation results, and evidence of regular refresher programs.

Action items:

• Train your board. Article 20 requires management bodies to undergo cybersecurity training. This is not optional and must be documented.
• Run phishing simulations at least quarterly.
• Cover the basics. Password hygiene, social engineering recognition, secure device handling, and incident reporting procedures.
• Track completion rates and follow up on non-compliance.

8. Cryptography and encryption policies

What NIS2 expects: Documented policies on the use of cryptography and encryption where appropriate. Standards for data-at-rest and data-in-transit protection.

What auditors will look for: Encryption policies, TLS configuration standards, key management procedures, and evidence of regular cryptographic reviews.

Action items:

• Enforce TLS 1.2+ everywhere. No exceptions for internal services.
• Encrypt sensitive data at rest. Database encryption, disk encryption, and backup encryption.
• Document your key management process. Who holds keys, rotation schedules, and revocation procedures.
• Review cryptographic standards annually. Algorithms weaken over time.

9. Access control and asset management

What NIS2 expects: Role-based access control, principle of least privilege, personnel vetting, and complete asset inventory.

What auditors will look for: Access control matrices, evidence of regular access reviews, asset inventory with ownership assigned, and device management policies.

Action items:

• Implement least privilege. Every user gets the minimum access needed for their role. Review quarterly.
• Maintain a complete asset inventory. Every device, server, application, and API endpoint that touches your infrastructure.
• Know your devices. This goes beyond traditional IT asset management. For web applications, you need to know what devices are accessing your systems, their trust level, and whether they have been tampered with.
• Conduct access reviews at least quarterly, with documented sign-off from managers.

Device fingerprinting transforms this from a manual exercise into an automated one. Guardian identifies every device that interacts with your application, assigns a persistent identifier across sessions, and scores its trustworthiness based on 70+ signals. You get a real-time asset registry of every endpoint touching your system, with risk context attached.

10. Multi-factor authentication and continuous authentication

What NIS2 expects: MFA or continuous authentication solutions, secured voice/video/text communications, and secured emergency communication systems.

What auditors will look for: MFA deployment records, continuous authentication capabilities, secured communication channels for crisis scenarios, and evidence of regular review.

Action items:

• Deploy MFA across all privileged access. Admin panels, production systems, and any system with access to sensitive data.
• Layer in continuous authentication. MFA verifies identity at the gate. Continuous authentication verifies it throughout the session.
• Secure internal communications. Encrypted channels for incident response and crisis management.
• Document everything. Which systems have MFA, which authentication methods are used, and how continuous authentication works.

Device intelligence functions as a continuous, invisible authentication layer. It does not replace MFA, but it strengthens it by verifying the device itself is trusted, not just the credentials. When session hijacking bypasses MFA by stealing a session token, device fingerprinting detects the environment change. When credentials are stuffed from a residential proxy on a spoofed browser, device intelligence catches the mismatch.

The incident reporting process: build it now

Do not wait for your first incident to figure out the reporting workflow. NIS2’s timeline is tight.

Within 24 hours: Submit an early warning to your national CSIRT. Include whether the incident appears malicious and whether it has cross-border impact. This is a brief alert, not a full analysis.

Within 72 hours: Submit an incident notification with your initial assessment of severity, impact, and indicators of compromise.

Within 1 month: Submit a final report with a detailed description, root cause analysis, mitigation measures, and cross-border impact.

Build this workflow before you need it:

1. Define “significant incident” criteria for your organization. Map them to NIS2’s threshold: severe operational disruption or financial loss.
2. Create notification templates for each stage.
3. Assign a named reporter with authority to submit the 24-hour early warning without waiting for committee approval.
4. Connect your detection tools to your response workflow. If your bot detection flags a credential stuffing campaign at scale, that signal should automatically trigger your incident classification process.
5. Drill it. Run a simulated incident through the full 24/72/30 pipeline at least twice a year.

Board-level governance: the personal liability angle

Article 20 makes cybersecurity a board responsibility. This is not a suggestion.

Management bodies must approve cybersecurity risk-management measures, oversee their implementation, and complete cybersecurity training. Members can be held personally liable for gross negligence after an incident.

For essential entities, repeated violations can result in a temporary ban from management positions.

What this means in practice:

• Board meeting minutes must document cybersecurity risk discussions
• Training certificates and logs must exist for every management body member
• Security policies require formal board approval, not just CISO sign-off
• The CISO must have a direct reporting line to the board, with regular updates

The board does not need to become technical. But they need to understand the risk landscape, approve the strategy, and have evidence they did both.

How device intelligence closes multiple compliance gaps at once

Most NIS2 compliance programs treat each Article 21 measure as a separate workstream. That works, but it creates silos and duplicates effort. Device intelligence cuts across multiple requirements simultaneously.

That is five of the ten requirements partially addressed by a single capability layer. Not fully (you still need policies, training, encryption, and more), but the hardest part of NIS2 compliance is producing continuous, auditable evidence. Device intelligence produces it automatically on every session.

Start your free trial

Getting started: practical next steps

1. Confirm your scope. Check your sector against Annex I/II and your size against the thresholds. Read our full NIS2 explainer if you are unsure.
2. Gap-assess against Article 21. Walk through all 10 measures and rate your current maturity honestly.
3. Prioritize by risk. If you have web-facing applications, risk analysis (21a), incident handling (21b), access control (21i), and continuous authentication (21j) should be early priorities.
4. Deploy detection first. You cannot comply with requirements you cannot measure. Start with visibility into what is actually hitting your systems.
5. Document as you go. Every control you implement, every risk you assess, every incident you handle. NIS2 is a “prove it” regulation.
6. Brief your board. Schedule a NIS2 readiness briefing. Ensure management training is on the calendar.

NIS2 is not asking you to build a fortress. It is asking you to demonstrate, continuously and with evidence, that you understand your risks and are actively managing them. Start with the evidence. The compliance follows.