The SAP blindspot: why NIS2 finds what your security programme missed

The NIS2 Directive does not just expand in which organizations must comply with EU cybersecurity rules. It changes who is accountable. Article 20 requires management bodies to approve cybersecurity risk-management measures and oversee their implementation. That means boards and senior leadership, including CISOs, carry direct personal responsibility for whether the organization’s critical systems are properly protected.

For most CISOs, the honest answer is that SAP has not been part of the security program. Not because anyone decided to exclude it, but because the tooling, processes, and team structures that grew up around enterprise security were built for a different layer of the stack. SAP was managed by Basis. GRC handled the access reviews. The SOC covered everything else. NIS2 does not recognize that division.

What Article 20 means for SAP

Article 20 requires management to approve and oversee cybersecurity risk-management measures. If a significant incident occurs in SAP and the CISO cannot demonstrate that appropriate controls were in place and continuously monitored, that is an Article 20 problem. The most common scenarios that create this exposure:

• A privilege escalation in SAP enables financial fraud that goes undetected for months
• An unauthorized transport deploys backdoor code to the production system
• A misconfigured RFC connection allows lateral movement from SAP to other critical systems
• A dormant but privileged account is used to exfiltrate financial or HR data

In each case, the question regulators will ask is not just what happened, but what monitoring and controls were in place and whether management had visibility over them. The separation between the security team and the SAP team is not an answer auditors will accept.

Enforcement has started — and the patterns are clear

NIS2 enforcement is no longer theoretical. Across Germany, France, and the Netherlands, regulators have already acted and three patterns are emerging that every CISO should understand.

The first is the reporting clock. Germany opened formal proceedings in May 2026 against several entities for failing to notify within the Article 23 24-hour window. The underlying cause: no detection layer capable of surfacing a reportable incident in time. The clock starts at awareness without real-time monitoring; the breach is discovered after it has already expired. A Dutch telecom provider was fined €525,000 under NIS1 for the same failure. Under NIS2, the fine ceiling is approximately 19 times higher.

The second is the gap between policy and evidence. In May 2026, France’s ANSSI issued formal warnings to entities that could not demonstrate minimum Article 21 measures were operating. Policy documents were deemed insufficient. Belgium’s CCB and the Dutch NCSC/RDI assessment of 120 essential entities reached the same conclusion: having a policy is not the same as having a control that works. That assessment also found that 52% of entities lacked management body-approved cybersecurity policies a direct Article 20 failure.

The third pattern is the one most relevant here: SAP is where all three converge. Board approval rarely covers SAP explicitly. The 24-hour clock runs on incidents originating in SAP. And operational evidence of Article 21 controls within SAP is not produced by generic security tooling.

The gaps NIS2 will find

The most common SAP security gaps are not the result of negligence. They exist because the tooling to close them at scale, in a form that non-SAP security teams could operate, has not always been available. What auditors are increasingly finding:

• No real-time threat detection at the SAP application layer, incidents surface through business anomalies, not security alerts
• SoD monitoring that runs quarterly at best, leaving conflicts undetected, Privileged Access Management closes this
• SAP Security Notes not tracked systematically, Patch Management automates this
• Custom ABAP code deployed without security scanning, introducing vulnerabilities that bypass all network-layer controls
• Firefighter IDs used without automated session recording, Identity Protection covers this
• TrustBroker enforces step-up MFA for high-risk SAP transactions, a control most identity programs stop short of

What closing the gap looks like

The SecurityBridge platform gives the CISO’s program full visibility into SAP without requiring the security team to become SAP experts. It deploys natively within SAP, requires no external infrastructure, and integrates with existing SIEM and SOAR tools.

For NIS2 specifically, it generates the continuous, audit-ready evidence that Article 21 compliance requires and gives management the oversight capability that Article 20 demands. The SAP blindspot can be closed before an auditor finds it. See how.

FAQ’s

Who is personally liable under NIS2?
Article 20 places direct personal responsibility on management bodies boards and senior leadership, including CISOs for approving and overseeing cybersecurity risk-management measures. This is not delegable to a team or a vendor. If a significant incident occurs and appropriate controls cannot be demonstrated, that is an Article 20 problem for the individuals at the top, not just an organizational compliance failure.

What are the most common SAP security gaps NIS2 audits find?
The most consistent findings are: no real-time threat detection at the SAP application layer, SoD monitoring that runs quarterly at best, SAP Security Notes not tracked systematically, custom ABAP code deployed without security scanning, and Firefighter IDs used without automated session recording. These gaps exist not because of negligence but because the tooling to close them at scale in a form that non-SAP security teams can operate has not always been available.

How can I showcase SAP security to an auditor?
Auditors expect a continuous operational record, not a policy document. That means SoD violations detected, attributed, and remediated with timestamps; dormant accounts flagged and actioned with decision records; Firefighter sessions logged and reviewed at transaction level; and MFA challenges recorded with risk classification rationale. SecurityBridge generates this evidence as a by-product of normal platform operation exportable on demand, not compiled manually before each audit.

Request a demo to see what NIS2-ready SAP monitoring looks like in practice. To learn more about how SecurityBridge supports NIS2 compliance, visit our NIS2 page.