Introduction

Every major compliance framework that applies to Indian organisations contains a provisioning and deprovisioning requirement. The language differs. RBI Clause 8(c) calls it access governance with documented approval records. SEBI CSCRF PR.AA.S1 calls it identity lifecycle management. IRDAI ICS Items 6 and 26 call it controlled provisioning of user accounts. ISO 27001:2022 A.5.16 calls it identity management. DPDPA Clause 8(7) calls it erasure and cessation of processing when the purpose is served. SOC 2 CC6.2 and CC6.3 call it user registration and authorisation and modification or removal of access.

Different language, identical technical requirement: access must be formally granted through a documented process, and access must be removed completely and promptly when it is no longer required. Both halves of the requirement must be technically enforced and continuously evidenced.

The provisioning half fails when access is granted informally: over email, through a verbal request, via an ad-hoc IT ticket, or by an administrator who copies an existing user’s access configuration without a documented approval. The deprovisioning half fails when access removal is incomplete, delayed, or undocumented: a departed employee whose accounts were removed from Active Directory but persist in three SaaS applications, a contractor whose engagement ended without a formal deprovisioning trigger, or an employee who changed roles but retained access from every previous function.

Both failures produce audit findings across every framework that examines them. This blog covers what the provisioning and deprovisioning requirement looks like in each major framework, what technical controls are required to satisfy it, and what evidence the controls must produce.

Provisioning Requirements Across Frameworks

The provisioning requirement is consistent across frameworks at its core: access must be granted through a formal process that produces a documented authorisation record.

What each framework requires

RBI Clause 8(c) requires that access governance controls ensure only authorised users have access to information systems. Authorisation implies a documented process. An authentication log showing a user has access does not demonstrate that the access was formally authorised. The approval record does.

SEBI CSCRF PR.AA.S1 and GV.PO.S1 to S5 require that access be provisioned based on formally defined roles with technically-enforced policies. Birthright access defined by role and additional access requiring documented approval are the two provisioning mechanisms that satisfy this requirement.

IRDAI ICS Item 6 requires controlled provisioning of temporary and contractor accounts with documented lifecycle management. Item 26 requires that access provisioning follow a defined process. The controlled and defined qualifiers indicate that informal provisioning does not satisfy these items.

ISO 27001:2022 A.5.16 requires that the full lifecycle of identities be managed, including creation through a managed process. A.5.18 requires that access rights be provisioned through a formal process. Both controls must produce structured records for certification audits.

SOC 2 CC6.2 requires that prior to issuing system credentials and granting system access, the entity registers and authorises new users. The authorisation must precede access, not follow it. Access granted before the approval is complete fails CC6.2 regardless of whether approval is eventually obtained.

DPDPA Clause 8(4) requires appropriate technical measures to ensure processing is limited to authorised purposes. Provisioning access to personal data systems without a documented authorisation tied to a specific processing purpose fails this requirement.

What compliant provisioning evidence looks like

A compliant provisioning record must contain: requester identity, approver identity and approval timestamp, justification for the access grant, the specific access being granted including system and permission level, provisioning execution timestamp, and SCIM sync confirmation from each connected application.

The timestamp sequence matters. The approval timestamp must precede the provisioning execution timestamp. An approval record dated after the access was granted is not a compliant provisioning record.

Multi-step approval for sensitive access must be documented with every approver in the chain: line manager approval, system owner approval, and security team approval where required. The complete approval chain, not only the final approval, must be in the record.

How Akku produces compliant provisioning evidence

Akku’s access request and approval workflow captures every provisioning event with the complete required record at the time of the event. Birthright access provisioned automatically on joining is recorded with the role trigger, the access definition, and the provisioning execution timestamp. Additional access requested beyond role defaults is recorded with requester identity, approver identity, approval timestamp preceding provisioning, justification, access scope, and SCIM sync confirmation.

SCIM-based provisioning generates a downstream sync record for every connected application. When a provisioning action in Akku does not propagate successfully to a connected application due to a connector failure, the failure is logged and flagged for administrator attention. The provisioning record in Akku without a corresponding sync confirmation is an incomplete record, and Akku surfaces this discrepancy rather than allowing it to persist silently.

Deprovisioning Requirements Across Frameworks

The deprovisioning requirement is equally consistent across frameworks: access must be removed completely and promptly when it is no longer required, with a documented audit trail of every removal action.

What each framework requires

RBI Clause 19(a) requires that access be revoked promptly when the need ends or the user’s role changes. Promptly is not defined precisely but IS auditors interpret it as same-day for employment terminations and within the current business cycle for role changes.

SEBI CSCRF PR.AA.S1(G1g) and G1h require automatic disabling of dormant accounts and prompt revocation of access when employment or engagement ends. The automatic requirement means deprovisioning cannot depend on a manual trigger from the business unit.

IRDAI ICS Item 10 requires automatic disabling of dormant accounts. Items 26 and 33 require that access be removed when employment ends. The combination means both event-triggered deprovisioning and threshold-based dormant account management are required.

ISO 27001:2022 A.5.16 requires that identity deletion follow a managed process. A.5.18 requires that access rights be revoked when no longer required. Both must produce structured evidence that removal occurred.

SOC 2 CC6.3 requires that access be modified or removed based on the system of record for entitlements. When employment ends, the system of record must reflect the change and trigger access removal. Deprovisioning that relies on a separate IT ticket disconnected from the HR system of record fails this standard.

DPDPA Clause 8(7)(a) requires erasure and cessation of processing when the purpose is no longer served. For workforce systems, employment termination is the event that triggers this determination. Clause 8(7)(b) requires cessation and erasure when consent is withdrawn.

What compliant deprovisioning evidence looks like

A compliant deprovisioning record must contain: the trigger event, whether employment termination, role change, access review revocation, consent withdrawal, or dormant account threshold crossing. The systems from which access was removed. The removal timestamp for each system. SCIM sync confirmation from each connected application. The identity of the administrator or automated process that executed the deprovisioning.

Completeness is critical. A deprovisioning record showing removal from Active Directory and the primary SaaS applications but silent on the legacy policy administration system, the custom internal tool, and the infrastructure access credentials is an incomplete record. The record must cover every system the user had access to.

Timing is equally critical. The removal timestamp must be same-day for employment terminations under most frameworks. Removals completed days after the triggering event are findings under RBI, SEBI, and SOC 2.

How Akku produces compliant deprovisioning evidence

Akku’s automated deprovisioning workflow is triggered by HR system events through SCIM or API integration. When an employee’s record is marked inactive in the HR system, Akku receives the trigger and initiates deprovisioning across all connected applications simultaneously. Each application removal generates a timestamped deprovisioning record with system identity, removal timestamp, and SCIM sync confirmation.

The deprovisioning audit trail covers every connected application, not only those with native directory integration. Legacy applications covered through credential replay receive deprovisioning actions through Akku’s application connector, with the removal event logged alongside direct-integration removals in the same audit trail.

For role changes, Akku’s mover workflow triggers a re-provisioning action: access from the previous role is reviewed, entitlements no longer appropriate for the new role are revoked, and new role-based entitlements are provisioned. The complete workflow record, covering both the revocation of previous access and the provisioning of new access, is generated at the time of the role change event.

The Orphan Account Problem

Orphan accounts are user accounts that exist without a linked, active identity. They are the accumulated product of incomplete deprovisioning over time: employees who left without a formal deprovisioning trigger, contractor accounts created for specific projects and never removed, accounts created during system migrations with no owner, and service accounts whose owning service was decommissioned but whose accounts persisted.

Every framework reviewed above creates an orphan account risk because every framework requires access to cease when the need ends. Orphan accounts are evidence that deprovisioning failed at some point in the past. They represent both a security risk, credentials that may be valid with no active owner to notice suspicious usage, and a compliance finding.

Akku’s IGA orphan account management detects accounts across all connected applications that exist without a linked, active identity in Akku’s directory. The detection run identifies the orphan, its connected application, the last authentication timestamp, and the absence of a linked active identity. Detected orphans are surfaced for resolution through deletion or reassignment. The detection run and resolution record constitute the proactive access hygiene evidence that frameworks including RBI, SEBI, and IRDAI specifically look for.

The SCIM Connector Failure Problem

SCIM-based provisioning and deprovisioning is the technical standard for automating access changes across connected applications. When SCIM connectors fail silently, provisioning and deprovisioning actions recorded in the IAM platform do not propagate to connected applications. The IAM platform record shows the action completed. The connected application retains the previous access state.

For deprovisioning specifically, a silent SCIM failure means a departed employee’s account persists in a connected application after the IAM platform records show it was removed. The deprovisioning evidence is misleading: it shows completion when the access was not actually revoked.

Akku’s connector health monitoring detects SCIM sync failures before they create access gaps. Failed sync events are logged and flagged for administrator attention. The deprovisioning record in Akku includes the SCIM sync status: completed with confirmation, or failed with the failure event logged. An auditor examining deprovisioning records can see which removals completed end-to-end and which require investigation.

Diagnostic Questions

For a sample of ten users provisioned in the last 12 months, can you produce the provisioning record for each showing the approval timestamp preceding the access grant, the approver identity, and the justification, without reconstructing from email history?

For a sample of ten users who departed in the last 12 months, can you produce the deprovisioning record for each showing every system from which access was removed, the removal timestamp for each system, and SCIM sync confirmation, with same-day completion for employment terminations?

Does your deprovisioning workflow trigger automatically from HR system events, or does it require a manual IT ticket submission after the HR event is recorded?

Has your organisation run an orphan account detection pass in the last 90 days, and is there a detection record and resolution record for every orphan identified?

Does your SCIM connector health monitoring detect failed sync events and flag them for administrator attention before they create persistent access gaps or misleading deprovisioning evidence?

CTAs

See how Akku’s User Lifecycle Manager addresses provisioning and deprovisioning requirements across DPDPA, RBI, SEBI CSCRF, IRDAI, ISO 27001, and SOC 2.

Book a conversation with the Akku team to assess your current lifecycle management controls against the provisioning and deprovisioning evidence standards your frameworks require.

FAQs

What is the difference between provisioning and birthright access, and how do they interact with compliance requirements?

Birthright access is the set of applications and systems a user receives automatically on joining based on their role, without requiring a separate access request. Provisioning is the technical process of granting that access. For compliance purposes, birthright access must be defined at the role level in a documented role matrix, provisioned automatically through an automated workflow rather than manually by an administrator, and recorded with the provisioning execution timestamp and the role trigger that initiated it. Additional access beyond birthright requires a separate request and approval process. Both birthright and requested access must produce compliant provisioning evidence, the difference is in the authorisation mechanism: role-based for birthright, request-based for additional access.

Why does same-day deprovisioning matter for compliance frameworks, and what counts as same-day?

Same-day deprovisioning matters because access that persists after employment ends creates both a security risk and a compliance gap simultaneously. A departed employee with valid credentials can access systems they are no longer authorised to use. Every framework that requires access to cease when the need ends treats delayed deprovisioning as a control failure. Same-day means within the same calendar day that the employment termination is recorded in the authoritative HR system. An employee whose termination is recorded at noon and whose access is removed at 11:59 PM the same day satisfies the same-day standard. Access removal completed the following business day does not.

How does SCIM-based deprovisioning differ from manual account deletion, and why does the difference matter for evidence?

SCIM-based deprovisioning sends a structured deprovision request to each connected application’s SCIM endpoint and receives a confirmation response. The confirmation is logged alongside the IAM platform deprovisioning record, creating an end-to-end evidence chain. Manual account deletion requires an administrator to log into each application separately, delete the account, and record the deletion. Manual records are subject to human error, inconsistent format, and documentation gaps. SCIM-based deprovisioning is deterministic and complete: if the SCIM request succeeds, the account is removed and the confirmation is logged. If it fails, the failure is also logged. Manual deprovisioning can succeed silently, fail silently, or be documented inconsistently. The evidence quality of SCIM-based deprovisioning is materially higher.

What should organisations do when they discover orphan accounts during a compliance review?

When orphan accounts are discovered, the organisation must take three actions. First, assess the risk: determine when each orphan account was last used, what systems it has access to, and whether there is any evidence of inappropriate use since the account became orphaned. Second, remediate: disable the account immediately to prevent further access, then delete it after confirming no outstanding dependencies. Third, document: record the detection, the risk assessment, the remediation action, and the resolution timestamp in the audit trail. For compliance evidence purposes, the detection and resolution record demonstrates proactive access hygiene. For the root cause, investigate why the account became orphaned and address the deprovisioning process gap that allowed it.

How do provisioning and deprovisioning requirements interact with third-party and contractor access governance?

Third-party and contractor access is subject to the same provisioning and deprovisioning requirements as permanent employee access under every framework reviewed. IRDAI Item 6 specifically addresses contractor account lifecycle. SEBI CSCRF GV.SC.S4 requires supply chain access governance equivalent to internal user governance. For contractors, provisioning must be time-bound: the access grant must include an expiry date aligned with the engagement end. When the engagement ends, deprovisioning must be automatic and complete, covering all systems the contractor had access to. Contractor accounts that persist after engagement end are orphan accounts and are treated as such in compliance examinations.

Can the same provisioning and deprovisioning evidence satisfy multiple compliance frameworks simultaneously?

Yes. The provisioning record structure, requester, approver, timestamp, justification, access scope, and SCIM confirmation, satisfies RBI Clause 8(c), SEBI CSCRF PR.AA.S1, IRDAI Items 6 and 26, ISO 27001 A.5.16, SOC 2 CC6.2, and DPDPA Clause 8(4) simultaneously. The deprovisioning record structure, trigger event, systems removed, removal timestamps, SCIM confirmation, and completeness across all connected applications, satisfies RBI Clause 19(a), SEBI CSCRF PR.AA.S1, IRDAI Items 10 and 26, ISO 27001 A.5.16, SOC 2 CC6.3, and DPDPA Clause 8(7) simultaneously. A single automated lifecycle management implementation producing these records continuously satisfies the provisioning and deprovisioning requirements of all applicable frameworks from one evidence source.