SAP NIS2 Compliance: Mapping GRC, ETD, and IAG to Article 21(2) — The Matrix No SAP Vendor Publishes

SAP runs the ERP backbone for a large share of Europe’s manufacturing, energy, healthcare, and public-sector organisations — which means SAP is also, quietly, part of the “network and information system” that NIS2 Article 21(2) regulates. Three SAP products get cited constantly in compliance conversations: GRC Access Control, Enterprise Threat Detection (ETD), and Identity Access Governance (IAG). What almost nobody publishes is exactly which Article 21(2) letter, and which section of Commission Implementing Regulation (EU) 2024/2690’s technical Annex, each one actually supports. This guide builds that matrix — and corrects two citation errors that circulate widely enough to have shown up, unprompted, in this article’s own research brief.

In short: SAP GRC supports Article 21(2)(a) and (i). SAP ETD supports Article 21(2)(b), tied to CIR Annex Section 3.2 — not “Section 6.11,” which doesn’t exist. SAP IAG supports Article 21(2)(i), tied to CIR Annex Section 11 — not “Section 6.3,” which is configuration management, unrelated to identity. None of the three, alone or together, produces the written policy documents an auditor asks for on day one.

Does NIS2 Apply to Your SAP Environment?

Plain-language summary: NIS2 doesn’t regulate SAP directly. It regulates your organisation, based on your size and sector — and once you’re in scope, Article 21(2)’s ten measures apply to every system that supports a regulated service, SAP included.

Question	If yes
Are you a medium/large enterprise (≥50 staff, or turnover and balance sheet both above roughly €10M) in an Annex I or Annex II sector — manufacturing, energy, transport, health, public administration, digital infrastructure, and others?	You’re presumptively in scope as an essential or important entity.
Does SAP (S/4HANA, ECC, or any SAP module) process, store, or support the finance, production-planning, or supply-chain data behind that regulated service?	Article 21(2)’s ten measures apply to that SAP landscape exactly as they apply to any other system.
Is your organisation itself a DNS provider, TLD name registry, cloud/data-centre/CDN provider, MSP, MSSP, online marketplace, search engine, social platform, or trust service?	CIR 2024/2690’s technical Annex binds you directly, section by section.
None of the above — you just run SAP as an ordinary ERP inside a regulated sector?	The CIR Annex isn’t a binding requirement for you — but its section numbers are still the most detailed technical benchmark available for what “good” looks like under Article 21(2). Auditors reference it informally even where it doesn’t formally apply.

That last distinction matters and gets skipped constantly: CIR 2024/2690’s Annex legally binds only eleven defined categories of digital-infrastructure and digital-service providers (DNS providers, TLD registries, cloud, data-centre, and CDN providers, MSPs, MSSPs, online marketplaces, search engines, social-networking platforms, and trust services) [2][11]. Most SAP customers — a manufacturer, a hospital group, a logistics operator — aren’t in that list. For them, Article 21(2)’s ten measures are directly mandatory regardless of tooling, but the CIR’s granular sub-points are a technical reference, not a checklist a regulator can cite against you by section number. This article uses those section numbers throughout precisely because they’re the sharpest available technical benchmark — not because every reader is legally bound by them. Germany’s national NIS2 competent authority, the BSI, transposes the same ten measures nationally under §30 Abs. 2 BSIG and points regulated entities toward ISO/IEC 27001:2022 or BSI-Standard 200-1 for the underlying management system [4] — a useful cross-check if your organisation is weighing an ISO-aligned ISMS against a directive-only reading of Article 21(2).

Why SAP Is NIS2’s Biggest Blind Spot

Security teams build their NIS2 programme around network firewalls, endpoint detection, and cloud posture management — and leave the ERP layer to the Basis team. SecurityBridge’s review of SAP security gaps found the pattern repeatedly: no real-time threat detection at the SAP application layer, segregation-of-duties (SoD) monitoring run at best quarterly, SAP Security Notes tracked unsystematically, custom ABAP code deployed without a security scan, and “firefighter” emergency-access IDs used without automated session recording [8]. In a Belgium/Netherlands readiness review of 120 essential entities, SecurityBridge reports that 52% lacked a cybersecurity policy formally approved by their management body [8] — the exact governance failure Article 21(2)(a) exists to close.

The regulatory exposure is direct, not theoretical: Onapsis notes that a disruption to a system running core financial or supply-chain operations is “almost guaranteed to be classified as a significant incident” under NIS2 [10], which starts the Article 23 24-hour early-warning clock. SecurityBridge separately reports that Germany’s supervisory authority opened formal proceedings in May 2026 over Article 23 notification failures [8] — an early signal that regulators are actually checking this clock, not just publishing it.

The SAP-to-Article 21(2) Compliance Matrix

This is the mapping the three leading SAP-security vendor pages — Layer Seven Security, SecurityBridge, and Onapsis — all discuss NIS2 without ever publishing [8][9][10]. Each treats NIS2 as background context for a generic product pitch. Here’s the specific version, verified line by line against the NIS2 Directive and the CIR 2024/2690 Annex [1][2][3][11] — see our full Article 21(2) breakdown and CIR 2024/2690 guide for the complete ten-measure and thirteen-section picture.

SAP product	Article 21(2) letter	CIR 2024/2690 Annex section
SAP GRC — Access Control module	(a) risk analysis and ISP; (i) access control policies	Section 2 (risk management policy) + Section 11 (access control)
SAP Enterprise Threat Detection (ETD)	(b) incident handling	Section 3.2 (monitoring and logging)
SAP Identity Access Governance (IAG)	(i) human resources security, access control policies, and asset management	Section 11 (access control), notably 11.2 management of access rights and 11.3 privileged accounts

Two corrections worth flagging: a claim resembling “SAP ETD maps to CIR Annex 6.11” circulates in generic compliance content — Section 6 (acquisition, development and maintenance) runs 6.1 through 6.10 and stops there; no 6.11 exists anywhere in the 13-section Annex. Logging and monitoring is Section 3.2, filed under incident handling, not acquisition. Similarly, “CIR Annex 6.3 for role-based access” is wrong on two counts: 6.3 is configuration management, and access control has its own dedicated Section 11, with role/access-rights detail at 11.2.

SAP GRC Access Control: Risk and Access Governance

SAP GRC’s Access Control module is built around a Risk Library that links business processes to specific transactions and authorization objects — including Fiori apps and OData services in current releases — and flags segregation-of-duties (SoD) conflicts automatically, such as one user holding both “create vendor” and “approve payment” access [5]. That’s the risk-analysis capability Article 21(2)(a) asks for, applied at the ERP layer.

Its User Access Review (UAR) module goes further into (i): it routes periodic access certifications to business owners, who confirm each user’s access is still necessary [5] — evidence that maps directly onto CIR Section 11’s access-rights-management sub-point (11.2). What GRC does not do is write the information security policy document itself, or the risk-assessment methodology that explains how your organisation scores and treats those SoD findings. GRC generates the evidence; it doesn’t generate the policy that says what the evidence should be judged against.

SAP Enterprise Threat Detection: Incident Handling at the Application Layer

SAP ETD aggregates logs from your SAP landscape, pseudonymises and normalises them, loads them into SAP HANA, and matches the result against predefined attack-pattern rules — brute-force attempts, suspicious login sequences, attempts to reach critical resources [6]. That’s a direct fit for Article 21(2)(b) incident handling, and specifically for CIR Section 3.2’s monitoring-and-logging requirements: automated, continuous or periodic monitoring, with a documented process for reviewing what the logs show.

The distinction worth understanding before you assume ETD closes this measure alone: conventional SIEM platforms operate at the infrastructure layer and largely can’t parse SAP’s own application-level log formats, while ETD reads those SAP logs natively but has limited visibility into the network and endpoint layer a SIEM covers [6]. The two are complementary, not interchangeable — an incident-handling programme built on ETD alone has a blind spot outside SAP, and one built on infrastructure SIEM alone has a blind spot inside it.

SAP Identity Access Governance: Closing the Access-Control Gap

SAP IAG (Cloud Identity Access Governance) bundles five services — Access Analysis, Privileged Access Management, Role Designer, Access Request, and Access Certification — into a single access-governance layer spanning SAP cloud and on-premise systems [7]. Its Access Certification service automates the periodic review CIR Section 11.2 describes, and its Privileged Access Management service maps to 11.3’s privileged-and-administrative-account controls [7][11].

Where GRC’s Access Control module is strongest inside classic SAP transaction data, IAG is built for the identity layer across hybrid landscapes — useful where role governance needs to span both an on-premise ECC system and a cloud-hosted SAP application. Neither product, however, writes the access control policy document itself — the thing CIR Section 11.1 actually asks for first, before any of the technical controls under it.

What SAP Tooling Doesn’t Give You

Run GRC, ETD, and IAG together and you’ve covered meaningful ground on Article 21(2)(a), (b), and (i). You still have nothing written for (c) business continuity and backup management, (d) supply chain security, (e) secure development and change management for the custom ABAP code your teams still ship, (f) an effectiveness-assessment process, (g) cyber hygiene training, (h) cryptography policy, or (j) MFA policy documentation. None of these are things SAP’s own tooling is designed to produce — they’re organisational policy documents, and an auditor asks for the document, not just a working control.

This is the gap between having a working technical control and having documented, auditable proof that the control exists on purpose, as policy, with an owner and a review cycle. SAP tooling proves the former. Article 21(2), and CIR 2024/2690 behind it, ask for the latter as well.

NIS2 Compliance by Role: What This Means for You

Role	What the SAP-to-Article 21(2) matrix means for you
CISO / IT Security Manager	You have the technical evidence trail (GRC risk data, ETD alerts, IAG certifications) — the gap is turning it into the documented policies and effectiveness-assessment process auditors expect to see alongside it.
Compliance Officer / Legal	Don’t let “we run SAP GRC” stand in for “we’re Article 21(2)-compliant” in an audit trail — SAP tooling covers three of ten measures at best. Track the remaining seven separately.
Board / C-Suite	NIS2 places management-body approval and oversight on these measures directly — see our board governance framework for what that approval process needs to look like in practice, independent of which vendor tooling sits underneath it.

FAQ

Does NIS2 require us to use SAP GRC, ETD, or IAG specifically?
No. Article 21(2) is technology-neutral and never names SAP or any vendor [1]. Any tooling that genuinely satisfies the underlying measure is acceptable — these three are simply the SAP-native options most SAP-run organisations already have licensed.

Is SAP GRC alone enough for NIS2 compliance?
No. It’s strong evidence for Article 21(2)(a) and (i), covering roughly two of the directive’s ten measures. Business continuity, supply chain security, secure development, cryptography policy, and the rest still need to be addressed and documented separately.

Are we legally required to configure ETD to CIR Section 3.2’s exact specification?
Only if your organisation is one of the eleven digital-infrastructure or digital-service categories the CIR Annex directly binds [2][11]. For everyone else, Article 21(2)(b)’s incident-handling obligation is mandatory regardless of tool, and Section 3.2 is the most detailed technical benchmark available for meeting it well — not a literal legal mandate.

We run SAP Business One, not S/4HANA — does any of this still apply?
Applicability turns on your organisation’s size and sector under NIS2, not which SAP product tier you run. A small SAP Business One shop below the important-entity size thresholds is generally out of scope; a large SAP Business One deployment inside a regulated sector is not exempt just because it isn’t running S/4HANA.

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

• NIS2 Directive (EU) 2022/2555, Article 21 — nis-2-directive.com [1]
• Commission Implementing Regulation (EU) 2024/2690, Annex — Advisera full-text mirror [2]
• “CIR 2024/2690 — NIS2 Technical Measures,” nisd2.eu [3]
• Bundesamt für Sicherheit in der Informationstechnik (BSI), “NIS-2 Risikomanagementmaßnahmen” — bsi.bund.de [4]
• “What is SAP (GRC) Access Control?,” Pathlock [5]
• “Log-Driven Security Operations with SAP Enterprise Threat Detection and SIEM/SOAR Platforms,” SAP Architecture Center [6]
• “SAP Cloud Identity Access Governance (IAG) Overview and Product Updates,” SAP Community [7]
• “The SAP Blind Spot: Why NIS2 Finds What Your Security Programme Missed,” SecurityBridge [8]
• “NIS2 Compliance for SAP Solutions,” Layer Seven Security [9]
• “Strengthen SAP Security for NIS2 Compliance,” Onapsis [10]
• “Implementing Acts IT — NIS2 Mapping,” OpenKRITIS — openkritis.de [11]