What is the most sensitive system in your organisation? Not the most technically complex. The one with the highest concentration of data that would cause the most damage if a former employee retained access to it after leaving.
For most manufacturing, financial services, and retail organisations, the answer is SAP. The general ledger. Accounts payable. Supplier pricing. Production schedules. Customer master data. Financial reporting. All of it was governed, transacted, and stored in an ERP system that was running before your IAM platform existed and is still running outside your IAM platform’s provisioning scope.
When an employee leaves, your central IAM offboarding workflow closes their Active Directory account, disables their email, revokes their SSO access, and produces a ULM deprovisioning record showing that access was removed on the date of departure. The offboarding record looks complete.
The SAP account is still active.
Not because the SAP Basis team forgot. Because SAP user management was never connected to the central IAM offboarding workflow. The notification has to travel from HR to IT to the SAP Basis team manually. Whether it arrives, how quickly it is acted on, and whether the deprovisioning is verified are entirely dependent on a manual communication chain that breaks regularly and leaves no evidence when it does.
This blog covers why SAP sits outside most identity governance architectures, what that gap looks like under ISO 27001, SOC 2, DPDPA, and RBI, and what connecting SAP to the central IAM offboarding workflow produces as evidence and security outcome.
Why SAP Is Structurally Excluded From Most IAM Governance
SAP has its own user administration layer. SU01 manages individual user accounts. Role assignments are handled through the SAP role framework, separate from the RBAC model in the central directory. Authentication in SAP can run through SSO but frequently does not, or runs through a different SSO configuration than the one the central IAM platform manages.
In most organisations, SAP was deployed by a dedicated implementation team, maintained by a SAP Basis function, and governed by a separate access control process owned by the SAP team rather than the IAM team. The central IAM platform manages every application in the SSO catalogue. SAP is not in the SSO catalogue. It is a separate system with separate credentials, separate role management, and separate access review processes.
The result is a fundamental governance architecture gap. The identity governance layer that is supposed to cover all access to sensitive systems does not cover the system that holds the most sensitive data. The access review that runs quarterly for every application in the IAM platform runs separately for SAP, on a different cadence, producing evidence in a different format, reviewed by a different team.
For auditors evaluating ISO 27001 A.8.4 access review coverage or SOC 2 CC6.3 access authorisation, the question of whether SAP was included in the access review scope is a material one. The answer in most organisations is that it was not, or that it was covered by a separate process whose evidence is not connected to the central access governance record.
What the Gap Creates Operationally
The Offboarding Gap
ISO 27001:2022 Annex A Control A.11.5 requires that responsibilities after termination include access revocation across all information systems. The evidence requirement is a User Lifecycle Management offboarding report showing immediate access revocation upon termination. The report must show all systems, not the systems managed by the central IAM platform.
For a manufacturing organisation where SAP governs procurement, production planning, and financial operations, a former employee with active SAP credentials after departure has access to supplier contracts, pricing negotiations in progress, production schedules that constitute competitive intelligence, and the ability to execute financial transactions. The ISO 27001 A.11.5 evidence gap is also an active security exposure.
DPDPA Section 8(7)(a) requires data fiduciaries to restrict processing of personal data when the lawful basis for processing ends. For employees, the lawful basis is the employment relationship. A SAP account active after departure is an active processing capability on data for which the lawful basis has ended. The DPDPA obligation is not satisfied by the central IAM offboarding record if that record does not cover SAP.
The Access Review Gap
SOC 2 CC6.3 requires that access is authorised, modified, or removed based on roles and responsibilities. For a SOC 2 Type II audit, the auditor evaluates whether access modifications occurred when role changes occurred. If an employee changed departments and their SAP roles were not updated to reflect the new role’s access requirements, the CC6.3 control has a gap for the full period during which the misaligned access existed.
For financial services organisations where SAP governs general ledger operations, RBI Cybersecurity Framework clause 19(a) requires access to information assets to be allowed only where a valid business need exists and mandates documented standards for need-based access to information systems. SAP access that was granted for a role that no longer exists, or retained after a role change, fails this standard. The access review that would catch it runs on a different cadence and produces evidence that is not connected to the central access governance record.
The Segregation of Duties Gap
SAP role assignments accumulate over time. A user who was given a procurement role when they joined the organisation may have accumulated finance and reporting roles through ad-hoc requests over the years. In most organisations, the SAP access review that would catch this runs less frequently than the central IAM access review and uses a different reviewer and a different evidence format.
The consequence is that segregation of duties violations, where a single user has incompatible roles that they should not hold simultaneously, accumulate invisibly in SAP while the central access governance layer shows clean reviews. The compliance posture looks clean because the governance layer is not covering the system where the violations exist.
What Connecting SAP to the Central IAM Workflow Produces
Akku’s User Lifecycle Management supports SAP as a provisioning and deprovisioning target through SCIM-based and API-based connectors. When an offboarding event is triggered in Akku, the deprovisioning action executes across all connected systems simultaneously, including SAP. The SAP account is disabled as part of the same workflow that handles Active Directory, email, and SSO access removal.
The ULM offboarding record captures the timestamp of deprovisioning across every connected system in a single audit trail entry. For an ISO 27001 A.8.2, A.11.5, or SOC 2 CC6.3 audit, the evidence is a single record showing that access was removed from all systems, including SAP, at the time of the offboarding event. The gap between the central IAM offboarding completion and the SAP account deactivation is zero because both actions happen within the same workflow execution.
Akku IGA‘s access recertification capability extends to SAP role assignments when SAP is connected to the IAM governance layer. SAP roles are included in the quarterly access review alongside every other application. The reviewer sees the user’s current SAP roles, the business justification for each, and the date of last review. The access recertification report covers SAP as part of the standard evidence set. The gap between the central access governance record and the SAP access state closes.
The Verification Test
For the last three employees who left your organisation, answer these two questions. First: Does the central IAM offboarding record show SAP account deactivation with a timestamp? If the answer is no, SAP is not in the offboarding workflow. Second: What is the timestamp difference between the central IAM offboarding completion and the SAP account deactivation?
If SAP deactivation is not in the central record, the access may still be active. If the timestamp difference is more than a few hours, the manual communication chain between the IT and SAP Basis teams introduces a gap that is not visible in the offboarding record. For manufacturing organisations and financial services organisations where SAP access is access to the most sensitive operational data in the environment, that gap is not a paperwork problem. It is an active access exposure.
Explore Akku IGA Capabilities | Talk to the Akku Team
Questions IT and Compliance Teams Ask About SAP Offboarding and Access Governance
Q: Why does SAP sit outside most central IAM platforms architecturally?
A: SAP has its own user administration layer, separate from the directory services and SSO-based authentication that most central IAM platforms manage. In most organisations, SAP was deployed before the central IAM platform and by a different team, establishing SAP user management as a separate process owned by the SAP Basis function. Integrating SAP into the central IAM provisioning and deprovisioning workflow requires a SCIM connector or API-based integration that most organisations have deferred. The result is that SAP access operates under separate governance from the rest of the identity estate, with a different access review cadence, different evidence format, and different ownership.
Q: What evidence does ISO 27001 A.11.5 require for SAP account deactivation on employee departure?
A: ISO 27001:2022 Annex A Control A.11.5 requires that responsibilities after termination include access revocation across all information systems. The evidence required is a User Lifecycle Management offboarding report filtered for deprovisioning events showing immediate access revocation upon termination. For SAP specifically, the evidence requires that SAP account deactivation is captured in the same offboarding record as all other system access removals, with a timestamp showing deactivation occurred at the time of termination. A SAP deactivation that occurs days after the central IAM offboarding, or is not documented in the central record at all, is a gap in the A.11.5 evidence.
Q: How does DPDPA apply to SAP access retained by departed employees?
A: DPDPA Section 8(7)(a) requires data fiduciaries to restrict processing of personal data when the specified purpose is no longer served. For employee data processed in SAP, the employment relationship is the lawful basis for processing. When the employment relationship ends, the lawful basis ends and the obligation to restrict further processing applies. A SAP account active after an employee’s departure is an active processing capability on data for which the lawful basis has ended. Section 8(7)(b) extends this requirement to downstream processors. An organisation that has not connected SAP to its central deprovisioning workflow cannot demonstrate that the DPDPA data erasure and processing restriction obligations were met at the time of departure.
Q: What SOC 2 controls are most directly affected by SAP role accumulation and access review gaps?
A: SOC 2 CC6.3 requires that access is authorised, modified, or removed based on roles and responsibilities. SAP role accumulation over time, where users hold roles beyond their current business function, is a direct CC6.3 finding. SOC 2 CC5.1 requires controls to mitigate risks, which includes segregation of duties controls. Incompatible SAP role combinations that exist because access review has not covered SAP role assignments are a CC5.1 finding. For a SOC 2 Type II audit, the question is whether these controls operated throughout the audit period. A SAP access review that runs less frequently than the central IAM access review creates a gap in the Type II evidence record.
Q: How does Akku connect SAP to the central IAM access review process?
A: When SAP is connected to the Akku IAM platform through a SCIM or API-based connector, SAP users and role assignments become visible in the Akku IGA governance layer. Akku IGA’s access recertification capability extends to SAP roles, including them in the quarterly access review alongside every other application. Reviewers evaluate SAP role assignments against the current business justification, and the access recertification report covers SAP as part of the standard evidence set. Role accumulation and segregation of duties violations in SAP become visible in the same review process that governs all other application access.
Q: What does the ULM offboarding record look like when SAP is connected to Akku?
A: When SAP is connected to Akku’s User Lifecycle Management, the offboarding workflow executes deprovisioning actions across all connected systems simultaneously. The ULM offboarding record captures a single timestamped entry showing the user identity, every system from which access was removed, and the timestamp of removal for each system. SAP account deactivation appears in the same record as Active Directory, email, and SSO access removal. The timestamp for SAP deactivation matches the offboarding event timestamp rather than reflecting a delay introduced by a manual notification chain.
