Category: Identity Governance & Administration (IGA)

Your SCIM provisioning connector ran its last sync six hours ago. It failed. Nobody received an alert. Nobody knows.

The employee who left the organisation this morning still has active entitlements in the three applications connected through that SCIM integration. The access revocation that should have happened at offboarding ran, the IGA platform recorded the deprovisioning event, but the sync that would have propagated that revocation to the downstream applications failed silently. The IGA record shows the account as deprovisioned. The application still has an active user. 

The new joiner who started today does not have access to the applications they need for their role. The provisioning sync that should have created their entitlements failed for the same reason. Their manager has raised a ticket. IT is investigating. Day one is half over.

Both scenarios have the same root cause: SCIM connectors fail without generating user-facing alerts, and most IAM platforms have no health monitoring layer that detects the failure state and surfaces it to the administrator before it produces a downstream consequence.

This blog covers how SCIM provisioning works at the protocol level, why failures are architecturally silent, what the two categories of silent failure produce as access gaps, and how Akku’s Provisioning Connector Health Monitoring detects and surfaces connector failures before they become security exposures or operational incidents.

How SCIM Provisioning Works and Why Failures Are Silent

SCIM 2.0 is a REST-based protocol for automating user provisioning between an identity platform acting as the identity provider and downstream applications acting as service providers. The identity provider sends HTTP requests to the service provider’s SCIM endpoint: POST to create a user, PUT or PATCH to modify attributes, and DELETE to remove a user. The service provider processes the request and returns a status code indicating success or failure. 

In a working integration, when the IGA platform triggers a deprovisioning event for a departing employee, the provisioning engine generates a SCIM DELETE request to each connected application’s SCIM endpoint. If all endpoints return 200 or 204 status codes, the deprovisioning is confirmed complete. The user’s access is revoked in all connected applications simultaneously.

Failure modes occur at several points in this chain. The SCIM endpoint may be temporarily unavailable due to the application’s own maintenance window or a network issue. The endpoint may return an error response: 429 rate limiting, 503 service unavailable, 401 authentication failure from an expired API token, or 400 bad request from a schema mismatch after an application update. The identity provider’s outbound connection may be blocked by a firewall rule change. Any of these produces a failed sync.

The critical architectural point is that most SCIM implementations handle failures by logging the error internally and moving on. The administrator interface shows the last successful sync timestamp. It does not prominently surface failed syncs in a way that creates operational urgency. An administrator who is not specifically looking for connector errors will not see them. The failure is silent until something downstream surfaces the consequence.

Two Categories of Silent Failure and What They Produce

Failed Deprovisioning Syncs

When a SCIM connector fails to deliver a DELETE or PATCH deactivation request to a downstream application, the user’s account in that application remains active after their offboarding is recorded in the IGA platform. The IGA record shows the deprovisioning completed. The application has an active account with valid credentials.

For applications containing sensitive data, this is an active security exposure. A former employee who still knows their application credentials, or whose credentials are retrievable through a password manager they used during employment, retains functional access to the application. The access is invisible to the IGA governance layer because the IGA record shows it as revoked.

For ISO 27001 A.8.2 and SOC 2 CC6.3, the evidence standard for deprovisioning is a record showing access was revoked across all connected systems. A silent SCIM failure means the evidence record is inaccurate: it shows revocation that did not actually occur. For a post-incident investigation or an access audit, the discrepancy between the IGA record and the actual application access state is a material finding.

Failed Provisioning Syncs

When a SCIM connector fails to deliver a POST request for a new joiner, the user’s account is not created in the downstream application. The IGA platform shows the provisioning event as triggered. The application has no user account. Day one access is broken.

Provisioning failures are typically discovered by the new joiner when they attempt to access the application and find no account exists. This produces a support ticket, an IT investigation, and a delay that can range from hours to days depending on the application and the team. The operational cost is real. The security cost is that the investigation reveals a gap in the provisioning architecture that may have produced similar silent failures for other users without triggering a support ticket because the affected user had not yet attempted to access the application.

Why These Failures Are Hard to Detect Without Health Monitoring

IAM platforms typically surface SCIM connector status through a log interface that records sync events. An administrator can query the log for failed sync events. The log is accurate and complete. The problem is that this requires someone to actively look for failures. No alert fires. No dashboard turns red. No notification reaches the IT operations team unless they have built a custom monitoring process around the log data.

In practice, the frequency of log review depends on operational discipline rather than automated detection. An IT team managing dozens of SCIM connectors across a large application estate cannot manually review every connector’s sync logs daily. The failure accumulates undetected until a downstream consequence, a former employee attempting access, a new joiner raising a ticket, an auditor finding a discrepancy, makes it visible.

The second detection gap is that failed syncs do not always produce immediate consequences. A failed deprovisioning sync for a departing employee who does not attempt to re-access the application goes undetected indefinitely. The orphaned account accumulates in the downstream application, visible in the application’s user list but absent from the IGA access record. This is precisely the category of access gap that periodic access reviews are designed to catch, but catching it requires the access review to cover the downstream application’s actual user list rather than only the IGA-provisioned entitlements.

What Akku’s Provisioning Connector Health Monitoring Delivers

Akku’s Provisioning Connector Health Monitoring introduces a dedicated health layer that continuously evaluates the operational status of each configured SCIM connector. Rather than relying on an administrator to review sync logs, the health monitoring layer proactively detects connector failures and surfaces them to the administrator console with the information needed to diagnose and remediate the failure before it produces a downstream access gap. The health monitoring capability integrates with Akku IGA‘s provisioning engine and covers all configured SCIM connectors across the application estate. 

The health monitoring layer tracks each connector across four status dimensions. Connectivity status confirms whether the connector can reach the application’s SCIM endpoint. Authentication status confirms whether the API token or OAuth credentials used by the connector are valid and have not expired. Sync status confirms whether the most recent provisioning and deprovisioning events processed by this connector resulted in successful SCIM responses from the application. Latency status confirms whether the connector’s response time is within the expected range, flagging degraded performance that may indicate a future failure before it produces an error. 

When any connector’s health status moves from healthy to degraded or failed, the Akku admin console surfaces an alert with the connector name, the failure type, the timestamp of the first failure event, and the number of provisioning and deprovisioning events that were queued or failed during the outage window. This gives the IT operations team the information they need to prioritise remediation based on the access impact: a connector failure during an active offboarding event carries higher priority than a connector failure for an application with no pending provisioning activity.

For connectors that have been degraded or failed, the health monitoring layer identifies the pending provisioning events that were not delivered. When the connector is restored, Akku’s provisioning engine replays the queued events to close the access gap. Failed deprovisioning events are replayed first to prioritise closure of active access exposures. The audit trail records the original deprovisioning event, the connector failure period, and the replay event with timestamps, producing a complete evidence chain for audit purposes.

The Compliance and Security Implications

ISO 27001 A.8.2 requires that access rights are removed when employment terminates. The compliance evidence is a deprovisioning record showing access was revoked. When a SCIM connector fails silently, the IGA record shows revocation but the application state does not reflect it. Health monitoring provides the visibility to detect this discrepancy and close it before the evidence record is used in an audit. 

SOC 2 CC6.3 requires that access is authorised, modified, or removed based on roles and responsibilities. A failed SCIM provisioning event that blocks a new joiner’s access on day one is a CC6.3 deviation: the access authorisation exists in the IGA record but has not been implemented in the application. For financial services organisations under RBI Cybersecurity Framework requirements for access control and for ITeS and BPO organisations where day-one access to client systems is an operational requirement, the provisioning failure has regulatory and contractual implications beyond the immediate IT inconvenience.

DPDPA Rules 2025 requires that data fiduciaries implement technical measures to protect personal data from unauthorised processing. A failed deprovisioning sync that leaves a former employee with active access to a system containing personal data is an unauthorised processing pathway. Health monitoring that detects the failure immediately and triggers remediation is the technical control that closes this exposure.

What to Check in Your Current Provisioning Architecture

For each SCIM connector in your IGA platform, answer these three questions. First: does a connector failure generate an alert that reaches the IT operations team without requiring manual log review? If the answer is no, failed syncs are accumulating undetected. Second: for the last five employee offboardings, does the deprovisioning record in your IGA platform show revocation confirmed by SCIM response from every connected application, or only that the deprovisioning event was triggered? If only triggered, the confirmation layer is missing. Third: for the last five new joiners, was day-one access available in all provisioned applications? If there were access issues on any day one, a provisioning connector failure was the likely cause.

Explore Akku IGA and Provisioning  |  Talk to the Akku Team

Questions IT and IAM Teams Ask About Provisioning Connector Health

Q: What is the SCIM 2.0 protocol response flow when a provisioning event succeeds versus fails?

A: In a successful SCIM provisioning flow, the identity provider sends an HTTP POST, PUT, PATCH, or DELETE request to the service provider’s SCIM endpoint. A successful response returns HTTP 200 OK, 201 Created for POST, or 204 No Content for DELETE. The identity provider records the successful response and marks the provisioning event as complete. In a failure flow, the service provider returns an error status: 401 Unauthorized for an expired token, 429 Too Many Requests for rate limiting, 503 Service Unavailable for endpoint downtime, or 400 Bad Request for a schema mismatch. The identity provider logs the error response. Whether it retries, queues the event, or marks it as failed depends on the platform’s error handling implementation. Most implementations log the failure but do not surface it prominently.

Q: How does Akku’s health monitoring distinguish between a transient connector failure and a persistent failure?

A: Akku’s health monitoring classifies connector failures by duration and failure type. A single failed sync event on an otherwise healthy connector is classified as a transient event and logged without triggering an alert, given that transient network issues, brief endpoint maintenance windows, and rate limit responses are normal operational occurrences for active connectors. A connector that fails on two or more consecutive sync cycles, or that returns an authentication failure, is classified as degraded and triggers an alert. A connector that has been in a failed state for a configurable duration threshold is classified as failed and escalates the alert. This tiered classification reduces alert noise from transient issues while ensuring that persistent failures that produce access gaps are surfaced promptly.

Q: What happens to provisioning events that were queued during a connector outage?

A: Provisioning and deprovisioning events that occur while a connector is in a failed or degraded state are queued by Akku’s provisioning engine with the original event timestamp. When the connector health status returns to healthy, the queued events are replayed in chronological order. Deprovisioning events are prioritised in the replay queue to close active access exposures before processing pending provisioning events for new joiners. Each replayed event is recorded in the audit trail with the original event timestamp, the connector failure period, and the replay execution timestamp, creating a complete evidence chain that shows both the original intent and the actual execution.

Q: How does an expired API token cause a silent SCIM connector failure?

A: SCIM connectors authenticate to the service provider’s endpoint using either a static API token or OAuth 2.0 client credentials. API tokens have expiry dates set by the application vendor, ranging from 30 days to indefinite depending on the application. When a token expires, the SCIM endpoint returns a 401 Unauthorized response to all subsequent requests. The provisioning engine logs the 401 response as a connector error. Without health monitoring, this error sits in the log. The connector has been broken since the token expired, and every provisioning and deprovisioning event since that date has failed silently. Akku’s health monitoring detects the 401 response on the first failure, classifies it as an authentication failure requiring attention, and alerts the administrator with the connector name and the failure type so the token can be rotated before the outage accumulates further access gaps.

Q: How does connector health monitoring integrate with Akku IGA’s access review process?

A: Akku IGA’s access review process certifies entitlements based on the IGA’s access records. If a SCIM connector failure has caused a deprovisioning event to fail, the IGA record shows the entitlement as revoked while the application still has an active account. The connector health monitoring layer surfaces this discrepancy by flagging connectors that have experienced deprovisioning failures and identifying the specific provisioning events that were not delivered. This allows the access review to include a verification step confirming that the IGA record and the application access state are consistent, rather than relying solely on the IGA record as evidence that access was revoked.

Q: What is the difference between a SCIM sync failure and a SCIM schema mismatch?

A: A SCIM sync failure is an infrastructure or connectivity issue: the connector cannot reach the endpoint, the token has expired, or the endpoint is returning server errors. The SCIM protocol exchange is failing before the provisioning logic executes. A SCIM schema mismatch is a protocol-level incompatibility: the identity provider is sending attributes in a format or structure that the service provider does not accept, producing a 400 Bad Request response. Schema mismatches typically occur after application updates that change the service provider’s accepted SCIM schema, or after changes to the identity provider’s attribute mapping configuration. Both produce failed sync events, but they require different remediation: infrastructure failures require connectivity or authentication fixes, while schema mismatches require the attribute mapping to be updated to match the service provider’s current schema.

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.

A provisioning record captures a point-in-time entitlement decision: this user was granted access to this application on this date. It records that the door was opened. It contains no information about whether anyone has walked through it since.

An access usage record captures an event: this user authenticated and launched this application at this timestamp from this device. It records that the access was exercised. It is a different dataset from the provisioning record and in most IAM architectures, it does not exist. 

The absence of access usage data has three distinct consequences that are usually treated as separate problems but share the same root cause. First, dormant accounts with valid access entitlements accumulate as an unmonitored attack surface. Second, access reviews that run without usage data certify entitlements rather than evaluate continued need, which is not what ISO 27001 A.5.18, SOC 2 CC6.3, or DPDPA Rules 2025 require from a periodic access review. Third, SaaS licences assigned to users who have not launched the application in months represent recoverable budget that the organisation has no mechanism to identify without usage data.

This blog covers the technical distinction between the two datasets, what each consequence looks like operationally, and what application launch monitoring at the SSO layer produces as a usage record without requiring per-application integrations.

Why Provisioning Records Are Not Usage Records

Provisioning is architecturally event-driven: it triggers on access requests and access removals. Between those two events, the provisioning platform has no visibility into what happens with the entitlement. Whether the user launches the application daily or not at all, the provisioning record is identical. The record reflects the entitlement state, not the usage state. 

Application usage data, where it exists, lives in the application itself. Applications that generate access logs produce records of who authenticated and when. Those records live in the application’s own logging infrastructure. Pulling them into a coherent cross-application usage view requires native API integrations with each application, a CASB layer that monitors application traffic, or manual extraction on a schedule. None of these is operationally straightforward at scale across 40 to 60 SaaS applications. 

The result is that most organisations have precise provisioning records and no structured usage data. The two datasets that together constitute a complete picture of access governance exist independently, and most organisations only have one of them.

What the Absence of Usage Data Costs

Dormant Accounts as an Unmonitored Attack Surface

An account that has not been used in 90 days is not actively monitored by the user who owns it. Password change notifications go unread. Anomalous MFA prompts go unreported. If the account’s credentials are compromised, the compromise may not surface for weeks because the legitimate user has no reason to notice anything unusual about an account they are not using.

NIST SP 800-53 Control AC-2 recommends disabling inactive accounts after a defined period. ISO 27001:2022 Annex A Control A.5.16 requires that identity management include a mechanism for reviewing and disabling inactive identities. Most organisations have a policy that specifies an inactivity threshold. Very few have a technical mechanism that enforces it, because they do not have the usage data needed to identify which accounts are inactive.

Access Reviews Without a Meaningful Baseline

Access reviews under ISO 27001 A.5.18 and SOC 2 CC6.3 are supposed to evaluate whether access is still appropriate. Without usage data, the reviewer can confirm that the entitlement exists and that the user’s current role appears to justify it. They cannot evaluate whether the access has been exercised in the review period, whether the usage pattern is consistent with the stated business need, or whether the access should continue to exist given that nobody has used it in six months.

Under DPDPA Rules 2025, access to personal data should be granted on a need-to-know basis and reviewed periodically. A review that certifies access without any data on whether the access has been exercised is not a meaningful review of whether the need-to-know condition is still met. For financial services organisations and healthcare organisations where access reviews are part of RBI, SEBI, and HIPAA compliance obligations, a review based on usage data is qualitatively and evidentially different from a review based on entitlement records alone.

Recoverable SaaS Licence Spend

SaaS licences are priced per seat. A seat occupied by a user who has not launched the application in six months is a seat being paid for without return. Industry data from SaaS management platforms consistently indicates that between 20 and 30 percent of provisioned SaaS seats are unused in a typical month. For a mid-market organisation with 500 users and 50 SaaS applications, that percentage represents a significant monthly spend on licences that could be reclaimed and reallocated or cancelled. Identifying and reclaiming those seats requires knowing which users have not launched which applications in a defined period. That requires usage data. 

What Application Launch Monitoring Produces

Application launch monitoring captures the event that occurs when a user authenticates through the IAM platform and is directed to a specific application. It operates at the SSO layer, not at the application layer. Any application that uses SSO-based authentication through Akku produces a launch event at the identity platform regardless of whether the application has its own session logging capability. No per-application integration is required.

Each launch event captures the user identifier, the application accessed, the timestamp, the device, and the geo-location of the authentication. This data is stored per user per application, producing a usage record that sits alongside the provisioning record in the identity platform.

Last-Used Date Per User Per Application

The immediately actionable output is a last-used date for each user-application combination. An access review showing a user has not launched an application in 120 days has a different conversation than one showing daily usage. The reviewer makes a decision based on actual usage behaviour rather than on whether the user’s role still appears to justify the access in the abstract.

For automated lifecycle management, last-used date enables a technical policy: accounts that have not accessed an application within a defined period are flagged for review or automatically suspended based on the risk profile of the application. This is the technical enforcement of what ISO 27001 A.5.16 and most inactivity policies describe but rarely implement.

Anomaly Detection From Usage Baseline 

Application launch data over time produces a usage baseline per user per application. A user who normally launches the CRM five times daily but whose launch events stop appearing for two weeks has experienced something: a missed offboarding, extended leave, or an account compromise that locked the legitimate user out. A user who normally accesses a specific application once a week but suddenly launches it dozens of times in a single session is also anomalous. Both signals are only available if launch data is being collected.

Licence Reclamation With Documented Evidence

Usage data enables licence reclamation with evidence rather than estimation. The IT team produces a report showing per application: provisioned users, users who launched at least once in the last 30 days, and users who have not launched in 90 days. That report is the basis for a licence reclamation conversation with the application vendor. Removing dormant seats from a SaaS licence is a straightforward conversation when the usage data supports it.

How This Connects to Automated User Lifecycle Management

Application launch data is most operationally powerful when connected to the automated user lifecycle management layer in Akku rather than existing as a standalone reporting view. When the last-used date for a user-application combination crosses a defined threshold, the lifecycle management layer triggers a review workflow automatically: the user’s manager is notified, confirmation of continued need is requested, and access is removed if no confirmation arrives within the defined period.

This closes the loop between usage visibility and access governance without requiring a manual process for each dormant account. The review is triggered by the data. The outcome is recorded in the provisioning system. The audit trail shows that dormant access was identified, reviewed, and either confirmed or removed, which is the evidence that a meaningful periodic access review under ISO 27001 A.5.18 and DPDPA is supposed to produce.

For ITeS and BPO organisations where employees frequently change project assignments and client system access needs corresponding adjustment, application launch data makes the access actually being used visible in a way that a provisioning record cannot. Access to a client system that has not been launched since a project ended three months ago is a deprovisioning candidate that the standard offboarding process may have missed. 

Before You Move On

Pick three applications in your environment that hold sensitive data. For each one, pull the list of provisioned users from your IAM platform. Then answer: of those users, how many have not accessed the application in the last 90 days?

If the IAM platform cannot answer that question from its own data, the usage visibility gap is confirmed. The provisioning record exists. The usage record does not. The security implication is a list of dormant accounts passing access reviews without any evidence of whether the access is still exercised. The compliance implication is that those reviews, under DPDPA and ISO 27001, are based on entitlement data rather than access behaviour. The cost implication is a straightforward calculation: dormant licensed seats multiplied by the per-seat monthly cost. 

Explore Akku IAM and Lifecycle Management  |  See Akku IGA and Access Reviews  |  Talk to the Akku Team

Questions IT and Compliance Teams Ask About Access Usage Visibility

Q: What is the technical difference between a provisioning record and an application launch record? 

A: A provisioning record captures the entitlement lifecycle: when access was granted, by whom, under what approval, and when it was removed. It records a decision about access. An application launch record captures a usage event: a specific user authenticated and was directed to a specific application at a specific timestamp. The two records describe different things. A provisioning record answers whether a user has access. An application launch record answers whether a user has used their access. Both are required for complete access governance. Most IAM platforms maintain only the provisioning record.

Q: How does application launch monitoring differ from application-level session logging? 

A: Application-level session logging is performed by the application itself and requires either native logging capability in the application or a CASB layer intercepting traffic. Application launch monitoring is performed at the SSO layer: when the user’s authenticated session is redirected from the identity platform to the application, the launch event is captured. It requires no integration with each individual application. Any application using SSO-based authentication through Akku produces a launch event at the identity platform regardless of the application’s own logging capability.

Q: How does DPDPA treat dormant access to personal data systems?

A: DPDPA requires that access to personal data is granted on a need-to-know basis and reviewed periodically. An account that has not accessed a personal data system in several months raises a question about whether the need-to-know condition is still met. A periodic access review certifying access without usage data cannot meaningfully evaluate this. The DPDPA’s access accountability requirements imply that the organisation can demonstrate not just that access exists and was approved, but that access is actively justified by current need. Application launch data provides the evidence needed to distinguish active access from dormant access. 

Q: What is a practical inactivity threshold for triggering an access review?

A: The appropriate threshold depends on the application’s risk profile. For high-sensitivity applications containing personal data, financial records, or privileged system access, 30 days is appropriate. For standard productivity applications, 60 to 90 days is common. The threshold should be defined in the access control policy rather than set arbitrarily, so the automated review trigger is aligned with the policy’s stated inactivity standard. ISO 27001 A.5.16 does not specify a number but requires that inactive identities are identified and addressed within a defined timeframe.

Q: How does usage data improve the quality of access reviews under SOC 2 CC6.3?

A: SOC 2 CC6.3 requires periodic review of whether existing access is still appropriate. With only entitlement data, the reviewer confirms the access exists, and the role appears to justify it. With usage data, the reviewer can evaluate whether the access has been exercised in the review period and whether the usage pattern is consistent with the stated business need. A reviewer who sees that a user has not launched an application in 180 days makes a substantively different decision than one who sees only that the entitlement exists. The audit evidence produced by a usage-informed review is qualitatively stronger under both SOC 2 and ISO 27001.

Q: How does Akku connect application launch data to the provisioning and deprovisioning lifecycle?

A: In Akku, application launch events are captured at the SSO layer when users access applications through Akku-managed SSO. This data feeds into the access governance layer alongside provisioning records, producing a combined view of who has access and who is using it. Inactivity thresholds can be configured as policy rules that trigger automated review workflows when a user-application combination has not produced a launch event within the defined period. The full chain from provisioning through usage monitoring through periodic review to deprovisioning is traceable in a single audit trail.

Defensible audit evidence for an access grant has a specific technical definition. It is not a confirmation that the access exists. It is not a record that the access was provisioned. It is a structured record of a formal authorization decision: the identity of the person who approved the access, their authority to approve it, the scope of access approved, the business justification, and the timestamp of the decision, all stored in a system that is queryable, tamper-evident, and independent of any individual’s inbox.

An email from a department head saying please give Rahul access to the finance system satisfies none of those requirements. It is a request. The IT manager acting on it is a provisioning action. Neither constitutes a formal authorization decision in the sense that ISO 27001:2022 Annex A Control A.5.18, SOC 2 CC6.1, or DPDPA Rules 2025 mean when they use that term.

The gap between what most organizations produce as access approval records and what those frameworks require is one of the most consistent findings in IT compliance audits. It persists not because IT teams are careless but because the tooling most organizations rely on was built to provision access efficiently. Recording the governance decision behind the provisioning action was never part of the design.

This blog covers exactly what defensible audit evidence for access governance requires technically, where informal approval processes fail against each framework standard, and what a structured approval workflow produces that an email thread cannot.

What Defensible Audit Evidence for Access Governance Actually Requires

ISO 27001:2022 Annex A Control A.5.18 requires that access rights are provisioned based on a formal authorization process, and that the process is documented. The documentation requirement is specific: it must be possible to demonstrate, for any access grant, that an authorization process was followed. That demonstration requires a record with identifiable fields, not a message that may or may not contain the relevant information depending on how it was written.

The specific fields that constitute a defensible access authorisation record are: the identity of the requester and their role, the identity of the approver and their authority to approve access of the type requested, the system and permission scope being approved, the business justification for the access, the timestamp of the approval decision, the duration of the access where time-limited, and a reference to the access control policy or role definition the approval was evaluated against.

SOC 2 CC6.1 requires that logical access controls restrict access to authorized individuals and that the authorization can be demonstrated. The evidence standard for CC6.1 is a queryable record showing that each access grant was authorized by a person with the defined authority to grant it. An email buried in a former employee’s archived mailbox does not constitute a queryable record in any operationally meaningful sense.

DPDPA Rules 2025 require that access to personal data is granted on a need-to-know basis. At the evidence level, this means the organization must demonstrate on demand that each access grant to a personal data system was based on a documented business need, approved by an appropriate authority, and reviewed since it was granted. A supervisory review under DPDPA does not arrive on a scheduled basis. It can arrive following an incident. The evidence of access governance needs to be retrievable immediately, not reconstructed from historical communications.

Where Informal Approval Processes Fail the Evidence Standard

The Record Is Tied to an Individual Inbox

An email approval lives in the approver’s inbox. When that person leaves the organization, the inbox is archived, restricted, or deleted depending on the organization’s data retention policy. Reconstructing an access decision made 18 months ago by a manager who left the organization 12 months ago requires locating the archived mailbox, obtaining access to it, identifying the correct thread, and confirming that the relevant approval is in the thread rather than in a separate conversation. This is an investigation, not a record retrieval.

A structured approval record stored in the identity governance platform is queryable by the compliance team regardless of whether the original approver is still with the organization. The record exists independently of any individual’s employment status.

The Record Has No Structured Schema

An email approval has no schema. Whether it contains the information an auditor needs depends entirely on how the email was written. A subject line reading access for new joiner and a body reading please sort this out contains no approver identity in a queryable field, no scope definition, no business justification, and no reference to an access control policy. It contains a request. That is not the same as an authorization record.

A structured approval record has defined fields. Every record for every access grant contains the same information in the same format, regardless of who wrote the request or how formally they phrased it. The schema enforces the evidence standard at the point of approval, not at the point of the audit.

The Approval Scope Is Undefined

Email-based approvals routinely approve access at an application level without defining the role, permission set, or data scope within the application. Approving access to Salesforce without specifying whether that means read-only access to one regional pipeline or administrative access to the full CRM is not a scoped authorization. It is a vague grant that cannot be meaningfully reviewed for continued appropriateness because the original scope was never defined.

Under SOC 2 CC6.3, access reviews are supposed to evaluate whether existing access is still appropriate. If the original approval did not define the scope, the reviewer has no baseline against which to evaluate appropriateness. They are certifying that the access exists and that the user’s role appears to justify something. They cannot evaluate whether the specific access granted was appropriate then or remains appropriate now.

What a Structured Approval Workflow Produces That Email Cannot

A Schema-Enforced Authorization Record 

A structured workflow captures the approval decision in a defined schema at the point the decision is made. The requester, approver, access scope, business justification, and timestamp are all mandatory fields. The record cannot be created without them. This means the evidence standard is enforced by the system rather than by the discipline of the person writing the email. 

A Queryable Audit Trail Independent of Personnel

The approval record lives in the identity governance platform, not in an inbox. It is queryable by system identifier, user identifier, approver identity, application, date range, and approval status. A compliance team preparing for an ISO 27001 audit can retrieve the complete approval history for any application in under a minute. The same query works whether the original approver is still with the organization or left three years ago.

An Access Review Baseline With Defined Scope

When an access review runs under ISO 27001 A.5.18 or SOC 2 CC6.3, the reviewer sees the original approval record alongside the current access state. They can evaluate whether the business justification still holds, whether the scope of access is still appropriate given the user’s current role, and whether the duration of the access was meant to be time-limited. This is a genuine review of continued appropriateness, not a certification that the access exists.

For financial services organizations under RBI’s Cyber Security Framework and SEBI CSCRF requirements, structured access approval records satisfy the audit trail requirement at the individual access grant level. For ITeS and BPO organizations subject to client compliance audits with short notice, retrievable approval records change the audit response time from days to minutes.

How This Connects to the Broader Identity Governance Architecture

Structured access approval workflows are one component of identity governance and administration that sits in front of the provisioning layer. The approval record triggers the provisioning action. The two records reference the same request identifier, so the full chain from approval to entitlement to periodic review to deprovisioning is traceable in a single audit trail.

For organizations using Akku IAM for provisioning, adding structured approval workflows closes the governance gap without replacing the provisioning architecture. The approval step sits in front of provisioning and produces the audit record that the provisioning action alone cannot.

Before You Move On

For any five access grants made in the last 12 months to a sensitive system, try to retrieve the authorization record from your current systems. Check whether the record contains the approver’s identity, the scope of access approved, the business justification, and the timestamp of the decision, all in a queryable format.

If any of those five records requires searching an inbox, asking the original approver, or acknowledging that the record may not exist in a structured form, the gap between your current process and what ISO 27001 A.5.18 and DPDPA require is confirmed.

Explore Akku IGA Capabilities  |  See Akku IAM Provisioning  |  Talk to the Akku Team 

Questions Compliance and IT Teams Ask About Access Approval Workflows

Q: What is the difference between an access request and an access approval under ISO 27001?

A: An access request is an expression of intent: someone wants access to a system. An access approval is a formal authorisation decision: a person with defined authority has reviewed the request against the access control policy and made a documented decision to approve it. ISO 27001:2022 Annex A Control A.5.18 requires that access rights are provisioned based on a formal authorisation process, and that the process is documented. An email request that an IT manager acted on is a fulfilled request. It is not a documented authorisation process unless the approval decision itself was recorded in a structured schema with the approver identity, scope, business justification, and timestamp.

Q: What does DPDPA Rules 2025 require specifically at the access approval evidence level?

A: DPDPA requires data fiduciaries to implement technical and organisational measures ensuring access to personal data is granted on a need-to-know basis. At the evidence level, the organisation must demonstrate on demand that each access grant to a personal data system was based on a documented business need approved by an appropriate authority. The DPDPA does not prescribe a specific tool. It sets an outcome: the access decision must be demonstrable. An email in an inbox that may or may not be searchable after the approver has left the organisation does not satisfy this standard in a regulatory review or supervisory investigation context.

Q: What should a structured access approval record contain to satisfy audit requirements across ISO 27001, SOC 2, and DPDPA simultaneously?

A: The record should contain the identity of the requester and their business role, the identity of the approver and their authority to approve access of the type requested, the system and permission scope being approved, the business justification for the access, the timestamp of the approval decision, the duration of the access where time-limited, and a reference to the access control policy or role definition the approval was evaluated against. This structure satisfies the documentation requirement of ISO 27001 A.5.18, the authorization evidence requirement of SOC 2 CC6.1, and the access accountability requirement of DPDPA. For multi-level approvals, each approval step should have its own record.

Q: How does a structured approval workflow connect to the access review process under SOC 2 CC6.3?

A: SOC 2 CC6.3 requires periodic review of whether existing access is still appropriate. For that review to be meaningful, the reviewer needs to know what was approved, at what scope, and for what business justification. A structured approval workflow provides this baseline automatically. The reviewer sees the original approval record alongside the current access state and can evaluate whether the justification still holds. Without this baseline, the reviewer can only certify that the access exists, not that it remains appropriate. The quality difference between the two types of review is the difference between a compliance exercise and a genuine governance evaluation.

Q: How do you transition from email-based approvals to a structured workflow without disrupting operations?

A: Three steps. First, define the approval workflow for each category of sensitive system: who has authority to approve access, what information must be captured, and what the response time expectation is. Second, configure the identity governance platform so that provisioning actions for those systems require a completed approval record rather than an informal message. Third, make the new process at least as fast as the informal one for routine requests. A well-configured approval workflow for a standard access request should complete in under an hour. The operational disruption is minimal if the workflow is designed around the actual approval behaviour rather than around a theoretical governance model.

Q: What is the regulatory risk of continuing with informal access approvals under DPDPA and ISO 27001? 

A: Under ISO 27001, informal access approvals are a control gap that affects certification. An auditor finding that access rights are provisioned without a documented authorization process is an A.5.18 nonconformity. Under DPDPA, the risk is potentially more significant because the data protection board has investigatory powers that are not confined to scheduled audits. An organization that cannot demonstrate structured access approval records for personal data systems is in a materially weaker position in any regulatory interaction, regardless of whether a breach has occurred. The absence of evidence is not evidence of absence in a regulatory investigation.