A Practical Guide to NIS2 Directive Compliance Using Picus

What Is the NIS2 Directive?

The NIS2 Directive (Directive (EU) 2022/2555) is the EU's law for achieving a high common level of cybersecurity across the Union. It entered into force in January 2023, replaced the original 2016 NIS Directive on 18 October 2024, and imposes binding obligations on essential and important entities across 18 critical sectors.

When did NIS2 enter into force, and what did it replace?

NIS2 entered into force in January 2023. EU Member States were required to transpose it into national law by 17 October 2024. It repealed the original NIS Directive (2016/1148) with effect from 18 October 2024.

What does NIS2 change compared to the original NIS Directive?

NIS2 significantly raises the EU's level of ambition on cybersecurity through four main shifts:

• A wider scope covering 18 critical sectors
• Clearer obligations for essential and important entities
• Stronger management accountability
• More aggressive supervision and enforcement

Where Does NIS2 Transposition Stand in 2026?

As of mid-2026, transposition is no longer theoretical. Most Member States (including Germany, Italy, Poland, Belgium, Croatia, Hungary, Greece, the Czech Republic, and the Baltic states) have enacted their national NIS2 laws and are now in live implementation. A smaller group is still completing the process: the Netherlands' Cyberbeveiligingswet is expected to enter into force around 1 July 2026, while France and Spain remain in active legislative processes.

In May 2025, the European Commission issued reasoned opinions to 19 Member States for incomplete transposition. This has compressed the timeline and accelerated enforcement. For essential and important entities, NIS2 is now a live operational obligation, not a future one.

What Technical Requirements Does NIS2 Impose Beyond the Directive Itself?

The obligations of NIS2 do not stop at the level of the Directive. For entities in the digital infrastructure and digital provider sectors, the Commission Implementing Regulation (EU) 2024/2690 (directly applicable without national transposition) translates the high-level measures of Article 21 into more than 150 specific, binding technical and methodological requirements across thirteen thematic areas.

The accompanying ENISA Technical Implementation Guidance explains how entities are expected to implement each requirement and, importantly, how they should evidence it.

The key takeaway: documenting a policy or deploying a tool is not compliance. Controls must be demonstrably effective.

What Should You Be Careful About in the 2026 NIS2 Amendments?

The short answer: the 2026 amendments are still proposals, not law. As of June 2026, the Commission's proposed changes to NIS2 have not been adopted, and they do not alter the core risk-management and incident-notification obligations that NIS2 compliance rests on.

What changes did the Commission propose in 2025–2026?

In November 2025 and January 2026, the Commission proposed targeted changes to NIS2 as part of the Digital Omnibus package and a broader cybersecurity package. The proposals focus on three areas:

• Incident notification routing — a single EU reporting portal operated by ENISA
• Scope clarifications
• Certification-based compliance pathways

Have the 2026 amendments been adopted yet?

No. As of June 2026, the proposals remain in the ordinary legislative procedure and have not been adopted. The Amendment Act text is expected to be finalized in early 2027.

Do the amendments change your core NIS2 obligations?

No. The proposals do not change the substantive risk-management obligations of Article 21 or the notification triggers and deadlines of Article 23. The foundation this guide is built on therefore remains stable.

What stays the same, and why it matters

Across risk management, incident handling, secure development, access control, and effectiveness assessment, NIS2 shifts expectations from control presence to control effectiveness. This creates a growing need for defensible, repeatable, and current evidence that controls work as intended in real-world conditions — evidence that can be produced for an auditor, a competent authority, or a national CSIRT at any time.

How Picus Supports Key NIS2 Requirements

The following sections map specific NIS2 obligations, at both the Directive level (Directive (EU) 2022/2555) and, where applicable, the binding detail of Commission Implementing Regulation (EU) 2024/2690 (the "Implementing Regulation"), to the Picus Platform's validation capabilities.

Each section identifies the regulatory requirement, explains what it demands from essential and important entities, and demonstrates how continuous security validation supports compliance with defensible, audit-ready evidence.

The sections covered are:

• Article 20: Governance and Management Body Accountability
• Article 21(2)(f) & Implementing Regulation Annex Section 7: Assessing the Effectiveness of Cybersecurity Risk-Management Measures
• Article 21(1) & 21(2)(a) & Implementing Regulation Annex Section 2: Risk Analysis, Proportionality, and Security Policies
• Article 21(2)(b) & Implementing Regulation Annex Section 3: Incident Handling
• Article 23: Incident Reporting Obligations (24-Hour and 72-Hour Timelines)
• Article 21(2)(e) & Implementing Regulation Annex Section 6: Security in Acquisition, Development, and Maintenance — Network Security, Vulnerability Handling, and Testing
• Article 21(2)(i) & (j) & Implementing Regulation Annex Section 11: Access Control and Multi-Factor Authentication
• Article 21(2)(d) & Implementing Regulation Annex Section 5: Supply Chain Security
• Article 32: Supervisory and Enforcement Measures – Audits, Scans, and Evidence of Implementation
• Article 21(4): Corrective Measures and Remediation

NIS2 Article 20: Governance and Management Body Accountability

Article 20 makes cybersecurity a board-level legal duty, not an IT concern. It requires the management bodies of essential and important entities to:

• Approve the cybersecurity risk-management measures
• Oversee their implementation
• Undergo cybersecurity training

It also makes them accountable for failures. National transpositions provide for personal liability and, under Article 32(5), the possibility of temporarily barring senior managers from their functions.

How does Picus support the NIS2 Article 20?

Effective oversight requires something a management body can actually see and act on. Picus turns control performance into board-level evidence: continuously updated prevention and detection scores, trend lines showing whether posture is improving or degrading, and clear identification of unresolved gaps.

This gives directors an objective basis for the approval and oversight duties Article 20 imposes, proving their oversight is informed by tested reality rather than status reports, and that the measures they approved are validated on an ongoing basis.

NIS2 Article 21(2)(f) & Implementing Regulation Annex Section 7: Assessing the Effectiveness of Cybersecurity Risk-Management Measures

Why is effectiveness validation now a legal requirement?

This is the single most consequential change NIS2 introduces for security validation, and it is written directly into the law.

Article 21(2) defines ten minimum categories of cybersecurity risk-management measures that every essential and important entity must implement. Point (f) makes assessing whether those measures actually work a mandatory measure in its own right, not an optional best practice.

The Implementing Regulation reinforces this in Annex Section 7, which requires entities to establish policies and procedures to monitor, measure, and evaluate the effectiveness of their cybersecurity risk-management measures. That includes defining what to assess, the methods for monitoring and measurement, who holds responsibility, how results are analysed, and how policies are reviewed and improved over time. ENISA's guidance treats security testing as a recurring means of verifying that measures remain effective.

NIS2 does not merely permit effectiveness testing. It obliges it. And it expects the results to feed directly back into the risk-management programme.

This is precisely the function of the Picus Platform.

How does Picus support NIS2 Article 21(2)(f)?

Picus continuously validates the effectiveness of the controls that underpin every other Article 21 measure.

Rather than relying on periodic, point-in-time assessments that go stale the moment a configuration drifts or a new malware/APT campaign emerges, Picus executes adversary-emulated attack techniques mapped to real-world TTPs and measures whether the entity's implemented security controls actually block, detect, log, and alert on the threats they are supposed to address. The result is a continuously updated, MITRE ATT&CK-mapped record of control performance (prevention scores, detection coverage rates, and remediation tracking) that constitutes exactly the kind of monitoring, measurement, and evaluation Article 21(2)(f) and Annex Section 7 require.

(See the Article 21(4) for the mitigation support).

This transforms the effectiveness-assessment obligation from a documented procedure that an entity promises to follow into an operational, evidence-backed process that produces measurable output on an ongoing basis. When a competent authority asks an essential entity to demonstrate not just that it has a policy to assess effectiveness, but that the assessment is actually being performed and acted upon, the entity can produce validated, time-stamped evidence rather than a narrative assurance.

Here, you can see all of the security control integrations that the Picus Platform can validate.

NIS2 Article 21(1) & 21(2)(a) & Implementing Regulation Annex Section 2: Risk Analysis, Proportionality, and Security Policies

Article 21(1) and 21(2)(a) require essential and important entities to ground their security measures in risk analysis and to keep those measures proportionate to their actual risk, their exposure, size, and the likely severity of incidents. The Implementing Regulation's Annex Section 2 turns this into a full risk-management cycle: risk assessment, risk treatment, management acceptance of residual risk, and continuous review.

How does Picus support the NIS2 Article 21(1) & 21(2)(a)?

The challenge with any risk-based approach is that a risk assessment is only as reliable as the assumptions behind it. Sole reliance on global and theoretical severity ratings (like CVSS, and EPSS) and configuration reviews tell an entity what could go wrong in principle; they do not tell it what is actually exploitable in its specific environment.

Picus grounds risk analysis in validated reality.

Through Adversarial Exposure Validation (AEV), combining agentic, autonomous Breach and Attack Simulation (BAS) and Autonomous Penetration Testing, Picus continuously tests whether the risks identified in an entity's assessment are genuinely exploitable against its live controls. This allows entities to assign evidence-based risk scores using the Picus Score rather than relying on static severity alone, and to demonstrate to management and to competent authorities that the residual risk they have chosen to accept reflects operational reality.

By tying risk identification, assessment, and monitoring to continuous validation results, Picus strengthens the entire risk-management programme and supports the proportionality principle directly: an entity can show that the depth and focus of its measures are calibrated to validated, real-world exposure rather than to generic templates.

NIS2 Article 21(2)(b) & Implementing Regulation Annex Section 3: Incident Handling

Article 21(2)(b) requires incident handling as a minimum measure, and the Implementing Regulation's Annex Section 3 details what this means in practice: detection, analysis, containment, eradication, recovery, documentation, communication plans, role assignment, and post-incident review.

The effectiveness of incident handling depends entirely on whether the underlying detection and response machinery actually fires when an attack occurs — and whether the people and processes around it respond correctly.

How does Picus support the NIS2 Article 21(2)(b)?

Picus continuously exercises the detection, alerting, escalation, and containment workflows that underpin an entity's incident-handling capacity.

Through production-safe adversary-emulated scenarios, Picus validates whether security events are detected, whether EDR, XDR, SIEM rules and alerting pipelines generate alerts with sufficient fidelity for investigation, whether escalation paths function as designed, and where visibility gaps exist across the environment.

This enables essential and important entities to confirm that their incident-handling capability is operationally effective before a real incident (or a competent authority's ad hoc audit following an incident) tests it for them. The resulting evidence also feeds directly into post-incident reviews and continuous improvement, ensuring that incident-handling procedures evolve based on tested control performance rather than assumptions.

In addition, by providing detection content, the Platform strengthens incident handling under NIS2 Article 21(2)(b) by providing ready-to-deploy SIEM and EDR detection rules in vendor-specific and SIGMA formats — no detection engineering expertise required. With each rule mapped to log sources, severity levels, and MITRE ATT&CK techniques, it ensures the alerting pipelines that Picus continuously validates are built on high-fidelity detections, making incident handling operationally effective when it matters most.

Figure 1. Picus Mitigation Library provides vendor-based detection rules

NIS2 Article 23: Incident Reporting Obligations (24-Hour and 72-Hour Timelines)

Article 23 sets one of the Directive's most demanding obligations: a staged timeline running from a 24-hour early warning, to a 72-hour notification with an initial impact assessment and any available indicators of compromise, to a final report within one month.

An incident is significant (and therefore reportable) where it causes or could cause severe operational disruption or financial loss, or affects others through considerable material or non-material damage.

The deadlines are unforgiving and presuppose one thing: an entity cannot report what it cannot detect. If detection controls fail silently, the clocks may start too late, and the indicators of compromise needed at 72 hours may never be captured.

How does Picus support the NIS2 Article 23 for reporting obligations?

Picus supports the reporting obligation by validating that the detection layer actually produces the signal the reporting timeline depends on. By executing adversary-emulated techniques and measuring how EDR, XDR, IDS, and SIEM respond, Picus confirms whether malicious behaviours are detected, whether they are logged with sufficient granularity to support an initial assessment, and whether the indicators of compromise that Article 23(4)(b) expects are actually generated and available.

Picus Detection Analytics shows which techniques trigger alerts and escalation and which are missed, allowing entities to close the visibility gaps that would otherwise translate into late or incomplete notifications.

By grounding detection in continuous validation, Picus helps essential and important entities meet the substance of their reporting obligations – not just procedurally, but with the timely, evidence-rich notifications the Directive demands.

NIS2 Article 21(2)(e) & Implementing Regulation Annex Section 6: Security in Acquisition, Development, and Maintenance

Article 21(2)(e) is one of the broadest measures in the Directive, and the Implementing Regulation's Annex Section 6 expands it into a wide set of binding controls: security in ICT acquisition, secure development lifecycles, configuration and change management, security testing, patch management, network security, segmentation, protection against malware, and vulnerability handling. ENISA's guidance specifically calls for a mix of testing techniques (penetration testing, static and dynamic application security testing, and code review) applied across the lifecycle.

How does Picus support NIS2 Article(2)(e)?

Picus provides empirical validation across this entire surface rather than relying on architecture diagrams, configuration reviews, or one-off test reports.

Network security and segmentation. Picus validates network security and segmentation controls by safely executing network-based infiltration techniques against firewalls and IPS, email infiltration scenarios against secure email gateways and firewalls, and web application attacks against WAFs, IPS, and Web Security Gateways — confirming that each control enforces its configured policies in practice, not just on paper.

Beyond perimeter validation, Picus tests whether segmentation actually prevents unauthorized east-west movement between trust zones, giving entities continuous, evidence-based assurance that network boundaries hold under real attack conditions.

Figure 2. Picus Network Infiltration Attacks by Picus Security Control Validation

Protection against malware. Picus tests whether endpoint and network defenses block and detect the malware and adversary tooling observed in current campaigns, including the specific TTPs of threat groups active against the entity's sector.

Vulnerability handling and patch management. Through its Exposure Validation capability, Picus ingests vulnerability findings from VMs such as Microsoft Defender for Endpoint, Tenable and Rapid7 InsightVM, matches them against live control performance data generated by its own adversarial simulations, and re-prioritises them based on validated exploitability rather than theoretical severity. This lets entities focus remediation on vulnerabilities that are genuinely exploitable in their environment, deprioritise those already mitigated by layered controls, and (after patching) revalidate to confirm that exploitation attempts are no longer successful and that exposure has measurably decreased.

Figure 3. Vulnerability Asset List provided by Picus Platform integrations

The result is a development-and-maintenance security programme whose effectiveness is continuously demonstrated, directly supporting both the Directive's measure and the more granular controls of Annex Section 6.

NIS2 Article 21(2)(i) & (j) & Implementing Regulation Annex Section 11: Access Control and Multi-Factor Authentication

Article 21(2)(i) and (j) require access control policies, asset management, and the use of multi-factor authentication where appropriate. The Implementing Regulation's Annex Section 11 sets out the details: managing access rights, authentication and authorization mechanisms, control of privileged accounts, segregation of administration systems, unique user identities, and MFA. These controls are frequently strong on paper and weak in practice – drift, misconfiguration, and over-provisioned privilege are among the most commonly exploited weaknesses.

How does Picus support the NIS2 Article 21(2)(i) & (j)?

Picus systematically tests identity and access controls against real attacker methodology. Through Autonomous Pentesting, AI agents plan engagements against crown jewels (domain admin, customer databases, payment systems) and chain real exploitation across hosts to capture concrete proof of compromise, not just a list of theoretical findings. This directly validates whether access restrictions and authentication mechanisms prevent unauthorized access and lateral movement, or whether they can be bypassed via credential theft, privilege escalation, and abuse of IAM and Active Directory configurations.

Critically, Picus maps the full attack path from initial foothold to crown jewel, because chained vulnerabilities cause breaches and isolated flaws mostly don't.

In cloud environments, through the Security Control Validation (SCV) module, Picus Platform extends this to IAM policies, misconfiguration exploitation, and privilege escalation across AWS, Azure, and GCP.

Figure 4. Picus Security Control Validation module contains cloud-based attacks for Azure, AWS, and GCP.

This gives essential and important entities evidence that their access-control measures meet the substance of Article 21(2)(i) and (j) and the Implementing Regulation's requirements, with clear identification of where privilege or authentication controls break down and concrete guidance on what to fix.

NIS2 Article 21(2)(d) & Implementing Regulation Annex Section 5: Supply Chain Security

Supply chain security is one of NIS2's most prominent additions.

Article 21(2)(d), reinforced by Article 21(3) and the Implementing Regulation's Annex Section 5, requires entities to account for the vulnerabilities and cybersecurity practices of their direct suppliers and service providers, and to consider the results of Union-level coordinated supply chain risk assessments.

How does Picus support the NIS2 Article 21(2)(d)?

While supply chain governance is principally a contractual and assurance discipline, a significant share of supply chain risk materialises technically, through vulnerabilities in third-party infrastructure, compromised software components, or trust relationships abused for initial access and lateral movement.

Figure 5. Picus Autonomous Pentesting

Picus addresses this technical dimension directly: Autonomous Pentesting agents map the full attack surface, chain real exploitation across hosts, and prove which paths from a compromised supplier or third-party component actually reach the entity's crown jewels, such as domain admin, customer databases, and payment systems.

Rather than theoretical exposure lists, Picus delivers concrete proof of compromise, validating whether segmentation would contain an intrusion and whether monitoring would detect it before damage spreads. The result is operational evidence about how the entity's own defenses perform against supply-chain-borne attack techniques, something supplier questionnaires and contractual assessments alone cannot provide.

NIS2 Article 32: Supervisory and Enforcement Measures — Audits, Scans, and Evidence of Implementation

NIS2 backs its obligations with real supervisory teeth. For essential entities, Article 32 gives competent authorities the power to conduct on-site inspections, regular and targeted security audits, ad hoc audits (including following a significant incident), and security scans, and, critically, to demand evidence of implementation of cybersecurity policies, including audit results and the underlying evidence.

Important entities are subject to comparable, largely ex-post supervision under Article 33.

Non-compliance can attract 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, alongside management accountability under Article 20 and potential personal liability for senior managers under Article 32(6). Providing false or grossly inaccurate information about risk-management measures is itself treated as a serious infringement.

How does Picus support the NIS2 Article 32?

This is where continuous validation becomes a supervisory asset rather than a compliance cost. When an authority requests evidence of implementation under Article 32(2)(g), not a description of intended controls, but proof that they work, Picus provides continuously generated, time-stamped, MITRE ATT&CK-mapped validation data with detailed reporting.

That reporting shows exactly what was tested, what was blocked, what was detected, what was logged and alerted on, and what was not. The same evidence base supports an entity's own internal and independent audits.

It also means an ad hoc audit following an incident finds a defensible, current record of control effectiveness rather than a scramble to assemble proof after the fact.

Because the evidence is produced continuously rather than at assessment time, entities can maintain a state of audit-readiness throughout the supervisory cycle. They can respond to short-notice requests with current data instead of stale point-in-time results.

NIS2 Article 21(4): Corrective Measures and Remediation

Article 21(4) closes the loop: where an entity identifies that its measures fall short, it must remediate without undue delay. The practical difficulty is that generic recommendations rarely translate into fast, defensible fixes.

How does Picus support the NIS2 Article 21(4)?

When Picus identifies a control failure, a technique that was not blocked, a detection that did not fire, a log source that was missing, the Picus Mitigation Library provides vendor-specific and vendor-neutral mitigation guidance. This gives security teams concrete remediation steps rather than generic advice.

Prevention Content

• Vendor-Based Mitigation: Picus Mitigation Library provides validated prevention signatures tailor-made for security controls, such as NGFW, IPS, and WAF.
• Generic Mitigation: Picus provides security best practices and mitigation suggestions that remediate gaps in the security posture.

Figure 6. Picus Platform provides ready-to-apply, and vendor-based prevention suggestions

Detection Content

• Picus Mitigation Library provides vendor-specific detection rules and vendor-neutral SIGMA rules for major SIEM and EDR technologies to detect endpoint attacks.
• Picus also provides log source recommendations to enhance log visibility and SIEM efficiency.

Figure 6. Picus Platform provides ready-to-apply, and vendor-based detection suggestions

After a fix is applied, the same validation scenario can be re-executed to confirm that the corrective measure actually closed the gap.

This turns Article 21(4) from a reactive obligation into a measurable, evidence-backed remediation cycle: identify the validated deficiency, apply targeted mitigation, and prove the fix worked. All within the kind of timeframe "without undue delay" implies.

Making NIS2 Compliance Resilient with Validation

NIS2 was designed to ensure that the network and information systems underpinning Europe's critical sectors remain resilient because the controls protecting them work in practice, not just on paper. The Directive says so in its own text: assessing the effectiveness of cybersecurity risk-management measures is a mandatory measure, the Implementing Regulation makes effectiveness assessment a binding requirement for digital infrastructure and providers, and Article 32 empowers authorities to demand evidence of implementation — not merely evidence of intent.

Essential and important entities should therefore approach NIS2 not as a one-time documentation exercise but as a long-term commitment to continuous assurance. Detection rules degrade, segmentation weakens after changes, access controls drift, and new adversary techniques emerge without being tested against existing defenses. When control effectiveness is assumed rather than proven, NIS2 compliance becomes fragile precisely at the moment a regulator, an auditor, or an attacker tests it.

Picus Platform helps essential and important entities move from periodic, assumption-based compliance to continuous, evidence-based assurance. By validating control effectiveness against real attack behavior, Picus turns NIS2 compliance into a living, defensible security posture — one that satisfies competent authorities, national CSIRTs, and auditors not just at the time of assessment, but continuously.

Get your free demo and see how Picus helps essential and important entities meet their NIS2 obligations with audit-ready evidence.

References

• Directive (EU) 2022/2555 (NIS2 Directive) — in particular Articles 20, 21, 23, 32, 33, and 34.
• Commission Implementing Regulation (EU) 2024/2690 — technical and methodological requirements (Annex Sections 1–13), directly applicable to DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online marketplaces, online search engines and social networking services platforms, and trust service providers.
• ENISA, Technical Implementation Guidance on Commission Implementing Regulation (EU) 2024/2690 (v1.0).

This guide reflects the legal position as of June 2026. The Digital Omnibus and 2026 cybersecurity package proposals to amend NIS2 remained in the legislative process at the time of writing and had not altered the Article 21 risk-management measures or the Article 23 reporting triggers and deadlines referenced above.