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.
