The key point is simple: SAP secures and operates much of the ECS platform. However, customers still own important application-level security controls. Clear responsibilities, ongoing monitoring and verified remediation are essential to prevent security gaps.
Running SAP S/4HANA as SAP Cloud ERP Private changes how an SAP environment is operated. SAP Enterprise Cloud Services (ECS) takes responsibility for much of the underlying infrastructure and technical operation of the landscape.
But this can lead to a risky assumption: if SAP operates the environment, SAP must be responsible for securing everything within it.
The reality is different. Moving to ECS changes how responsibilities are divided. It does not remove the customer’s responsibility for SAP security.
SAP ECS typically manages the infrastructure, operating systems, databases, availability, technical monitoring and agreed maintenance activities. The exact responsibilities depend on the customer’s contract and service definition.
A risky assumption: if SAP operates the environment, SAP must be responsible for securing everything within it.
However, many controls that determine whether an SAP application is secure remain with the customer. These include:
We explored these shared responsibilities in our recent webinar on SAP security in an ECS environment. The session examined what SAP manages, what remains with the customer, and where security gaps can arise if responsibilities are not clearly defined.
Security patching is another area where responsibilities can become unclear.
SAP may carry out agreed technical patching. However, installing a correction is only one part of managing a vulnerability. Someone must assess how urgent it is, understand its possible business impact and arrange suitable testing.
The customer must also verify that the issue has been fixed. A patch may have been installed, but a configuration change or manual correction may still be needed. Completing the technical task does not always mean the security risk has been removed.
SAP hardening guidance and secure baseline settings provide an important starting point. But security cannot be treated as a one-time activity. Configuration changes, new interfaces, code changes, upgrades and support work can gradually move a system away from its approved baseline.
Customers operating in an ECS environment generally remain responsible for several critical areas:
The greatest risk is often not a lack of security activity. It is the gap between the work performed by SAP, the customer and other service providers.
One party may assume that another is reviewing SAP Security Notes. The managed service provider may believe access governance belongs to the customer. The customer may assume SAP is monitoring application-level security settings.
Unless responsibilities are clearly documented, assigned and checked, important controls can fall between organisational boundaries.
Every organisation using ECS should create a detailed responsibility matrix. It should show who assesses, approves, implements, tests and verifies each security activity. It should not simply state which organisation is broadly “responsible.”
Traditional SAP security reviews provide only a point-in-time assessment. By the time a report is delivered, new vulnerabilities, configuration changes or access risks may already have appeared.
A modern ECS environment needs continuous visibility across:
Findings must be prioritised, assigned to an owner and tracked until the remediation has been verified.
This is difficult to manage through spreadsheets and occasional manual reviews. The volume and complexity of SAP security information are simply too great.
This is where automated solutions such as smarterSec can help.
#smarterSec continuously assesses the SAP landscape, identifies vulnerabilities and configuration gaps, and verifies remediation. It helps customers manage the security responsibilities that ECS does not remove.
It also provides assurance that critical risks are not being overlooked in the gap between SAP and the customer.