SAP security audit

SAP holds your company's most critical financial, procurement and HR processes. A poorly designed role, an exposed RFC interface or an unapplied security note can give an attacker —internal or external— control over transactions that move real money. We audit your SAP environment with the same mindset as someone trying to compromise it, not just by checking a compliance checklist.

Is your SAP secure, or does it just pass the internal audit checklist?

Most SAP security reviews stay in compliance territory: confirming a segregation of duties (SoD) matrix is documented, that a password policy exists, or that the system is under maintenance. That doesn't confirm the environment can withstand a real attack. SAP compromises typically exploit specific combinations: a service account with its default password, an RFC interface reachable without access control, a custom ABAP program with an injection flaw, or SAP Security Notes published months ago and never applied. An offensive audit confirms which of all that is actually exploitable in your specific instance.

What the SAP security audit covers

  • Authorizations and profiles: critical roles, segregation of duties (SoD) conflicts and least privilege
  • Default and service accounts (SAP*, DDIC, SAPCPIC, EARLYWATCH) and their password policy
  • RFC interface and Gateway security: access control lists (secinfo/reginfo), gw/sim_mode and trusted RFC connections
  • Patch management: SAP Security Notes applied against the monthly SAP Security Patch Day calendar
  • Custom ABAP code: SQL/OS injection, cross-site scripting in Web Dynpro/BSP and poor custom-development practices
  • Exposure of Fiori, OData and Message Server services to untrusted networks or the Internet
  • HANA database security when it is part of the scope
  • Security Audit Log: what gets logged, retention and real incident detection capability

How we run the audit

  1. Scope and access: We define the scope (modules, clients, production or pre-production environment) and obtain audit access or a test account. We agree which active tests are allowed and within which window.
  2. Configuration and authorization review: We analyze roles, profiles and SoD conflicts, default accounts, Gateway parameters and the real state of SAP Security Notes application.
  3. Attack surface analysis: We enumerate exposed RFC interfaces, accessible Fiori/OData services, trusted connections between systems and the highest-risk custom ABAP code.
  4. Controlled offensive simulation: We reproduce real techniques (RFC abuse, escalation via poorly designed roles, exploitation of unpatched known vulnerabilities) in the agreed environment to confirm the real impact.
  5. Report and remediation: We document every finding with evidence, severity (CVSS) and business impact, and deliver a prioritized remediation plan for the Basis/SAP team.

What you get when we finish

  • Executive report: risk level of the SAP environment, for management and the CISO
  • Technical report: findings with evidence, CVSS and remediation steps for the Basis team
  • A map of roles and critical SoD conflicts with their risk level
  • Prioritized hardening checklist (authorizations, Gateway, patching)
  • Closing meeting with your Basis or SAP administration team
  • Optional re-test to verify that critical findings have been fixed

When should you audit your SAP environment?

  • Your company runs SAP in production and has only had compliance reviews, never an offensive security audit
  • Before or after an S/4HANA migration or a significant expansion of modules
  • After an incident or suspicion of internal fraud in financial or procurement processes
  • When a client, external auditor or investor requires you to prove the security of the ERP
  • To comply with NIS2, ENS or ISO 27001 for the systems supporting critical business processes
  • If you have custom ABAP developments that have never passed a code security review

Frequently asked questions about the SAP security audit

Is this the same as a segregation of duties (SoD) review for internal audit?

No. An SoD review for internal audit or compliance confirms a documented matrix exists and that, on paper, no prohibited combinations are assigned. Our audit goes further: it confirms which of that is actually exploitable, adds analysis of the RFC/Gateway interface, custom ABAP code and patch status, and simulates the real impact of an attacker, not just the documented theoretical risk.

Do you need access to the production system?

For the configuration and authorization review, a read-only user or access to a pre-production system with the same configuration is enough. For active offensive testing we agree the scope, environment (usually pre-production) and, if needed, a test account in advance. Everything is done with explicit authorization and under a confidentiality agreement (NDA).

Do you cover both on-premise SAP and S/4HANA Cloud?

Yes, adapting the scope: on-premise and S/4HANA Private Cloud analysis includes the infrastructure layer, the Gateway and the underlying operating system; S/4HANA Public Cloud scope focuses on authorizations, integrations and configuration, since SAP directly manages part of the infrastructure.

Does the audit disrupt ERP operations?

No. Most of the work is configuration, role and code analysis, which doesn't affect users. Active tests are agreed in advance, preferably run in a pre-production environment, and if they must touch production, within a window agreed with the Basis team.

Is the report valid for regulatory compliance (NIS2, ENS, ISO 27001)?

Yes. The report documents the security posture of the SAP environment with evidence and is valid as part of the documentation for NIS2 adequacy, ISO 27001 certification or adequacy to the Spanish National Security Framework (ENS) for the systems within its scope.