Introduction

IRDAI ICS Annexure III Item 10 requires that user accounts inactive beyond a defined threshold be automatically disabled. The operative word is automatically. A manual process where an IT administrator periodically reviews account activity reports and disables dormant accounts does not satisfy this requirement at the scale most insurance organisations operate. Automation is the technical requirement, not merely a recommended approach.

Dormant accounts represent a persistent access risk that is disproportionate to their apparent inactivity. An account that has not been used in 90 days belongs to a user who is either no longer employed, on extended leave, or has moved to a different role with different system access requirements. In each case, the account may hold entitlements that are no longer appropriate. If the account’s credentials are compromised through a phishing attack or credential stuffing, the attacker has access to systems the account is entitled to reach without any authentication anomaly triggering an alert, because the account has simply never been used recently.

Most insurance IT teams run dormant account reviews periodically, typically quarterly or semi-annually. The review identifies inactive accounts, produces a list, and administrators work through the list to disable or remove accounts. Between review cycles, dormant accounts accumulate. Accounts created during the gap between the last review and the current one are not caught until the next cycle. Item 10 requires a technical control that closes this gap continuously, not periodically.

This blog covers what Item 10 requires technically, why periodic manual reviews do not satisfy the automation requirement, what other IRDAI ICS items relate to account lifecycle management, and how automated dormant account management operates.

What Item 10 Requires Technically

Item 10 requires automatic disabling of user accounts that have been inactive beyond a defined threshold. The requirement has three components: activity monitoring, threshold enforcement, and automatic action.

Activity monitoring

Automatic disabling requires continuous monitoring of account activity. The system must track the last authentication event for every user account across all connected systems. For a centralised identity management platform, this means the last successful authentication event in the audit log for each user identity.

The activity monitoring scope matters. An account that has not authenticated to the organisation’s SSO platform in 90 days may still have authenticated directly to a legacy application that does not route through the centralised identity layer. If the dormant account definition is based on SSO activity alone, accounts with residual direct application access may not be detected as dormant.

Comprehensive activity monitoring requires the centralised authentication layer to serve as the single authentication path for all systems. When all systems authenticate through the centralised IdP, the last authentication event in the centralised log accurately reflects the account’s activity state across all systems.

Threshold enforcement

The inactivity threshold must be defined in the IT security policy and technically configured in the identity management platform. Industry practice at IRDAI-regulated entities typically sets the dormant account threshold at 90 days of inactivity, though some organisations use 60 days for accounts with access to sensitive systems.

The threshold must be applied consistently across all user account categories: employees, contractors, third-party administrators, and service accounts. Service accounts present a specific challenge because they may have legitimate periods of inactivity that do not indicate dormancy. Separate threshold policies for service accounts versus human user accounts address this distinction.

Automatic action

When an account crosses the inactivity threshold, the automatic action must be account disabling, not flagging for administrator review. Item 10’s automation requirement means the disabling must occur without human intervention. The disabling event must generate a timestamped audit record capturing the account identity, the triggering threshold, and the disabling timestamp.

The distinction between automatic disabling and automatic flagging is significant. A system that identifies dormant accounts and queues them for administrator review is a manual process with automated discovery. Item 10 requires automated enforcement: the account is disabled when the threshold is crossed, regardless of whether an administrator reviews the flag.

Related IRDAI ICS Items on Account Lifecycle Management

Item 10 does not exist in isolation. Several other IRDAI ICS items address related aspects of account lifecycle management that interact with dormant account controls.

Item 6: Temporary and contractor account lifecycle

Item 6 requires that temporary and contractor accounts be provisioned with a defined expiry date and removed or disabled promptly when the engagement ends. For organisations where contractor access is common, Item 6’s requirement is closely related to Item 10: both require that accounts do not persist beyond the point where they are needed.

Technically, Item 6 requires time-bound access for temporary accounts. The access grant must include an expiry date. When the expiry date arrives, access is automatically removed. This is the JIT access model applied to temporary engagements rather than individual sessions.

Item 26 and Item 33: Joiner-mover-leaver processes

Items 26 and 33 address the broader user lifecycle management requirement: accounts must be provisioned promptly on joining, updated when roles change, and removed promptly on departure. These items frame the ongoing lifecycle management context within which Item 10’s dormant account control operates.

An organisation with a strong joiner-mover-leaver process will have fewer dormant accounts because departures are deprovisioned promptly. Dormant accounts accumulate when the leaver process is incomplete: employees who left informally, contractors whose engagements ended without a formal deprovisioning trigger, or accounts created for specific projects that were never removed when the project concluded.

Item 189: Access reviews

Item 189 requires access reviews to be conducted periodically. Access reviews complement dormant account controls by identifying accounts that are active but hold entitlements that are no longer appropriate. An account that authenticates monthly but holds access to systems unrelated to the user’s current role is not dormant but may be over-provisioned. Item 189’s access reviews address this category of access risk that dormant account controls alone do not cover.

Akku’s IRDAI compliance mapping shows IGA and User Lifecycle Manager together address Items 6, 10, 26, 33, 150, 152, 155, 157, 189, and 341 across 10 total mappings.

Why Periodic Manual Reviews Do Not Satisfy Item 10

Item 10’s automation requirement is specific and cannot be satisfied by a periodic manual process, regardless of how frequently the reviews are conducted.

The gap between review cycles

Any periodic review process has a gap between cycles during which dormant accounts accumulate unchecked. If reviews are conducted quarterly, accounts that cross the inactivity threshold in month two of the quarter remain active for up to two months before being disabled. An attacker who compromises credentials for a dormant account during this window has undetected access for the duration of the gap.

Item 10’s requirement for automatic disabling eliminates this gap. When the threshold is crossed, the account is disabled immediately, not at the next review cycle. The gap is reduced from weeks or months to hours or less, depending on how frequently the activity monitoring system checks account states.

Scalability at insurance organisation scale

An insurance organisation with thousands of employees, hundreds of contractors, and dozens of third-party integrations cannot reliably manage dormant account identification and disabling through manual processes. At scale, manual review processes produce inconsistent results: some dormant accounts are caught promptly, others persist through multiple review cycles due to oversight or workload constraints.

Automated dormant account management applies the threshold consistently to every account simultaneously. No account is overlooked because an administrator was occupied with other work during the review cycle.

Audit evidence quality

A manual dormant account review produces evidence that reflects what was reviewed during a specific cycle. An automated dormant account control produces evidence that reflects what occurred for every account continuously. The quality of the audit evidence from an automated control is materially higher than from a manual process, and IRDAI IS auditors examining Item 10 compliance assess the evidence quality alongside the process description.

How Automated Dormant Account Management Works in Akku

Akku’s User Lifecycle Manager implements automated dormant account management through continuous activity monitoring and threshold-based enforcement.

Activity monitoring

The centralised audit log captures every authentication event across all connected applications. The User Lifecycle Manager monitors the last authentication timestamp for every user identity in the Akku directory. When an account’s last authentication event exceeds the configured inactivity threshold, the account is flagged for automatic action.

For accounts with access to systems that route authentication through Akku’s centralised identity layer, activity monitoring is comprehensive. For legacy systems with direct authentication not yet migrated to SSO, activity monitoring covers the centralised authentication layer but not direct application authentication. Full coverage requires all systems to authenticate through the centralised IdP.

Threshold configuration

Inactivity thresholds are configurable per user group or organisational unit. A 90-day threshold can be applied to standard employee accounts while a 30-day threshold applies to accounts with privileged access to critical systems. Service account thresholds can be set separately to accommodate legitimate inactivity patterns.

Automatic disabling and audit record

When an account crosses the threshold, the User Lifecycle Manager automatically disables the account across the Akku directory and triggers deprovisioning notifications to connected applications via SCIM. The disabling event generates a timestamped audit record capturing account identity, triggering threshold, last activity timestamp, and disabling timestamp. This record is the compliance evidence that Item 10 requires.

Re-activation workflow

When a disabled account needs to be re-activated, a structured re-activation workflow requires manager approval and justification before the account is re-enabled. The re-activation record is stored in the audit trail alongside the disabling record, providing a complete lifecycle history for the account.

Diagnostic Questions

Does your organisation have a technically-enforced inactivity threshold that automatically disables accounts when crossed, or does dormant account management rely on periodic manual review cycles?

For accounts disabled through dormant account controls in the last 12 months, is there a timestamped audit record for each disabling event showing the account identity, the triggering threshold, and the disabling timestamp?

Does your activity monitoring cover all systems that user accounts can authenticate to, or only systems that route through the centralised identity layer, leaving direct application authentication outside the monitoring scope?

Are temporary and contractor accounts provisioned with defined expiry dates that trigger automatic removal when reached, or does contractor account removal depend on a manual deprovisioning request from the business unit?

When dormant accounts are re-activated, is there a structured approval workflow requiring manager authorisation and documented justification, with the re-activation event recorded in the audit trail?

CTAs

See how Akku’s User Lifecycle Manager addresses IRDAI Item 10 dormant account requirements through automated activity monitoring and threshold-based enforcement.

Book a conversation with the Akku team to assess your current dormant account management against IRDAI ICS Item 10’s automation requirement.

FAQs

What is the specific inactivity threshold IRDAI Item 10 requires for dormant account disabling?

IRDAI ICS Item 10 requires automatic disabling of accounts inactive beyond a defined threshold but does not specify a precise number of days in the checklist item itself. Industry practice at IRDAI-regulated insurers typically applies a 90-day threshold for standard employee accounts and a shorter threshold, often 30 to 60 days, for accounts with privileged access to critical systems. The threshold must be defined in the organisation’s IT security policy and consistently applied through technical enforcement. IS auditors examining Item 10 compliance assess both the defined threshold and the evidence that it is technically enforced, not merely policy-stated.

What is the difference between account disabling and account deletion for Item 10 purposes?

Account disabling suspends the account, preventing authentication while preserving the account record and its audit history. Account deletion permanently removes the account. Item 10 requires automatic disabling as the immediate action when the inactivity threshold is crossed. Permanent deletion typically follows a further review process to confirm the account is no longer needed and to preserve audit trail integrity. For departed employees, deletion may be deferred to align with data retention obligations. For contractor accounts with confirmed engagement end, deletion may be appropriate immediately following disabling.

How does dormant account management interact with accounts that have legitimate periods of inactivity, such as employees on extended leave?

Employees on extended leave, maternity leave, long-term medical leave, or sabbatical may have accounts that cross the inactivity threshold without representing a security risk. The recommended approach is to configure a separate inactivity policy for accounts in defined leave status, with a longer threshold or a hold that prevents automatic disabling during the leave period. The leave status must be sourced from an authoritative HR system and applied to the account automatically when leave begins. Accounts on leave hold are still monitored and can be reviewed periodically. When leave ends, the standard inactivity threshold applies from the return-to-work date.

Does Item 10 apply to service accounts as well as human user accounts?

Yes, Item 10 applies to all user accounts including service accounts. Service accounts present a specific challenge because they may have legitimate periods of inactivity that do not indicate dormancy. A service account used for a batch job that runs monthly will appear inactive for 29 days out of every 30. Applying a standard 90-day inactivity threshold to service accounts requires careful threshold configuration to avoid false positives. The recommended approach is a separate inactivity policy for service accounts with a longer threshold, combined with a service account inventory that documents the expected activity pattern for each account. Service accounts with no documented expected activity pattern should be reviewed and either given an activity expectation or removed.

What audit evidence does IRDAI Item 10 compliance require, and how should it be structured for IS audit examination?

IRDAI IS auditors examining Item 10 compliance typically request evidence of the automated disabling mechanism configuration, showing the threshold is technically enforced rather than policy-stated. They request a sample of disabling events from the audit log showing timestamped records for accounts disabled through the automated control during the examination period. They verify that the disabling events are generated automatically at the time of threshold crossing, not manually triggered following a review. They also verify that disabled accounts have had their access to connected systems revoked, requiring SCIM deprovisioning confirmation records alongside the identity platform disabling records.

Can Akku’s dormant account management satisfy both IRDAI Item 10 and SEBI CSCRF PR.AA.S1’s dormant account requirements simultaneously?

Yes. IRDAI Item 10 and SEBI CSCRF PR.AA.S1(G1g) and G1h both require automatic disabling of accounts inactive beyond a defined threshold. The same automated dormant account management capability in Akku’s User Lifecycle Manager satisfies both requirements from the same technical control. The threshold configuration, activity monitoring, automatic disabling, and audit record generation are identical for both frameworks. The compliance mapping differs in clause references, but the underlying control is the same implementation producing the same continuous evidence.

Introduction

ISO 27001:2022 Annex A.5.18 requires that access rights be reviewed at regular intervals and when employment or contractual changes occur. The control is one of the most consistently cited sources of nonconformities in ISO 27001 certification audits because organisations either do not conduct reviews on a defined cadence, conduct them informally without producing structured evidence, or conduct a single review before the certification audit rather than maintaining a continuous review process.

The operating effectiveness standard that ISO 27001 auditors apply to A.5.18 requires evidence that reviews occurred throughout the certification period, not only at the point of assessment. A review conducted in the month before the certification audit produces a single evidence record. A review process that ran quarterly throughout the certification period produces four records per year, each demonstrating that the control operated at that point in time. Auditors sample from across the period. A single record does not satisfy sampling from multiple points.

The evidence quality requirement is equally important. Auditors examining A.5.18 evidence look for structured records showing which entitlements were reviewed, who made each decision, what decision was made, and whether revocations were actioned. Informal evidence including email threads where managers acknowledged a list of user access, spreadsheet trackers with no timestamps, and verbal confirmations with no documentary record do not constitute structured A.5.18 evidence.

This blog covers what A.5.18 requires technically, how access reviews must be structured to produce compliant evidence, what cadence satisfies the regular intervals requirement, and how the review process integrates with automated lifecycle management.

What A.5.18 Requires

A.5.18 has two distinct triggering conditions for access rights review: regular intervals and employment or contractual changes.

Regular interval reviews

The regular interval requirement means that all access rights across in-scope systems must be reviewed on a defined, recurring schedule. The control does not specify a minimum interval. ISO 27001 auditors typically consider quarterly reviews as demonstrating a robust periodic control. Annual reviews are the minimum that most auditors accept, but a single annual review produces only one evidence record per year, which limits the operating effectiveness evidence available for sampling.

Regular interval reviews must cover the full population of users with access to in-scope systems. A review that covers only senior administrators or only users with privileged access does not satisfy the full-population requirement. Every user with access to any in-scope system must be included in at least one review cycle per year.

Event-triggered reviews

Employment and contractual changes must trigger immediate access rights review rather than waiting for the next scheduled cycle. When an employee changes roles, their access from the previous role must be reviewed and entitlements no longer appropriate must be revoked. When a contractor’s engagement ends, all access must be removed. When an employee returns from extended leave, their access must be reviewed to ensure it remains appropriate.

Event-triggered reviews are in addition to regular interval reviews, not a substitute for them. An organisation that conducts event-triggered reviews for every role change but has no scheduled regular interval review does not satisfy A.5.18’s dual requirement.

What Structured A.5.18 Evidence Looks Like

The evidence standard for A.5.18 requires that the review process produces a structured record for every review cycle covering specific fields that an auditor can examine.

Review cycle record

Each review cycle must produce a record containing: the review scope covering which systems and which user populations were included, the review date and the period covered, the identity of each reviewer, the list of entitlements reviewed per user, the decision for each entitlement, certify or revoke, with the reviewer’s identity and a timestamp, and for revocations, a corresponding deprovisioning record showing the access was actually removed.

The deprovisioning record is the evidence gap that most organisations miss. A review cycle that produced revocation decisions but cannot show corresponding access removal records has incomplete evidence. The review decision and the access removal must be linked in the audit trail.

Reviewer accountability

A.5.18’s review must involve appropriate reviewers: typically the user’s direct manager for role-based entitlements and the system or data owner for sensitive system access. The reviewer must be a person with sufficient knowledge to assess whether the access remains appropriate, not an IT administrator who rubber-stamps a list.

The reviewer identity must be captured in the review record. A review log showing that entitlements were reviewed but not showing who made each decision does not satisfy the accountability requirement.

Evidence of revocation actioning

For every revocation decision in a review cycle, there must be a corresponding access removal record showing that the entitlement was actually removed, from which system, at what time, and through which mechanism. A review record showing that access was revoked but no corresponding deprovisioning record demonstrates that the review process operates but does not produce consistent follow-through, which is a control design weakness.

How to Structure the Review Process for A.5.18 Compliance

Implementing A.5.18 in a way that produces compliant evidence throughout the certification period requires a structured review workflow, not a periodic manual exercise.

Defining review scope and population

The review scope must be defined in the ISMS documentation. It must specify which systems are in scope, which user categories are included, the review cadence for each user category, and which reviewer roles are responsible for each system or user category.

For practical implementation, the review population should be segmented by risk level. Users with privileged access to critical systems require more frequent reviews than standard users with routine application access. A quarterly review for privileged access and an annual review for standard access is a common segmentation that balances thoroughness with operational workload.

Automated review campaign workflow

A manual review process where IT sends a spreadsheet to managers and collects responses does not produce the structured, timestamped evidence A.5.18 requires. An automated review campaign workflow sends structured certification requests to each reviewer, captures responses with timestamps, routes revocation decisions to automated deprovisioning workflows, and produces a complete campaign record linking every decision to the corresponding access change.

The automation requirement is not explicit in A.5.18, but the evidence quality standard that auditors apply in practice is difficult to achieve without automation at scale. An insurance company with 5,000 employees and 50 connected systems cannot produce per-entitlement, per-reviewer, timestamped evidence from a manual spreadsheet process.

Integrating event-triggered reviews

Event-triggered reviews for role changes and departures must be integrated with the regular interval review process, not managed as a separate workflow. When a user changes roles, the event-triggered review should operate through the same review campaign infrastructure as the regular interval review, producing the same evidence format. This ensures that the evidence from event-triggered reviews is comparable to and searchable alongside the evidence from regular cycle reviews.

How Akku Implements A.5.18 Access Review Campaigns

Akku’s IGA access review and re-certification campaign capability implements A.5.18 through a structured workflow that produces continuous, auditor-ready evidence throughout the certification period.

Campaign configuration

Review campaigns are configured with scope, cadence, reviewer assignments, and escalation rules. Scope defines which systems and user populations are included. Cadence defines when the campaign runs: quarterly, semi-annually, or annually per user category. Reviewer assignments map each entitlement to the appropriate reviewer: manager for role-based access, system owner for sensitive system access. Escalation rules define what happens when a reviewer does not respond within the defined period.

Review request and decision capture

When a campaign runs, Akku sends structured certification requests to each reviewer covering every entitlement in their review scope. Each request presents the user identity, the system, the access level, and the last authentication date. The reviewer makes a certify or revoke decision for each entitlement. Every decision is captured with reviewer identity and timestamp at the time of submission.

Automated deprovisioning for revocations

Revocation decisions automatically trigger deprovisioning workflows. Access is removed from the relevant system through SCIM or direct integration, and a deprovisioning record is generated and linked to the review decision record. The evidence chain from review decision to access removal is complete and auditable without manual follow-up.

Campaign evidence record

Each completed campaign produces a structured evidence record covering campaign scope, run date, reviewer assignments, every decision made with reviewer identity and timestamp, and deprovisioning records for all revocations. This record is stored in Akku’s append-only audit log and is available for auditor examination at any time.

Akku’s ISO 27001 mapping shows Identity and Access Governance addresses 16 clause references including Clauses 8.1, 8.1.a, 8.1.c, 8.1.d, 9.1, 9.1.c, A.8.1, A.8.2, A.8.4, A.9.4, A.9.6, A.11.5, A.15.3, A.16.3, A.16.6, and A.19.4, the highest single-module count in Akku’s ISO 27001 mapping. This reflects the centrality of access governance and review processes to ISO 27001 certification.

What ISO 27001 Certification Auditors Examine for A.5.18

Understanding what auditors examine helps organisations assess whether their current review process produces evidence that will satisfy certification.

Sampling approach

Auditors select a sample of review cycles from across the certification period. For a 12-month certification period with quarterly reviews, they may sample two or three cycles. For each sampled cycle, they examine the campaign record in detail: scope, reviewer identities, decision timestamps, and deprovisioning records for revocations.

They also select a sample of individual users and trace their access history across the sampled review cycles. For a user who changed roles during the period, they verify that an event-triggered review was conducted and that access from the previous role was appropriately revoked.

Evidence quality assessment

Auditors assess whether the evidence shows genuine reviewer engagement with the entitlements being reviewed. A review where every decision is certify with timestamps clustered in a two-minute window suggests that the reviewer approved a list without examining it. A review where decisions are spread across a realistic timeframe, with a mix of certify and revoke decisions and some revocations for identifiable reasons, demonstrates genuine engagement.

Nonconformity triggers

Common A.5.18 nonconformities include: no evidence of reviews during part of the certification period, reviews with no corresponding deprovisioning records for revocations, reviews with no reviewer identity captured, informal evidence such as email threads rather than structured records, and event-triggered reviews not conducted for documented role changes or departures.

Diagnostic Questions

How many access review cycles has your organisation completed in the last 12 months, and is there a structured evidence record for each cycle showing reviewer identities, decision timestamps, and deprovisioning records for revocations?

For a sample of users who changed roles in the last 12 months, is there an event-triggered access review record showing that entitlements from the previous role were reviewed and that inappropriate access was revoked?

Does your review process capture a certify or revoke decision per entitlement per reviewer with a timestamp, or does it produce a bulk acknowledgment that the list was reviewed without per-entitlement decisions?

For revocations made in the last access review cycle, is there a corresponding deprovisioning record for each revocation showing that access was actually removed, from which system, and at what time?

Can your review process scale to cover all users with access to all in-scope systems within a single review cycle, or does the manual workload limit review coverage to a subset of the full user population?

CTAs

See how Akku’s IGA access review campaigns address ISO 27001 A.5.18 requirements with structured evidence, automated deprovisioning, and continuous certification period coverage.

Book a conversation with the Akku team to assess your current access review process against ISO 27001 A.5.18 certification requirements.

FAQs

How frequently must access reviews run to satisfy ISO 27001 A.5.18’s regular intervals requirement?

ISO 27001:2022 A.5.18 does not specify a minimum review frequency. The standard requires reviews at regular intervals and when employment or contractual changes occur. In practice, certification auditors consider quarterly reviews as demonstrating a robust periodic control. Annual reviews are generally accepted as the minimum, though a single annual review produces limited operating effectiveness evidence for auditors sampling across the certification period. Organisations with users holding access to high-sensitivity systems typically run quarterly reviews for those user populations and annual reviews for standard access, balancing thoroughness with operational workload.

What makes access review evidence structured rather than informal for A.5.18 purposes?

Structured access review evidence contains: a defined review scope showing which systems and users were included, reviewer identities for each entitlement reviewed, a certify or revoke decision per entitlement with a timestamp, and deprovisioning records for all revocations. Informal evidence including email threads where managers acknowledged a list, spreadsheet trackers with no timestamps, and verbal confirmations with no documentary record does not constitute structured evidence. The key distinguishing features are per-entitlement decisions with reviewer identity and timestamp, and a demonstrable link between revocation decisions and actual access removal.

Does A.5.18 require that every access right be reviewed in every cycle, or can reviews be risk-based?

A.5.18 requires that access rights be reviewed at regular intervals. A risk-based approach that reviews high-sensitivity access more frequently and standard access less frequently is consistent with the standard, provided the review cadence for each category is defined and consistently applied. What is not consistent with A.5.18 is reviewing only a subset of users within each cycle while deferring others to future cycles indefinitely. Every user must be included in at least one complete review cycle per defined interval.

What happens during an ISO 27001 certification audit if A.5.18 review records have gaps for part of the certification period?

Gaps in A.5.18 review records for part of the certification period will typically result in a nonconformity. If the certification audit covers a 12-month period and review records only exist for the last three months, the auditor cannot sample from the full period and will note the absence of evidence as a gap in operating effectiveness. The severity of the nonconformity depends on the extent of the gap. A minor gap may result in a minor nonconformity with a corrective action requirement. A systematic absence of reviews for most of the period may result in a major nonconformity that prevents certification or requires a follow-up audit.

How does A.5.18 interact with A.5.16 identity management and A.5.17 authentication information?

A.5.16 covers the identity management process: creation, maintenance, and deletion of identities. A.5.17 covers the management of authentication information including credentials. A.5.18 covers the periodic review of the access rights those identities hold. Together, the three controls address the full access lifecycle: A.5.16 governs how identities are created and removed, A.5.17 governs how credentials are managed, and A.5.18 governs how the access entitlements tied to those identities are kept current and appropriate. All three require structured evidence for certification, and gaps in any one of them will be identified during the access controls portion of the certification audit.

Can access review evidence from Akku be used for both ISO 27001 A.5.18 and SOC 2 CC6.3 certification simultaneously?

Yes. ISO 27001 A.5.18 and SOC 2 CC6.3 both require periodic review of access rights with documented outcomes. The access review campaign records generated by Akku’s IGA module contain reviewer identities, decision timestamps, entitlement scope, and deprovisioning records for revocations. This evidence satisfies both A.5.18’s structured evidence requirement and CC6.3’s system of record for entitlements requirement. Organisations pursuing both certifications simultaneously can run a single review campaign cadence and use the same evidence records for both audit processes, reducing the duplication of effort that separate compliance programmes create.

Introduction

SOC 2 Trust Services Criteria CC5.1 requires that the entity selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels. Segregation of duties is the primary control activity CC5.1 addresses for access governance. The criterion requires that incompatible functions be separated so that no single individual can both initiate and approve a transaction, both create and release a payment, or both provision and certify their own access.

Most organisations have a segregation of duties policy. The policy states that incompatible functions must be separated and lists examples of conflicting role combinations. SOC 2 auditors examine CC5.1 by asking whether SoD is technically enforced, not whether it is policy-described. A policy stating that the accounts payable function must be separated from the payment approval function does not prevent a user from holding both roles if the IAM platform has no mechanism for detecting and preventing conflicting role assignments.

Technical SoD enforcement means that the IAM platform defines conflicting role combinations as rules, detects violations when they occur, prevents them where possible at the provisioning layer, and remediates existing violations through a structured workflow. Evidence of technical enforcement is what CC5.1 auditors expect. Evidence of SoD policy documentation is a prerequisite, not a substitute.

This blog covers what CC5.1 requires for SoD, the difference between policy-stated and technically-enforced SoD, how a SoD rules engine operates, and what evidence the control produces.

What CC5.1 Requires for Segregation of Duties

CC5.1 sits within the COSO Control Activities principle and covers the selection and development of control activities that mitigate risk. For access governance, SoD is the primary risk mitigation control activity that CC5.1 addresses.

The risk SoD addresses

SoD mitigates two categories of risk. Fraud risk: when incompatible functions are combined in a single individual, that individual can execute and conceal fraudulent transactions without requiring a second party. Error risk: when a single individual controls an end-to-end process, errors can occur and persist without detection because no independent party reviews the work.

For capital markets entities, financial services firms, and ITeS companies processing financial transactions, SoD violations in payment processing, financial reporting, and access provisioning create direct fraud exposure. For technology companies processing client data, SoD violations in access provisioning, where the same administrator both provisions access and certifies access reviews, undermine the independence of the review process.

What CC5.1 expects technically

CC5.1 expects that SoD is implemented as a technical control, not only documented as a policy. The control activity must demonstrate operating effectiveness throughout the audit period. A technical SoD control that detects and remediates violations continuously produces continuous operating evidence. A policy document that states SoD is required produces no operating evidence.

The control activity must cover the full population of users across all in-scope systems throughout the audit period. SoD violations that occurred during the audit period and were not detected or remediated are findings against CC5.1 operating effectiveness, regardless of whether the SoD policy existed.

Policy-Stated SoD vs Technically-Enforced SoD

The distinction between policy-stated and technically-enforced SoD is what determines whether CC5.1 is satisfied.

What policy-stated SoD looks like

A policy-stated SoD posture consists of a documented list of conflicting role combinations, a policy statement requiring that users not hold conflicting roles, and a manual review process where an administrator periodically checks whether any users hold combinations on the conflict list. The review is typically conducted quarterly or annually, and violations found are remediated by removing one of the conflicting roles.

The problems with this approach for CC5.1 purposes are multiple. Violations that occur between review cycles are undetected and unremediated for weeks or months. New role assignments that create violations are not blocked at provisioning time. The evidence produced is a periodic review record rather than a continuous detection record. Auditors sampling CC5.1 evidence from across the audit period will find gaps between review cycles where the control was not actively operating.

What technically-enforced SoD looks like

A technically-enforced SoD posture consists of a rules engine that defines conflicting role combinations as machine-readable rules, continuous detection that evaluates every role assignment against the rules in real time, prevention controls that block provisioning of access that would create a violation, and remediation workflows that address detected violations through a structured approval and removal process.

The evidence produced by technical enforcement is continuous: every detection event, every prevention action, and every remediation decision is logged with a timestamp. Auditors examining CC5.1 from any point in the audit period find active detection and remediation evidence rather than gaps between periodic review cycles.

How a SoD Rules Engine Operates

Akku’s IGA SoD rules engine implements technical SoD enforcement through four components: rule definition, continuous detection, provisioning prevention, and remediation workflow.

Rule definition

SoD rules define conflicting role combinations at the IAM platform level. A rule specifies two or more roles that must not be held simultaneously by the same user. Rules can be defined at the role level, for example accounts payable manager and payment approver, or at the permission level, for example create payment and approve payment across different applications.

Rules must cover all in-scope applications and all identified conflict categories. An effective SoD rule set is derived from the organisation’s risk assessment and covers the conflict categories that represent the highest fraud and error risk. For ITeS companies, common conflict categories include access provisioning and access certification, financial transaction initiation and approval, and system change implementation and change approval.

Continuous detection

The rules engine evaluates every user’s current role set against the defined conflict rules continuously. When a role assignment creates a violation, the detection event is logged immediately with the user identity, the conflicting roles, and the detection timestamp. Detection is not periodic: it occurs as role assignments are made and as rules are updated, not at a scheduled review interval.

For existing violations that predate rule definition, the initial rule activation triggers a detection pass across all current user role assignments, surfacing all existing violations for remediation.

Provisioning prevention

Where the rules engine is integrated with the provisioning workflow, a provisioning request that would create a SoD violation can be blocked at the approval stage. The approver receives a notification that the requested access would create a conflict with an existing role, and the request requires explicit override justification or role removal before it can proceed.

Prevention controls are the strongest form of SoD enforcement because they prevent violations from occurring rather than detecting and remediating them after the fact. For the most critical conflict categories, prevention is preferable to detection and remediation.

Remediation workflow

Detected violations that are not prevented at provisioning trigger a remediation workflow. The workflow notifies the user’s manager and the system owner of the violation, requests a decision on which role to retain and which to remove, and captures the decision with approver identity and timestamp. The remediation decision triggers automatic role removal through the same provisioning infrastructure used for standard access changes.

The remediation record, including detection timestamp, notification, decision, and removal confirmation, is the complete evidence chain that CC5.1 auditors examine for each violation detected during the audit period.

What CC5.1 Auditors Examine for SoD

Understanding the CC5.1 audit examination approach helps organisations assess whether their SoD controls will satisfy the criterion.

Evidence of technical enforcement

Auditors examine whether SoD is technically enforced or policy-stated. They request evidence of the rules engine configuration, showing which conflict rules are defined and which systems are in scope. They review detection logs, verifying that violations were detected continuously throughout the audit period rather than only at periodic review points. They examine prevention records for any provisioning requests that were blocked due to SoD conflicts.

Violation and remediation records

Auditors sample violations detected during the audit period and trace each from detection through remediation. They verify that every violation was addressed through a structured remediation process with a documented decision and that access removal followed the remediation decision. Violations detected but not remediated within a reasonable timeframe are evidence of control weakness.

Coverage completeness

Auditors assess whether the SoD rules cover the conflict categories that represent material risk for the entity. An organisation that has defined SoD rules for financial functions but has no SoD controls for access provisioning, where the same administrator both provisions and certifies their own access, has incomplete SoD coverage.

SoD Requirements Across Other Compliance Frameworks

SoD requirements are not unique to SOC 2. Multiple frameworks covered in this series require SoD enforcement, and the same technical control satisfies all of them.

RBI Clause 9(b) requires effective segregation of duties in IT operations and application development environments. SEBI CSCRF Identity and Access Governance guidelines PR.AA.S3 and PR.AA.S5 require that access be provisioned based on formally defined roles with conflict prevention. ISO 27001:2022 A.5.3 requires segregation of duties. DPDPA Clause 8(4) requires appropriate technical measures to ensure processing is limited to authorised purposes, which SoD enforcement implements at the access layer.

The same IGA SoD rules engine that satisfies SOC 2 CC5.1 simultaneously satisfies RBI Clause 9(b), SEBI CSCRF access control requirements, and ISO 27001 A.5.3 from one technical control. Akku’s SOC 2 mapping shows Identity and Access Governance addresses CC5.1, CC6.2, and CC6.3 across three mapping points.

Diagnostic Questions

Does your organisation have a technically-enforced SoD rules engine that detects conflicts continuously, or does SoD management rely on periodic manual reviews of role assignments against a conflict list?

For any SoD violation detected in the last 12 months, is there a complete evidence chain covering detection timestamp, remediation notification, decision record, and access removal confirmation?

Does your SoD rules engine cover all in-scope applications in a single platform, or do conflict rules exist only for some systems while others are outside the SoD enforcement scope?

When a provisioning request would create a SoD violation, is the request flagged or blocked at the approval stage, or does the violation only become apparent after access has been granted?

Has your organisation defined SoD rules for access provisioning functions as well as business process functions, ensuring that administrators cannot both provision and certify their own access?

CTAs

See how Akku’s IGA SoD rules engine addresses SOC 2 CC5.1 requirements through continuous detection, provisioning prevention, and structured remediation workflows.

Book a conversation with the Akku team to assess your current SoD posture against SOC 2 CC5.1 technical enforcement requirements.

FAQs

What is the difference between CC5.1 and CC6.3 for SoD purposes in a SOC 2 engagement?

CC5.1 covers the selection and development of control activities that mitigate risk, including SoD as a risk mitigation activity. It is the criterion that requires SoD to exist as a control. CC6.3 covers the authorisation, modification, and removal of access rights based on the system of record for entitlements. It is the criterion that requires access changes to be governed through a defined process. SoD enforcement under CC5.1 defines which role combinations are prohibited. Access governance under CC6.3 ensures that role changes and access requests follow a governed approval process. Both are required and they address different layers of the access governance framework.

Does SOC 2 CC5.1 require that SoD be technically enforced, or is a policy-stated SoD posture sufficient?

SOC 2 auditors assess CC5.1 as a control activity criterion, meaning they evaluate whether the control operates effectively throughout the audit period. A policy-stated SoD posture produces evidence of policy existence but not of continuous control operation. Auditors examining CC5.1 from across a 12-month audit period will find that a policy document existed but cannot find evidence of active detection and remediation throughout the period. Technical enforcement produces continuous detection and remediation evidence that satisfies the operating effectiveness standard. Policy documentation is a prerequisite for technical enforcement, not a substitute for it.

How should organisations prioritise which SoD conflict rules to define first?

SoD rule prioritisation should be based on risk assessment. The highest-priority conflict rules cover functions where a single individual having both capabilities creates direct fraud or material error risk. For financial services entities, payment initiation and approval is typically the first priority. For technology companies, access provisioning and access certification is a common high-priority conflict. For all entities, system change implementation and change approval creates a quality control risk. The rule set should expand over time to cover lower-priority conflicts as the programme matures.

What remediation timeline is considered acceptable for SoD violations under SOC 2 CC5.1?

SOC 2 does not specify a defined remediation timeline for SoD violations. Auditors assess whether violations were remediated within a reasonable period given the risk they represent. For high-risk conflicts such as payment initiation and approval, same-day or next-day remediation is expected. For lower-risk conflicts, remediation within the current review cycle is typically acceptable. Violations that persist unremediated for weeks or months without documented justification are evidence of control weakness. A compensating control, such as enhanced monitoring of transactions by users with unresolved violations, can partially mitigate the risk while remediation is pending.

Can the same SoD rules engine satisfy both SOC 2 CC5.1 and RBI Clause 9(b) simultaneously?

Yes. SOC 2 CC5.1 and RBI Clause 9(b) both require effective segregation of duties as a technical control. The same IGA SoD rules engine that detects conflicts continuously, prevents conflicting provisioning requests, and generates remediation workflows produces compliance evidence for both frameworks from the same technical control. The evidence record format, detection logs, prevention records, and remediation decision records, satisfies both auditors examining CC5.1 and RBI IS auditors examining Clause 9(b). Organisations subject to both frameworks do not need separate SoD controls, only a single rules engine with rules covering both frameworks’ identified conflict categories.

What is the relationship between SoD enforcement and access reviews, and do they address different risks?

SoD enforcement and access reviews address different categories of access risk and are both required for complete access governance. SoD enforcement addresses the risk that a single user holds two roles that, combined, enable fraud or material error without detection. It focuses on the combination of roles rather than the appropriateness of individual roles. Access reviews address the risk that a user holds roles that were appropriate at some point but are no longer appropriate for their current function. They focus on whether each individual role remains justified. An organisation with strong SoD enforcement but no access reviews will prevent conflicting role combinations but will not detect over-provisioning or entitlement drift. Both controls are required for a complete access governance framework.

Introduction

SEBI CSCRF applies to all regulated entities but differentiates requirements by entity tier. Market Infrastructure Institutions face the highest requirements. Qualified Regulated Entities, defined by thresholds including trading volume, assets under management, number of clients, and systemic importance, face enhanced requirements above the baseline that apply to Mid-size and Small REs. Understanding which tier your organisation falls into and what the enhanced requirements mean technically is the starting point for a compliant CSCRF implementation.

Most capital markets entities approaching SEBI CSCRF compliance focus on the baseline requirements that apply across all tiers. The Qualified RE tier, which covers the largest brokers, fund managers, and infrastructure participants in Indian capital markets, faces additional requirements in specific sub-categories that are frequently underestimated during initial compliance planning.

The enhanced requirements for Qualified REs are not fundamentally different controls from the baseline. They are the same control categories, identity management, access governance, privileged access, monitoring, and audit evidence, applied with greater depth, more frequent review cycles, and more granular evidence requirements. The difference is in the operating effectiveness standard: a Qualified RE with quarterly access reviews and annual privileged access certifications satisfies the enhanced standard. A Mid-size RE with annual reviews for both satisfies the baseline.

This blog covers what the Qualified RE tier designation means, which CSCRF sub-categories have enhanced requirements for this tier, and what those enhanced requirements mean technically for IAM implementation.

Understanding the Qualified RE Tier

SEBI CSCRF classifies regulated entities into tiers based on systemic importance and operational scale. The classification determines which guideline levels within each sub-category apply to the entity.

Tier classification criteria

The Qualified RE designation applies to entities that exceed defined thresholds across metrics including: average daily turnover for brokers, assets under management for fund managers, number of active clients, and the entity’s role in settlement or clearing infrastructure. Entities that exceed these thresholds are subject to enhanced requirements in addition to the baseline requirements that apply to all tiers.

Market Infrastructure Institutions, covering stock exchanges, clearing corporations, and depositories, face the highest requirements across all sub-categories. Qualified REs face the next level. Mid-size and Small REs face the baseline requirements.

Self-assessment obligation

SEBI CSCRF requires that each regulated entity assess its tier classification and implement the corresponding requirements. The self-assessment is not a one-time exercise: entities whose scale changes over time must reassess their tier classification periodically and update their implementation accordingly.

For Qualified REs, the tier designation creates a compliance programme that is more demanding than the baseline in specific, identifiable areas. Planning and resourcing the programme requires understanding which areas have enhanced requirements and what they add beyond the baseline.

Enhanced Identity Management Requirements for Qualified REs

PR.AA.S1 identity management requirements have enhanced guideline levels for Qualified REs that go beyond the baseline lifecycle management controls.

Enhanced user registration and authorisation

For Qualified REs, PR.AA.S1’s enhanced guidelines require more formal role definition processes, more granular access provisioning controls, and more frequent review of access entitlements for high-risk user categories.

The baseline PR.AA.S1 requirements cover unique user identification, lifecycle management, and dormant account controls. The Qualified RE enhanced requirements add: formalised role matrices documenting which roles are authorised for which system access, structured access provisioning workflows with multi-step approval for high-sensitivity access, and more frequent access reviews for users with access to trading systems and client data.

Enhanced access governance

Identity and Access Governance requirements for Qualified REs include more comprehensive SoD rule sets covering capital markets-specific conflict categories. The baseline SoD requirements prevent generic conflicting role combinations. The enhanced requirements for Qualified REs specifically address capital markets conflicts: front-office trading access combined with back-office settlement authority, client account management combined with fund transfer authorisation, and compliance oversight combined with the activities being overseen.

For Qualified RE fund managers and brokers, the capital markets SoD rule set is more specific and more extensive than a generic SoD implementation. The rules engine must define and enforce the specific conflict combinations that create fraud and manipulation risk in capital markets operations.

How Akku addresses enhanced identity requirements

Akku’s IGA module supports configurable SoD rule sets that can be extended to cover capital markets-specific conflict categories. The role matrix documentation, multi-step approval workflows for sensitive access, and configurable review cadences per user population satisfy the enhanced Qualified RE identity management requirements.

Enhanced Privileged Access Requirements for Qualified REs

The privileged access requirements for Qualified REs under PR.AA.S10 through S12 are more detailed than the baseline, reflecting the higher systemic risk of privileged access at large capital markets entities.

Enhanced session governance

For Qualified REs, the enhanced PR.AA.S11 requirements add: more detailed session request justifications specifying the specific operational task to be performed, shorter maximum JIT session durations for access to trading and settlement infrastructure, more frequent approval workflow reviews to ensure approvers are current and appropriate, and real-time monitoring requirements with defined response timelines for anomalous session activity.

The session duration limits for Qualified RE access to critical trading infrastructure are typically shorter than for general privileged access: a two-hour maximum session for production trading system access rather than an eight-hour working day session. The shorter duration limits reduce the blast radius of a compromised or misused privileged session.

Enhanced session recording requirements

For Qualified REs, session recording coverage requirements extend to all access paths to systems classified as critical, not only SSH and database sessions. Web application sessions to trading platforms, order management systems, and client portals require session recording at the activity level.

The forensic search capability for Qualified RE session recordings must support more granular queries: not only searching by command string or SQL query text but by specific action types, such as order submission, account modification, or configuration change, across the session recording history.

Enhanced privileged access review cadence

For Qualified REs, privileged access review campaigns must run at a higher frequency than the baseline. Quarterly reviews for all privileged entitlements, with monthly reviews for the highest-risk privileged accounts covering trading system administration, is the enhanced standard that SEBI examinations at Qualified REs assess.

Enhanced Monitoring Requirements for Qualified REs

DE.CM continuous monitoring requirements have enhanced specifications for Qualified REs that require more sensitive detection thresholds and shorter response timelines.

Enhanced authentication anomaly detection

For Qualified REs, PR.AA.S7’s proportionality requirement applies with greater specificity. Trading platform access requires the highest authentication assurance in the entity’s environment. Anomaly detection thresholds for authentication events to trading systems must be more sensitive than for other systems: geographic anomalies, new device access, and time-of-day deviations should trigger step-up challenges at lower deviation levels for trading platform access than for lower-sensitivity systems.

The response timeline for authentication anomaly alerts is also enhanced for Qualified REs. Where baseline entities may have a 24-hour investigation SLA for anomaly alerts, Qualified REs should have a same-day investigation SLA for alerts involving trading system access.

Enhanced on-demand log access

GV.OC.S2(G3)’s on-demand log access requirement for Qualified REs requires faster response times and more granular log coverage than the baseline. Where a baseline entity might satisfy the requirement with a structured log export producible within two business days, a Qualified RE examination request may require a response within a single business day for the most critical log categories.

The log granularity for Qualified REs must extend to trading activity logs where these are captured through the IAM infrastructure: order submission events, account access events, and configuration change events must be queryable alongside authentication and session records in the centralised audit trail.

How Akku addresses enhanced monitoring requirements

Akku’s Adaptive MFA supports configurable anomaly detection thresholds per application or system category. Trading platform access can be configured with more sensitive thresholds than internal administrative systems. The centralised audit trail with structured JSON and CSV export satisfies the on-demand access requirement across all log categories within the IAM infrastructure’s scope.

Enhanced Audit Evidence Requirements for Qualified REs

SEBI CSCRF examination practice at Qualified REs reflects the higher systemic importance of these entities. Examinations are more thorough, sample larger populations, and assess operating effectiveness over longer periods than examinations at smaller entities.

Longer evidence retention

For Qualified REs, the implicit evidence retention expectation for SEBI examination purposes extends to two years for authentication event logs and three years for privileged session recordings covering trading system access. These extended retention periods reflect the higher regulatory scrutiny and the longer investigation timelines that market integrity incidents may require.

More comprehensive sampling

SEBI examinations at Qualified REs sample larger populations from longer periods. Where a baseline examination might sample 10 provisioning events from the last six months, a Qualified RE examination might sample 25 events from the last 12 months. The evidence infrastructure must be capable of producing complete, structured records for any sampled event without gaps.

Real-time evidence availability

For Qualified REs, the on-demand evidence production standard implies faster response than the baseline. Evidence requests for specific sessions, specific users, or specific time windows should be producible within the same business day rather than within two business days. The infrastructure must support ad-hoc queries across the full retention window without pre-preparation.

Assessing Your Tier and Planning Your Implementation

The Qualified RE tier classification creates a compliance programme that requires explicit planning beyond the baseline CSCRF implementation.

Tier assessment

The first step is confirming whether your entity meets the Qualified RE thresholds. The thresholds cover trading volume, client count, and AUM. Entities near the threshold should assess conservatively: an entity that might qualify in a high-volume quarter should plan for Qualified RE requirements rather than assuming baseline requirements will apply.

Gap assessment against enhanced requirements

For entities that are or may be Qualified REs, the gap assessment must specifically address the enhanced requirements in PR.AA, DE.CM, and GV.OC. The gap assessment should identify: current review cadences versus enhanced cadence requirements, current session governance depth versus enhanced session requirements, current monitoring sensitivity versus enhanced threshold requirements, and current log retention versus enhanced retention expectations.

Implementation prioritisation

The highest-priority enhanced requirements for Qualified REs are typically: shorter JIT session durations for trading system access, more sensitive anomaly detection thresholds for trading platform authentication, quarterly privileged access review cycles, and extended log retention for trading system sessions. These address the highest-risk access scenarios in the capital markets context and are most likely to be the focus of SEBI examination scrutiny.

Diagnostic Questions

Has your organisation formally assessed whether it meets the Qualified RE thresholds under SEBI CSCRF, and has the assessment been documented and reviewed in the last 12 months?

For privileged access to trading systems and settlement infrastructure, are JIT session durations configured with the shorter limits appropriate for Qualified RE requirements, or do they use the same limits as general privileged access?

Does your anomaly detection configuration apply more sensitive thresholds for authentication events to trading platforms than for lower-sensitivity internal applications, and is there a documented threshold configuration for each system tier?

Are privileged access reviews for trading system administrators running on a quarterly cadence with documented evidence from each cycle, or on an annual cadence that satisfies only the baseline requirement?

Does your evidence retention for trading system session recordings extend to the enhanced period appropriate for Qualified RE examination scrutiny, and can you produce any session recording from within that retention window on the same business day of a SEBI request?

CTAs

See how Akku addresses SEBI CSCRF Qualified RE requirements across enhanced identity governance, privileged access controls, monitoring, and audit evidence for capital markets entities.

Book a conversation with the Akku team to assess your current implementation against SEBI CSCRF requirements for your entity tier.

FAQs

How does a capital markets entity determine whether it qualifies as a Qualified RE under SEBI CSCRF?

The Qualified RE classification is based on thresholds covering trading volume, assets under management, number of active clients, and systemic importance. The specific threshold values are defined in the SEBI CSCRF framework document. Entities should assess their metrics against these thresholds across the most recent period and classify conservatively where they are near the threshold. SEBI may also designate specific entities as Qualified REs based on their systemic role in settlement or clearing infrastructure regardless of volume thresholds. Entities uncertain about their classification should seek guidance from their SEBI compliance function or seek clarification directly from SEBI.

What are the most significant practical differences between Mid-size RE and Qualified RE compliance requirements?

The most significant practical differences are in review cadence, session governance depth, and monitoring sensitivity. Qualified REs must run access reviews more frequently, typically quarterly rather than annually, for users with access to critical trading infrastructure. Session durations for privileged trading system access must be shorter. Anomaly detection thresholds must be more sensitive for trading platform authentication. Log retention periods are longer. Evidence production must be faster in response to examination requests. The underlying controls are the same, but the operating depth and evidence density required are materially higher.

Does a broker that was a Mid-size RE in previous years automatically become a Qualified RE if its trading volume exceeds the threshold in the current year?

Yes. The tier classification is based on current metrics, not historical status. An entity that exceeds the Qualified RE thresholds must implement the enhanced requirements applicable to that tier. The transition from Mid-size to Qualified RE creates a compliance programme gap that must be closed: the enhanced access review cadences, session governance requirements, and monitoring configurations must be implemented, and the evidence infrastructure must begin generating enhanced evidence from the point of classification change. There is no automatic grace period, though SEBI may provide implementation timelines for entities newly crossing the threshold.

Can Akku’s platform be configured differently for Qualified RE versus Mid-size RE requirements, or does it apply the same configuration to all entities?

Akku’s platform is fully configurable to the requirements of each entity tier. JIT session duration limits can be configured per application or system category, allowing shorter limits for trading system access and standard limits for lower-sensitivity systems. Anomaly detection thresholds are configurable per application, supporting more sensitive thresholds for trading platform authentication. Access review campaign cadences are configurable per user population, supporting quarterly campaigns for privileged users and annual campaigns for standard users simultaneously. Log retention periods are configurable to meet the extended requirements appropriate for Qualified RE examination scrutiny.

How does the Qualified RE enhanced requirement for capital markets SoD rules differ from a standard SoD implementation?

A standard SoD implementation prevents generic conflicting role combinations: access provisioning and access certification, payment initiation and payment approval, system change implementation and change approval. Capital markets SoD for Qualified REs requires an additional layer of capital markets-specific conflict rules: front-office trading access combined with back-office settlement authority, client account management combined with fund transfer authorisation, market surveillance access combined with trading desk access, and compliance monitoring combined with the trading activities being monitored. These conflict combinations create specific manipulation and insider dealing risks that are particular to capital markets operations and require rules tailored to the entity’s operational structure.

What evidence should a Qualified RE be able to produce for a SEBI examination of their enhanced privileged access controls?

A SEBI examination of Qualified RE privileged access controls typically covers: session request and approval records for all privileged trading system sessions in the examination period, showing the specific operational justification for each session. Session recordings for sampled sessions showing activity at the keystroke or query level. JIT session duration records showing that sessions terminated at the configured limit or earlier. Quarterly privileged access review records covering all privileged trading system entitlements with timestamped certification or revocation decisions. Real-time monitoring capability demonstration showing live session visibility and termination capability. Authentication anomaly alert records for the examination period with investigation documentation.

Introduction

SEBI CSCRF PR.AA.S1(G1g) and PR.AA.S1(G1h) require that user accounts inactive beyond a defined threshold be automatically disabled and that departed users’ accounts be removed promptly. These are the access hygiene requirements within the broader PR.AA identity management sub-category, and they are consistently among the findings in SEBI CSCRF examinations at capital markets entities.

Dormant accounts accumulate for predictable reasons. Employees leave without a formal IT deprovisioning trigger. Contractors’ engagements end with access removal overlooked in the offboarding process. Accounts created for specific projects persist after the projects conclude. Service accounts outlive the services they were created for. Each of these creates an account that exists without an active, legitimate owner, holds valid credentials, and represents an attack surface that grows invisibly over time.

The access hygiene framing in SEBI CSCRF is deliberate. Access hygiene is not a one-time cleanup exercise. It is a continuous operational discipline: accounts are monitored for inactivity, disabled when they cross the threshold, removed when the owner relationship is confirmed gone, and reviewed periodically to prevent silent accumulation. The automatic requirement in PR.AA.S1(G1g) means this discipline must be technically enforced, not manually managed through periodic reviews.

This blog covers what PR.AA.S1(G1g) and G1h specifically require, how dormant accounts accumulate and why manual controls fail to address them reliably, and how automated dormant account management satisfies the SEBI CSCRF access hygiene standard.

What PR.AA.S1(G1g) and G1h Require

PR.AA.S1 covers identity management and user registration requirements under SEBI CSCRF. G1g and G1h are the specific guidelines addressing account lifecycle at the inactive and departed user layer.

PR.AA.S1(G1g): Automatic disabling of inactive accounts

G1g requires that user accounts inactive beyond a defined threshold be automatically disabled. The automatic requirement is not satisfied by a process where a system produces a report of inactive accounts that an administrator then reviews and manually disables. The disabling must occur through an automated technical control triggered by the inactivity threshold being crossed.

The inactivity threshold must be defined and configured in the identity management platform. The platform must monitor last authentication timestamps for all user accounts continuously and trigger the disabling action when the threshold is crossed without requiring administrator initiation.

The disabling event must generate a timestamped audit record. For SEBI examination purposes, the audit record demonstrates that the automated control operated, that the threshold was crossed, and that disabling occurred at the appropriate time.

PR.AA.S1(G1h): Prompt removal of departed user accounts

G1h requires that accounts belonging to users who have left the organisation be removed promptly. Promptly implies a short timeframe: SEBI examination practice treats same-day or next-day removal as compliant for employment terminations. Accounts that persist for days or weeks after departure are findings.

Prompt removal requires an automated deprovisioning workflow triggered by the HR system event recording the departure. Manual deprovisioning that depends on an IT ticket being raised after the HR event creates a gap between the departure event and the access removal. For high-risk environments such as capital markets entities, this gap represents meaningful exposure.

Removal under G1h differs from disabling under G1g. G1g disabling is a reversible action taken when an account crosses an inactivity threshold, pending investigation of whether the account should be retained or removed. G1h removal is a definitive action taken when the user’s departure is confirmed, removing the account entirely from the access infrastructure.

How Dormant Accounts Accumulate

Understanding how dormant accounts accumulate is necessary for designing controls that prevent accumulation rather than periodically cleaning it up.

Incomplete offboarding processes

The most common source of dormant accounts is incomplete offboarding. When an employee leaves, the HR system records the departure and initiates the payroll and benefits offboarding. IT offboarding, which should include access revocation across all connected systems, may not be triggered automatically from the HR event. If IT offboarding requires a separate ticket or notification from the line manager, and that notification is delayed or overlooked, the employee’s accounts persist.

At scale, the gap between HR departure records and IT access revocation produces a consistent backlog of accounts belonging to departed employees. Monthly or quarterly access reviews surface these gaps retrospectively. G1h’s prompt removal requirement means they must be addressed at the time of departure.

Contractor and third-party access

Contractor access is particularly prone to dormant account accumulation because contractor departures are less formally managed than permanent employee departures. When a contractor’s statement of work ends, the contractor stops attending but the IT offboarding trigger may not exist. Without a formal engagement end trigger in the identity management platform, the contractor’s accounts persist indefinitely.

Service provider and vendor accounts created for specific integrations or support access face the same issue. The initial access provisioning may follow a formal process, but the deprovisioning trigger when the relationship ends is often absent.

Project and temporary access

Access granted for specific projects, system migrations, or temporary cross-functional assignments may not have defined expiry dates. When the project concludes, the temporary access persists because there is no technical expiry mechanism and no deprovisioning trigger in the lifecycle management workflow.

Service account proliferation

Service accounts created for application integrations, automated processes, and system-to-system communications accumulate over time as applications are upgraded or replaced. The old service account may remain active after the integration is replaced with a newer version, holding credentials and potentially access to systems it no longer needs to reach.

Why Periodic Manual Reviews Do Not Satisfy G1g’s Automation Requirement

G1g’s automatic requirement is specific. A quarterly dormant account review that identifies inactive accounts and queues them for administrator action is not an automated control. It is a manual process with automated discovery. The distinction matters for two reasons.

The gap between review cycles

A quarterly review has a three-month gap during which dormant accounts accumulate unchecked. An account that crosses the inactivity threshold in the first week of the quarter remains active for up to three months before the next review catches it. During this window, the dormant account represents an unmonitored attack surface.

Automated threshold enforcement closes this gap. When the threshold is crossed, the account is disabled immediately. The gap is reduced to the monitoring check interval, typically hours, not the review cycle interval of months.

Scalability and consistency

A capital markets entity with thousands of users across dozens of connected applications cannot reliably manage dormant account identification and disabling through manual review processes. Manual processes produce inconsistent results at scale: some accounts are caught promptly, others persist through multiple review cycles due to oversight or competing workload priorities.

Automated threshold enforcement applies consistently to every account. No account is overlooked because an administrator had higher-priority work during the review cycle.

How Automated Dormant Account Management Works

Akku’s User Lifecycle Manager implements G1g and G1h requirements through continuous activity monitoring and threshold-based automated enforcement.

Continuous activity monitoring

The centralised authentication event log captures every authentication event across all connected applications. The User Lifecycle Manager monitors the last authentication timestamp for every user identity in the Akku directory against a configured inactivity threshold.

For accounts that authenticate through Akku’s centralised SSO, activity monitoring is comprehensive. For legacy applications that do not route authentication through Akku, activity monitoring covers the centralised layer but not direct application authentication. Full G1g coverage requires all applications to authenticate through the centralised IdP so that inactivity can be detected comprehensively.

Threshold configuration

Inactivity thresholds are configurable per organisational unit or user group. A 90-day threshold for standard employee accounts and a 30-day threshold for privileged accounts are common configurations at capital markets entities. Service accounts can be given separate threshold policies that account for their legitimate inactivity patterns.

The threshold must be defined in the IT security policy and technically configured to match. An auditor examining G1g compliance will verify both the policy definition and the platform configuration.

Automated disabling and audit record

When an account crosses the threshold, the User Lifecycle Manager automatically disables the account in the Akku directory and triggers deprovisioning notifications to connected applications via SCIM. The disabling event generates a timestamped audit record capturing account identity, triggering threshold, last activity timestamp, and disabling timestamp.

This audit record is the G1g compliance evidence. It demonstrates that the automated control operated, that the threshold was applied at the correct time, and that the disabling action was executed without administrator initiation.

G1h departure-triggered removal

G1h’s prompt removal requirement is addressed through Akku’s automated deprovisioning workflow. When an employee departure is recorded in the HR system, the event triggers Akku’s deprovisioning workflow through SCIM or API integration. Deprovisioning across all connected applications is initiated simultaneously, with SCIM sync confirmation records generated for each application.

The deprovisioning audit trail covering every system from which access was removed, with timestamps and sync confirmations, is the G1h compliance evidence. The trigger timestamp from the HR system event and the deprovisioning completion timestamps together demonstrate that removal was prompt.

Orphan Account Detection as a Complement to G1g and G1h

Automated G1g and G1h controls prevent new dormant accounts from accumulating going forward. They do not address dormant accounts that existed before the controls were implemented. Orphan account detection addresses the historical backlog.

Akku’s IGA orphan account management scans all connected applications for accounts that exist without a linked, active identity in the Akku directory. Accounts belonging to departed employees who were not deprovisioned completely, contractor accounts persisting after engagement end, and project access accounts with no current owner are identified in the scan.

Each identified orphan is surfaced for resolution through deletion or reassignment. The detection run and resolution record demonstrate proactive access hygiene beyond the threshold-based controls that G1g and G1h require. SEBI examiners looking for evidence of access hygiene discipline will find both the automated threshold controls and the orphan detection records as complementary evidence of a complete programme.

Diagnostic Questions

Does your identity management platform automatically disable accounts when they cross a configured inactivity threshold without requiring administrator initiation, or does dormant account management rely on periodic reports and manual review?

For accounts disabled through the automated dormant account control in the last 12 months, is there a timestamped audit record for each disabling event showing the account identity, threshold crossed, and disabling timestamp?

When an employee departure is recorded in the HR system, does access revocation across all connected applications complete within the same business day through an automated workflow, or does it require a separate IT ticket or manual trigger?

Has your organisation run an orphan account detection scan in the last 90 days to identify accounts across connected applications that exist without a linked, active identity, and is there a resolution record for every orphan identified?

Does your inactivity monitoring cover all systems that user accounts can authenticate to, or only systems that route through the centralised identity layer, leaving direct application authentication outside the monitoring scope?

CTAs

See how Akku’s User Lifecycle Manager addresses SEBI CSCRF dormant account requirements through automated threshold enforcement, departure-triggered deprovisioning, and orphan account detection.

Book a conversation with the Akku team to assess your current dormant account controls against SEBI CSCRF PR.AA.S1 access hygiene requirements.

FAQs

What inactivity threshold should capital markets entities configure for G1g compliance?

SEBI CSCRF does not specify a precise inactivity threshold in G1g. Industry practice at capital markets entities typically applies 90 days for standard employee accounts and 30 days for privileged accounts with access to critical trading or settlement systems. The threshold must be defined in the IT security policy and technically configured in the identity management platform. Shorter thresholds for higher-risk accounts reflect the access hygiene principle: accounts with greater access privilege represent greater dormant risk and warrant earlier disabling. SEBI examiners will assess whether the configured threshold is proportionate to the risk profile of the user population it covers.

Does G1g apply to service accounts as well as human user accounts?

Yes. G1g applies to all user accounts including service accounts. Service accounts present a configuration challenge because they may have legitimate periods of inactivity. A batch processing service account that runs monthly will appear inactive for 29 of every 30 days. Applying a standard 90-day threshold to this account would disable it before its next scheduled run. The solution is separate inactivity threshold policies for service accounts, configured based on the known activity schedule of each service account category. Service accounts with no documented activity schedule should be treated as candidates for removal through orphan account management rather than threshold-based disabling.

What is the difference between account disabling under G1g and account removal under G1h?

Account disabling under G1g is triggered by inactivity threshold crossing. It is a reversible action that prevents authentication while preserving the account record and its audit history pending investigation. The account may belong to an employee on extended leave, in which case it can be re-enabled with manager approval when they return. Account removal under G1h is triggered by confirmed departure. It is a definitive action that removes the account from the access infrastructure following the departure event. The distinction matters because G1g disabling may require a reinstatement process for legitimate returns, while G1h removal does not.

How should capital markets entities handle accounts belonging to employees on extended leave under G1g?

Employees on extended leave, such as maternity or paternity leave, long-term medical leave, or sabbatical, may cross the inactivity threshold without representing a dormant account risk in the traditional sense. The recommended approach is to configure a separate inactivity policy for accounts in defined leave status, with either a longer threshold or a hold that prevents automatic disabling during the leave period. The leave status must be sourced from an authoritative HR system and applied to the account when leave begins. When leave ends, the standard threshold applies from the return date. Accounts on leave hold should still be reviewed periodically as part of the broader access governance programme.

Can the same automated dormant account management capability satisfy both SEBI CSCRF G1g and IRDAI Item 10 simultaneously?

Yes. SEBI CSCRF PR.AA.S1(G1g) and IRDAI ICS Item 10 both require automatic disabling of accounts inactive beyond a defined threshold. The same automated dormant account management capability in Akku’s User Lifecycle Manager satisfies both requirements from the same technical control. The threshold configuration, activity monitoring, automatic disabling, SCIM-based downstream notification, and audit record generation are identical for both frameworks. The compliance mapping references differ, but the technical control and the evidence it produces are the same. Organisations subject to both SEBI CSCRF and IRDAI ICS benefit from this overlap: one control deployment, one evidence trail, two framework requirements satisfied.

What does SEBI expect to see during an examination of dormant account controls specifically?

SEBI examiners reviewing dormant account controls under PR.AA.S1 typically request evidence of the automated disabling mechanism configuration showing the threshold is technically enforced. They request a sample of disabling events from the audit log showing timestamped records generated automatically when thresholds were crossed during the examination period. They verify that the disabling events were generated by the automated control, not by manual administrator action following a report. They also examine whether disabled accounts had their access to connected applications revoked, requiring SCIM deprovisioning confirmation records alongside the identity platform disabling records. Finally, they may request an orphan account scan result showing the current state of accounts across connected applications.

Introduction

ISO 27001:2022 Annex A.8.2 requires that the allocation and use of privileged access rights be restricted, controlled, and reviewed. The control is one of the most audit-intensive in the standard because privileged access failures are disproportionately represented in the security incidents that drive ISO 27001 certification in the first place. Organisations pursuing certification almost always have a privileged access policy. Fewer have implemented the technical controls that satisfy A.8.2’s allocation, use, and review requirements simultaneously.

The allocation requirement means privileged access must be granted through a formal process on a need-to-use basis. The use requirement means the use of privileged access rights must be logged at sufficient detail to reconstruct what occurred. The review requirement means privileged access entitlements must be periodically examined and those no longer required must be revoked.

Standing privilege, where administrators hold persistent, unrestricted access to target systems between sessions, fails all three requirements simultaneously. It cannot be said to be allocated on a need-to-use basis when it persists indefinitely. It cannot produce use evidence beyond authentication records without session-level recording. It cannot be reviewed in a meaningful way when entitlements have no defined scope or expiry.

This blog covers what each component of A.8.2 requires technically, why standing privilege is architecturally incompatible with A.8.2 compliance, and how JIT access with per-session ephemeral credentials and session activity logging constitutes the correct implementation.

Allocation Requirements Under A.8.2

A.8.2 requires that privileged access rights be allocated to users on a need-to-use and event-by-event basis in line with the access control policy. The event-by-event standard is specific: each privileged access event should be individually authorised, not covered by a standing entitlement that grants access indefinitely.

What need-to-use and event-by-event means technically

Need-to-use means that privileged access is granted only when there is a current, specific operational requirement. An administrator who needs to investigate an issue on a production server has a current need. That same administrator has no need for access to the server when they are not actively working on it. A standing entitlement that grants them permanent SSH access to the server satisfies neither the need-to-use nor the event-by-event standard.

Event-by-event means that each access event requires its own authorisation. A system administrator who needs to access three servers on three separate occasions needs three separate authorisations, not a single standing entitlement covering all future access to all servers.

Technically, this standard requires JIT access: privileged access is granted for the duration of a specific, approved session and automatically revoked at session close or on JIT window expiry. There is no standing access between sessions. Each session requires a new authorisation through the approval workflow.

Formal authorisation process

A.8.2 requires that privileged access allocation follow a formal process. The process must produce a documented record of the authorisation: who requested access, to which system, for what purpose, for what duration, who approved, and when. This record is the allocation evidence that A.8.2 requires.

Akku’s session approval workflow produces this record automatically for every privileged session. The request captures target system, access level, duration, and justification. The approval captures approver identity and timestamp. No session opens without a corresponding approval record when the workflow is enabled.

AkkuArka per-session ephemeral credentials

AkkuArka implements the event-by-event allocation standard at the credential layer. For every approved privileged session, AkkuArka generates a unique, cryptographically random credential scoped to the target system. The credential exists only for the duration of the session: it is generated at approval, injected at the protocol layer by AkkuReka, and permanently revoked on session close. The user never sees or types the credential.

This model makes standing privilege architecturally impossible. No privileged user holds credentials to target systems between sessions. Every connection to a critical system requires a new approved session with a new ephemeral credential. The allocation is truly event-by-event.

Use Requirements Under A.8.2

A.8.2 requires that the use of privileged access rights be logged. The logging requirement is where most organisations have their largest A.8.2 gap: authentication logs confirm that privileged sessions occurred but record nothing about what occurred during them.

What use logging requires technically

Use logging at the level A.8.2 requires means session-level activity recording. For an administrator accessing a Linux server, the use log must capture every command executed during the session. For a database administrator, the use log must capture every SQL query executed. For a Windows server administrator, the use log must capture screen activity sufficient to reconstruct what was done.

The use log is the accountability mechanism A.8.2’s restriction and control requirements depend on. If privileged access use cannot be reconstructed from logs, the control over how privileged access was used cannot be assessed. The allocation and review components of A.8.2 are undermined if the use component is absent.

The use log also satisfies the intersection between A.8.2 and A.8.15. A.8.15 requires logging of user activities. A.8.2 requires logging of privileged access use. For privileged users, the same session activity log satisfies both controls simultaneously.

SMARTAudit Trails as A.8.2 use evidence

SMARTAudit Trails capture every privileged session at the protocol layer through AkkuReka, producing the use log A.8.2 requires across all supported session types.

SSH sessions produce full screen recordings and complete keystroke logs. Every command typed by the privileged user is captured with timestamp, directory context, and output. This is the use log for Linux server and network device administration.

MySQL and PostgreSQL sessions produce full screen recordings and structured capture of every SQL query executed. Each query record includes query text, timestamp, and session context. This is the use log for database administration.

RDP sessions produce full screen video recordings at configurable frame rates. This is the use log for Windows server administration.

Kubernetes sessions produce session event recordings and command logs for kubectl operations.

All recordings are stored encrypted, indexed for forensic search, and accessible from the Akku admin console for in-browser playback. The append-only storage architecture ensures that use logs cannot be modified after generation, satisfying A.8.2’s control requirement.

Review Requirements Under A.8.2

A.8.2 requires that privileged access rights be reviewed at regular intervals. Reviews must assess whether current entitlements remain appropriate and revoke those that do not. The review is the mechanism for detecting and closing the gap between what privileged users are currently entitled to access and what they currently need.

What privileged access review requires technically

Privileged access review requires a structured campaign where the current privileged access entitlements of all users with privileged access are presented to appropriate reviewers, typically the security team and system owners, for certification or revocation. Each reviewer must make a decision per entitlement, and that decision must be timestamped and logged.

For revocations, the review record must be linked to a deprovisioning record showing that access was actually removed. A review record showing that a privileged entitlement was revoked but no corresponding deprovisioning record is an incomplete evidence chain that ISO 27001 auditors will identify.

The review cadence for privileged access should be more frequent than for standard access. Quarterly reviews for privileged access entitlements are common at organisations seeking to demonstrate robust A.8.2 compliance. The higher-risk nature of privileged access, combined with the event-by-event allocation standard that limits standing privilege, means that the review is primarily examining role-level entitlements: which users have the PAM platform roles that permit them to request privileged sessions to which target systems.

Akku’s access review campaigns for privileged access

Akku’s IGA access review and re-certification campaigns support privileged access review at the PAM role level. The campaign sends certification requests to designated reviewers for every user with PAM platform roles. Each reviewer makes a certify or revoke decision per entitlement. Decisions are timestamped and logged. Revocations trigger automated removal of the PAM role, preventing the user from requesting further privileged sessions to the covered target systems.

The campaign record, covering scope, reviewer assignments, decision timestamps, and deprovisioning records for revocations, constitutes the A.8.2 review evidence that ISO 27001 auditors examine.

Why Standing Privilege Fails A.8.2

Standing privilege, the model where administrators hold persistent credentials to target systems that are valid between sessions, fails all three A.8.2 requirements simultaneously. Understanding why clarifies what the JIT access model resolves.

Standing privilege and allocation

A.8.2 requires allocation on a need-to-use and event-by-event basis. Standing privilege is a single allocation that covers all future access events indefinitely. It is not need-to-use because it persists when there is no current operational need. It is not event-by-event because it does not require separate authorisation for each access event. Standing privilege fails A.8.2’s allocation standard by design.

Standing privilege and use

A.8.2 requires that use be logged. If administrators connect to target systems directly using standing credentials, the connection occurs outside any session proxy that would generate use logs. Authentication events are captured by the target system’s own logs, but these can be modified by a sufficiently privileged administrator. Session activity logs require a session proxy layer that stands between the administrator and the target system. Standing privilege allows connections that bypass this proxy, producing no use logs.

Standing privilege and review

A.8.2 requires periodic review of privileged access rights. Standing privilege creates entitlements with no defined scope or expiry. The review must assess whether the standing entitlement should continue, but since the entitlement covers all future access without restriction, the review cannot assess whether specific planned future access remains appropriate. The review becomes a binary decision to retain or remove the standing entitlement, without the granularity that A.8.2’s restriction and control requirements imply.

JIT access with per-session ephemeral credentials resolves all three failures. Every access event is individually authorised (allocation), recorded through the session proxy (use), and the role-level entitlement that permits session requests is what the periodic review assesses (review).

What ISO 27001 Certification Auditors Examine for A.8.2

Allocation evidence examination

Auditors select a sample of privileged sessions from the certification period and request the allocation records for each. They verify that each session has a corresponding approval record showing the justification, approver identity, and timestamp. Sessions that opened without a corresponding approval record, or with informal approval through email, are findings.

Use evidence examination

Auditors request the use logs for the sampled sessions. They verify that the logs capture session activity at an appropriate level: keystroke logs for SSH, query logs for databases, screen recordings for RDP. Sessions where only authentication records exist, with no session activity recording, indicate that the use component of A.8.2 is not implemented.

Review evidence examination

Auditors examine privileged access review records from across the certification period. They verify that reviews were conducted on a defined cadence, that every privileged access entitlement was covered, that decisions were timestamped with reviewer identities, and that revocations were actioned. A single review conducted in the pre-audit window does not satisfy the operating effectiveness standard for a 12-month certification period.

Akku’s ISO 27001 mapping shows Privileged Access Manager addresses A.8.3, A.16.2, A.16.6, A.16.7, and A.16.8 across five clause mappings. Identity and Access Governance, with 16 clause references, covers the broader access governance controls including the review component.

Diagnostic Questions

For any privileged session to a critical system in the last six months, can you produce the allocation record showing the approved justification, approver identity, and timestamp, and the use record showing session activity at the keystroke or query level?

Do privileged users in your organisation hold standing credentials to target systems that allow them to connect at any time without a new approval, or does every connection require a new approval and use a session-specific credential?

Has your organisation conducted a formal review of privileged access entitlements in the last 12 months, with timestamped certification or revocation decisions for every privileged entitlement, and deprovisioning records for all revocations?

Does your session recording coverage extend to all critical systems including Linux servers accessed via SSH, production databases, and Windows servers accessed via RDP, or are some critical systems outside the session recording perimeter?

When a system administrator’s employment ends, is their privileged access removed across all connected systems within the same business day, with a timestamped deprovisioning record as evidence?

CTAs

See how Akku addresses ISO 27001 A.8.2 privileged access management requirements through JIT access, per-session ephemeral credentials, SMARTAudit Trails, and access review campaigns.

Book a conversation with the Akku team to assess your current privileged access posture against ISO 27001:2022 A.8.2 certification requirements.

FAQs

What does event-by-event allocation mean in practice for a system administrator who needs regular access to production servers?

Event-by-event allocation means each access event requires its own authorisation rather than being covered by a standing entitlement. For a system administrator who regularly accesses production servers, this means submitting a session request for each access occasion, specifying the target system, purpose, and duration. The approval workflow handles routine requests efficiently: low-risk access to familiar systems can be auto-approved or approved by a designated approver within minutes. The event-by-event standard does not make routine access impractical; it ensures each access event has a documented justification and authorisation that satisfies A.8.2’s allocation requirement.

Does A.8.2 apply to service accounts as well as human administrators?

Yes. A.8.2 covers all privileged access rights, including those held by service accounts used for automated processes. Service accounts with privileged access to production systems should be subject to the same allocation, use, and review requirements as human administrator accounts. Where service accounts require privileged access for specific automated tasks, that access should be scoped to the minimum required, documented in the access governance records, and reviewed periodically. Unreviewed service accounts with broad privileged access are a common finding in ISO 27001 audits and represent a real attack surface if service account credentials are compromised.

How does A.8.2 interact with A.9.2 (user access provisioning) in the ISO 27001:2022 control set?

A.9.2 in the 2013 version of ISO 27001 covered user access provisioning and was reorganised in the 2022 version into A.5.16 (identity management) and A.5.18 (access rights). A.8.2 covers privileged access rights specifically as a technological control, while A.5.18 covers access rights review broadly. Together they define the complete access governance framework: A.5.16 covers identity lifecycle, A.5.18 covers periodic review of all access rights, and A.8.2 covers the specific additional requirements for privileged access including event-by-event allocation, use logging, and review. All three must be implemented and evidenced for complete access governance coverage in a certification audit.

What is the minimum review frequency for privileged access entitlements to satisfy A.8.2?

ISO 27001:2022 A.8.2 requires review at regular intervals without specifying a minimum frequency. In certification audit practice, quarterly review for privileged access entitlements is considered robust. Semi-annual review is generally accepted. Annual review is the minimum most auditors accept, though a single annual review produces limited operating effectiveness evidence for a 12-month certification period. The review cadence should be defined in the ISMS documentation and consistently applied throughout the certification period.

Can the same access review campaign satisfy both A.8.2’s privileged access review requirement and A.5.18’s general access rights review requirement?

Yes. A single access review campaign that covers both privileged and standard access entitlements satisfies both A.8.2 and A.5.18 review requirements from the same campaign record. The campaign must be structured so that privileged entitlements are reviewed by appropriate reviewers, typically security team and system owners, while standard entitlements are reviewed by line managers. The campaign record must document which entitlements are privileged and which review process applied to each. Running separate campaigns for privileged and standard access is also acceptable and may be operationally preferable if privileged access is reviewed more frequently than standard access.

How does AkkuArka’s per-session ephemeral credential model affect the A.8.2 review process?

Per-session ephemeral credentials mean that there are no standing target system credentials to review at the entitlement level. What the periodic review assesses is the PAM platform role assignments: which users have roles that permit them to request privileged sessions to which target systems. The review certifies or revokes PAM platform roles rather than individual system credentials. When a PAM platform role is revoked following a review decision, the user can no longer request sessions to the systems that role covers. This is a cleaner review model than reviewing standing credentials because the entitlement boundary is clearly defined at the role level in the IAM platform, not distributed across individual system credential stores.

Introduction

ISO 27001:2022 introduced A.8.16 as a new control with no direct equivalent in the 2013 version. The control requires that networks, systems, and applications be monitored for anomalous behaviour and that appropriate actions be taken when anomalies are detected. The 2022 revision’s addition of A.8.16 reflects a deliberate shift in the standard’s monitoring posture: from reactive log review to proactive anomaly detection.

Organisations certified under ISO 27001:2013 and transitioning to the 2022 version face a specific gap assessment for A.8.16. The 2013 standard’s monitoring requirements under A.12.4 covered log generation and protection. A.8.16 goes further by requiring that logs be actively monitored, that anomalous behaviour be detected, and that detection trigger a response. The distinction is meaningful: an organisation can fully satisfy A.8.15’s logging requirement while having no anomaly detection capability that satisfies A.8.16.

The IAM layer is where A.8.16’s monitoring requirement is most immediately actionable. Authentication events contain the signals for anomaly detection: geographic location, device identity, time of day, MFA outcome, and access patterns. A monitoring infrastructure that evaluates these signals continuously against user baselines and generates alerts when they deviate satisfies A.8.16 at the authentication layer. Building this capability requires Adaptive MFA with anomaly detection, not only authentication event logging.

This blog covers what A.8.16 specifically requires, how it differs from A.8.15, what the 2022 update means for organisations transitioning from the 2013 standard, and what IAM controls satisfy the new monitoring obligation.

What A.8.16 Requires

A.8.16 sits within the Technological Controls theme and addresses monitoring activities as a control category.

Anomalous behaviour detection

A.8.16 requires that monitoring procedures be established and implemented to detect anomalous behaviour in networks, systems, and applications. The detection requirement is active and automated: anomalies must be identified as they occur or shortly after, not discovered during retrospective log review.

Anomalous behaviour in the IAM context includes authentication from unusual locations or devices, authentication at unusual hours, MFA failure patterns indicating credential stuffing attempts, access to systems or functions outside a user’s established pattern, and privileged session activities inconsistent with the session’s stated purpose.

The monitoring must operate continuously. A.8.16 is not satisfied by a weekly log review that examines authentication events from the previous seven days. Continuous monitoring requires automated evaluation of events against baselines as they occur, with detection and alerting that does not depend on the review schedule.

Appropriate actions on anomaly detection

A.8.16 requires that appropriate actions be taken when anomalies are identified. The response component distinguishes A.8.16 from a passive monitoring requirement. Detected anomalies must trigger defined responses: step-up authentication challenges for authentication anomalies, session termination for suspicious privileged sessions, account suspension for account compromise indicators, or investigation workflows for ambiguous events.

The response must be proportionate to the anomaly severity. A geographic anomaly that may reflect legitimate travel warrants a step-up challenge and investigation. An impossible travel event warrants immediate account suspension. A response mechanism that treats all anomalies identically, regardless of severity, does not satisfy A.8.16’s appropriate actions requirement.

Documentation and evidence

A.8.16 compliance requires evidence that monitoring is operating. This includes monitoring infrastructure configuration documentation, anomaly alert records demonstrating detection events throughout the certification period, investigation records showing that alerts were acted upon, and response records documenting the actions taken for each anomaly.

Certification auditors examining A.8.16 will look for evidence of active monitoring, not only for the existence of a monitoring policy. The operating effectiveness standard requires that detection events occurred throughout the certification period and that each was responded to appropriately.

How A.8.16 Differs From A.8.15

A.8.15 and A.8.16 are complementary but distinct controls. Understanding the distinction is necessary for organisations assessing their gap against the 2022 standard.

A.8.15: Log generation and retention

A.8.15 requires that logs recording user activities, exceptions, faults, and security events be produced, kept, and regularly reviewed. The control focuses on what is recorded and how those records are protected and retained. An organisation satisfies A.8.15 by deploying comprehensive logging, protecting logs against tampering, retaining them for defined periods, and reviewing them regularly.

Regular review under A.8.15 does not require automated anomaly detection. A scheduled log review process where an administrator examines logs on a defined cadence satisfies A.8.15’s review requirement. The review is systematic but not necessarily automated.

A.8.16: Continuous anomaly detection

A.8.16 requires that monitoring detect anomalous behaviour and trigger appropriate responses. This is a real-time or near-real-time requirement. The monitoring must surface anomalies without waiting for a scheduled review cycle. Automated baseline comparison and alert generation are what A.8.16 requires that A.8.15 does not.

An organisation that has comprehensive logging under A.8.15 but no automated anomaly detection has a gap in A.8.16. The logs exist and are reviewed, but the review does not satisfy the continuous detection and alert generation requirement.

The gap for ISO 27001:2013 certified organisations

Organisations certified under ISO 27001:2013 satisfied A.12.4’s logging and monitoring requirements without needing automated anomaly detection. The 2022 transition to A.8.16 requires assessing whether current monitoring infrastructure includes automated detection or only systematic log review. If only the latter, deploying anomaly detection capability is the gap that must be closed for 2022 certification.

What the 2022 Update Means for IAM Stack Requirements

A.8.16’s addition to the 2022 standard has specific implications for the IAM stack components that organisations deploy for compliance.

Adaptive MFA as an A.8.16 control

Adaptive MFA with AI-powered anomaly detection satisfies A.8.16 at the authentication layer. Every authentication event is evaluated against the user’s behavioural baseline. Deviations trigger step-up authentication challenges and generate anomaly detection events in the audit trail. This is continuous, automated monitoring with proportionate response: the definition of what A.8.16 requires.

An organisation that deploys standard MFA, where the same second factor is applied uniformly to every authentication event, satisfies A.8.5’s authentication requirement but not A.8.16’s anomaly detection requirement. A.8.16 requires that the authentication layer evaluate each event for anomalous signals and respond proportionately. Only Adaptive MFA with baseline evaluation satisfies both A.8.5 and A.8.16 simultaneously.

Privileged session monitoring as an A.8.16 control

Real-time privileged session monitoring through AkkuReka satisfies A.8.16 at the privileged access layer. Administrators view all active privileged sessions and can terminate sessions exhibiting anomalous behaviour. Session activity monitoring that surfaces commands or queries inconsistent with the session’s stated purpose is the privileged access equivalent of authentication anomaly detection.

Retrospective session recording through SMARTAudit Trails satisfies the evidence component of A.8.16: a complete record of privileged session activity that supports post-anomaly investigation.

Identity governance monitoring as an A.8.16 control

SoD violation detection in the IGA rules engine satisfies A.8.16 at the access governance layer. Continuous detection of conflicting role combinations, with alert generation and remediation workflows, is anomalous access pattern detection applied to entitlement combinations rather than authentication events.

Access review anomaly detection, where the review process surfaces users whose access scope has deviated significantly from their peers in the same role, extends A.8.16’s anomaly detection to the entitlement layer.

Implementing A.8.16 in Stages

For organisations transitioning from ISO 27001:2013 certification, implementing A.8.16 can be staged to prioritise the highest-risk monitoring scenarios first.

Stage one: Authentication anomaly detection

The first priority is deploying Adaptive MFA with baseline evaluation for all authentication events to in-scope systems. This is the highest-impact A.8.16 implementation because authentication is the first layer where anomalies can be detected and the step-up response prevents rather than merely records suspicious access.

Authentication anomaly detection covers geographic anomalies, impossible travel, device anomalies, time-of-day deviations, and MFA failure pattern analysis. Each anomaly type requires a baseline model and a configured response threshold.

Stage two: Privileged session monitoring

The second priority is real-time monitoring of active privileged sessions through PAM. This extends A.8.16’s anomaly detection to the post-authentication layer, covering what privileged users do during sessions rather than only how they authenticate.

Real-time monitoring with termination capability addresses the highest-impact privileged access scenarios: a compromised administrator account or an insider threat actor would be visible in the active session monitor and terminable before significant damage occurs.

Stage three: Access governance anomaly detection

The third priority is SoD violation detection and access pattern analysis at the entitlement layer. This extends A.8.16’s monitoring to the access governance domain, detecting anomalous access combinations that may indicate fraud enablement or insider threat preparation.

Access pattern analysis, identifying users whose entitlement scope has grown significantly beyond their peer group, complements the authentication-layer and session-layer detection with a longer-term perspective on access accumulation.

Diagnostic Questions

Does your monitoring infrastructure evaluate authentication events against user-specific baselines and generate alerts when anomalies are detected, or does it log events for periodic review without automated anomaly detection?

When transitioning from ISO 27001:2013 certification to the 2022 standard, have you assessed whether your current monitoring infrastructure satisfies A.8.16’s automated detection requirement or only A.8.15’s logging and review requirement?

For anomaly detection events generated in the last 12 months, is there a documented response record for each event showing investigation and resolution, or do alerts exist without corresponding investigation evidence?

Does your privileged session monitoring provide real-time visibility with termination capability, or does monitoring consist only of retrospective review of session recordings after sessions close?

Can you demonstrate to a certification auditor that A.8.16’s anomaly detection has been operating continuously throughout the certification period, with detection events and response records spanning the full period?

CTAs

See how Akku’s Adaptive MFA and privileged session monitoring address ISO 27001:2022 A.8.16 continuous monitoring requirements across authentication, session, and access governance layers.

Book a conversation with the Akku team to assess your current monitoring posture against ISO 27001:2022 A.8.16 certification requirements.

FAQs

What specifically did ISO 27001:2022 add with A.8.16 that was not in the 2013 standard?

ISO 27001:2013 included A.12.4 covering monitoring system use, which required logging of user activities, exceptions, and security events, and protection of logging information. The 2022 revision reorganised these requirements into A.8.15 and added A.8.16 as a new control requiring active monitoring for anomalous behaviour with appropriate response actions. The key addition in A.8.16 is the anomaly detection and response requirement: not only must events be logged and reviewed, but the monitoring infrastructure must detect anomalies automatically and trigger responses. This moves the standard from systematic log review to continuous automated detection, reflecting the evolution of security monitoring practices since 2013.

Does A.8.16 require a dedicated security information and event management platform?

A.8.16 requires that networks, systems, and applications be monitored for anomalous behaviour. It does not prescribe specific technologies. A SIEM platform is one way to implement A.8.16, but it is not the only way. For organisations whose primary anomaly detection concern is at the IAM layer, Adaptive MFA with anomaly detection, privileged session monitoring, and SoD violation detection collectively satisfy A.8.16 without requiring a full SIEM deployment. Organisations with broader monitoring requirements covering network traffic, endpoint behaviour, and application events may benefit from a SIEM. The A.8.16 requirement is technology-neutral: what matters is that anomalous behaviour is detected and that appropriate actions are taken.

How does the transition timeline from ISO 27001:2013 to 2022 affect the A.8.16 gap?

ISO published ISO 27001:2022 in October 2022. The transition period allows organisations certified under the 2013 standard to transition to the 2022 standard by October 2025. Organisations that have not yet transitioned should assess their A.8.16 gap as part of their transition planning. The gap assessment should determine whether current monitoring infrastructure includes automated anomaly detection or only systematic log review. Where a gap exists, the time to close it is before the transition audit, not during it. Deploying Adaptive MFA with anomaly detection and establishing the investigation workflow and response documentation before the transition audit ensures A.8.16 evidence covers the required certification period.

What does A.8.16 require for response documentation, and how detailed must investigation records be?

A.8.16 requires that appropriate actions be taken when anomalies are detected. The response documentation must demonstrate that actions were proportionate to the anomaly severity and that investigations were conducted. For a geographic anomaly that resolved as a legitimate business trip, the investigation record might be brief: the alert was reviewed, the user confirmed they were travelling, and the alert was cleared as a false positive. For a potential account compromise, the investigation record would be more extensive: the alert was reviewed, the session was terminated, the user was contacted, the password was reset, and a forensic review of the session was conducted. The documentation standard is that any auditor reading the record can understand what happened, what was investigated, and what action was taken.

How does A.8.16 interact with A.5.25 and A.5.26 covering information security incident management?

A.8.16’s anomaly detection feeds into the incident management process covered by A.5.25 (assessment and decision on information security events) and A.5.26 (response to information security incidents). When A.8.16’s monitoring detects an anomaly that is assessed as a genuine security incident rather than a false positive, the incident management process under A.5.25 and A.5.26 is triggered. The monitoring and incident management controls are therefore sequential: A.8.16 detects the signal, A.5.25 assesses whether it constitutes an incident, and A.5.26 governs the response. Organisations implementing A.8.16 should ensure their incident management process is connected to the anomaly detection alert workflow so that escalation from detection to incident response is structured and documented.

Can an organisation satisfy A.8.16 using only the authentication layer monitoring from an IAM platform without network or endpoint monitoring?

A.8.16 requires monitoring of networks, systems, and applications. The authentication layer is one component of this scope but not the complete scope. An organisation that monitors only authentication events satisfies A.8.16 for the authentication layer but has gaps in network anomaly detection and endpoint behaviour monitoring. For organisations seeking ISO 27001 certification, the scope of A.8.16 monitoring must be assessed against the organisation’s ISMS scope. For an ITeS company whose ISMS scope covers its service delivery infrastructure, authentication and application monitoring may be sufficient. For a bank with a broader ISMS scope covering network infrastructure, network monitoring is also required. The authentication-layer monitoring that Akku provides is a necessary component of A.8.16 compliance but may need to be supplemented with network and endpoint monitoring depending on the organisation’s ISMS scope.

Introduction

SEBI CSCRF GV.OC.S2(G3) requires that logs, user details, and application data be accessible to SEBI on demand. This is not a notification requirement or a periodic reporting obligation. It is a structural requirement about log architecture: the infrastructure must be capable of producing structured exports of any requested data for any requested period at any time, without requiring advance preparation or manual compilation.

Most capital markets entities maintain logs. The compliance gap is almost always in accessibility and structure. Logs distributed across individual application systems in different formats, requiring aggregation before they can be exported. Authentication logs in one system, privileged session records in another, access change records in a third. A SEBI examination request arriving on a Tuesday morning for all authentication events and privileged access records covering a specific 90-day period cannot be fulfilled within a regulatory response timeframe from this architecture. It requires days of manual work to aggregate, normalise, and format.

The on-demand standard requires the opposite architecture: a centralised, queryable log infrastructure where any requested event type covering any requested period can be exported in structured format within hours of the request. This is an architectural requirement that cannot be satisfied by improving the manual compilation process. It requires building log centralisation into the IAM platform from the outset.

This blog covers what GV.OC.S2(G3) specifically requires, what log architecture satisfies the on-demand standard, which event types must be covered, and how the architecture integrates with the broader SEBI CSCRF log access requirements.

What GV.OC.S2(G3) Requires

GV.OC.S2 sits within the Govern function’s Organisational Context sub-category. G2 and G3 together define SEBI’s expectations for log governance and on-demand access.

GV.OC.S2(G2): Privileged user responsibilities

GV.OC.S2(G2) requires that responsibilities for privileged access be formally defined and that audit records reflect the scope of each privileged user’s authorised activities. This is the governance layer for privileged access: defined scope, documented approval, and audit records that demonstrate scope adherence.

Technically, G2 requires that every privileged session has a corresponding session record that can be mapped to the defined responsibilities for that privileged user category. A session record showing a database administrator executing schema modifications on an authorised database satisfies G2. A session record showing the same administrator querying customer data outside their defined scope is a G2 violation that the audit record makes visible.

GV.OC.S2(G3): On-demand log access

GV.OC.S2(G3) requires that logs, user details, and application data be accessible to SEBI on demand. The three categories cover the full scope of what a SEBI examination might request.

Logs covers all security event logs including authentication events, access change records, privileged session records, policy violation events, and administrative action records. User details covers identity records, role assignments, access entitlements, and user lifecycle records. Application data covers application access records, session events, and data access logs where these are captured by the IAM infrastructure.

The on-demand requirement means these categories must be producible at any time, for any period within the retention window, in a structured format suitable for regulatory examination. A response timeline consistent with a regulatory request, typically within one to two business days, is the operational standard.

What Log Architecture Satisfies the On-Demand Standard

Satisfying GV.OC.S2(G3)’s on-demand requirement is an architectural problem, not a process problem. The architecture must be designed for on-demand access from the outset.

Centralised log storage

All IAM-generated events must flow into a single, centralised log store. Authentication events from every connected application, access change records from the provisioning infrastructure, privileged session records from the PAM layer, administrative action records from the identity governance platform, and policy violation events from the contextual access layer must all be queryable from a single interface.

When log events are stored in separate systems per application, producing a consolidated view requires aggregation across multiple systems with potentially incompatible formats and timestamp conventions. This aggregation cannot be performed reliably within the timeframe of a regulatory request. Centralised storage eliminates this constraint.

Structured event format

Every log event must be stored in a consistent, structured format. Unstructured log text that requires parsing before it can be filtered or exported does not satisfy the on-demand standard. A structured event record containing defined fields, including event ID, timestamp, actor identity, target system, event type, outcome, source IP, and geographic location, can be filtered, queried, and exported without transformation.

The structured format requirement also applies to privileged session records. Session metadata must be stored as structured data alongside session recordings. SQL query capture must be stored as structured data, queryable by query text and timestamp. Keystroke logs must be indexed for search by command string.

Append-only integrity

The integrity of exported logs must be demonstrable. A log that can be modified after the fact cannot satisfy a regulatory examination where the accuracy of records is under scrutiny. Append-only architecture, where new records are added but existing records cannot be modified or deleted, is what makes the integrity claim credible.

When SEBI requests log records for a specific period, the regulated entity must be able to assert that the records produced are complete and unmodified. The append-only architecture is the technical basis for this assertion.

Retention coverage

Logs must be retained for a period sufficient to satisfy any regulatory request. SEBI CSCRF does not specify a precise retention period. Industry practice at capital markets entities typically maintains authentication event logs and access change records for two years. Privileged session recordings are retained for two years or longer for sessions involving access to critical trading and settlement infrastructure.

The retention policy must be defined, documented, and technically enforced. Logs deleted before the retention period expires create gaps in the on-demand access capability that SEBI could identify during an examination.

Event Types GV.OC.S2(G3) Covers

The three categories in GV.OC.S2(G3), logs, user details, and application data, map to specific event types that the IAM infrastructure must capture and make available.

Logs category

Authentication events: every login attempt across all connected applications with actor identity, timestamp, source IP, device identifier, geographic location, MFA method, and outcome. These are the events that satisfy PR.AA.S8’s authentication logging requirement simultaneously with GV.OC.S2(G3).

Privileged session events: session request, approval decision, session open, active duration, activity summary, termination reason, and credential revocation for every privileged session. Session recordings linked to these metadata records for SSH, RDP, and database sessions.

Access change events: provisioning actions, deprovisioning actions, role assignments, role removals, and access review decisions with requester, approver, justification, and timestamp for each.

Administrative events: policy changes, target system additions and removals, user account creation and deletion, and platform configuration changes with actor identity and timestamp.

Policy violation events: SoD violations, contextual access policy blocks, MFA failures exceeding threshold, and anomaly detection events.

User details category

Identity records: every user identity in the directory with creation date, status, role assignments, and last authentication timestamp.

Role and entitlement records: current and historical role assignments per user, with effective dates and the approval records for each assignment.

Access entitlement records: per-user, per-system access entitlement state across all connected applications, queryable at any point in time within the retention window.

Lifecycle records: provisioning and deprovisioning events for every user, with trigger events and timestamped completion records.

Application data category

Application access records: session-level access events per application per user, showing which applications were accessed, when, and with what authentication assurance.

Data access logs: where privileged sessions to databases are captured through SMARTAudit Trails, the SQL query log constitutes the application data record for database access events.

How Akku’s Architecture Satisfies GV.OC.S2(G3)

Akku’s centralised audit log architecture is designed to satisfy on-demand log access requirements as a structural property of the platform, not as a bolt-on reporting capability.

Single queryable audit trail

Every event generated by Akku’s IAM modules, authentication events from SSO and Adaptive MFA, access change events from User Lifecycle Manager and IGA, privileged session events from PAM, administrative events from the platform console, and policy events from contextual access and SoD enforcement, flows into a single audit log. This log is queryable by actor, system, event type, time range, and outcome from the Akku admin console.

A SEBI examination request for all authentication events and privileged session records for a specific 90-day period can be responded to by querying the centralised audit log with the specified filters and exporting the results. No manual aggregation across multiple systems is required.

Structured export formats

Akku’s audit log exports in JSON and CSV format. Both formats are structured, with consistent field naming across all event types. The export can be filtered by any combination of actor identity, target system, event type, time range, and outcome before export, allowing the export to be scoped precisely to the examination request without producing irrelevant data.

API access to audit logs enables programmatic integration with SIEM and log aggregation platforms, supporting automated export workflows for recurring regulatory reporting obligations.

SMARTAudit Trail integration

Session recordings from SMARTAudit Trails are accessible for in-browser playback and exportable for submission to SEBI examiners requesting forensic review of specific sessions. Session metadata including session ID, actor identity, target system, start and end timestamps, and recording availability is queryable from the same audit log interface as other event types.

Append-only integrity

Akku’s audit log is append-only. Existing records cannot be modified or deleted. When log records are exported for a SEBI examination, the regulated entity can assert that the records are complete and unmodified from the time of generation. This integrity property is what makes the exported records reliable as regulatory evidence.

Akku’s SEBI compliance mapping shows the Audit Logs module addresses 20 guideline references across GV.OC.S2(G2), GV.OC.S2(G3), PR.AA.S8, PR.AA.S12, PR.AA.S15(G2a), PR.IP.S2(G1e), PR.IP.S15(G1d), PR.MA.S2(G4), DE.CM.S1 to S3(G1), RS.AN.S1 to S3(G1 to G4), RS.AN.S4 to S5(G1 to G5), EV.ST.S1 to S3(G5 to G8), the highest single-module mapping count in the SEBI compliance documentation.

Preparing for a SEBI Log Access Request

Capital markets entities should treat GV.OC.S2(G3) as a readiness requirement, not a reactive capability. The on-demand standard means the capability must exist before the request arrives, not be built in response to it.

Readiness assessment

Assess the current log architecture against three questions: Can all authentication events for any 90-day period be exported in structured format from a single query without manual compilation? Can all privileged session records for any 90-day period, including session metadata and recording availability, be produced within two business days of a request? Can user detail records showing current and historical access entitlements for any user be produced on demand?

If the answer to any of these is no, the architecture has a GV.OC.S2(G3) gap.

Tabletop exercise

Conduct a tabletop exercise simulating a SEBI examination log access request. Assign a team member to submit a request for all authentication events, access change records, and privileged session records for a specific 90-day period chosen at random. Measure the time required to produce the export and assess whether the output is structured, complete, and in a format suitable for regulatory submission.

The exercise identifies process gaps alongside architectural gaps. An architecture that can produce the records but requires multiple system administrator actions and format normalisation before export has an operational gap that will fail the on-demand standard even if the underlying data exists.

Diagnostic Questions

For a 90-day period chosen at random from the last two years, can you produce a structured export of all authentication events across all connected systems from a single query without manual aggregation from individual application logs?

Can you produce on demand the current access entitlement state for any user across all connected applications, showing which systems they have access to and when each entitlement was granted?

Are your privileged session records, including session metadata and recording availability, stored in the same queryable infrastructure as your authentication event logs, or in a separate system requiring separate access and export?

Does your log export produce structured JSON or CSV output with consistent field naming across all event types, or does it produce application-specific log formats requiring normalisation before submission?

Has your organisation conducted a tabletop exercise simulating a SEBI log access request and measured the time required to produce a compliant response?

CTAs

See how Akku’s centralised audit log architecture addresses SEBI CSCRF GV.OC.S2(G3) on-demand log access requirements across authentication events, privileged sessions, and access records.

Book a conversation with the Akku team to assess your current log architecture against SEBI CSCRF’s on-demand access standard.

FAQs

What does on-demand mean in the context of GV.OC.S2(G3), and what response timeline should entities target?

On-demand means the infrastructure must be capable of producing requested records at any time without advance preparation. The regulation does not specify a response timeline. In regulatory examination practice, a response within one to two business days for a structured log export is generally considered compliant with the on-demand standard. A response that requires more than a week due to manual compilation, format normalisation, or system access coordination does not satisfy the on-demand standard regardless of whether the underlying data exists.

Does GV.OC.S2(G3) require that SEBI have direct access to log systems, or that entities can produce exports on request?

GV.OC.S2(G3) requires that logs, user details, and application data be accessible to SEBI on demand. This is interpreted as the ability to produce structured exports in response to regulatory requests, not as a requirement for SEBI to have direct system access. The regulated entity produces the requested data in structured format for submission to SEBI. The key requirements are that the data can be produced promptly, that it is complete for the requested period, and that its integrity can be demonstrated through the append-only log architecture.

What is the difference between the log access requirement in GV.OC.S2(G3) and the session activity logging requirement in PR.AA.S12?

PR.AA.S12 covers the content requirement for privileged session logs: what must be captured during privileged sessions, specifically activity at the command and query level. GV.OC.S2(G3) covers the accessibility requirement for all logs: how they must be stored and made available for regulatory examination. Both apply simultaneously. PR.AA.S12 determines what is in the privileged session log. GV.OC.S2(G3) determines how that log, along with all other IAM-generated logs, must be structured and accessible. Satisfying PR.AA.S12 without satisfying GV.OC.S2(G3) means the right content is captured but cannot be produced in the way SEBI requires.

How does the GV.OC.S2(G3) on-demand requirement interact with data protection obligations under DPDPA?

Capital markets entities subject to both SEBI CSCRF and DPDPA face a potential tension between the log retention required for GV.OC.S2(G3) and the storage limitation principle under DPDPA Clause 8(4). Logs containing personal data of employees and customers must be retained for regulatory purposes but should not be kept longer than necessary. The recommended approach is to define retention periods that satisfy the longer of the regulatory requirement and the data protection principle, apply data minimisation within the log by capturing only the fields required for compliance purposes, and implement a defined deletion schedule at the end of the retention period that itself produces an audit record.

What happens if a capital markets entity cannot produce complete log records for a SEBI-requested period due to gaps in retention or log architecture?

If a regulated entity cannot produce complete records for a SEBI-requested period, this constitutes a gap in GV.OC.S2(G3) compliance. The severity of the consequence depends on the nature of the gap: a technical failure causing log loss is treated differently from a deliberate retention policy that deleted records before the retention period required. Either way, the entity should document the gap, explain the cause, and provide whatever records are available along with a remediation plan. Proactive disclosure of log architecture gaps before an examination is preferable to discovering them during one.

Can the same centralised log architecture satisfy both SEBI CSCRF GV.OC.S2(G3) and RBI Clause 15’s on-demand evidence requirement simultaneously?

Yes. RBI Clause 15 requires audit trails available for forensic investigation and regulatory examination. SEBI CSCRF GV.OC.S2(G3) requires logs accessible to SEBI on demand. Both requirements are satisfied by a centralised, append-only, structured audit log with export capability covering all IAM-generated events. The same export produced for a SEBI examination request satisfies the on-demand accessibility standard. The same records, with their tamper-evident append-only architecture, satisfy the forensic investigation standard. For entities regulated by both RBI and SEBI, the log architecture investment addresses both frameworks simultaneously.

Introduction

GDPR consent requirements are specific, technically demanding, and frequently misimplemented. Article 6 establishes consent as one of six lawful bases for processing. Article 7 sets the conditions that make consent valid. Article 9 imposes additional requirements for consent to process special category data. Together, they define a consent infrastructure standard that goes significantly beyond a checkbox on a registration form.

The most common implementation gap is the conflation of consent capture with consent management. Capturing consent means recording that a user clicked agree. Managing consent means maintaining a versioned, purpose-specific, withdrawable, auditable consent record per Data Subject that demonstrates ongoing lawful basis for every processing activity. GDPR requires the latter.

The accountability principle in Article 5(2) and Article 7(1) requires that controllers be able to demonstrate that consent was given. Demonstration requires structured records, not a database row indicating that a form was submitted. A supervisory authority examining consent compliance will ask to see the consent record for a specific Data Subject, the notice version under which consent was given, the specific purposes consented to, and whether any withdrawals have been recorded. A system that cannot produce this information per Data Subject per purpose per notice version is not a compliant consent management system.

This blog covers what Articles 6, 7, and 9 each require technically, how a compliant consent management infrastructure must be architected, and how Akku’s CIAM Consent Manager addresses each requirement. All article references are drawn from the GDPR and Akku’s GDPR compliance mapping documentation.

Lawful Basis Requirements Under Article 6

Article 6 establishes six lawful bases for processing personal data. Consent is one of them. The others are contract, legal obligation, vital interests, public task, and legitimate interests. Organisations that rely on consent as their lawful basis for some or all processing activities must implement a compliant consent management infrastructure. Organisations that rely primarily on other lawful bases may have limited consent management requirements, but they must still be able to demonstrate which lawful basis applies to each processing activity.

What Article 6 requires for consent as a lawful basis

Article 6(1)(a) permits processing where the Data Subject has given consent to processing of their personal data for one or more specific purposes. The specific purposes requirement is critical: a single consent covering all processing purposes does not satisfy Article 6(1)(a)’s specificity requirement. Each processing purpose requires its own consent record.

The specific purposes requirement also means that processing cannot extend beyond the purposes consented to. If a Data Subject consents to processing for service delivery but not for marketing, processing for marketing purposes without a separate consent is unlawful under Article 6.

What this requires technically

Purpose-specific consent records are the core technical requirement. The consent management system must maintain a separate consent record per Data Subject per processing purpose. Each record must capture the Data Subject identity, the specific purpose, the notice version under which consent was given, and the consent timestamp.

The system must be capable of evaluating whether a valid consent record exists for a given Data Subject and processing purpose before processing occurs. Where no valid consent exists and no other lawful basis applies, processing must not proceed.

Akku’s CIAM Consent Manager maintains purpose-specific consent records per Data Subject. The consent record data model captures Data Subject identity, processing purpose, notice version, consent timestamp, channel, and withdrawal status. Each processing purpose has a separate record, allowing partial consent and partial withdrawal.

Consent Validity Conditions Under Article 7

Article 7 sets four conditions for valid consent: freely given, specific, informed, and unambiguous indication of agreement. Each condition has a technical implementation requirement.

Freely given

Article 7(4) provides that consent is not freely given if it is bundled with other agreements as a condition of service when the processing is not necessary for the performance of that contract. A terms-of-service acceptance that bundles consent to marketing processing with consent to service delivery processing, where the marketing consent is not necessary for service delivery, does not constitute freely given consent for the marketing purpose.

Technically, freely given consent requires that consent to non-essential processing purposes be separately captured from agreement to service terms. The consent management system must support distinct consent events for different processing purposes rather than a single agreement covering all purposes.

Specific

Article 7’s specificity requirement reinforces Article 6(1)(a)’s specific purposes condition. Consent must be given for a defined processing purpose. A consent to unspecified future processing or to a broadly-defined category of purposes does not satisfy the specificity requirement.

Technically, specificity requires that each consent record references a specific, defined processing purpose description. The purpose description must be sufficiently granular that the Data Subject can understand what they are consenting to.

Informed

Consent must be given with the benefit of a compliant notice as required by Articles 13 and 14. The Data Subject must have received information about the controller’s identity, the processing purposes, the legal basis, retention periods, Data Subject rights, and the right to withdraw consent before consenting. Consent obtained without a compliant preceding notice is not informed consent.

Technically, informed consent requires that the consent event is linked to a specific notice version. The consent management system must record which notice version was presented before consent was sought. When the notice changes, existing consents remain valid only for the purposes and notice content under which they were given. New or changed processing purposes require fresh consent under the updated notice.

Unambiguous indication of agreement

Article 7 requires that consent be given through a clear affirmative action. Pre-ticked boxes, inactivity, or silence do not constitute unambiguous consent. The Data Subject must take a positive action to indicate agreement.

Technically, unambiguous consent requires that the consent capture mechanism records a positive action by the Data Subject, not an absence of objection. The record must capture the action taken, such as button click, form submission, or API consent event, not only the resulting consent state.

Withdrawal under Article 7(3)

Article 7(3) requires that the Data Subject can withdraw consent at any time and that withdrawal must be as easy as giving consent. Processing must cease when consent is withdrawn. The right to withdraw must be communicated to the Data Subject before they give consent.

Technically, withdrawal requires a self-service interface accessible through the same channel as the original consent mechanism. Withdrawal must not require contacting support. On withdrawal, downstream processing systems must be notified to cease processing. The notification must be automated at scale.

Akku’s CIAM Consent Manager addresses Articles 5(1)(a), 5(1)(b), 5(1)(c), 5(1)(d), 5(2), 6(1), 7(1), 7(2), 7(3), 7(4), and 8(1) across 28 mapping points in Akku’s GDPR compliance documentation, the largest single-module count in the mapping.

Demonstrating Consent Under Article 7(1)

Article 7(1) requires that where processing is based on consent, the controller must be able to demonstrate that the Data Subject has given consent. This is the accountability requirement for consent specifically.

What demonstration requires technically

Demonstration requires that for every Data Subject whose personal data is processed on the basis of consent, the controller can produce a structured consent record showing: the Data Subject identity, the processing purpose, the notice version under which consent was given, the consent timestamp, the channel through which consent was given, and whether the consent remains valid or has been withdrawn.

A supervisory authority examination may request consent records for a specific Data Subject or a sample of Data Subjects. The records must be producible from a structured, queryable system, not reconstructed from server logs or inferred from application behaviour.

The records must also be tamper-evident. A consent record that can be modified after the fact cannot satisfy Article 7(1)’s demonstration requirement because its accuracy is not verifiable. Append-only consent records where each event is logged without modifying previous entries constitute the tamper-evident standard.

How Akku produces it

Akku’s CIAM Consent Manager maintains a complete consent history per Data Subject per processing purpose. Every consent event, update, and withdrawal is added as a new record rather than overwriting the previous state. The history is append-only and tamper-evident. A supervisory authority examination request for a specific Data Subject’s consent history can be fulfilled from a structured query against the consent record database, producing a complete chronological record of every consent event with timestamps and notice version references.

Special Category Data Requirements Under Article 9

Article 9 prohibits processing of special category data unless one of the listed exceptions applies. Article 9(2)(a) permits processing of special category data where the Data Subject has given explicit consent for one or more specified purposes.

What explicit consent for special category data requires

Explicit consent for special category data is a higher standard than standard consent. The Data Subject must explicitly consent to the processing of a specific category of sensitive data for a specific purpose. Implicit or bundled consent does not satisfy the explicit requirement.

Special category data includes data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data for the purpose of uniquely identifying a person, health data, and data concerning sex life or sexual orientation. For organisations processing any of these categories, explicit consent requirements must be implemented separately from standard processing consent.

What this requires technically

A separate consent flow for each special category data processing purpose is required. The consent capture must make clear to the Data Subject that they are consenting to processing of a specific sensitive data category. The consent record must capture the special category data type alongside the processing purpose.

The higher standard of explicit consent means that the consent capture mechanism must produce clearer evidence of a deliberate, informed decision than standard consent mechanisms. Two-step confirmation flows, where the Data Subject first receives information about the special category data and then takes a separate explicit confirmation action, are a common technical implementation of the explicit consent standard.

Akku’s CIAM Consent Manager addresses Article 9(2)(a) through special category consent workflows within the consent management infrastructure.

Notice Requirements That Precede Valid Consent

Valid consent under Articles 6 and 7 requires a preceding compliant notice. Articles 13 and 14 define what the notice must contain. The notice infrastructure is therefore a prerequisite for the consent management infrastructure.

Notice versioning requirement

Every consent record must reference the notice version under which it was obtained. This requires that the consent management system maintains a versioned notice registry, with each version identified by a version number or effective date. When the notice is updated, the new version is added to the registry. Consent records reference the specific version presented before consent was sought.

Notice versioning is the mechanism that allows the controller to demonstrate that consent was informed: the consent record references the notice version, and the notice version record shows what information the Data Subject received before consenting.

Re-consent for notice changes

When the notice changes in a material way, such as a new processing purpose being added or the retention period changing, Data Subjects who consented under the previous notice must be re-consented under the new notice for the affected purposes. The re-consent workflow must present the updated notice and capture a new consent event linked to the new notice version.

The controller must be able to demonstrate which Data Subjects are operating under which notice version at any point in time. This requires the consent record data model to capture notice version per consent record, not just per Data Subject.

How CIAM Consent Manager Addresses Articles 6, 7, and 9

Akku’s CIAM Consent Manager implements the technical infrastructure for GDPR consent management across Articles 6, 7, and 9 through six core capabilities.

Centralised consent record storage maintains versioned, timestamped consent records per Data Subject per processing purpose. Every consent event is stored with Data Subject identity, purpose, notice version, timestamp, and channel.

Versioned notice management maintains a notice registry with version history. Every consent record references the applicable notice version. Re-consent workflows support notice updates requiring fresh consent.

Purpose-specific consent capture supports separate consent events per processing purpose, satisfying Article 6(1)(a)’s specificity requirement and Article 7(4)’s freely-given condition.

Self-service withdrawal interface accessible through the same channel as original consent, with automated downstream processing cessation notifications, satisfying Article 7(3).

Special category consent workflows implement the explicit consent standard for Article 9(2)(a) processing purposes.

Append-only consent audit trail captures every consent lifecycle event in tamper-evident format, satisfying Article 7(1)’s demonstration requirement and Article 5(2)’s accountability principle.

Diagnostic Questions

For any Data Subject whose personal data you are processing on the basis of consent, can you produce a structured consent record showing the specific purposes consented to, the notice version under which consent was given, and the consent timestamp, without manual reconstruction?

Does your consent capture mechanism support separate consent events per processing purpose, or does it capture a single agreement covering all processing activities?

When your privacy notice changes materially, does your consent management system identify which Data Subjects require re-consent under the new notice and initiate a re-consent workflow automatically?

Is consent withdrawal achievable through a single self-service action in the same interface where consent was given, with automated processing cessation across all connected systems on withdrawal?

For Data Subjects whose data you process under special category consent, does your consent record capture the specific data category and purpose for which explicit consent was given, separately from standard processing consent?

CTAs

See how Akku’s CIAM Consent Manager addresses GDPR Articles 6, 7, and 9 requirements across consent capture, record management, withdrawal, and audit trails.

Book a conversation with the Akku team to assess your current consent management infrastructure against GDPR’s technical requirements.

FAQs

What is the difference between consent as a lawful basis and other lawful bases under Article 6, and when should organisations use consent?

GDPR Article 6 provides six lawful bases for processing. Consent is appropriate when the processing is genuinely optional, the Data Subject has a real choice, and the organisation does not have an existing contractual or legal basis for the processing. Consent is not appropriate as a substitute for other lawful bases when processing is necessary for contract performance or legal compliance. Relying on consent for processing that is actually necessary for a contract creates a practical problem: if the Data Subject withdraws consent, the organisation cannot use the contractual necessity basis retrospectively. Organisations should identify the most appropriate lawful basis for each processing activity rather than defaulting to consent for all processing.

What does Article 7(4) mean for organisations that bundle consent with service terms?

Article 7(4) provides that consent is not freely given if it is made conditional on a contract that is not necessary for the processing purposes bundled into the consent. If an organisation’s service terms include a checkbox that both accepts the terms of service and consents to marketing processing, the marketing consent is not freely given because it is bundled with the service agreement as a condition of access. The marketing consent must be separately capturable and refusable without affecting access to the service. Technically, this requires separate consent capture mechanisms for processing purposes that are not necessary for the core service.

How does Article 7(3)’s withdrawal requirement interact with processing that was lawfully conducted before withdrawal?

Article 7(3) requires that withdrawal of consent does not affect the lawfulness of processing carried out on the basis of consent before withdrawal. Processing that occurred while consent was valid is not retrospectively unlawful. The obligation is to cease processing from the point of withdrawal and, where requested, to erase the data. The consent management system must record the withdrawal timestamp precisely so that the lawfulness boundary between pre-withdrawal and post-withdrawal processing can be demonstrated.

What makes consent to special category data processing explicit under Article 9(2)(a)?

Explicit consent for special category data requires a higher standard of clarity than standard consent. The Data Subject must explicitly agree to processing of a specific category of sensitive data for a specific purpose. Implicit consent, such as providing health data on a form without a specific consent statement, does not satisfy the explicit standard. Two-step confirmation flows where the Data Subject first receives information about the special category data and then takes a separate explicit confirmation action, combined with a consent record that captures the specific data category and purpose, is the common technical implementation of the explicit consent standard.

Does GDPR require organisations to re-obtain consent when their privacy notice changes?

Re-consent is required when the notice changes in a material way that affects the basis on which consent was originally given. Adding a new processing purpose or changing the nature of processing that was previously described in the notice are examples of material changes requiring re-consent. Technical changes to the notice that do not affect the processing described, such as formatting updates or clarifications that do not change the substance, typically do not require re-consent. The controller must assess each notice change and determine whether the change is material enough to affect the validity of existing consents.

Can a single consent management deployment address both GDPR and DPDPA consent requirements?

Yes. GDPR Articles 6 and 7 and DPDPA Clauses 5 and 6 share substantial overlapping requirements. Both require purpose-specific consent. Both require that consent be withdrawable with equal ease to how it was given. Both require that the controller maintain records demonstrating that consent was obtained. Both require notice to precede consent. Akku’s CIAM Consent Manager implements the consent infrastructure that satisfies both frameworks from a single deployment. The consent record data model is extended to capture the specific fields each framework requires, and the notice versioning infrastructure supports compliance with both frameworks’ notice obligations simultaneously.

Introduction

SEBI CSCRF GV.OC.S2(G2) requires that responsibilities for privileged access be formally defined at capital markets entities. This is not a job description requirement. It is an access governance requirement: each privileged account must have a defined scope of access, a defined set of authorised activities, a defined approval process for session initiation, and a defined audit trail covering what occurred during every session. Defined responsibilities means technically-enforced boundaries, not documented role descriptions.

Most capital markets entities have privileged access policies that describe what administrators are permitted to do. Fewer have implemented the technical controls that enforce those boundaries and produce evidence of enforcement. A policy stating that database administrators are authorised to perform schema changes but not to query customer data is a defined responsibility on paper. A PAM implementation that restricts database session access scope to schema management operations and produces SQL query capture evidence is a technically-enforced defined responsibility.

The distinction matters because SEBI CSCRF is increasingly examined at the technical evidence layer, not the policy documentation layer. GV.OC.S2(G3)’s on-demand log access requirement means SEBI can request evidence of privileged access governance at any time. PR.AA.S12’s session activity logging requirement means session recordings must exist for every privileged session. An entity that can produce policy documents but not session recordings and access scope evidence has not satisfied the framework’s privileged access requirements.

This blog covers what SEBI CSCRF requires for privileged access governance across GV.OC, PR.AA, and GV.RM, what each requirement means technically, and how PAM controls produce the evidence the framework requires.

Defined Responsibilities Under GV.OC.S2

GV.OC.S2 sits within the Govern function’s Organisational Context sub-category. It covers the governance structures and accountability mechanisms that regulated entities must establish for cybersecurity management.

What GV.OC.S2 requires for privileged access

GV.OC.S2(G2) requires that responsibilities for privileged access to critical systems be formally defined. Each privileged account or privileged user category must have a documented and technically-enforced access scope: which systems can be accessed, which protocols are permitted, which operations are authorised, and under what conditions access may be initiated.

GV.OC.S2(G3) requires that logs, user details, and application data covering privileged access be accessible to SEBI on demand. This is an on-demand evidence obligation. The infrastructure must be capable of producing structured exports of privileged session records for any requested period without requiring manual compilation.

What this requires technically

Technically-enforced defined responsibilities require a PAM platform where access scope is configured per privileged user or role, not described in policy documents. Each privileged user’s session capability must be constrained to the systems and protocols they are authorised to access. Attempts to access systems or use protocols outside the defined scope must be blocked at the session layer, not relied on the user’s discretion.

The on-demand log access requirement under GV.OC.S2(G3) requires an append-only, tamper-evident privileged session log infrastructure with structured export capability. Logs must be producible in structured format for any period SEBI specifies. This requirement cannot be satisfied by log files stored in individual application systems that require manual aggregation.

How Akku addresses it

Akku PAM implements technically-enforced access scope through RBAC at the PAM layer. Each role defines permitted target systems, permitted protocols, permitted access hours, and JIT duration limits. A database administrator role that is configured for MySQL access on specified servers cannot open sessions to SSH servers or RDP hosts, regardless of what the policy document states. The scope is enforced at the session proxy layer, not at the user’s discretion.

AkkuReka’s session proxy architecture ensures that every privileged session routes through the platform. No direct connection between a privileged user and a target system exists outside the proxy. This architectural control ensures that the defined access scope is technically enforced for every session, producing the access governance evidence GV.OC.S2(G2) requires.

The append-only audit log with structured JSON and CSV export satisfies GV.OC.S2(G3)’s on-demand access requirement. Every privileged session record is available for export covering any requested period without manual compilation.

Privileged Access Governance Under PR.AA.S10 to S12

PR.AA.S10 through PR.AA.S12 define the technical privileged access management standard for SEBI-regulated entities. These guidelines require separate management of privileged accounts, formal approval for every session, and session-level activity logging.

PR.AA.S10: Separate management of privileged accounts

PR.AA.S10 requires that privileged accounts be separately identified, managed, and monitored. Privileged users must not use privileged credentials for routine non-administrative tasks. Each privileged account must be individually accountable with no shared administrative credentials.

Technically, separate management means privileged accounts must be distinct from standard user accounts. A system administrator should not use their privileged account for email, web browsing, or standard business application access. The privileged account is used exclusively for privileged sessions initiated through the PAM platform.

AkkuArka’s per-session ephemeral credential model enforces account separation at the credential layer. No privileged user holds standing credentials to target systems. Credentials are generated at session approval and revoked at session close. The privileged account in the target system is managed by AkkuArka, not by the user directly.

PR.AA.S11: Formal approval and time-limited access

PR.AA.S11 requires that privileged access be granted based on formal approval, with access scope defined and time-limited where possible. GV.RM.S1(G1c) reinforces this by requiring that high-privilege access be treated as a specific risk category.

Technically, formal approval requires a session request workflow where the privileged user submits a request specifying the target system, access level, duration, and justification. An approver reviews the request and explicitly approves or denies it. No session opens without an approved request when the workflow is enabled.

Time-limited access requires JIT session windows that expire automatically. The maximum session duration is configurable per role. On expiry, the session is automatically terminated, the ephemeral credential is revoked, and access is removed. Standing privilege with no defined time limit is architecturally impossible under this model.

Akku’s session approval workflow captures target system, access level, duration, justification, approver identity, and approval timestamp for every privileged session. JIT windows expire automatically with session termination and credential revocation logged.

PR.AA.S12: Session activity logging

PR.AA.S12 requires that all privileged session activity be logged with sufficient detail to reconstruct the actions taken during the session. Authentication records confirming a session occurred do not satisfy this requirement.

Technically, session activity logging at the level PR.AA.S12 requires means keystroke logs for SSH sessions, SQL query capture for database sessions, and screen recordings for RDP sessions. These must be generated at the protocol layer by the session proxy, not by the target system’s own logging mechanisms, which can be disabled or modified by a sufficiently privileged user.

SMARTAudit Trails satisfy PR.AA.S12 across all supported protocol types. SSH sessions produce full screen recordings and complete keystroke logs. Database sessions produce full screen recordings and structured SQL query capture. RDP sessions produce full screen video recordings. All recordings are stored encrypted, indexed for forensic search, and accessible from the Akku admin console.

Risk Management Requirements Under GV.RM

GV.RM.S1 and GV.RM.S2 require that capital markets entities treat privileged access as a specific risk category within their risk management framework. This creates governance obligations that complement the technical controls.

What GV.RM requires

GV.RM.S1(G1c) requires that high-privilege access be identified as a risk category with associated risk treatment measures. The risk treatment for privileged access is the PAM control set: formal approval workflows, per-session ephemeral credentials, session activity logging, and periodic access reviews.

GV.RM.S1(G1d) requires that risk treatment measures include monitoring and review of privileged access activity. This maps to the real-time session monitoring capability that allows administrators to view active sessions and the periodic review of privileged access entitlements through access certification campaigns.

How Akku addresses it

Akku’s privileged access governance infrastructure constitutes the risk treatment measure that GV.RM.S1(G1c) requires for high-privilege access. The formal approval workflow, per-session ephemeral credentials through AkkuArka, session activity logging through SMARTAudit Trails, and real-time monitoring through AkkuReka together form the technical risk treatment for privileged access as a risk category.

Periodic access review and re-certification campaigns for privileged entitlements satisfy GV.RM.S1(G1d)’s monitoring and review requirement. Every privileged access entitlement is reviewed on a defined cadence, with documented certification or revocation decisions.

Akku’s SEBI mapping shows Privileged Access Manager addresses PR.AA.S11, PR.AA.S10 to S12 guideline references G2a, G2b, G2c, PR.AA.S15(G4c), PR.DS.S4(G2), PR.MA.S2(G3), and GV.RM.S1 to S2(G1c) across 12 total guideline mappings.

Privileged Access Audit Evidence for SEBI Examination

SEBI CSCRF’s on-demand log access requirement under GV.OC.S2(G3) means that privileged access evidence must be continuously maintained and immediately producible, not assembled before examination.

What a SEBI examination of privileged access expects

A SEBI examination of privileged access governance at a capital markets entity typically covers: evidence that privileged accounts are separately managed with no shared credentials, session request and approval records showing formal authorisation for sampled sessions, session activity logs covering what privileged users did during sampled sessions, evidence that JIT access windows are time-limited and automatically terminated on expiry, periodic access review records showing that privileged entitlements are certified regularly, and structured log exports demonstrating that privileged session records are available on demand for any requested period.

How the evidence package is assembled

Each category of evidence is available as a continuous output from Akku’s privileged access infrastructure. Session approval records are stored in the audit log at the time of each approval event. SMARTAudit Trail recordings are generated and indexed at the time of each session. JIT expiry events are logged with session termination and credential revocation timestamps. Access review records are generated at the time of each certification campaign cycle.

When a SEBI examination requests privileged access evidence for a specified period, the evidence package is assembled from the audit log and session recording index without retrospective compilation. The on-demand accessibility is a structural property of the infrastructure, not a preparation exercise.

Diagnostic Questions

For every privileged session to a critical trading or settlement system in the last 90 days, is there a session recording capturing what the privileged user did, and can you produce it within the same business day of a SEBI request?

Does your privileged access infrastructure technically enforce the defined scope of each privileged role, blocking sessions to systems or protocols outside the defined scope at the session proxy layer, or does enforcement rely on user discretion?

Can you produce a structured export of all privileged session records for any 90-day period SEBI specifies, in JSON or CSV format, without manual log compilation from individual application systems?

When a JIT session window expires, is the session automatically terminated and the credential automatically revoked with a timestamped audit record, or does expiry rely on the administrator manually closing the session?

Has your organisation reviewed and certified all privileged access entitlements in the last 12 months, with a documented record of every certification or revocation decision made during that review?

CTAs

See how Akku maps to SEBI CSCRF privileged access requirements across GV.OC, PR.AA, and GV.RM guidelines.

Book a conversation with the Akku team to assess your current privileged access governance against SEBI CSCRF’s technical obligations.

FAQs

What does GV.OC.S2(G2)’s defined responsibilities requirement mean for privileged access, and how is it different from a job description?

A job description describes what an administrator is expected to do in their role. GV.OC.S2(G2)’s defined responsibilities requirement means that the PAM infrastructure technically enforces what each privileged user can do: which systems they can access, which protocols are permitted, which operations are authorised, and under what conditions sessions may be initiated. A database administrator whose defined responsibilities include schema management but not customer data queries must have a PAM role configuration that blocks queries to customer data tables, not merely a job description that states such queries are outside their remit. Technical enforcement is the operative requirement.

What is the difference between PR.AA.S11 and PR.AA.S12, and what separate controls does each require?

PR.AA.S11 covers the authorisation and governance of privileged sessions: how they are requested, approved, scoped, and time-limited. It is satisfied by a formal session approval workflow with JIT access windows and per-session ephemeral credentials. PR.AA.S12 covers the logging of what happened during privileged sessions: commands executed, queries run, screen activity recorded. It is satisfied by SMARTAudit Trails capturing session activity at the protocol layer. Both are required simultaneously. An entity with formal approval workflows but no session activity logging satisfies PR.AA.S11 but not PR.AA.S12. An entity with session recordings but no formal approval process satisfies PR.AA.S12 but not PR.AA.S11.

Why does SEBI CSCRF require per-session ephemeral credentials rather than allowing standing privileged credentials?

Per-session ephemeral credentials eliminate the standing credential risk that makes privileged account compromise the highest-impact attack vector in capital markets environments. A standing credential that is valid indefinitely can be stolen through phishing, credential stuffing, or insider access and used to open privileged sessions outside the PAM governance framework. A per-session ephemeral credential exists only for the duration of an approved session. It cannot be stolen and reused because it is permanently revoked on session close. PR.AA.S11’s time-limited access requirement and PR.AA.S10’s individual account accountability requirement together create the governance basis for the per-session ephemeral credential model.

How does real-time session monitoring satisfy SEBI CSCRF’s privileged access requirements?

Real-time session monitoring allows administrators to view all active privileged sessions and terminate any session exhibiting suspicious behaviour instantly. For SEBI CSCRF, real-time monitoring satisfies the supervision component of GV.OC.S2(G2)’s defined responsibilities requirement: not only must responsibilities be defined, but privileged sessions must be visible to administrators who can intervene when necessary. Session termination events are logged with actor, timestamp, and reason, producing an audit record of supervisory actions taken. This evidence demonstrates that the privileged access governance framework is actively operated, not merely configured.

What does SEBI CSCRF require for third-party and contractor privileged access, and how does this differ from internal privileged user requirements?

SEBI CSCRF GV.SC.S4 requires that third-party and supply chain access be governed through lifecycle controls equivalent to those for internal users, including time-bound access and prompt revocation on engagement end. For privileged access, this means contractors and third-party administrators must be subject to the same PAM governance framework as internal privileged users: formal session approval, defined access scope, per-session ephemeral credentials, session activity logging, and JIT access windows. The session approval workflow should capture the engagement scope and end date, with automatic access expiry configured to align with the engagement end. There is no reduced requirement for third-party privileged access compared to internal privileged access.

Can SEBI request privileged session recordings as part of a regulatory examination, and how should entities prepare for this?

GV.OC.S2(G3) requires that logs, user details, and application data be accessible to SEBI on demand. Session recordings are logs of privileged user activity. Entities should assume that SEBI examinations can include requests for specific session recordings as part of an investigation into cybersecurity incidents, access control compliance, or privileged activity reviews. Preparation requires that session recordings are stored with consistent metadata including session ID, actor identity, target system, and timestamp, indexed for retrieval by any of these fields, and accessible in exportable format for submission. The infrastructure must be capable of producing specific session recordings within the timeframe of a regulatory request.