SAP Is Not a Black Box Anymore — The CISO Needs to See Inside

SAP security does not fail because organizations lack security tools. It fails when SAP remains disconnected from the security system that tells the CISO whether controls are actually working.

By Eckhart Mehler for CISOsCISO — a perspective on cybersecurity leadership, governance and the decisions that determine whether organizations retain control.

There is a strange contradiction in many large enterprises.

We monitor endpoints with EDR. We correlate identities, devices, network activity and cloud events in our SIEM. We hunt for indicators of compromise. We measure vulnerabilities. We investigate suspicious authentication. We build SOC dashboards and automate incident response.

And then there is SAP.

The system that may run finance, procurement, payments, supply chains, HR and some of the organization’s most sensitive business processes is often treated as a separate security universe.

The SAP team has its tools.

The SOC has its tools.

The CISO has risk reports.

Auditors have their checklists.

Everyone sees something.

But who sees the whole picture?

That, increasingly, is the real SAP security problem.

SAP Was Never Really a Black Box

SAP became a black box organizationally, not technically.

Its complexity encouraged specialization. Specialization created dedicated teams. Dedicated teams developed their own processes, terminology, tools and governance.

Eventually, separation became normal.

Ask the enterprise security team about a compromised endpoint and you may receive a detailed timeline within minutes.

Ask what happened inside a critical SAP system during the same period and the investigation may suddenly cross organizational boundaries.

Who has the logs?

Which logs are enabled?

Who can interpret them?

Are they in the SIEM?

Which privileged SAP activities occurred?

Was custom code involved?

Was an SAP vulnerability exploitable?

Did an attacker move from an endpoint or identity into SAP?

Can the SOC correlate these events?

These should no longer be exotic SAP questions.

They are normal cybersecurity questions.

And that changes what the CISO should expect from SAP security.

The CISO Does Not Need Another Dashboard

This distinction matters.

The objective is not to give the CISO access to another technical console.

The objective is to make SAP part of the organization’s security control system.

For me, that means connecting three perspectives:

Microsoft Defender tells me what is happening around SAP.

Microsoft Sentinel helps tell me what is happening across SAP and the wider enterprise.

Onapsis helps tell me what is specifically dangerous inside the SAP landscape and whether SAP-specific weaknesses and changes are creating exposure.

None of these perspectives is sufficient alone.

Together, however, they can begin to dismantle the SAP black box.

Defender: What Is Happening Around SAP?

An SAP attack rarely begins and ends inside SAP.

An attacker may compromise an endpoint.

Steal credentials.

Abuse an identity.

Escalate privileges.

Access a server.

Move laterally.

Reach SAP.

And then exploit the business application.

That means SAP security cannot be understood by looking only at SAP.

This is where the broader Microsoft Defender ecosystem becomes important.

Endpoint, identity, cloud and other security signals can provide context that the SAP application itself cannot.

A suspicious SAP login is one thing.

A suspicious SAP login associated with a compromised endpoint, anomalous identity behavior and previous malicious activity is something entirely different.

For the CISO, Defender therefore represents an important part of the enterprise attack context.

But Defender does not eliminate the need for SAP-specific security expertise.

It provides another part of the picture.

Sentinel: Where the Pictures Come Together

Microsoft Sentinel can become the bridge between SAP security and enterprise security operations.

That is strategically more important than simply forwarding another log source into a SIEM.

The objective should be correlation.

Imagine an attacker compromising an employee account.

Defender identifies suspicious endpoint behavior.

Identity telemetry indicates unusual authentication.

Shortly afterwards, the same identity performs unusual activity against SAP.

A privileged operation occurs.

A critical SAP transaction is executed.

Perhaps a configuration is changed.

Perhaps data is accessed.

Perhaps an administrative account is created.

Viewed separately, these may appear as different technical events owned by different teams.

Viewed together, they may describe one attack.

That is the value of bringing SAP into the enterprise SOC.

Microsoft’s Sentinel solutions for SAP are designed to correlate SAP application and BTP activity with other enterprise signals and support detections for scenarios including privilege escalation, unauthorized changes, unauthorized access and misuse of sensitive transactions.

For the CISO, this changes an important question.

Instead of asking:

“Are SAP logs being collected?”

I would ask:

“Can our SOC detect an attack that starts outside SAP, enters SAP and then abuses a critical business process?”

That is a much more meaningful security question.

Onapsis: Seeing What Generic Security Tools Cannot

But there is another problem.

SAP is not merely another server workload.

Its security model contains application logic, transactions, authorization concepts, interfaces, custom ABAP code, configuration dependencies and vulnerabilities that require specialized understanding.

This is where platforms such as Onapsis become relevant.

Onapsis adds SAP-specific depth around areas such as vulnerability management, ABAP code analysis, threat detection and continuous monitoring, and its capabilities can be integrated into Microsoft Sentinel.

That combination is important.

Sentinel provides the enterprise correlation layer.

Onapsis provides specialized SAP security context.

The SOC should not have to become a team of SAP security researchers before it can recognize a critical SAP event.

Specialized tooling can translate SAP-specific technical conditions into security-relevant information that enterprise security operations can consume.

This is exactly what should happen in a mature security architecture:

specialized detection at the technology layer, centralized correlation at the enterprise layer.

From Three Tools to One Assurance Model

The mistake would be to procure all three capabilities and declare the problem solved.

Tools do not create governance.

I would think about them as layers of an assurance architecture.

Defender provides context.

What is happening to identities, endpoints and surrounding infrastructure?

Sentinel provides correlation.

How do SAP events relate to what is happening elsewhere in the enterprise?

Onapsis provides SAP depth.

Which SAP-specific vulnerabilities, dangerous configurations, custom-code issues or attack patterns matter?

Above all three sits something that cannot be purchased:

governance.

Someone still needs to decide what constitutes unacceptable risk.

Someone must own remediation.

Someone must decide which events require escalation.

Someone must verify that telemetry is complete.

Someone must accept residual risk.

And someone must ask whether the controls actually work.

That is where the CISO enters the picture.

The CISO Should Not Operate SAP Security

This does not mean the CISO organization should take over SAP operations.

Quite the opposite.

The separation of responsibilities remains important.

SAP operations should operate SAP.

The SOC should monitor and investigate.

Security specialists should provide SAP-specific expertise.

Information Security should establish requirements, challenge assumptions and oversee risk.

Internal Audit should provide independent assurance.

Business owners should own business risks.

The CISO should ensure that these pieces form a functioning control system.

That is fundamentally different from running SAP.

The CISO does not need to configure every SAP security parameter.

But the CISO should be able to answer:

Do we know our critical SAP risks?

Do we have controls against them?

Can we see whether those controls are working?

Can our SOC detect relevant attacks?

Can we correlate SAP events with identities, endpoints and cloud activity?

Do SAP-specific vulnerabilities and custom-code risks enter our vulnerability and risk processes?

Who acts when something fails?

If these questions cannot be answered, the black box still exists.

The Audit Trap

Many organizations still discover too much about SAP security shortly before an audit.

The pattern is familiar.

The audit approaches.

Consultants arrive.

Authorizations are reviewed.

Configurations are checked.

Evidence is collected.

Findings are discussed.

Exceptions suddenly become urgent.

Then the audit ends.

Everyone returns to normal.

Until next year.

This is not security assurance.

It is periodic inspection.

And periodic inspection is particularly dangerous for a platform that changes continuously.

Users change.

Roles change.

Interfaces change.

Custom code changes.

Threats change.

Vulnerabilities appear.

Administrators make changes.

Cloud services evolve.

A control that worked during an audit in June may not protect the system in December.

The answer is not more auditing.

It is better telemetry and continuous assurance.

Continuous Assurance Changes the Question

A mature SAP security model should allow the CISO organization to move from asking:

“Did we pass the audit?”

to:

“What evidence do we have today that our most important controls are functioning?”

This is where Sentinel, Defender and Onapsis become strategically interesting.

Not because they produce more alerts.

But because they can produce evidence.

Evidence that security-relevant SAP activity is visible.

Evidence that suspicious activity is detected.

Evidence that SAP events are correlated with enterprise threats.

Evidence that vulnerabilities are identified.

Evidence that custom code is assessed.

Evidence that privileged activities are monitored.

Evidence that incidents enter established response processes.

Evidence that remediation actually happens.

This turns security monitoring into something much more valuable for the CISO:

control assurance.

The SOC Must Be Able to See SAP

There is a simple test I would apply.

Ask the SOC:

“Show me what happened in SAP during our five most serious security incidents of the last twelve months.”

If the answer is:

“We would need to ask the SAP team,”

you have identified a visibility problem.

If the answer is:

“We don’t collect those logs,”

you have identified a monitoring problem.

If the answer is:

“We collect them, but we don’t know what they mean,”

you have identified a detection problem.

If the answer is:

“We detected something but nobody knew who was responsible,”

you have identified a governance problem.

And if the answer is:

“We can show you the complete attack chain across identity, endpoint, infrastructure and SAP, including the response,”

you are getting much closer to what modern SAP security should look like.

RISE Makes This More Important, Not Less

The migration to SAP RISE can create a dangerous psychological effect.

The infrastructure moves.

Operational responsibilities change.

SAP takes responsibility for defined parts of the environment.

And gradually the organization begins to assume:

SAP is handling security.

But Shared Responsibility does not mean transferred accountability.

RISE changes who performs certain tasks.

It does not remove the organization’s responsibility for understanding its risks.

This makes observability even more important.

The CISO needs to understand which security telemetry remains available.

Which SAP logs reach Sentinel?

Which infrastructure and platform logs are available?

Which events remain under customer control?

What does SAP monitor?

What does the customer’s SOC monitor?

What does Onapsis monitor?

Where do responsibilities overlap?

And, more dangerously:

Where does nobody monitor?

A Shared Responsibility Model without shared observability is incomplete.

S/4HANA Does Not Eliminate Security Debt

The same caution applies to S/4HANA transformation.

A new platform does not automatically mean a new security architecture.

Legacy roles migrate.

Interfaces migrate.

Custom code survives.

Process exceptions survive.

Organizational compromises survive.

And security debt can survive.

A modern S/4HANA platform can therefore contain decades of accumulated assumptions.

This is precisely why custom-code analysis, vulnerability management, authorization governance and security monitoring need to be integrated into the transformation program — not added shortly before go-live.

A migration should not simply ask:

“Does the process still work?”

It should also ask:

“Should this process, interface, authorization or piece of custom code still exist in this form?”

That is the difference between migration and transformation.

My CISO View: Build a SAP Security Control Loop

I would ultimately want to see a closed loop:

SAP generates security-relevant evidence.

Onapsis adds SAP-specific security intelligence and identifies technical exposure.

Defender provides identity, endpoint and broader attack context.

Sentinel correlates the signals and makes them actionable for the SOC.

The SOC detects, investigates and responds.

The ISMS evaluates control effectiveness and systemic risk.

Risk owners remediate or explicitly accept residual risk.

Internal Audit independently verifies that the system works.

And then the cycle starts again.

That is much more powerful than an annual SAP security assessment.

It turns SAP security from a specialist activity into an enterprise security capability.

The Dashboard I Would Want as CISO

I do not want hundreds of SAP alerts.

I want answers.

Are all critical SAP systems connected to security monitoring?

Are the expected logs actually arriving?

Which critical vulnerabilities remain unresolved?

Which critical custom-code findings are open?

Which privileged or emergency activities occurred?

Which high-risk authorization changes occurred?

Which SAP incidents were correlated with Defender or other enterprise signals?

Which detections were investigated by the SOC?

Which critical controls failed?

Which remediation actions are overdue?

Which risks have been explicitly accepted — and by whom?

That is a CISO dashboard.

The technology underneath may involve Sentinel, Defender, Onapsis and native SAP capabilities.

But the dashboard should describe risk and control effectiveness, not products.

SAP Security Is a Governance Test

The deeper lesson has little to do with any individual security product.

SAP exposes whether an organization can govern complexity.

Can specialized technology remain integrated into enterprise risk management?

Can the SOC see across organizational boundaries?

Can specialized security intelligence become enterprise intelligence?

Can technical findings become risk decisions?

Can controls produce evidence?

Can management distinguish between a control that exists and a control that works?

These questions become even more important as SAP moves deeper into cloud operating models.

The future of SAP security is therefore not another isolated SAP security console.

It is integration.

Integration of SAP with the SOC.

Integration of specialized SAP intelligence with enterprise threat detection.

Integration of identity, endpoint and application signals.

Integration of vulnerability management with risk management.

Integration of operational security with the ISMS.

And integration of technical evidence with management accountability.

SAP is no longer allowed to be the black box in the middle of the enterprise.

Not because the CISO needs to understand every transaction code.

But because the CISO must understand whether the organization can see, detect, respond and prove that its controls work.

That is the real shift.

From SAP security to SAP security assurance.

And once you look at it that way, Sentinel, Defender and Onapsis are not primarily security tools.

They are sensors in a much larger governance system.

The CISO’s job is to make sure that system closes the loop.

Publication Note & Disclaimer
This article provides security and governance analysis, not legal advice. Regulatory obligations must be assessed against the facts, jurisdictions, data types, and roles of the organizations involved.

This article reflects my personal professional perspective and does not represent the official policy or position of my employer. Drafting and editorial refinement may have been supported by commercially available AI-assisted tools. The analysis, conclusions and final curation are entirely my own.

For information regarding image credits, copyrights, trademarks and other intellectual property rights, please refer to the Imprint.