Palo Alto Networks NIS2 Compliance: What NGFW, Prisma Cloud, and Cortex XDR Actually Cover (and What They Don’t)

Ask a Palo Alto Networks account team whether their platform makes an organisation NIS2 compliant, and the pitch will lean toward yes. Ask an auditor the same question about a live NGFW, Prisma Cloud, and Cortex XDR deployment, and the answer looks different: solid technical coverage on three of Article 21(2)’s ten required measures, and a stack of missing paperwork on the rest.

That gap isn’t a knock on the products — NGFW, Prisma Cloud (now largely folded into Cortex Cloud), Cortex XDR, and Cortex XSOAR are genuinely capable tooling. It’s a knock on the assumption that being in scope for NIS2 and owning good security tools are the same problem. Article 21(2) asks for ten categories of measures, and roughly seven are policies, assessments, and documented processes no console generates on its own.

This guide maps each core Palo Alto product to the specific Article 21(2) letter it supports, pulls in the CIR 2024/2690 technical Annex where it genuinely applies (correcting a citation that circulates in vendor marketing), and lists what an auditor asks for that the stack doesn’t produce.

Does Article 21(2) Apply to You?

Article 21 applies to essential and important entities across the sectors listed in Annexes I and II — energy, transport, banking, health, digital infrastructure, manufacturing, and others — once an organisation clears the medium-or-large enterprise size threshold (roughly 50+ staff, or turnover and balance sheet both above €10 million), or is separately designated regardless of size. If that’s already confirmed, the sharper question is: does a Palo Alto deployment demonstrate compliance with Article 21(2), or just reduce the risk that a gap in it turns into an incident? Those are different questions, and the mapping below keeps them separate.

The Ten Article 21(2) Measures — Where the Palo Alto Stack Actually Lands

Article 21(2) lists ten mandatory measure categories [1]. Mapped against the four products this guide covers, the pattern is consistent: strong technical coverage on network security, incident handling, and part of access control — and no coverage at all on the governance and documentation measures.

Palo Alto Product	Article 21(2) Letter(s)	What It Actually Covers	Where Coverage Stops
NGFW (PAN-OS)	(e) network security	Segmentation, app-ID/user-ID policy enforcement, IPS/threat prevention at the perimeter and between zones	Doesn’t produce the written network-security policy an auditor asks to see
Prisma Cloud / Cortex Cloud	(a) risk analysis (partial); (i) asset management (partial)	Cloud posture findings, misconfiguration detection, workload and identity risk scoring across hybrid/multi-cloud estates	Doesn’t write the risk-analysis policy itself, and CIR 2024/2690’s technical Annex only binds cloud providers, not cloud customers running workloads there — see correction below
Cortex XDR	(b) incident handling	Correlated detection across endpoint, network, and cloud telemetry; automated investigation and containment	Detection isn’t the same as (f) — the documented procedure to assess whether the whole risk-management programme is working
Cortex XSOAR	(b) incident handling (documentation layer)	Playbook-driven case timelines, evidence capture, and the audit trail Article 23 notifications need to be defensible	Automates the paperwork during an incident — doesn’t write the incident-handling policy that has to exist before one

NGFW (PAN-OS): Network Security and Segmentation — Article 21(2)(e)

NGFW is the cleanest mapping in the stack. Article 21(2)(e) requires “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure” [1], and network security in practice means segmentation, controlled inter-zone traffic, and restricted remote access. That’s also the language ENISA’s technical implementation guidance uses for good practice — access between zones restricted to what’s necessary, administration networks segregated from operational traffic, segmentation rules reviewed on a schedule [5]. App-ID and User-ID policy enforcement on a PAN-OS firewall is a direct technical implementation of that segmentation principle, and it lines up with CIR 2024/2690 Annex Section 6.7 (network security) and 6.8 (network segmentation) — the technical-methodology reference point for digital-infrastructure entities, and a reasonable good-practice benchmark for everyone else [3].

The mechanism matters more than the checkbox. Palo Alto’s own Unit 42 incident-response team found that in the fastest quarter of 2025 intrusions, attackers moved from initial access to data exfiltration in 72 minutes — four times faster than the year before [6]. Segmentation doesn’t stop initial access; it caps how far a compromised zone can reach before containment. That’s the actual risk (e) is managing — not the fact of having a firewall, but whether its rule base can stop lateral movement once perimeter defence has failed.

What NGFW doesn’t do: write the network security policy itself. Auditors under Article 32 (essential entities) or Article 33 (important entities) ask for the policy governing how segmentation decisions get made and reviewed — a PAN-OS rule base, however well-configured, is evidence of implementation, not the governance artefact.

Prisma Cloud / Cortex Cloud: Correcting the “CIR 6.7” Cloud Security Claim

A specific citation circulates in vendor and reseller material: that cloud security posture tools satisfy “CIR 2024/2690 Section 6.7.” That’s incorrect on two counts, and worth untangling because it’s the kind of error that looks authoritative until someone checks the primary text.

Section 6.7 of the CIR Annex is Network Security — the same sub-point NGFW maps to above — not a cloud-specific section [3]. There is no dedicated “cloud security” heading in the Annex; cloud-relevant controls sit across Section 6.1 (acquisition of ICT services), Section 11 (access control), and Section 12 (asset management) instead [3]. More importantly, CIR 2024/2690 only legally binds nine categories of digital-infrastructure and digital-service entities — DNS providers, TLD registries, cloud computing providers, data centres, CDNs, MSPs, MSSPs, online marketplace/search/social platforms, and trust service providers [4]. An organisation merely running workloads on a cloud platform isn’t automatically bound by the CIR’s technical Annex unless it is itself one of those nine provider types (most often the MSP/MSSP or cloud-provider category — see the cloud provider incident-response guide).

That doesn’t make Cortex Cloud’s posture findings useless for a general NIS2 entity — CIEM capability alone calculates effective permissions across AWS, Azure, and GCP, flags overly-permissive access, and recommends least-privilege fixes [10], a genuinely useful input to Article 21(2)(a) risk analysis and the asset-inventory half of (i). Unit 42’s own research attributes identity weaknesses — stolen credentials, MFA bypass, IAM misconfiguration — a role in nearly 90% of the incidents it investigated in 2025 [6]. The posture score is an input to the risk-analysis policy, not a substitute for having written one — and the CIR citation belongs to a different section than the one usually quoted for it.

Cortex XDR: Feeds Article 21(2)(b), Not (f)

Cortex XDR’s correlated detection across endpoint, network, and cloud telemetry is a direct technical contribution to Article 21(2)(b) — incident handling — and to CIR Annex Section 3 (Incident Management), specifically 3.2 monitoring and logging, and 3.5 incident response [1][3]. Faster, better-correlated detection shortens the window between compromise and containment, which is the entire point of (b).

Where it gets conflated: (f) requires “policies and procedures to assess the effectiveness of cybersecurity risk-management measures” [1] — a distinct, recurring governance exercise, not a detection capability. A well-tuned XDR platform can supply evidence for an effectiveness review (detection rates, dwell time, false-positive trends), but it isn’t the review itself. Conflating good detection tooling with a documented process for periodically assessing whether the whole risk-management programme works is a common, easily-caught gap in Article 21(2) self-assessments.

Cortex XSOAR: Automating the Article 23 Paper Trail

Article 23 sets a three-stage reporting clock once a significant incident is confirmed: an early warning within 24 hours of becoming aware, a fuller incident notification within 72 hours, and a final report no later than one month after that notification [2]. Meeting those deadlines under pressure is largely a documentation problem — assembling the timeline, severity assessment, and indicators of compromise fast enough to file on time.

This is where Cortex XSOAR’s playbook-driven case management earns its place: automated evidence capture and a structured incident timeline map onto CIR Section 3.3 (event reporting) and 3.6 (post-incident review) [3], and onto what Article 23 notifications require. In our experience reviewing incident-response templates against this timeline, the 72-hour notification is the stage most likely to slip — not because the technical response is slow, but because nobody assigned ownership of drafting the regulatory filing itself. XSOAR shortens the evidence-gathering half of that problem; it doesn’t decide who signs the notification or what the entity’s escalation policy says about when “early warning” triggers.

Expedition: Configuration Hygiene as a Compliance Side Effect

Expedition is Palo Alto’s free, community-supported migration tool — the fourth generation of what used to be the Migration Tool — built to convert legacy, port-based firewall rules into application-based PAN-OS policy using machine-learning-assisted recommendations [7]. It’s explicitly meant for temporary migration work, not production runtime [7].

Its relevance to Article 21(2) is indirect but real: CIR Annex Section 6.3 (configuration management) and 6.4 (change management) expect a defensible record of how network configuration got to its present state [3]. A legacy rule base built up over a decade of ad hoc changes is exactly the kind of asset an Article 32 on-site audit flags — not because the rules are wrong, but because nobody can explain why they exist. Running the migration through Expedition and keeping the before/after policy diff produces useful change-management evidence for that section, as a byproduct of the migration rather than a compliance feature in itself.

The Measures Palo Alto Never Touches

Seven of Article 21(2)’s ten letters have no meaningful coverage from NGFW, Prisma Cloud/Cortex Cloud, Cortex XDR, Cortex XSOAR, or Expedition combined. None of this is a defect in the products — they’re security tools, not governance, continuity, or HR systems.

Letter	Measure	What Actually Closes It
(a)	Risk analysis policy	A written risk-analysis and information-security policy — not a tool’s risk score
(c)	Business continuity	Backup strategy, disaster-recovery plan, and a documented crisis-management procedure
(d)	Supply chain security	Supplier classification, security clauses in contracts, and a supplier directory — none of it is a security-product function
(f)	Effectiveness assessment	A recurring, documented procedure for reviewing whether the risk-management programme as a whole is working
(g)	Cyber hygiene and training	A training programme and awareness materials — no security platform delivers staff training
(h)	Cryptography policy	A written standard for when and how encryption and key management are applied, beyond what’s encrypted in transit by default
(i)	HR security (non-asset half)	Background-check procedures and offboarding/termination processes — asset inventory is only half of (i)

What an Auditor Still Wants to See

Under Article 21‘s supervisory regime, essential entities face proactive on-site inspections, random checks, and security audits under Article 32 with no trigger required [11]; important entities face reactive review under Article 33, triggered by an indication of non-compliance. Either way, the request pattern is consistent across two roles:

• CISO / Security Architect — asked to demonstrate the technical control (NGFW rule base, XDR detection coverage, Cortex Cloud posture findings) actually implements the policy on paper. A mismatch between the documented policy and the live configuration is a common audit finding in its own right.
• Compliance Officer — asked for the seven governance documents in the gap table above, dated, version-controlled, and mapped to the specific Article 21(2) letter each one satisfies. This is usually the longer half of audit preparation, precisely because it has no corresponding security-tool output to point to.

Frequently Asked Questions

Does owning Palo Alto Networks products make an organisation NIS2 compliant?
No single vendor’s product suite satisfies Article 21(2) alone. NGFW, Prisma Cloud/Cortex Cloud, Cortex XDR, and Cortex XSOAR together give strong technical coverage of roughly three of the ten required measure categories. The rest are governance and documentation obligations that exist independently of any security tool.

Does CIR 2024/2690 apply just because a company uses cloud infrastructure?
No. The CIR’s technical Annex legally binds only nine defined categories of digital-infrastructure and digital-service providers [4]. A general entity that merely runs workloads on a commercial cloud platform isn’t automatically in that scope; Article 21(2) still applies directly, just not the CIR’s provider-specific Annex.

Which Article 21(2) measure is easiest to mistake as “covered” by security tooling?
(f) — effectiveness assessment. Detection metrics from a platform like Cortex XDR look like evidence of an effectiveness review, but (f) asks for a documented, recurring procedure to assess the whole risk-management programme, not a dashboard of statistics.

Does Cortex XSOAR meet the Article 23 deadlines automatically?
It shortens the evidence-gathering work the 24-hour and 72-hour deadlines demand, but it doesn’t file the notification or decide when the clock starts — those remain organisational decisions [2].

Key Takeaways

• NGFW, Prisma Cloud/Cortex Cloud, Cortex XDR, and Cortex XSOAR map cleanly to Article 21(2)(b) and (e), and partially to (a) and (i) — roughly three of ten required measures.
• The widely repeated “CIR 2024/2690 Section 6.7 covers cloud security” claim is inaccurate on two counts: 6.7 is network security, not cloud-specific, and the CIR’s technical Annex only binds nine defined digital-infrastructure entity types — not every cloud customer.
• Seven measures — (a) policy, (c) business continuity, (d) supply chain, (f) effectiveness assessment, (g) training, (h) cryptography policy, (i)’s HR half — require documentation no security platform produces.
• Expedition’s migration output doubles as configuration-management evidence for CIR Section 6.3/6.4, if the before/after policy diff is retained rather than discarded after cutover.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

• NIS 2 Directive, Article 21 — nis-2-directive.com
• NIS 2 Directive, Article 23 — nis-2-directive.com
• CIR (EU) 2024/2690 Annex, technical and methodological requirements — OpenKRITIS mapping
• “NIS2 CIR 2024/2690: Cybersecurity Requirements for EU Digital Infrastructure” — Advisera
• ENISA Technical Implementation Guidance on cybersecurity risk-management measures (v1.0, June 2025) — enisa.europa.eu
• 2026 Unit 42 Global Incident Response Report — Palo Alto Networks
• Expedition Documentation — Palo Alto Networks LIVE community
• Cortex Cloud product overview — Palo Alto Networks
• “Palo Alto Networks and Deutsche Telekom Bring AI-Driven Security with Advanced Sovereignty Controls” — Palo Alto Networks press release
• CIEM — Cloud Infrastructure Entitlement Management product page — Palo Alto Networks
• NIS 2 Directive, Article 32: Supervision of essential entities — nis-2-directive.com