The Operational Trap that Leaves SAP Security Gaps Wide Open

When organizations think about SAP support, they think that the Application Management Services (‘AMS’) manage the system comprehensively, including SAP security & compliance. AMS handles functional and technical SAP application support including patches, transports, and day-to-day incidents. Extending that to include security seems natural. So, most organization assumes that SAP security & compliance must also be covered – but that is often not the case.

This gap usually surfaces at the worst possible moment: during an audit, a security breach investigation, or a regulatory review. By then, the gap between assumed coverage and actual coverage has become a real (or a security/ compliance) problem.

Here’s why confusing AMS with SAP security is one of the riskiest assumptions organisations make – and how to fix it.

What AMS Actually Does

AMS emerged to solve a specific problem: How do organizations maintain and stabilize their SAP environment after the implementation team leaves? Their primary mandate is usually functional and technical SAP application support (FI/CO, MM, SD, BASIS, enhancements, tickets).

AMS providers excel at:

• Incident management – fixing issues that break the system
• Change management – implementing approved changes
• Patch and release management – keeping the system current
• Performance monitoring – meeting uptime SLAs
• User support – provisioning access, resolving tickets

All of these are operational in nature. Success is measured by uptime. AMS core focus is: Is the system working?

AMS have Service Level Agreements (‘SLA’) – these are typically for processing requests or for system availability. Almost none have accountability for the overall SAP security, risk and compliance posture.

But security asks a different question entirely: Is the system secure?

The Operating Model Problem

SAP security and operations aren’t just different tasks—they require different mindsets, skills, tools, and success measures.

Think about a ‘Priority One’ incident. AMS team is focused on fixing the issues and/ or restoring the system. Speed matters. But the security questions – Was that access appropriate? Should it be revoked? Does it violate Segregation of Duties (‘SoD’)? – belong to a different function entirely.

Access Governance

AMS may handle access provisioning (creating users, assigning roles). But provisioning isn’t governance. Governance means continuously evaluating whether that access is still appropriate as roles change, responsibilities shift, business processes evolve and SoD violations are managed.

Security Configuration

SAP has hundreds of security parameters and settings. Configuring them correctly requires understanding the threat model—not just knowing how to operate the system.

AMS configures to make the system work. Security teams configure to resist exploitation. A permissive setting that simplifies operations? AMS sees no problem. Security sees risk.

Proactive Risk Identification

AMS is reactive by design. Tickets come in, tickets are resolved. SLAs are met. There’s no structural incentive to hunt for security risk that hasn’t yet created an incident.

Managed security is different. It continuously monitors for anomalies—unusual access patterns, configuration drift, segregation of duties violations. The goal is to find risk before it becomes an incident.

Audit Readiness

When auditors review SAP controls, they ask about access certification processes, SoD conflict resolution, privileged access governance, and continuous control monitoring.

AMS can show operational evidence: tickets, changes, uptime. But they’re often poorly positioned to show the security governance evidence that auditors actually want, because that requires a different programme running in the background.

Why This Confusion Persists

Some of the key factors behind this obvious gap are as follows:

• Scope ambiguity in contracts. AMS agreements reference ‘security’ but mean access provisioning, not security governance.
• Incident response conflation. Because AMS teams respond to security incidents, organizations assume security is covered. Responding to an incident isn’t the same as managing the landscape that made it possible.
• Invisible risks. Security gaps that don’t create operational symptoms don’t appear in the ticket queue. SoD accumulation, configuration drift, privilege creep—they stay hidden until they become a breach.
• Organisational convenience. A separate security programme requires budget, governance, and executive ownership. Assuming AMS covers it is simpler—until you’re in an audit and it doesn’t.

This confusion is also attributed to a lack of awareness of specialized Managed SAP Security Services Providers, who are focused on addressing this gap.

Read this blog from Hexadius comparing SAP AMS and Specialized SAP Managed Security Services Provider.

The Solution: Specialized Managed SAP Security Services Provider

Now that this gap is clear, let’s look at how a specialized Managed SAP Security Services provider helps complement the AMS model and address this gap.

Organizations that manage SAP security effectively have separated operations and security clearly. A functioning security program includes:

• Continuous access governance (not just provisioning)
• Proactive risk monitoring (regular assessment of configuration, technical users, RFC connections)
• SoD management as an ongoing discipline (not an annual project)
• Security-specific expertise (authorisation architecture, GRC tooling, SAP threat landscape)
• Clear accountability (distinct from operational service delivery)

This model can be built internally if organizations have the capability and scale. It can be sourced from a specialist Managed SAP Security Provider like Hexadius.