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.