What is the difference between preventative and detective access controls in SAP?

How preventative and detective controls differ in SAP access governance

In SAP, preventative access controls stop an inappropriate request, assignment, or action before it can take effect. Detective access controls assume access already exists and then look for misuse, conflict, or drift after the fact. The practical difference is timing, but also purpose: one reduces the chance of bad access, the other reduces the time bad access can remain undiscovered.

That distinction matters because SAP environments often combine role design, emergency access, workflow approvals, and review cycles. A control can be strong at one point in the lifecycle and weak at another, so organisations should not treat approval logic, role engineering, and access recertification as interchangeable safeguards.

In SAP control design, preventative controls usually live closest to request and provisioning decisions. They include approval workflows, role provisioning rules, password and authentication settings, SoD checks at assignment time, and restrictions that block a transaction or entitlement before the user receives it. Detective controls operate later, through access reviews, critical access reviews, exception monitoring, and review of actual use patterns against what was approved.

The best way to think about the split is that preventative controls reduce exposure, while detective controls validate whether the preventive layer is holding up in practice. In mature programmes, the detective layer is not a substitute for weak role design, and the preventive layer is not a substitute for periodic review of accumulated access.

Why SAP access control teams need both layers

Preventative controls are strongest when the risk is predictable and the rule can be applied consistently. If a role should never include a sensitive transaction or if a workflow should require approval before access is granted, prevention is the right first line. SAP organisations use this to reduce role explosion, excessive privilege, and obvious segregation of duties conflicts before they enter production.

Detective controls become critical where business complexity, legacy role structures, emergency access, or inherited access makes perfect prevention unrealistic. In those cases, access reviews and monitoring catch the residual risk: over-assigned roles, dormant access, conflicting duties, or access that was valid once but no longer matches business need. SAP auditability depends on this second layer because not every entitlement problem can be prevented cleanly at request time.

The two layers also support different operating questions. Preventative controls answer, “Should this access be granted now?” Detective controls answer, “Did this access remain appropriate after business change, exception handling, or role drift?” When teams confuse those questions, they tend to overinvest in approvals and underinvest in review quality, or the reverse.

What changes in practice when you separate prevention from detection

The control objective changes depending on where the control sits in the access lifecycle. For preventative controls, the key requirement is to make bad access hard to create, using rules, ownership, and workflow gates that block the grant itself. For detective controls, the key requirement is evidence, because the organisation must be able to prove who had access, why they had it, and whether that access was still acceptable.

That difference affects how SAP teams measure success. Prevention is measured by blocked violations, exceptions avoided, and the consistency of role assignment logic. Detection is measured by review completion, review quality, remediation speed, and how quickly the organisation can identify and remove access that has become excessive or inappropriate. If those measures are blurred, teams may mistake high approval volume for strong security, even when review remediation is slow.

This is why access design in SAP should be treated as a control system, not a single control. For practical guidance on how identity governance, least privilege, and access reviews fit together, see IAM and IGA Basics and the Privileged Access Management Guide. For role and authorisation modelling, Authorisation Models Guide is the more useful companion.

Practitioner Guidance

What to prioritise: Start by classifying each SAP control by lifecycle point. If it blocks assignment or execution, treat it as preventative; if it validates continued appropriateness or surfaces drift, treat it as detective.

What to verify: Check that preventative controls are actually enforced in the SAP path, not just documented in policy, and that detective reviews produce remediation within a defined SLA rather than becoming a compliance checkbox.

Common mistake: Teams often rely on periodic user access reviews to compensate for weak role engineering. That leaves the organisation carrying avoidable exposure between review cycles.

Practitioner takeaway: Strong sap access governance uses prevention to stop avoidable grants and detection to catch what business reality, exceptions, and role drift inevitably create.

Related resources from NHI Mgmt Group

• What is the difference between continuous controls monitoring and traditional periodic SAP access reviews?
• What is the difference between network controls and identity controls for infrastructure access?
• What is the difference between role-based access and context-based access in SAP?
• What is the difference between human access controls and NHI controls for agents?