The misconception that will not go away
Speaking ahead of Mastering SAP Collaborate in Sydney, Onno Coenen, Managing Director APAC and VP Global Alliances at SecurityBridge, named the single biggest misunderstanding he still encounters among SAP customers: the belief that SAP handles application security once a system runs in SAP's cloud. That belief is wrong, and Coenen calls it the number one mistake customers make. Under RISE with SAP and similar cloud arrangements, SAP secures the infrastructure layer, but responsibility for users, configuration, custom code, and in-application activity sits with the customer, exactly as it did on-premises.
That shared responsibility model is well documented, yet it is clearly failing to land with the people who need to act on it. Coenen's read is that the misconception persists because cloud migration gets sold internally as a risk reduction project, and application-layer security gets quietly assumed to be part of that reduction rather than called out as an unchanged customer obligation. The gap between assumption and reality only becomes visible when an incident exposes it, which is a costly way to learn the lesson.
Australia's landscape looks different from Europe's
Coenen's comparison between Australian and European SAP estates is instructive for anyone benchmarking their own security posture against peers. Australian organizations are consolidating onto SAP Cloud ERP quickly, often moving directly to RISE with SAP, and their landscapes tend to be smaller and more consolidated than in Europe, where some manufacturers still run dozens or even hundreds of separate SAP systems. That difference changes the actual business case for security automation tooling, since the return on investment scales differently across a handful of consolidated systems than across a sprawling, fragmented European estate.
Australia is positioned, in Coenen's account, as a regional front-runner within APAC, helped by stronger local engagement with frameworks such as NIST. Cost remains the limiting factor across much of developing Asia, where organizations recognize the same risks but lack budget to act on them at the same pace. That regional unevenness matters for any multinational CIO managing SAP across APAC, since a security posture that looks adequate in one market may be meaningfully behind in another operating under the same global policy.
SAP is invisible to the security team, until it isn't
Perhaps the most operationally useful detail in Coenen's account is how often SAP sits outside an organization's security operations entirely. SAP is frequently missing from SIEM monitoring, meaning the application layer running finance, HR, and supply chain data often has no presence in the same dashboards a SOC uses to watch everything else. That blind spot exists even as decision authority over SAP security shifts increasingly from dedicated SAP teams, which Coenen describes as often overloaded, to cyber teams and CISOs who expect SAP to be visible the same way every other system is.
That shift in ownership is already producing concrete operational changes. One of Australia's largest banks has directed its SAP team to patch within seven days, a target Coenen says can only be met with an advanced automated tool rather than manual processes. An Australian energy provider began its security program with compliance and patch management tooling as part of a broader vulnerability initiative, with plans to add real-time threat detection next. Coenen describes customer engagement splitting roughly evenly between vulnerability management and real-time visibility work, with visibility demand growing faster of the two.
The custom code problem nobody budgeted for
Custom ABAP code is where Coenen's warnings get most concrete and most uncomfortable for long-tenured SAP shops. Much of that code was written by contractors who have since left the organization, which means vulnerability backlogs accumulate without anyone fully understanding the original business logic behind a given piece of code. Prioritizing remediation under those conditions becomes guesswork rather than risk-based triage, since fixing a vulnerability safely requires understanding what the code was meant to do in the first place, not just where the flaw sits.
Coenen's blunt description of the exposure this creates is worth sitting with: an attacker, or an insider, can walk straight through an unmonitored application layer with outdated custom code. This risk extends well beyond Australia. It is a structural feature of any long-running SAP estate where contractor turnover outpaces documentation discipline, which describes the large majority of enterprise SAP customers worldwide, regardless of region or industry. Boards that assume a recent cloud migration automatically closed this gap are operating on the same misconception Coenen flags as the most common one he hears in the field today.
What CIOs should take from this before their next SAP review
The first practical step is reviewing the RISE with SAP shared responsibility model with named accountability attached, so a specific person or team owns user access, configuration, custom code, and application monitoring, rather than assuming SAP's cloud operations team covers it implicitly. The second is integrating SAP activity into existing SIEM and SOC tooling so the application layer stops being a blind spot relative to every other system the security team already watches daily.
The third step is setting a measurable patch target, following the seven-day benchmark one major Australian bank has already adopted, and testing honestly whether current manual processes can actually hit it without automated tooling. The fourth is building a risk-based remediation plan for custom ABAP code that accounts for the reality that original developers are often gone, which means documentation and institutional knowledge have to be rebuilt as part of the remediation effort itself, not treated as a nice-to-have alongside it.
