Introduction

IRDAI ICS Annexure III contains detailed endpoint security requirements that are among the most technically specific in the guidelines. Items 11, 15, 28, and 31 address session lockout, removable media controls, peripheral device restrictions, and URL filtering respectively. Together they define an endpoint security baseline that applies to every managed device across the insurer’s environment.

Most insurance IT teams have policies addressing these requirements. Session lockout is documented in the IT security policy. USB use is described as restricted. Bluetooth connections to corporate devices are stated as controlled. URL filtering is listed as a security measure. The compliance gap is almost always between the policy statement and technical enforcement. A session lockout policy that relies on users configuring their own screen saver settings is not a technically-enforced control. A USB restriction policy that requires users to request exceptions is not the same as a GPO that blocks USB storage devices at the operating system layer.

IRDAI IS auditors examining these items assess technical enforcement, not policy documentation. Item 11’s session lockout requirement is examined by testing whether devices actually lock after the defined inactivity period, not by reading the policy. Item 15’s removable media requirement is examined by attempting to connect a USB storage device and verifying it is blocked, not by reviewing the acceptable use policy.

This blog covers what each of the four items requires technically, how GPO Manager and MDM implement the controls, and what evidence each control produces for IS audit examination.

Item 11: Session Lockout Requirements

Item 11 requires automatic session lockout after a defined period of inactivity on managed endpoints. The lockout must be technically enforced, not user-configured.

What Item 11 requires technically

Automatic session lockout requires a centrally-configured policy that applies a screen lock after a defined inactivity timeout. The policy must be enforced at the operating system layer, not relying on users to configure their own lock screen settings. Users must not be able to disable or extend the lockout timeout without administrative approval.

The inactivity threshold must be defined in the IT security policy and technically configured to match. Common thresholds at insurance organisations are five minutes for devices in shared or public areas and ten to fifteen minutes for individual workstations in secure office environments. The threshold should be shorter for devices with access to sensitive customer or policy data.

The lockout must require re-authentication before the session resumes. A screen that locks but can be dismissed without entering credentials does not satisfy the security objective of Item 11. The re-authentication requirement connects Item 11 to the centralised authentication infrastructure: the lockout screen should require the user to re-authenticate through the same identity layer as the initial login.

How Akku addresses it

GPO Manager enforces session lockout policies centrally across Windows, macOS, and Linux endpoints from a single dashboard. The inactivity timeout is configured at the organisational unit or group level, ensuring consistent enforcement regardless of individual user configuration. Users cannot modify the lockout timeout without administrative access to the GPO configuration.

For mobile devices managed through MDM, equivalent passcode lock policies enforce automatic device lock after a defined inactivity period. MDM-enforced passcode requirements ensure that the lock screen requires credential entry to resume the session.

The GPO configuration record constitutes the technical enforcement evidence Item 11 requires. IS auditors examining Item 11 can verify the configured timeout in the GPO policy and test enforcement on a sample of managed endpoints. Akku’s IRDAI mapping shows GPO Manager and MDM together address Item 11 within the combined 31-mapping endpoint security coverage.

Item 15: Removable Media Controls

Item 15 requires controls on the use of removable media including USB storage devices on managed endpoints. The control must prevent data exfiltration through USB storage without authorised exception management.

What Item 15 requires technically

USB storage device restrictions must block the mounting of USB storage devices at the operating system layer. A policy stating that USB storage is restricted does not prevent a user from connecting a USB drive and copying files to it. A GPO that blocks USB storage device class at the driver level prevents the device from mounting regardless of user intent.

The restriction must apply to USB storage specifically. USB peripherals that are not storage devices, keyboards, mice, headsets, and similar devices, should not be blocked unless specific policy requires it. A well-configured USB restriction blocks the USB Mass Storage device class while permitting other USB device classes.

Exception management requires a formal approval process for temporary USB access where legitimate business need exists. The exception must be time-bound, logged, and revoked automatically at expiry. Standing exceptions that persist indefinitely undermine the control.

How Akku addresses it

GPO Manager enforces USB storage restrictions at the operating system layer across Windows, macOS, and Linux endpoints. The USB Mass Storage device class is blocked by default. USB peripherals of other classes continue to function normally. The restriction applies consistently across all managed endpoints in the organisational unit or group the policy targets.

For mobile devices, MDM enforces equivalent data transfer restrictions, blocking file transfer through USB connections and restricting AirDrop and Bluetooth-based file sharing.

The GPO enforcement record and audit log of USB connection attempts provide the IS audit evidence for Item 15. An auditor testing Item 15 compliance by connecting a USB storage device to a managed endpoint will find the device does not mount. Akku’s IRDAI mapping shows Items 15 and 201 among the 31 endpoint-related mappings covered by the combined GPO Manager and MDM module pair.

Item 28: Bluetooth and Peripheral Device Controls

Item 28 requires controls on Bluetooth usage and peripheral device connections to reduce data transfer and unauthorised pairing risks. Insurance environments where agents and intermediaries carry mobile devices create specific Bluetooth risk scenarios that Item 28 addresses.

What Item 28 requires technically

Bluetooth restrictions on managed endpoints must prevent unauthorised device pairing and data transfer through Bluetooth connections. The restriction can be implemented at two levels: disabling Bluetooth entirely on managed endpoints where business need does not require it, or restricting Bluetooth to approved device categories and pairing to pre-approved devices.

For insurance agent environments where mobile devices may need Bluetooth connectivity for legitimate purposes, selective restriction is more operationally viable than blanket disabling. Restricting Bluetooth file transfer while permitting Bluetooth audio and input device connections addresses the data exfiltration risk without blocking legitimate usage.

For workstations in secure data processing environments, complete Bluetooth disabling is the appropriate control. A customer data processing workstation has no legitimate business requirement for Bluetooth connectivity.

Camera and microphone controls, also addressed within the Item 28 context, require restrictions on camera and microphone usage on managed endpoints in sensitive areas. Covert capture through endpoint cameras and microphones is a data security risk in environments processing confidential insurance data.

How Akku addresses it

GPO Manager enforces Bluetooth limitations on Windows, macOS, and Linux endpoints. Bluetooth can be disabled entirely for specific organisational units or restricted to specific permitted device categories. Camera and microphone access can be blocked through GPO controls restricting application access to these peripherals.

MDM enforces equivalent controls on Android and iOS devices. Camera access can be restricted per device or per organisational group. Bluetooth settings can be controlled to prevent file transfer while permitting other Bluetooth usage categories.

The GPO and MDM configuration records, combined with audit logs of policy enforcement events, constitute the IS audit evidence for Item 28. Akku’s IRDAI mapping covers Items 27, 28, 73, 75, 81, and 86 within the endpoint control section of the combined GPO Manager and MDM mapping.

Item 31: URL Filtering Requirements

Item 31 requires URL filtering to restrict access to high-risk or non-business web categories from managed endpoints. URL filtering is a dual-purpose control: it reduces malware exposure from high-risk web categories and prevents data exfiltration through web-based channels including personal cloud storage, personal email, and file-sharing services.

What Item 31 requires technically

URL filtering must be enforced at the DNS or proxy layer, not relying on browser settings that users can modify. DNS-based filtering blocks resolution of domains in restricted categories before any connection is established. This is more robust than browser-level filtering, which can be bypassed by changing browser settings or using an alternative browser.

The filtering must cover the categories that represent the highest risk in an insurance environment. At minimum, this includes malware and phishing domains, personal cloud storage services such as consumer Dropbox and Google Drive personal accounts, personal email services, file-sharing and upload services, and categories associated with policy data exfiltration.

The filtering should produce access attempt logs that record blocked requests with the user identity, the attempted URL or domain, the blocking category, and the timestamp. These logs are both an operational security signal and an IS audit evidence source.

For remote workers accessing the internet from outside the corporate network, URL filtering through a cloud-based DNS filtering service extends the control to off-network endpoints. Corporate network-only filtering leaves remote endpoints unprotected during the majority of their operational time.

How Akku addresses it

GPO Manager implements DNS-based URL filtering across managed endpoints. Category-based filtering blocks domains in configured restricted categories. The filtering applies regardless of which browser the user is using or what browser settings they have configured. For remote endpoints, DNS filtering through the endpoint’s DNS resolver extends the control to off-network access.

In addition to DNS-based category filtering, GPO Manager enforces specific application-level blocks on personal cloud drives, personal email access through browser interfaces, FTP client usage, and upload services. These targeted controls address the specific data exfiltration channels that Item 31 is designed to prevent.

Access attempt logs from the filtering infrastructure record blocked requests with user identity, domain, category, and timestamp. These logs are queryable from the Akku admin console and constitute the IS audit evidence for Item 31 enforcement. Akku’s IRDAI mapping covers Items 31, 44, 107, 185, 193, 194, 197, 216, 217, 261, 280, and 305 within the network and data control section of the combined GPO Manager and MDM mapping.

Why Endpoint Controls Are the Largest Single Coverage Area in Akku’s IRDAI Mapping

GPO Manager and MDM together carry 31 of the 97 total IRDAI control mappings in Akku’s compliance documentation, the highest combined module count. This reflects the IRDAI ICS Guidelines’ detailed and specific endpoint security requirements across session management, peripheral controls, network access, data protection, and device governance.

The 31 mappings span Items 11, 15, 18, 27, 28, 31, 36, 37, 44, 73, 75, 81, 86, 87, 102, 106, 107, 111, 154, 177, 185, 193, 194, 197, 201, 216, 217, 261, 270, 280, and 305. Together these items define the IRDAI ICS endpoint security baseline across device enrollment, session security, peripheral restrictions, data transfer controls, network access governance, and system configuration requirements.

The concentration of IRDAI requirements in the endpoint layer reflects the guidelines’ recognition that insurance environments, particularly those with field agent networks, BYOD programmes, and distributed branch operations, face significant data security risk at the device layer. Controls at the identity and application layer are necessary but not sufficient. Endpoint-level enforcement is required to address the data exfiltration, device compromise, and configuration drift risks that identity controls alone cannot prevent.

Diagnostic Questions

Do managed endpoints in your organisation lock automatically after a defined inactivity period with a centrally-configured GPO policy, or does the lockout rely on individual user screen saver settings?

When a USB storage device is connected to a managed endpoint in your environment, is it blocked at the OS layer by a GPO restricting the USB Mass Storage device class, or is the restriction enforced through a policy statement that users are expected to follow?

Does your URL filtering apply to remote endpoints accessing the internet from outside the corporate network, or only to devices on the corporate network?

Are access attempt logs from URL filtering available for IS audit examination, showing blocked requests with user identity, domain, category, and timestamp, or does the filtering operate without producing queryable logs?

For mobile devices used by insurance agents and intermediaries, do MDM policies enforce the same data transfer and peripheral controls as GPO policies on corporate workstations, or are mobile endpoints subject to weaker controls?

CTAs

See how Akku’s GPO Manager and MDM address IRDAI ICS endpoint security requirements across session lockout, removable media, peripheral controls, and URL filtering.

Book a conversation with the Akku team to assess your current endpoint security posture against IRDAI ICS Annexure III requirements.

FAQs

What is the difference between a policy-stated USB restriction and a technically-enforced USB restriction for IRDAI Item 15 purposes?

A policy-stated restriction is a document stating that USB storage devices should not be used without authorisation. It relies on user compliance and manual enforcement. A technically-enforced restriction is a GPO that blocks the USB Mass Storage device class at the operating system driver layer, preventing any USB storage device from mounting regardless of user intent. IRDAI IS auditors examining Item 15 test technical enforcement, not policy existence. They connect a USB storage device to a managed endpoint and verify it does not mount. A policy document does not prevent the device from mounting. A GPO does.

Why does Item 31 require DNS-based URL filtering rather than browser-level filtering?

Browser-level filtering can be bypassed by changing browser settings, using an alternative browser, or using a browser extension that overrides filter settings. DNS-based filtering operates below the browser layer: it blocks the DNS resolution of restricted domains before any TCP connection is established, regardless of which browser or application initiates the request. This makes DNS-based filtering significantly more robust against user circumvention. For insurance environments where data exfiltration risk through web channels is a compliance concern, DNS-based filtering is the technically appropriate implementation of Item 31’s URL filtering requirement.

How should insurance organisations handle legitimate business exceptions to USB storage restrictions under Item 15?

Legitimate business exceptions to USB storage restrictions require a formal approval process documented in IT security policy. The exception must specify the user, the device, the business justification, and the time period. The exception should be implemented as a time-bound GPO exception for the specific device or user rather than a blanket policy relaxation. The exception request, approval decision, implementation, and expiry must all be logged. IS auditors examining Item 15 will look for evidence that exceptions are governed through a formal process, not informally granted. Uncontrolled exception proliferation that effectively negates the USB restriction control is a finding.

Does Item 28’s Bluetooth restriction apply to all managed devices or only to devices in specific risk categories?

IRDAI ICS Item 28 applies to managed endpoints without specifying a subset. The practical implementation should be risk-stratified: devices in secure data processing environments handling confidential policyholder data should have Bluetooth disabled entirely. Devices used by field agents and intermediaries may permit Bluetooth for legitimate operational purposes such as connecting to printers or headsets, with file transfer capabilities restricted. MDM and GPO allow organisational-unit-level policy assignment, enabling different Bluetooth restriction levels to be applied to different device populations based on their risk profile and operational requirements.

How does Akku’s GPO Manager differ from Microsoft’s Group Policy for IRDAI compliance purposes?

Microsoft’s Group Policy is designed for Windows Active Directory environments. It provides endpoint policy management for Windows-domain-joined devices but requires Active Directory infrastructure and does not natively extend to macOS, Linux, or mobile devices. Akku’s GPO Manager is platform-agnostic and cloud-delivered. It applies consistent policies across Windows, macOS, and Linux endpoints from a single dashboard without requiring Active Directory infrastructure. For insurance organisations with mixed-OS environments or those that have migrated away from on-premises Active Directory, Akku’s GPO Manager provides the same endpoint policy enforcement capability across the full device estate. For IRDAI compliance purposes, the platform-agnostic coverage is significant because Items 11, 15, 28, and 31 apply to all managed endpoints regardless of operating system.

Can GPO Manager and MDM controls satisfy both IRDAI ICS and SEBI CSCRF endpoint security requirements simultaneously?

Yes. IRDAI ICS Items 11, 15, 28, and 31 and SEBI CSCRF PR.AA.S15, PR.DS.S1 to S3, and PR.DS.S4 address overlapping endpoint security requirements including session lockout, removable media controls, peripheral restrictions, and data transfer controls. The same GPO Manager and MDM configuration that enforces IRDAI Item 15’s USB storage restriction simultaneously satisfies SEBI CSCRF PR.DS.S1 to S3’s data protection requirements. Akku’s GPO Manager and MDM carry 31 IRDAI mappings and 21 SEBI CSCRF mappings respectively, reflecting the substantial overlap between the two frameworks’ endpoint security requirements. A single endpoint policy configuration satisfies both frameworks from the same technical control.

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

The difference between SOC 2 Type I and Type II is not a matter of audit scope or report length. It is a fundamentally different evidentiary standard. Type I attests that controls are suitably designed at a point in time. Type II attests that controls operated effectively throughout a defined period, typically six to twelve months. The shift from design to operating effectiveness changes what evidence is required, how it must be produced, and what constitutes a finding.

Most organisations that struggle with SOC 2 Type II do so because they approach it with a Type I mindset. They document controls thoroughly, configure systems correctly, and produce polished evidence packages. Then the auditor samples from the third month of the period and finds that the provisioning records from that month do not include approval timestamps. Or samples from the seventh month and finds that no access reviews were conducted in that quarter. Or samples from the fourth month and finds a gap in MFA enforcement logs for a critical system.

These gaps do not indicate that the controls are poorly designed. They indicate that the controls did not operate consistently throughout the period. Type II’s operating effectiveness standard is not satisfied by a well-designed control that operated correctly for part of the period. It is satisfied only by a control that operated correctly throughout the period and produced structured evidence of its operation at every point.

This blog covers what operating effectiveness means specifically, how it differs from control design, what the auditor sampling approach reveals about evidence requirements, and how continuous evidence generation from IAM controls satisfies the Type II standard.

What Operating Effectiveness Means

Operating effectiveness is the standard that distinguishes Type II from Type I. Understanding it precisely is necessary for building the evidence infrastructure that satisfies it.

Design versus operation

A control is suitably designed if its design can reasonably be expected to achieve the control objective. For access provisioning, a suitably designed control has a defined approval workflow, documented role definitions, and a provisioning system that connects the two. Type I attests to this design.

A control operates effectively if it consistently achieves the control objective in practice over time. For access provisioning, effective operation means every provisioning event during the period was processed through the approval workflow, every approval record contains the required fields, and every provisioning action was reflected in connected systems. Type II attests to this operation.

The gap between design and operation is common and predictable. A designed control may have a documented exception process that is used too frequently. A provisioning workflow may be bypassed for urgent requests. An access review may be skipped during a busy period. Each of these is a design-operation gap: the control was designed correctly but did not operate consistently.

The continuous operation requirement

Operating effectiveness requires that the control operated throughout the audit period, not only during the periods when the organisation was paying attention. An auditor sampling from twelve equally spaced points across a 12-month period will find any significant operational gaps. A control that operated for ten months and had a two-month gap will be sampled during that gap.

The continuous operation requirement means that the infrastructure generating evidence must itself be continuous. Evidence generated by automated controls is continuous by design: every provisioning event produces a record, every authentication event produces a log entry, every access review decision is timestamped. Evidence generated by manual processes is discontinuous: it exists when someone performed the manual step and is absent when they did not.

What the auditor sampling approach reveals

SOC 2 Type II auditors sample systematically across the audit period. For a 12-month period, they typically examine evidence from at least three to four points spread across the period. For specific controls, they may examine every instance during the period rather than a sample.

The sampling approach is designed to detect operational gaps. An organisation that prepared evidence only for the weeks immediately before the audit will find that auditors sample from periods when no evidence was prepared. The only sustainable response to systematic sampling is continuous evidence generation throughout the period.

IAM Controls That Must Produce Continuous Evidence

Each IAM control relevant to SOC 2 must produce evidence continuously throughout the audit period. The evidence standard for each control is specific.

Provisioning controls: CC6.2

Every user provisioned during the audit period must have a corresponding provisioning record with the complete required fields: requester, approver, approval timestamp preceding provisioning, justification, access scope, and SCIM sync confirmation. The record must exist at the time of the provisioning event, not be reconstructed before the audit.

Auditors sample provisioning events from across the period. A provisioning event from month four with no approval record is a CC6.2 finding regardless of how robust the provisioning process is for other months. The continuous evidence requirement means every event must produce a complete record.

The most common CC6.2 gap is SCIM connector failures that result in provisioning records in the IAM platform without corresponding access grants in connected applications. Connector health monitoring that detects and alerts on sync failures before they persist is the operational control that prevents this gap.

Deprovisioning controls: CC6.3

Every departure during the audit period must have a corresponding deprovisioning record covering every system from which access was removed, with same-day timestamps for employment terminations and SCIM sync confirmations for each connected application.

Auditors examine departures from across the period. A departure in month six where deprovisioning was delayed three days is a CC6.3 finding regardless of how effective deprovisioning was for other departures. The automated deprovisioning workflow triggered by HR system events is the control that produces same-day, complete deprovisioning records consistently throughout the period.

Access review controls: CC6.3

Access reviews must have been conducted on a defined cadence throughout the period, with structured evidence from every cycle. A quarterly review cycle must produce four evidence records per year. An annual review cycle must produce one. Auditors sample from across the period: if only one review occurred in the pre-audit window, samples from earlier in the period find no evidence.

The access review campaign infrastructure must be running throughout the period, not activated in preparation for the audit. Campaigns run on a configured schedule, produce structured records at each cycle, and generate timestamped decision records for every entitlement reviewed.

MFA enforcement controls: CC6.1 and CC6.6

MFA enforcement must be continuous and consistent throughout the period. The authentication event log must show that every session to in-scope systems during the period was preceded by a successful MFA event. Gaps in MFA enforcement, periods where sessions opened without MFA, are CC6.1 and CC6.6 findings.

The most common MFA gap is inconsistent coverage: MFA enforced for some systems or some access paths but not others. Auditors examining MFA enforcement across a sample of sessions will identify paths that bypass MFA. Ensuring that all session paths to in-scope systems route through the centralised MFA enforcement layer, and that the authentication event log covers all paths, prevents this gap.

Anomaly monitoring controls: CC7.2

The anomaly detection infrastructure must have been operating throughout the period, with detection events and investigation records spanning the full period. A monitoring infrastructure deployed in the month before the audit has evidence for one month. Auditors sampling from earlier in the period find no monitoring evidence.

The paradox of anomaly monitoring is that a healthy, well-monitored environment will produce anomaly detection events regularly throughout the period. An organisation that has no anomaly detection events for ten months has either an extremely clean environment or a monitoring infrastructure that is not sensitive enough to detect the anomalies that occur in any active user population. Either way, the absence of detection events raises questions that auditors will examine.

The Continuous Evidence Architecture

Satisfying SOC 2 Type II operating effectiveness requires an evidence architecture that generates structured, complete, tamper-evident records as a byproduct of daily operations, not as a preparation exercise before the audit.

Automated controls over manual processes

Manual processes generate evidence when a human performs a step. They do not generate evidence when the step is not performed. Automated controls generate evidence for every event they process, regardless of whether anyone is watching.

For provisioning, an automated workflow that captures every approval event in a structured record before provisioning executes generates continuous evidence. A manual process where an administrator emails an approval to a colleague generates evidence only when someone remembers to document it.

The shift from manual to automated controls is not primarily a productivity improvement for SOC 2 purposes. It is an evidence quality improvement: automated controls produce consistent, structured, timestamped evidence for every event, while manual processes produce inconsistent evidence that reflects operational attention rather than operational reality.

Centralised audit trail

A centralised audit trail that captures events from all IAM modules, authentication events, provisioning events, access review decisions, privileged session events, and policy changes, into a single queryable record is the infrastructure that makes continuous evidence accessible.

When an auditor samples from the fourth month of the period and requests provisioning records from that window, the centralised audit trail produces the records without requiring manual compilation from multiple systems. The accessibility of evidence is as important as its existence: evidence that exists but requires days to produce from multiple disparate systems does not satisfy the operating effectiveness examination standard.

Append-only integrity

Continuous evidence must be tamper-evident. Evidence that can be modified after the fact cannot satisfy the operating effectiveness standard because its accuracy at any sampled point in time cannot be verified. The append-only audit log architecture, where new records are added but existing records cannot be modified, is the technical basis for tamper-evident continuous evidence.

Common Operating Effectiveness Failures and How to Prevent Them

Understanding the most common operating effectiveness failures helps organisations design controls that avoid them.

Provisioning outside the formal workflow

When urgent access requests bypass the formal approval workflow, the provisioning event may be captured but the approval record is absent or informal. Auditors sampling CC6.2 will identify these instances. The prevention is configuring the approval workflow to handle urgent requests efficiently: auto-approval for low-risk access, rapid-approval paths for time-sensitive requests, and escalation workflows for emergency access, all within the formal process that produces compliant records.

Deprovisioning delays for contractor and project access

Contractor departures and project access expiry frequently produce deprovisioning delays because the trigger mechanism is less formalised than for permanent employee departures. The prevention is configuring time-bound access for all contractor and project entitlements, with automated expiry that produces deprovisioning records without requiring a manual trigger.

Access review cycle gaps

Access review cycles that skip a quarter due to competing priorities produce gaps in the review evidence that auditors will identify. The prevention is configuring the review campaign to run automatically on the defined schedule, not requiring manual initiation. A campaign that runs without administrator activation and escalates non-responses to ensure completion does not depend on anyone remembering to initiate it.

MFA coverage gaps for new systems

When new systems are added to the in-scope environment during the audit period, their authentication events may not route through the centralised MFA enforcement until the integration is completed. If the integration is delayed, there is a period when the new system’s access events are not covered by MFA. Auditors sampling that period will find the gap. The prevention is establishing a policy that new systems cannot be placed in production for in-scope services until MFA integration is complete.

Diagnostic Questions

For any provisioning event from any month in the last 12 months chosen at random, can you produce the complete approval record with requester, approver, approval timestamp preceding provisioning, justification, and SCIM sync confirmation?

For any departure from any month in the last 12 months chosen at random, can you produce the deprovisioning record covering every connected application, with same-day timestamps and SCIM sync confirmation for each?

How many access review cycles ran during the last 12 months, and is there a structured evidence record from each cycle covering every in-scope entitlement?

Can you identify any period in the last 12 months when MFA enforcement had a gap for any in-scope system, and if so, what was the root cause and how was it closed?

If an auditor sampled anomaly detection evidence from month six of your last audit period, would they find monitoring events and investigation records from that month, or would the monitoring evidence begin only in the months immediately preceding the audit?

CTAs

See how Akku generates continuous SOC 2 Type II operating effectiveness evidence across provisioning, deprovisioning, access reviews, MFA enforcement, and anomaly monitoring.

Book a conversation with the Akku team to assess whether your current IAM infrastructure produces the continuous evidence SOC 2 Type II operating effectiveness requires.

FAQs

What is the specific difference between a SOC 2 Type I and Type II audit outcome, and why do enterprise clients prefer Type II?

A SOC 2 Type I report attests that controls are suitably designed at a specific date. It provides assurance that the control framework is appropriate but says nothing about whether controls have been operating consistently. A SOC 2 Type II report attests that controls operated effectively throughout a defined period, typically six to twelve months. Enterprise clients prefer Type II because it provides assurance of consistent control operation over time, not a snapshot. For clients entrusting sensitive data to an ITeS or technology provider, consistent operation over time is what reduces their risk. A provider that has well-designed controls on the day of the Type I audit but operational gaps during the year provides less assurance than a provider with Type II evidence of consistent operation.

What does an SOC 2 Type II auditor mean by sampling, and how does it affect the evidence requirement?

Sampling means the auditor selects specific instances from across the audit period for examination rather than reviewing every instance. For a 12-month audit period with hundreds of provisioning events, the auditor might examine 25 provisioning events spread across the period. If any sampled event lacks a compliant approval record, that event is an exception. The proportion of exceptions in the sample is used to assess whether the control operated effectively throughout the period. Evidence that exists only for a subset of instances, those immediately before the audit, will be underrepresented in the sample relative to their actual frequency, but the auditor will find them if they sample consistently across the period.

How many access review cycles are needed during a 12-month SOC 2 Type II audit period?

SOC 2 does not specify a minimum review frequency. However, the operating effectiveness standard requires that evidence of review operation be available for auditor sampling from across the period. A quarterly review cycle produces four evidence records per year, allowing auditors to sample from multiple points across the period and find evidence at each. An annual review produces one record that covers only one point in time. Most SOC 2 Type II engagements covering a 12-month period treat quarterly access reviews as the standard that demonstrates robust operating effectiveness. Annual reviews are accepted but produce limited operating evidence that requires the auditor to rely heavily on the single available record.

What happens when a SOC 2 Type II audit finds operating effectiveness gaps?

When auditors find operating effectiveness gaps, they record them as exceptions. The impact on the audit report depends on the frequency and materiality of exceptions. Isolated exceptions with clear root causes and remediation plans may result in a qualified opinion with a note. Systemic exceptions indicating that a control did not operate as designed throughout the period may result in a more significant qualification or an adverse opinion on that criterion. For organisations in their first Type II engagement, some exceptions are common as the transition from design to continuous operation reveals gaps in the evidence infrastructure. The key is to have a remediation plan and to demonstrate that the gaps are being closed.

Why does automated control infrastructure produce better operating effectiveness evidence than manual processes?

Automated controls produce evidence as a structural output of their operation: every event processed generates a record, regardless of whether anyone performed a manual step. Manual processes produce evidence only when a human performs the required action and documents it. Under operating effectiveness sampling, auditors examine evidence from randomly selected points across the period. Automated controls have evidence at every point because they operate continuously. Manual processes have evidence only when the manual step was performed: periods where competing priorities delayed the manual step appear as gaps in the sampling. The operating effectiveness standard is most reliably satisfied by controls that generate evidence automatically, without depending on human performance consistency throughout the period.

Can an organisation begin a SOC 2 Type II audit immediately after completing a Type I, or is there a waiting period?

There is no mandatory waiting period between a Type I and the start of a Type II audit period. However, the Type II audit period can only cover time after the controls were in place and operating. If the Type I audit identified gaps that required remediation, the Type II period should begin after remediation is complete and the controls are operating as designed. Starting the Type II period immediately after a Type I audit works only if the controls were already operating effectively before the Type I, and the Type I simply documented their design. For organisations that made significant changes to their control environment to achieve Type I, a period of at least three to six months of operating evidence before beginning a Type II engagement produces a stronger evidence base.

Introduction

RBI 2023 Master Direction Clause 19(b) requires close supervision of privileged users with logged system activities sufficient to reconstruct what actions were taken during privileged sessions. This is one of the most technically specific requirements in the RBI framework, and it is consistently among the findings in RBI IS audits at banks and NBFCs that have application-layer MFA but no session-level recording for privileged infrastructure access.

The requirement has two components that are often conflated. Supervision means real-time visibility into active privileged sessions and the ability to terminate sessions exhibiting suspicious behaviour. Logged system activities means session-level recordings that capture what privileged users did during completed sessions, at sufficient detail for forensic reconstruction. Both are required. An organisation with session recordings but no real-time monitoring capability has one component. An organisation with monitoring capability but authentication logs instead of session recordings has the other. Clause 19(b) requires both.

The forensic reconstruction standard is the operative evidence requirement. A RBI IS auditor examining a suspected incident involving a privileged user needs to reconstruct the sequence of events: which commands were run, which queries were executed, what data was accessed, what was changed. An authentication log showing the user connected at a given time satisfies none of these requirements. Keystroke logs and SQL query capture satisfy all of them.

This blog covers what Clause 19(b) requires at the implementation level, what an RBI IS audit examination of 19(b) looks for, how the requirement integrates with Clauses 19(a) and 19(c), and what technical controls produce the evidence standard the clause demands.

What Clause 19(b) Requires in Full

Clause 19(b) is part of the broader Clause 19 access control provision. Understanding its place within that structure clarifies what the supervision and logging requirements are designed to achieve.

The full Clause 19 structure

Clause 19(a) requires need-based access: privileged users access only what their current role requires. Clause 19(b) requires close supervision with logged system activities for those privileged users. Clause 19(c) requires MFA for privileged access to critical information systems.

Together, the three sub-clauses address who gets privileged access, how their sessions are supervised and recorded, and how they are authenticated. Clause 19(b) sits between the access governance controls of 19(a) and the authentication controls of 19(c). It is the accountability layer: given that a privileged user has been granted need-based access under 19(a) and authenticated with MFA under 19(c), what evidence exists of what they did during their session?

Close supervision

Close supervision requires real-time visibility. An administrator must be able to see all active privileged sessions from a monitoring console at any time, not only review historical recordings. The monitoring must be live enough to allow intervention: if a privileged user initiates actions that appear suspicious during an active session, an administrator must be able to terminate the session before the actions complete.

This is a materially different capability from historical log review. Log review identifies what happened after the session closed. Real-time supervision enables intervention during the session. Both are required under Clause 19(b)’s close supervision standard.

Logged system activities sufficient for reconstruction

The logged system activities requirement sets the evidence standard: sufficient to reconstruct what actions were taken. Reconstruction requires activity-level records. For SSH sessions: every command executed with timestamp, directory context, and output. For database sessions: every SQL query executed with timestamp and table context. For RDP sessions: screen recordings sufficient to visually reconstruct what the user did.

The reconstruction standard is specifically what distinguishes Clause 19(b)’s logging requirement from standard authentication logging. Authentication logs support verification of identity and session timing. Session activity logs support reconstruction of actions. The clause requires the latter.

What an RBI IS Audit Examination of Clause 19(b) Looks For

RBI IS auditors examining Clause 19(b) compliance follow a consistent examination pattern. Understanding this pattern helps organisations assess whether their current controls will satisfy the examination.

Session recording sampling

Auditors select a sample of privileged sessions to critical systems from the examination period, typically the last 12 months. For each sampled session, they request the session recording and verify that it captures activity at the appropriate level: keystroke logs for SSH, SQL query capture for database sessions, screen recordings for RDP. Sessions where only authentication records exist, with no session activity recording, are findings.

The sampling is typically stratified: sessions to core banking systems, sessions to payment infrastructure, and sessions to production databases are the highest priority. Sessions to development or test environments may be sampled separately at lower priority.

Real-time monitoring capability demonstration

Auditors test real-time monitoring capability by asking administrators to demonstrate live visibility into active privileged sessions from the monitoring console. They verify that the console shows active session details including actor identity, target system, session duration, and activity. They test session termination capability: can an administrator terminate a specific session from the monitoring console, and is the termination event logged?

An organisation that can produce historical session recordings but cannot demonstrate live monitoring capability has an incomplete Clause 19(b) implementation. Both components are examined.

Approval workflow records

Auditors examine whether privileged sessions were opened through a formal approval process. They look for session request records showing target system, access level, duration, and justification, alongside approval records showing approver identity and timestamp. Sessions that opened without a corresponding approval record indicate either that the approval workflow was bypassed or that it was not required, both of which raise concerns under Clause 19(b)’s supervision standard.

Coverage completeness

Auditors assess whether session recording coverage is complete across all critical systems. A regulated entity with session recordings for database access but not for SSH access to Linux servers has partial coverage. The examination includes a coverage assessment: which systems are within the session recording perimeter and which are outside it.

How AkkuReka and SMARTAudit Trails Address Clause 19(b)

AkkuReka’s session proxy architecture and SMARTAudit Trails together constitute the technical implementation of Clause 19(b)’s supervision and logging requirements.

AkkuReka session proxy architecture

AkkuReka uses an outbound worker model. A lightweight worker process deploys in the same network segment as the target systems. The worker initiates an outbound TLS 1.3 connection to the Akku cloud. No inbound firewall ports are required on the target network. Every privileged session routes through AkkuReka. No direct connection between a privileged user and a target system exists outside the proxy.

This architectural control is what makes Clause 19(b)’s coverage completeness achievable. When all privileged connections must route through AkkuReka, session recording coverage is complete by design. There are no access paths to critical systems that bypass the recording infrastructure.

The outbound worker model also addresses a common deployment constraint at RBI-regulated entities: organisations with air-gapped or highly restricted network segments can deploy the AkkuReka worker within the restricted segment without requiring inbound firewall rules that security policy prohibits.

SMARTAudit Trail coverage

SSH sessions produce full screen recordings and complete keystroke logs per command. Every command typed by the privileged user is captured with a timestamp, the directory context at the time of execution, and the command output. This is the keystroke-level activity log that Clause 19(b)’s reconstruction standard requires for Linux server and network device access.

MySQL and PostgreSQL database sessions produce full screen recordings and structured capture of every SQL query executed during the session. Each query record captures query text, timestamp, and session context. This is the query-level activity log that Clause 19(b) requires for database access.

RDP sessions to Windows servers and workstations produce full screen video recordings at configurable frame rates. Session event logs capture session open, active duration, and termination reason. The screen recording provides the visual reconstruction capability Clause 19(b) requires for Windows server access.

Kubernetes sessions produce session event recordings and command logs for kubectl operations. HTTP and HTTPS web application sessions produce session recordings and event logs.

Real-time session monitoring

The Akku admin console displays all active privileged sessions in real time. Each active session shows actor identity, target system, session duration, and current activity. Any live session can be terminated instantly from the console. Termination is recorded in the audit log with the administrator’s identity, the termination timestamp, and the reason.

This is the close supervision capability Clause 19(b) requires. The monitoring console is not a retrospective log viewer: it is a live supervision interface with intervention capability.

Session approval workflow

Every privileged session request submitted through the Akku IAM portal includes target system, requested access level, duration, and justification. Approvers are notified via email or in-platform notification. No session opens without explicit approval when the workflow is enabled. The session is held in a pending state until approved.

Approval and denial decisions are logged with approver identity and timestamp. The complete approval workflow record, from request submission through approval or denial through session open, constitutes the formal authorisation evidence that Clause 19(b)’s supervision requirement implies.

How Clause 19(b) Interacts With Clauses 19(a) and 19(c)

Clauses 19(a), 19(b), and 19(c) address different layers of privileged access risk and must be implemented together for a defensible Clause 19 posture.

The access governance layer: Clause 19(a)

Clause 19(a) requires that privileged access be need-based. JIT access implements this by ensuring no privileged user holds standing access to target systems. Access is granted for the duration of an approved session and revoked automatically on expiry. The session approval workflow under Clause 19(b) is the mechanism through which need-based access is both granted and documented: every session has an approved justification that establishes why the access was needed at that time.

The authentication layer: Clause 19(c)

Clause 19(c) requires MFA for privileged users accessing critical information systems. Akku enforces MFA at the IAM layer before AkkuReka opens the session proxy connection. The privileged user must authenticate to Akku IAM with MFA before any session to a critical system can open. The MFA event is logged and linked to the subsequent session record, providing the complete authentication-to-session evidence chain that a comprehensive Clause 19 examination requires.

The complete Clause 19 evidence chain

A complete Clause 19 evidence chain for a single privileged session includes: the session request with target system, access level, duration, and justification. The approval record with approver identity and timestamp. The MFA authentication event confirming identity assurance before session open. The session activity recording capturing what occurred during the session. The session close event with duration and termination reason. The credential revocation event confirming that the ephemeral credential is permanently invalidated.

This end-to-end evidence chain is what a rigorous RBI IS audit examination of Clause 19 will look for. Each element satisfies a different component of the clause’s requirements, and all elements are required for a complete response to an examination request.

Diagnostic Questions

For a sample of five privileged sessions to critical systems from the last three months, can you produce the session recording capturing what occurred during each session at the keystroke or query level, not only the authentication record?

Does your monitoring infrastructure provide live visibility into active privileged sessions with session termination capability, or does your monitoring capability rely on retrospective log review?

For every privileged session to a critical system in the last 12 months, is there a corresponding session request and approval record showing the justification for access and the approver’s identity?

Does your session recording coverage extend to all critical systems, including Linux servers accessed via SSH, production databases, and network device management interfaces, or only to systems with web-based management consoles?

Can you produce on demand, for any 90-day period an RBI examiner specifies, a structured export of all privileged session records including session metadata, approval records, and recording availability confirmation?

CTAs

See how Akku’s AkkuReka and SMARTAudit Trails address RBI Clause 19(b) requirements for privileged access supervision and session activity logging.

Book a conversation with the Akku team to assess your current privileged access controls against RBI Clause 19(b)’s supervision and logging standard.

FAQs

What is the specific difference between close supervision under Clause 19(b) and periodic log review?

Close supervision under Clause 19(b) requires real-time visibility into active privileged sessions with the ability to intervene and terminate sessions during their execution. Periodic log review examines completed session records after sessions have closed. The distinction matters because close supervision enables prevention: a suspicious action can be stopped before it completes. Periodic log review enables investigation: it establishes what happened after the fact. Clause 19(b) requires both: real-time supervision during sessions and logged system activities for completed sessions. Periodic log review alone does not satisfy the close supervision component.

Does Clause 19(b) apply only to privileged sessions to core banking systems, or to all privileged access?

Clause 19(b) applies to all privileged users with access to information systems classified as critical under the regulated entity’s IT risk framework. This includes core banking systems, payment processing infrastructure, production databases, network infrastructure management interfaces, and any system whose compromise would have a material impact on operations or data security. The regulated entity must define which systems are critical and ensure that privileged access to all of them falls within the Clause 19(b) supervision and logging perimeter.

What does the reconstruction standard in Clause 19(b) mean for database session logging specifically?

The reconstruction standard requires that the session activity log be sufficient to reconstruct what actions were taken during the session. For database sessions, reconstruction requires knowing which queries were executed, against which tables, at what times, and with what results. A screen recording of a database management client provides visual reconstruction capability. Structured SQL query capture provides searchable, analysable reconstruction capability. An auditor or forensic investigator examining a suspected data access incident needs to search the session logs for all queries against a specific table without reviewing screen recordings manually. Structured query capture satisfies this requirement. Screen recordings alone do not.

How does AkkuReka’s outbound worker architecture address deployment constraints at RBI-regulated entities?

Many RBI-regulated entities operate production systems in network segments with strict inbound firewall policies that prohibit adding new inbound port rules. AkkuReka’s outbound worker model addresses this constraint by deploying a lightweight worker process within the restricted network segment. The worker initiates an outbound TLS 1.3 connection to the Akku cloud, requiring only outbound HTTPS on port 443. No inbound firewall rules are required on the target network or target systems. This deployment model allows AkkuReka to cover critical systems in restricted network segments without requiring changes to inbound firewall policy that security governance would not approve.

What is the relationship between per-session ephemeral credentials and Clause 19(b)’s supervision requirement?

Per-session ephemeral credentials support Clause 19(b)’s supervision requirement by ensuring that every privileged access event routes through the approved session workflow. When no standing credentials exist for target systems, a privileged user cannot open a session outside the AkkuReka proxy and approval workflow. Every privileged access event is necessarily supervised through the monitoring console and recorded through SMARTAudit Trails. If standing credentials existed, a privileged user could potentially connect to target systems directly, bypassing the supervision and recording infrastructure entirely. Per-session ephemeral credentials make this architectural bypass impossible, ensuring complete supervision coverage.

How should a regulated entity handle Clause 19(b) compliance for third-party vendors who require privileged access to critical systems?

Third-party vendor privileged access is subject to the same Clause 19(b) requirements as internal administrator access. Vendor sessions must be brokered through AkkuReka, subject to the formal approval workflow with target system, duration, and justification, and recorded through SMARTAudit Trails. The vendor’s representative is assigned a session-specific identity in Akku IAM for the duration of their engagement. All session records and approval records for vendor access are retained in the same audit trail as internal privileged sessions, providing the same forensic evidence quality for vendor sessions as for internal administrator sessions.

Introduction

GDPR Articles 15 through 22 establish eight rights for Data Subjects. Each right creates a corresponding technical obligation for the controller. The right to access personal data requires a self-service portal or fulfilment workflow capable of producing a structured summary of personal data and processing activities within one month. The right to erasure requires workflows that propagate deletion across every connected system where the Data Subject’s data is held. The right to data portability requires export in a structured, machine-readable format. The right to restriction requires a technical flag that prevents processing without deleting data.

Rights that exist on paper but lack technical fulfilment infrastructure cannot be exercised in practice. An organisation that describes its Data Subject rights commitment in a privacy notice but has no technical mechanism for fulfilling an access request within one month has not implemented the right. The supervisory authority will assess whether rights are technically exercisable, not whether they are described in documentation.

The scale problem makes this critical for organisations with large user populations. An organisation processing data for hundreds of thousands of customers cannot fulfil Data Subject rights requests through manual processes within GDPR’s one-month response window. At scale, manual fulfilment is operationally impossible. Technical fulfilment workflows are the only viable approach.

This blog covers what each of the primary GDPR Data Subject rights requires technically, what the fulfilment infrastructure must be capable of, and how each right interacts with the IAM and consent management infrastructure. All article references are drawn from the GDPR and Akku’s GDPR compliance mapping documentation.

Right to Access Under Article 15

Article 15 gives Data Subjects the right to obtain confirmation of whether their personal data is being processed and, if so, access to that data and information about the processing.

What Article 15 requires technically

Article 15(1) requires that the controller provide confirmation of processing and, where processing is occurring, access to the personal data being processed, the purposes of processing, the categories of data, the recipients or categories of recipients with whom data has been shared, the envisaged retention period, the existence of other Data Subject rights, the right to lodge a complaint with a supervisory authority, and the source of the data where it was not collected directly from the Data Subject.

Article 15(3) requires that the controller provide a copy of the personal data undergoing processing. The copy must be in a format that the Data Subject can understand.

The one-month response window under Article 12(3) applies: the controller must respond within one month of receiving the request, with a possible extension to three months for complex or numerous requests.

What this requires technically

A self-service access request portal is required for organisations with large user populations. The portal must allow Data Subjects to submit access requests and receive structured responses without requiring manual processing by staff for each request.

The response must be assembled from all systems processing the Data Subject’s personal data. This requires a data mapping that connects the Data Subject’s identity to all systems holding their data, and a query mechanism for assembling the response from those systems.

The recipient disclosure under Article 15(1)(c) requires that the controller maintain a current record of every entity to whom each Data Subject’s personal data has been disclosed. This is a data governance record that must be queryable at the time of an access request.

Akku’s CIAM Consent Manager addresses Article 15(1) and (3) through Data Subject access request workflows, with the consent record providing the processing purpose and recipient information components of the required response.

Right to Rectification Under Article 16

Article 16 gives Data Subjects the right to obtain rectification of inaccurate personal data and completion of incomplete personal data.

What Article 16 requires technically

Rectification requests must update personal data across every connected system where it is held. A name correction applied in the CRM but not in the billing system, the support system, and the marketing platform is an incomplete rectification. The controller must ensure that the correction propagates across all systems holding the relevant personal data.

Article 19 requires that the controller inform each recipient to whom personal data has been disclosed of the rectification, unless this proves impossible or involves disproportionate effort. For organisations using Data Processors who hold copies of the personal data, the notification workflow must reach every processor holding the data that was corrected.

What this requires technically

A rectification workflow must accept the correction from the Data Subject, update the primary record in the relevant system, propagate the correction to all connected systems holding the data, and notify Data Processors of the correction where required.

At scale, this propagation must be automated. A manual process requiring a staff member to update each system individually cannot operate reliably within the one-month response window for high volumes of rectification requests.

Akku’s CIAM Consent Manager and User Lifecycle Manager together address Article 16 through correction workflow capabilities and downstream propagation mechanisms.

Right to Erasure Under Article 17

Article 17 gives Data Subjects the right to erasure of their personal data, the right to be forgotten, under defined conditions including withdrawal of consent, completion of the purpose for which data was collected, and objection to processing.

What Article 17 requires technically

Article 17(1) specifies the conditions under which erasure must be fulfilled: the data is no longer necessary for the purpose for which it was collected, the Data Subject withdraws consent and no other lawful basis applies, the Data Subject objects to processing under Article 21 and there are no overriding legitimate grounds, the data was unlawfully processed, or erasure is required for compliance with a legal obligation.

Article 17(2) requires that where the controller has made personal data public, they take reasonable steps to inform other controllers processing the data of the erasure request.

Article 19 requires notification to recipients of the erasure, as with rectification.

What this requires technically

Erasure workflows must delete personal data from every system where it is held, not only from the primary database. The erasure must be verifiable: the controller must be able to demonstrate that the data was deleted from each system. Where data is held in backup systems, the erasure timeline must account for backup retention cycles and document when backup copies will be overwritten.

The erasure workflow must respect legal retention obligations that may override the erasure right. Where data must be retained for legal compliance, the controller may restrict processing rather than erase, pending the end of the retention period.

Downstream notification to Data Processors and other recipients must be automated for organisations with multiple processors. The notification must include the Data Subject identity and the scope of the erasure so that processors can take corresponding action.

Akku’s CIAM Consent Manager addresses Articles 17(1) and 19 through erasure workflow capabilities. The User Lifecycle Manager addresses Article 17 through automated deprovisioning workflows triggered by consent withdrawal under Clause 8(7)(b) of DPDPA, with equivalent functionality supporting GDPR Article 17 erasure workflows.

Right to Restriction Under Article 18

Article 18 gives Data Subjects the right to restrict processing of their personal data in defined circumstances: the accuracy of the data is contested, the processing is unlawful but the Data Subject prefers restriction over erasure, the controller no longer needs the data but the Data Subject requires it for legal claims, or the Data Subject has objected to processing pending verification of whether the controller’s legitimate grounds override.

What Article 18 requires technically

Restriction of processing means the personal data is retained but processing activities are suspended. The data must be flagged as restricted in every system where it is held. Processing operations that are not permitted during restriction, typically everything except storage, legal claims, protection of rights of another person, or public interest grounds, must be blocked for flagged records.

Restriction is technically more complex than erasure because it requires a persistent flag that modifies the processing behaviour of every system holding the data, rather than simply deleting it. The flag must persist until the restriction is lifted by the Data Subject or until the conditions for restriction no longer apply.

A restriction flag system must be queryable across all connected systems and must prevent processing of flagged records at the application layer.

Right to Data Portability Under Article 20

Article 20 gives Data Subjects the right to receive their personal data in a structured, commonly used, machine-readable format and to transmit that data to another controller.

What Article 20 requires technically

Article 20(1) requires that the controller provide personal data in a structured, commonly used, machine-readable format where processing is based on consent or contract and is carried out by automated means.

The machine-readable format requirement means JSON, CSV, or XML, not a PDF. The Data Subject must be able to use the exported data in another system without manual reformatting.

The portability right applies to personal data provided by the Data Subject: data derived by the controller from the Data Subject’s data is not covered. A customer’s purchase history is portable. Analytics models derived from that history are not.

A self-service data export function that produces machine-readable output covering all in-scope personal data categories is the technical implementation of Article 20. The export must be generated from the controller’s data processing systems and delivered to the Data Subject securely.

Right to Object Under Article 21

Article 21 gives Data Subjects the right to object to processing of their personal data based on the controller’s legitimate interests or for direct marketing purposes.

What Article 21 requires technically

Article 21(1) requires that processing cease when a Data Subject objects, unless the controller demonstrates compelling legitimate grounds that override the Data Subject’s interests or the processing is for the establishment, exercise, or defence of legal claims.

Article 21(2) provides an absolute right to object to processing for direct marketing purposes, with no balancing test required.

What this requires technically

An objection workflow must receive the objection, assess whether compelling legitimate grounds apply for non-marketing processing, suppress the Data Subject’s records from marketing processing immediately and unconditionally, and propagate the suppression to all systems conducting the relevant processing.

The marketing suppression must be immediate and technically enforced. A marketing suppression flag that relies on staff to manually update mailing lists does not satisfy Article 21(2)’s absolute marketing opt-out right.

Akku’s CIAM Consent Manager addresses Articles 21(1) and 21(2) through objection and marketing suppression workflows, with the consent record data model supporting objection status per processing purpose.

The Common Technical Infrastructure Across All Rights

All six Data Subject rights require a common technical foundation: a Data Subject identity verification mechanism at the point of rights exercise, a structured rights submission portal, automated fulfilment workflows for each right type, cross-system propagation mechanisms for corrections and erasures, and an audit trail covering every rights request and fulfilment action.

Identity verification

Before fulfilling any Data Subject rights request, the controller must verify that the requester is the Data Subject or an authorised representative. Insufficient verification creates a risk of inadvertent disclosure to unauthorised parties. Excessive verification creates barriers that effectively deny the right.

The verification mechanism must be proportionate to the sensitivity of the data involved and the nature of the right being exercised. An access request for contact details requires lighter verification than an erasure request for financial records.

Audit trail for rights fulfilment

Every rights request and every fulfilment action must produce a timestamped audit record. The request receipt, the verification outcome, the fulfilment action taken, the systems updated, and the response sent must all be captured in a structured record.

The rights fulfilment audit trail is the evidence a supervisory authority will examine when a Data Subject complains that their rights were not fulfilled. It must demonstrate that the request was received, acted upon within the required timeframe, and fulfilled completely.

Akku’s CIAM Consent Manager produces a structured audit trail for every Data Subject rights exercise event. The audit trail is append-only and tamper-evident, constituting the demonstrability evidence that Article 5(2)’s accountability principle requires.

Diagnostic Questions

Can your organisation fulfil a Data Subject access request by producing a structured summary of all personal data held and all processing activities within one month, without a manual data compilation exercise across multiple system administrators?

When a Data Subject requests erasure, does the deletion propagate automatically to every connected system holding their personal data, and does the controller receive confirmation of deletion from each system?

Does your organisation maintain a restriction processing flag that can be applied to a Data Subject’s records across all connected systems, blocking non-permitted processing activities for flagged records?

Is your data portability export function capable of producing personal data in machine-readable format, covering all in-scope data categories, without requiring staff to manually compile and format the export?

When a Data Subject objects to direct marketing processing, is the suppression applied immediately and automatically across all marketing processing systems, or does it require manual update of individual mailing lists?

CTAs

See how Akku’s CIAM Consent Manager addresses GDPR Data Subject rights requirements across access, rectification, erasure, restriction, portability, and objection workflows.

Book a conversation with the Akku team to assess your current Data Subject rights fulfilment infrastructure against GDPR’s technical obligations.

FAQs

What is the one-month response window under GDPR Article 12, and when does it start?

Article 12(3) requires that the controller respond to Data Subject rights requests without undue delay and in any event within one month of receiving the request. The one-month period begins when the controller receives the request, not when they begin processing it. Where requests are complex or numerous, the controller may extend the period by a further two months, but must inform the Data Subject of the extension and the reasons for it within the initial one-month period. For high-volume organisations, manual fulfilment processes that require days to initiate will frequently fail to deliver responses within the one-month window, making automated fulfilment workflows necessary.

Does the right to erasure under Article 17 apply to all personal data a controller holds, or only to data in primary systems?

The right to erasure applies to all personal data the controller processes, regardless of where it is stored. This includes primary databases, backup systems, archive storage, third-party processors, and any other location where the controller’s personal data exists. For backup systems, erasure may not be immediately executable because backup media cannot always be selectively overwritten. The recommended approach is to maintain a suppression record that prevents the backup data from being restored and used after the erasure request is received, and to document when the backup copies will be overwritten through normal backup rotation. The controller must inform the Data Subject that complete erasure from backup systems will occur at the next backup rotation.

What does machine-readable format mean for Article 20 data portability, and what formats satisfy the requirement?

Machine-readable format means a structured format that can be processed by software without manual reformatting. JSON, CSV, and XML are the formats that satisfy this requirement. A PDF is not machine-readable for portability purposes because it cannot be processed by another system without format conversion. The format must be commonly used, meaning the Data Subject can use standard software to read and transfer the data to another controller. The portability export must cover personal data provided by the Data Subject and processed on the basis of consent or contract by automated means. Derived data, analytics models, and inferred attributes are not covered by the portability right.

How does the right to restriction under Article 18 differ from the right to erasure under Article 17?

Erasure removes personal data from all systems. Restriction retains the data but suspends most processing activities. The Data Subject may prefer restriction over erasure where they need the data for legal claims, where the accuracy is being contested and they want the data retained pending verification, or where the processing is unlawful but the Data Subject prefers to have it restricted rather than deleted. Technically, restriction requires a persistent flag that modifies processing behaviour across all systems holding the data, while erasure requires deletion. Restriction is more technically demanding because it requires ongoing enforcement across all systems, not a one-time deletion action.

What notification obligations arise when a Data Subject exercises erasure or rectification rights under Article 19?

Article 19 requires that the controller inform each recipient to whom personal data has been disclosed of any rectification, erasure, or restriction, unless this proves impossible or involves disproportionate effort. Recipients include Data Processors who hold copies of the data and other controllers to whom the data was disclosed. The notification must include the Data Subject identity and the scope of the rectification, erasure, or restriction so that recipients can take corresponding action. For organisations with multiple Data Processors, the notification workflow must reach every processor holding the relevant data. Manual coordination across multiple processors is not scalable for high-volume rights exercises. Automated notification workflows that propagate rights exercise events to connected processors are required at scale.

Can a single CIAM deployment address both GDPR and DPDPA Data Subject and Data Principal rights requirements simultaneously?

Yes. GDPR Articles 15 through 21 and DPDPA Clauses 11 through 14 share substantial overlapping requirements. Both require self-service access to personal data summaries. Both require correction and erasure workflows that propagate across connected systems. Both require withdrawable consent with automated processing cessation. Both require a rights submission portal with structured request and response records. Akku’s CIAM Consent Manager implements the rights fulfilment infrastructure that satisfies both frameworks from a single deployment. The consent record data model and audit trail architecture are extended to capture the specific fields each framework requires, and the fulfilment workflows handle both GDPR and DPDPA rights exercise events through the same operational infrastructure.

Introduction

Multi-factor authentication appears as a requirement in every major compliance framework that applies to Indian organisations. RBI requires it for privileged users accessing critical systems. SEBI CSCRF requires it proportionate to resource sensitivity. IRDAI requires it for network device management and critical system access. ISO 27001:2022 requires secure authentication procedures. SOC 2 requires boundary protection for external access. DPDPA and GDPR require appropriate technical security measures, which regulators and auditors consistently read as including MFA for personal data system access.

The compliance conversation about MFA has matured beyond whether MFA is deployed to whether the deployment satisfies the specific requirement each framework imposes. Most organisations have deployed MFA. The compliance gaps are almost universally in three areas: coverage, proportionality, and evidence.

Coverage gaps exist when MFA is enforced for some access paths but not others. Web-based application login covered, SSH access to the same servers not covered. Customer-facing authentication covered, internal administrator access to production databases not covered. The coverage gap means the MFA deployment satisfies the convenient access paths but misses the high-risk ones.

Proportionality gaps exist when the same MFA method is applied uniformly to all access scenarios regardless of risk. SEBI CSCRF PR.AA.S7 requires authentication commensurate with resource sensitivity. A uniform TOTP deployment applied identically to a document management system and a core banking platform does not satisfy proportionality. Adaptive MFA that escalates the challenge for high-sensitivity access does.

Evidence gaps exist when MFA enforcement operates but the authentication event log does not capture MFA method and outcome per event, or does not cover all access paths. The evidence gap means MFA is enforced in practice but cannot be demonstrated to a compliance auditor.

This blog maps each framework’s MFA requirement to its specific technical standard, identifies the most common deployment gaps, and covers what a compliant MFA implementation must produce as evidence.

MFA Requirements by Framework

RBI 2023 Master Direction

Clause 19(c) requires MFA for privileged users accessing critical information systems. The scope is infrastructure-level: system administrators, database administrators, network engineers, and any role with elevated access to systems classified as critical.

Clause 20(b) requires MFA for all remote access to critical information systems. This extends beyond privileged users to all users accessing critical systems from outside the corporate network.

The most common RBI MFA gap is infrastructure coverage: MFA enforced at the web management console layer but not for direct SSH, database client, and network device CLI access. Clause 19(c)’s critical systems scope covers these access paths, and auditors test them.

SEBI CSCRF

PR.AA.S7 requires authentication controls commensurate with the sensitivity of the resource. This is the proportionality requirement: higher-sensitivity resources require stronger authentication. PR.AA.S9 requires MFA for access to sensitive and critical systems.

The most common SEBI CSCRF MFA gap is uniform deployment: MFA is enforced but the same method and challenge intensity applies to all systems regardless of their classification. PR.AA.S7’s proportionality requirement distinguishes a trading platform from an internal wiki. Adaptive MFA that applies risk-based step-up for higher-sensitivity access satisfies this requirement. Uniform MFA does not.

IRDAI ICS

Item 52 requires MFA for managing network devices and for privileged access to critical systems. Item 64 requires MFA for remote access to organisational systems. Item 65 requires MFA for access to critical applications from outside the corporate network. Item 148 requires step-up authentication for high-sensitivity systems.

The most common IRDAI MFA gap is infrastructure scope: Items 52 and 64 specifically reference network device management and privileged infrastructure access, which are frequently left outside MFA enforcement perimeters.

ISO 27001:2022

A.8.5 requires secure authentication procedures. The control requires that authentication be appropriate to the sensitivity of the information and systems being accessed, and that authentication credentials be protected. The proportionality implication of A.8.5 aligns with SEBI CSCRF PR.AA.S7.

The most common ISO 27001 MFA gap is evidence: MFA is enforced but the authentication event log does not capture MFA method and outcome per event in a structured format that certification auditors can examine.

SOC 2 Type II

CC6.1 requires logical access security software and infrastructure. CC6.6 requires boundary protection against threats from outside the system boundary, which covers MFA for external and remote access. The operating effectiveness requirement means MFA enforcement must be continuous and consistently evidenced throughout the audit period.

The most common SOC 2 MFA gap is operating effectiveness evidence: MFA is deployed but the authentication event log has gaps, coverage inconsistencies, or does not capture events from all access paths throughout the audit period.

DPDPA and GDPR

Clause 8(5) of DPDPA and Article 32 of GDPR both require appropriate security safeguards and appropriate technical measures respectively. Neither explicitly mandates MFA. Both create a general security obligation that regulators and auditors consistently interpret as requiring MFA for systems processing personal data, particularly for privileged access.

The most common gap for DPDPA and GDPR purposes is the absence of MFA for privileged access to databases and servers holding personal data, where a single compromised credential provides unrestricted access to the most sensitive data in the organisation.

The Three Deployment Gaps

Coverage gaps

Coverage gaps are the most prevalent and the most consequential. Every access path to a critical or sensitive system that does not route through MFA enforcement is a coverage gap.

Web-based management console access is typically covered. SSH access to the underlying servers that the consoles manage is typically not. Database client connections using native database protocols are typically not. Network device CLI access via SSH or Telnet is typically not. Kubernetes API access via kubectl is typically not.

These uncovered access paths represent the highest-risk privileged access scenarios in most regulated environments. The web console is a monitored, logged interface. A direct SSH connection to the same server bypasses the console’s audit trail entirely and may not enforce MFA.

Closing coverage gaps requires routing all privileged access to critical systems through a PAM session proxy that enforces MFA at the session layer, before any target system connection opens, regardless of the protocol used. This is the only approach that provides coverage completeness across all privileged access paths.

Proportionality gaps

Proportionality gaps exist when the authentication challenge does not scale with resource sensitivity. A user accessing a document management system and a user accessing a core banking platform face the same TOTP challenge. The platforms have vastly different risk profiles, but the authentication assurance is identical.

Frameworks requiring proportionate authentication, specifically SEBI CSCRF PR.AA.S7 and IRDAI Item 148, require that the authentication model distinguish between sensitivity levels. Adaptive MFA satisfies this by evaluating risk signals at each authentication event and escalating the challenge for higher-risk scenarios: more sensitive systems, unusual access contexts, new devices, or anomalous locations.

The practical implementation is not simply applying different MFA methods to different system tiers. It is deploying an authentication layer that evaluates context at each event and applies a proportionate challenge dynamically, covering both the system sensitivity and the access context simultaneously.

Evidence gaps

Evidence gaps exist when MFA enforcement operates but the audit trail does not capture the required information for every event. Specifically: MFA method not recorded in the authentication event log, MFA outcome not recorded per event, authentication events from some access paths not captured in the centralised log, or log retention insufficient to cover the examination period.

For RBI IS audits, auditors request authentication logs and verify that privileged sessions to critical systems were preceded by successful MFA events. If the log does not capture MFA method and outcome per session, the auditor cannot verify MFA enforcement from the log.

For SOC 2 Type II, auditors sample authentication events from across the audit period. If the log has gaps for some access paths or some time periods, the sample will find events with no corresponding MFA record.

The evidence requirement means the authentication event log must capture: actor identity, timestamp, target system or application, MFA method used, MFA outcome, source IP, device identifier, and geographic location, for every authentication event, across every covered access path, continuously throughout the compliance period.

What a Compliant MFA Implementation Produces

A compliant MFA implementation produces three outputs: enforcement coverage, proportionate challenge behaviour, and structured evidence.

Enforcement coverage

All authentication events to critical and sensitive systems route through the MFA enforcement layer, regardless of the protocol used. SSH access, database connections, RDP sessions, Kubernetes API calls, and web application logins all require MFA at the session proxy layer before the target connection opens. No access path to a covered system bypasses the MFA requirement.

Proportionate challenge behaviour

The authentication challenge scales with the risk profile of the access scenario. High-sensitivity systems require stronger second factors or multi-step challenges. Unusual access contexts, new locations, unrecognised devices, or anomalous timing trigger step-up challenges regardless of the system being accessed. Familiar, low-risk access contexts receive the appropriate challenge without unnecessary friction.

Structured evidence

Every authentication event produces a structured log record with all required fields. The record is generated at the time of the authentication event, stored in append-only format, retained for the compliance period, and exportable in structured format for regulatory examination. The log covers all access paths, all systems, and the complete compliance period with no gaps.

Akku’s Adaptive MFA implements all three outputs. Coverage is achieved through the centralised authentication layer that all connected applications route through and through PAM-layer enforcement for infrastructure access. Proportionality is achieved through AI-powered anomaly detection that evaluates risk signals and escalates challenges accordingly. Evidence is produced by the centralised authentication event log that captures all required fields for every event in append-only, exportable format.

Diagnostic Questions

Does your MFA deployment cover direct SSH access to production servers, direct database client connections, and network device CLI access, or only web-based management console authentication?

For your highest-sensitivity systems, specifically core banking platforms, payment infrastructure, and personal data databases, does MFA apply a stronger challenge than for lower-sensitivity internal applications, or is the same method applied uniformly?

Does your authentication event log capture MFA method and outcome per event for every authentication attempt across every covered access path, or are some access paths not reflected in the centralised log?

For any 30-day window chosen at random from the last 12 months, can you produce a structured export of all authentication events showing MFA method and outcome for every event, without manual compilation from individual application logs?

Has your organisation tested MFA coverage by attempting to connect to critical systems using direct protocol access without routing through the centralised MFA enforcement layer, to verify that no access paths bypass the requirement?

CTAs

See how Akku’s Adaptive MFA addresses compliance requirements across RBI, SEBI CSCRF, IRDAI, ISO 27001, SOC 2, DPDPA, and GDPR with coverage, proportionality, and structured evidence.

Book a conversation with the Akku team to assess your current MFA deployment against the specific requirements of the frameworks that apply to your organisation.

FAQs

Why do compliance frameworks require MFA specifically, and what risk does it address?

MFA addresses credential compromise, the most common initial access vector in security incidents. A single compromised password provides unrestricted access to any system the account is entitled to reach. Adding a second factor means that compromised credentials alone are insufficient for access: the attacker also needs the second factor, which requires either physical possession of the user’s device or a separate attack to obtain. For regulated organisations where a single compromised administrator credential could provide access to core banking systems, customer databases, or payment infrastructure, the risk reduction from MFA enforcement is directly proportionate to the access privilege of the protected accounts.

What is the difference between standard MFA and adaptive MFA for compliance purposes?

Standard MFA applies the same second-factor challenge to every authentication event regardless of context. Adaptive MFA evaluates risk signals at each authentication event and escalates the challenge when signals indicate elevated risk. For compliance frameworks that require proportionate authentication, specifically SEBI CSCRF PR.AA.S7 and IRDAI Item 148, standard MFA does not satisfy the proportionality requirement. Adaptive MFA satisfies it by applying stronger challenges to higher-risk access scenarios. For frameworks with a simpler MFA requirement such as RBI Clause 19(c), both standard and adaptive MFA satisfy the requirement, though adaptive provides stronger security posture.

Does deploying MFA for customer-facing applications satisfy the privileged user MFA requirements in RBI and IRDAI?

No. Customer-facing MFA covers authentication for customers accessing their accounts through internet banking or insurance portals. RBI Clause 19(c) and IRDAI Items 52 and 64 cover internal privileged user authentication to backend critical systems. These are separate populations, separate access scenarios, and separate technical requirements. Satisfying customer-facing MFA requirements does not satisfy internal privileged user MFA requirements. Organisations must address both independently.

What MFA methods are phishing-resistant, and when should they be required?

Phishing-resistant MFA methods are those that cannot be intercepted or replayed by an attacker who tricks the user into authenticating to a fake service. FIDO2 hardware security keys and platform authenticators using WebAuthn are phishing-resistant because the authentication is cryptographically bound to the legitimate domain. Push notification MFA and SMS OTP are not phishing-resistant because they can be defeated by real-time phishing attacks where the user is tricked into approving or entering the factor on a fake site. For the highest-privilege accounts with access to core banking and payment infrastructure, phishing-resistant methods are increasingly recommended by RBI IS auditors and align with global best practice for privileged account protection.

How should organisations handle MFA for service accounts that cannot complete interactive authentication challenges?

Service accounts used for automated processes cannot complete interactive MFA challenges because they are not operated by a human who can respond to a step-up prompt. For service accounts, MFA alternatives include certificate-based authentication where the service authenticates with a client certificate stored in a secure vault, API keys with short rotation cycles that provide a credential security equivalent, and network-level access controls that restrict service account connections to specific IP ranges and ports. The appropriate approach depends on the protocol the service account uses. Service accounts with privileged access to critical systems should be governed through the same PAM infrastructure as human privileged users, with their credentials managed in AkkuVault and their access sessions logged.

What evidence should organisations retain to demonstrate MFA compliance across multiple frameworks simultaneously?

A single structured authentication event log covering all authentication events with MFA method, outcome, actor identity, timestamp, source IP, device, and geographic location satisfies the MFA evidence requirements of RBI, SEBI CSCRF, IRDAI, ISO 27001, SOC 2, DPDPA, and GDPR simultaneously. The log must be: complete, covering every authentication event across every covered system; continuous, with no gaps during the compliance period; structured, in JSON or CSV format with consistent field naming; append-only, with tamper-evident integrity; and exportable, producible for any time period within the retention window without manual compilation. A single log with these properties serves every framework’s evidence requirement from one source.

Introduction

The Digital Personal Data Protection Act, 2023 creates technical obligations that require infrastructure changes, not only policy updates. Consent management systems must be built or upgraded. Access controls for personal data systems must be implemented and evidenced. Data Principal rights fulfilment workflows must be operational. Audit trails must be continuous and tamper-evident. None of these are achievable by updating a privacy policy document.

Most IT teams approaching DPDPA compliance face a common challenge: the obligations are clear in principle but the implementation sequence is not. Attempting to implement everything simultaneously produces incomplete results across all areas. A phased approach that prioritises the highest-risk obligations first, builds the foundational technical infrastructure before the dependent controls, and produces auditable evidence at each phase is more effective than a parallel implementation attempt.

This 90-day action plan is structured around three 30-day phases. Phase one builds the foundational access control and identity infrastructure that every other DPDPA technical obligation depends on. Phase two implements consent management and Data Principal rights workflows. Phase three implements audit trail infrastructure, lifecycle management automation, and evidence packaging. The sequence is deliberate: access controls must be in place before consent management can be layered on top, and both must be operational before the audit trail evidence they generate can be packaged for regulatory examination.

All clause references are drawn directly from the DPDPA and Akku’s DPDPA compliance mapping documentation, which covers 24 of the 38 technical compliance items with 33 total clause mappings.

Phase One: Access Controls and Identity Infrastructure (Days 1 to 30)

Phase one addresses the Clause 8(4) and 8(5) obligations: appropriate technical measures to ensure processing is limited to authorised purposes and reasonable security safeguards to prevent personal data breaches. These are the foundational controls that all other DPDPA technical obligations build on.

Priority 1: Centralised identity store and SSO

If your organisation’s applications authenticate through separate credential systems, centralising authentication is the first infrastructure task. Every application that processes personal data must authenticate through a single identity layer. This is not a convenience feature for DPDPA purposes: it is what makes Clause 8(5)’s security safeguard requirement technically implementable at scale.

Actions for days 1 to 10: Inventory all applications that process personal data of Indian residents. Identify which applications authenticate through a centralised IdP and which maintain separate credentials. Prioritise migration to centralised authentication for applications processing the highest volumes or most sensitive categories of personal data.

Priority 2: Role-based access controls for personal data systems

Clause 8(4) requires that processing be limited to authorised purposes. Technically, this means RBAC must define which users can access which personal data systems for which purposes. Every user’s access to personal data systems must be tied to a role definition that reflects their authorised processing activities.

Actions for days 10 to 20: Map each role in your organisation to the personal data systems that role legitimately requires access to. Define RBAC role configurations in your IAM platform reflecting these mappings. Identify users whose current access exceeds what their role requires and initiate access reduction.

Priority 3: Adaptive MFA for personal data system access

Clause 8(5) requires reasonable security safeguards. MFA is the primary authentication security safeguard. For personal data systems, MFA must cover both end-user access and privileged administrator access.

Actions for days 20 to 30: Deploy Adaptive MFA for all applications processing personal data. Extend MFA to infrastructure-level access for administrators with privileged access to personal data systems through PAM. Verify that MFA enforcement is consistent across all covered systems and that the authentication event log is capturing MFA method and outcome per event.

Phase Two: Consent Management and Data Principal Rights (Days 31 to 60)

Phase two addresses the Clause 5 and 6 obligations for consent management and the Clauses 11 through 14 obligations for Data Principal rights. These require a consent management system, not policy documentation.

Priority 4: Consent management infrastructure

Actions for days 31 to 40: Deploy a consent management system capable of maintaining purpose-specific consent records per Data Principal. Configure versioned notice management for each processing purpose for which consent is the lawful basis. Define the consent record data model covering Data Principal identity, processing purpose, notice version, consent timestamp, channel, and withdrawal status.

For organisations with existing consent capture mechanisms, assess whether current records satisfy the Clause 6(7) record-keeping requirement. A database row recording form submission does not constitute a compliant consent record. If current records are insufficient, design a migration or re-consent strategy.

Priority 5: Consent withdrawal workflows

Clause 6(3) requires that withdrawal be as easy as giving consent. Clause 6(4) requires processing cessation on withdrawal.

Actions for days 40 to 50: Implement self-service withdrawal interfaces in every channel where consent was originally captured. Configure automated downstream processing cessation notifications triggered by withdrawal events. Test the end-to-end withdrawal workflow: Data Principal initiates withdrawal, downstream systems receive cessation notification, processing stops, and the withdrawal event is recorded with a timestamp in the consent audit trail.

Priority 6: Data Principal rights fulfilment workflows

Clauses 11 through 14 require operational rights fulfilment infrastructure for access requests, correction and erasure requests, grievance redress, and nomination.

Actions for days 50 to 60: Implement a Data Principal rights submission portal accessible through the same channels as the consent management system. Configure structured request logging with unique reference numbers and timestamps. Build correction and erasure workflows that propagate changes across all connected systems processing the relevant personal data. Implement the grievance submission and response mechanism with documented response records.

Phase Three: Audit Infrastructure, Lifecycle Management, and Evidence Packaging (Days 61 to 90)

Phase three implements the ongoing operational controls and evidence infrastructure that make DPDPA compliance continuous rather than point-in-time.

Priority 7: Privileged access session recording for personal data systems

Clause 8(5) requires security safeguards for personal data systems. For privileged users with direct access to databases and servers holding personal data, session-level recording is the security safeguard that produces the forensic evidence standard required by a regulatory examination.

Actions for days 61 to 70: Deploy AkkuReka’s session proxy for all privileged access to databases and servers holding personal data. Verify that SMARTAudit Trails are capturing SQL query logs for database sessions and keystroke logs for SSH sessions. Confirm that session recordings are stored encrypted and indexed for forensic search.

Priority 8: Automated lifecycle management for personal data access

Clause 8(7)(a) requires erasure when the processing purpose is no longer served. Clause 8(7)(b) requires cessation and erasure on consent withdrawal. Both require automated deprovisioning workflows, not manual offboarding checklists.

Actions for days 70 to 80: Configure automated deprovisioning workflows triggered by employment termination events from HR systems. Verify that deprovisioning propagates to all connected applications processing personal data, with SCIM sync confirmation records for each. Configure dormant account detection with a defined inactivity threshold for accounts with access to personal data systems. Implement access review campaigns for personal data system access on a defined cadence.

Priority 9: Audit trail verification and evidence packaging

Clause 8(4) requires that technical measures be demonstrable. This requires that the audit trail generated by phases one through three is structured, complete, tamper-evident, and producible on demand.

Actions for days 80 to 90: Verify that the centralised audit log captures authentication events, provisioning and deprovisioning events, consent lifecycle events, Data Principal rights request and response events, and privileged session events in a single queryable trail. Test the evidence package assembly: for a sample of Data Principals, verify that the consent record, access record, and any rights exercise records can be produced in structured format without manual compilation. Run a tabletop exercise simulating a Data Protection Board examination request and assess whether the evidence package produced would satisfy the request within 24 hours.

What the 90-Day Plan Does Not Cover

This plan covers the technical and system-driven layer of DPDPA compliance. Several obligations are outside the scope of what any technology platform addresses and must be progressed in parallel through legal and governance workstreams.

Appointment of a Data Protection Officer or consent manager as required under the Act. Data protection impact assessments for high-risk processing activities. Review and update of data processing agreements with Data Processors. Assessment of cross-border data transfer mechanisms for personal data transferred outside India. Board-level governance of the data protection programme. Staff training on DPDPA obligations and data handling procedures.

These workstreams should run concurrently with the technical implementation phases, not sequentially. The technical controls this plan implements are necessary but not sufficient for full DPDPA compliance.

Key Milestones and Evidence Checkpoints

End of Phase One (Day 30): Every application processing personal data authenticates through a centralised identity layer. RBAC role configurations reflect authorised processing purposes. MFA is enforced for all personal data system access. Authentication event logging is producing continuous, structured records.

End of Phase Two (Day 60): A compliant consent management system is operational with versioned notices, purpose-specific records, and self-service withdrawal. Data Principal rights fulfilment workflows are live and producing structured request and response records.

End of Phase Three (Day 90): Automated deprovisioning is triggered by employment termination and consent withdrawal events. Access reviews are running on a defined cadence. Privileged session recordings exist for all database and server access to personal data systems. A complete audit evidence package can be assembled on demand without manual compilation.

Diagnostic Questions

Has your organisation completed an inventory of all applications processing personal data of Indian residents, and do you know which of those applications currently authenticate through a centralised identity layer?

For each processing activity where consent is the lawful basis, does a purpose-specific consent record exist per Data Principal, or does your current system capture a single agreement covering all processing?

If the Data Protection Board requested evidence of your technical security measures for personal data systems today, could you produce structured authentication event logs, access records, and privileged session recordings within 24 hours?

When an employee who had access to personal data systems leaves your organisation, does their access cease automatically across all connected systems within the same business day, with a timestamped audit record of every account removed?

Has your organisation tested the end-to-end Data Principal rights fulfilment workflow, from submission through to correction or erasure propagation across connected systems, with a documented record of the test and its outcomes?

CTAs

See how Akku addresses DPDPA technical compliance requirements across consent management, access controls, lifecycle management, and audit trails.

Book a conversation with the Akku team to assess your current technical posture and plan your DPDPA implementation sequence.

FAQs

What is the most critical DPDPA technical obligation to implement first?

The foundational obligation is Clause 8(4)’s requirement for appropriate technical measures to ensure processing is limited to authorised purposes. Technically, this means centralised authentication and role-based access controls for personal data systems must be in place before consent management or rights fulfilment workflows can be layered on top. Without knowing who can access which personal data systems and under what authorisation, consent management alone does not constitute appropriate technical measures. Access controls are the foundation on which all other DPDPA technical obligations rest.

Does the 90-day timeline apply to all organisations, or does it vary by organisation size and complexity?

The 90-day timeline is a structured framework, not a universal commitment. Larger organisations with complex application landscapes, multiple data processing systems, and large Data Principal populations will require more time for each phase. The sequence of phases is consistent regardless of organisation size: access controls before consent management before audit infrastructure. What varies is the time required within each phase. Organisations with existing centralised identity infrastructure and mature access controls may compress phase one significantly. Organisations building consent management from scratch may require more time in phase two.

What should organisations do about personal data collected before DPDPA came into force?

Clause 5(2) requires that Data Fiduciaries who collected personal data before the Act came into force, without providing a Clause 5-compliant notice, must provide a compliant notice as soon as reasonably practicable and give Data Principals the opportunity to withdraw consent. Technically, this requires identifying which Data Principals’ records were collected under pre-Act processes, delivering a compliant notice to each, and recording their response in the consent management system. This re-consent exercise should be incorporated into phase two of the implementation plan, following deployment of the consent management infrastructure.

How does DPDPA compliance interact with existing ISO 27001 or SOC 2 programmes?

Organisations with existing ISO 27001 or SOC 2 programmes will find substantial overlap with DPDPA’s technical obligations. Clause 8(5)’s security safeguards requirement maps directly to ISO 27001 A.8.5, A.8.2, and A.8.15. Clause 8(4)’s access limitation requirement maps to ISO 27001 A.5.15 and SOC 2 CC6.2 and CC6.3. Organisations that have implemented these controls for ISO 27001 or SOC 2 purposes have already addressed a significant portion of DPDPA’s technical layer. The primary DPDPA-specific addition is the consent management infrastructure under Clauses 5 and 6, which has no direct ISO 27001 or SOC 2 equivalent.

What evidence should organisations be able to produce for a Data Protection Board examination?

A Data Protection Board examination of DPDPA compliance will typically focus on: consent records demonstrating that processing is based on valid consent, access control records showing that personal data access is limited to authorised personnel, deprovisioning records demonstrating that access ceases when the processing purpose is no longer served, Data Principal rights fulfilment records showing that rights exercises were responded to appropriately, and security safeguard records demonstrating that technical measures are implemented and operating. All of these must be producible from structured, queryable systems in a format suitable for regulatory submission, not assembled through manual compilation before the examination.

What is the consequence of not having a compliant consent management system when DPDPA enforcement begins?

Processing personal data without a valid lawful basis under DPDPA is a violation of the Act. Where consent is the intended lawful basis, processing without a compliant consent record means there is no demonstrable lawful basis for the processing. The Data Protection Board can direct the Data Fiduciary to cease processing, impose financial penalties, and require remediation. The absence of a compliant consent management system is not only a technical gap: it is a fundamental lawful basis gap that affects the legality of all processing activities that rely on consent.

Introduction

RBI 2023 Master Direction Clause 20 addresses teleworking and remote access security. It is one of the most operationally relevant clauses for regulated entities whose workforce operates in hybrid or distributed modes. The clause establishes four requirements: centralised authentication for remote access under Clause 20(a), MFA for remote access to critical systems under Clause 20(b), session logging for remote access under Clause 20(c), and device compliance verification before remote access is granted under Clause 20(d).

Most regulated entities deployed remote access infrastructure rapidly during the pandemic period and have not fully assessed whether that infrastructure satisfies Clause 20’s technical requirements. VPN connectivity was extended to more staff. Laptop issuance increased. MFA was deployed for internet banking and email access. What many entities did not address systematically is the Clause 20 requirement for centralised authentication covering all remote access paths, device compliance verification before access is granted, and session logging that covers remote access events at the activity level rather than only the connection level.

The distinction between remote access that is operationally functional and remote access that satisfies Clause 20 is the same distinction that runs through the rest of the Master Direction: policy compliance versus technical enforcement. An organisation with a teleworking policy, a VPN deployment, and endpoint security software has the operational infrastructure for remote work. Whether that infrastructure satisfies Clause 20’s centralised authentication, device verification, MFA, and session logging requirements is a separate question.

This blog covers each Clause 20 sub-clause in detail, what it requires technically, the most common implementation gaps, and how IAM controls address each requirement.

Centralised Authentication for Remote Access Under Clause 20(a)

Clause 20(a) requires that remote access to information systems be provided through a secure, centralised authentication mechanism. All remote sessions must authenticate through a single identity layer that applies consistent security controls regardless of which system the user is accessing.

What the clause requires technically

Centralised authentication means that every remote access event, whether the user is accessing a business application, an infrastructure management console, or a cloud-hosted service, routes through the same identity provider with the same authentication policy applied. Fragmented remote access infrastructure where different systems have different authentication mechanisms and different MFA enforcement does not satisfy the centralised requirement.

The centralised mechanism must be secure: it must enforce authentication controls appropriate to the sensitivity of the systems being accessed. A centralised VPN that provides network-level access without application-level authentication controls does not constitute a centralised authentication mechanism for Clause 20(a) purposes. The centralised mechanism must sit at the application and session layer, not only at the network layer.

The most common gap

The most common Clause 20(a) gap is the coexistence of centralised authentication for some systems and direct authentication for others. Cloud SaaS applications route through the centralised IdP. Legacy on-premises systems authenticate directly with Active Directory credentials. Infrastructure management interfaces accept direct SSH key authentication without routing through the centralised identity layer. The result is partial centralisation that does not satisfy the complete coverage Clause 20(a) requires.

How Akku addresses it

Akku’s unified cloud identity store and SSO infrastructure provide the centralised authentication mechanism Clause 20(a) requires. All connected applications, cloud SaaS, legacy on-premises systems through directory integration, and custom internal applications through credential replay, authenticate through Akku’s centralised IdP. Infrastructure access routes through AkkuReka’s session proxy, extending centralised authentication to SSH, RDP, database, and Kubernetes access.

The single identity layer means that every remote access event, regardless of the destination system, generates a record in the same centralised authentication event log. This unified logging is both the centralisation evidence and the session logging evidence Clause 20(c) requires.

MFA for Remote Access Under Clause 20(b)

Clause 20(b) requires MFA for all remote access to critical information systems. The scope covers both end users and privileged users accessing critical systems from outside the corporate network.

What the clause requires technically

MFA must be enforced for every remote access session to a critical information system, not only for sessions flagged as high-risk. The consistent enforcement requirement means that MFA cannot be optional or context-dependent for critical system access from remote locations: every remote session to a critical system must complete MFA before access is granted.

The critical information systems scope under Clause 20(b) follows the same definition as Clause 19(c): systems whose compromise would have a material impact on operations, including core banking platforms, payment processing infrastructure, production databases, and network management interfaces.

For privileged users accessing critical infrastructure remotely, Clause 20(b) and Clause 19(c) overlap: both require MFA for the same access scenarios. The combined requirement means that privileged remote access to critical systems must satisfy both the privileged user MFA standard of Clause 19(c) and the remote access MFA standard of Clause 20(b) simultaneously.

The most common gap

The most common Clause 20(b) gap is inconsistent coverage: MFA is enforced for corporate email and productivity applications but not for remote access to production servers, databases, and network management interfaces. The corporate applications are the ones with web-based logins that were covered when MFA was first deployed. The infrastructure access paths were added to the remote access perimeter without MFA integration.

How Akku addresses it

Akku’s Adaptive MFA enforces authentication for all applications connected to the centralised identity layer. For remote access scenarios, contextual access controls detect that the session originates from outside the corporate network and apply the appropriate challenge. For infrastructure access, PAM-layer MFA enforcement through AkkuReka ensures that every remote SSH, RDP, and database session requires MFA at the IAM layer before the session proxy connection opens.

The consistent coverage across all application and infrastructure access paths is what satisfies Clause 20(b)’s all remote access to critical systems standard.

Session Logging for Remote Access Under Clause 20(c)

Clause 20(c) requires that remote access sessions be logged with sufficient detail to enable identification of the user, the systems accessed, and the actions taken. This is a session activity logging requirement, not only a connection logging requirement.

What the clause requires technically

Connection logging records that a remote session was established: user identity, source IP, target system, connection timestamp, and session duration. Action logging records what happened during the session: commands executed for SSH, queries run for database access, screen activity for RDP.

Clause 20(c)’s identify the user, the systems accessed, and the actions taken standard requires all three dimensions. Identifying the user requires the actor identity in the session record. Identifying the systems accessed requires the target system in the session record. Identifying the actions taken requires session activity logging at the command or query level for privileged access.

For standard end users accessing business applications remotely, application-level activity logs within those applications provide the actions taken dimension. For privileged users accessing infrastructure remotely, there is typically no application-level activity log for direct system connections. SMARTAudit Trails are the control that satisfies the actions taken requirement for remote privileged sessions.

The most common gap

The most common Clause 20(c) gap is the distinction between connection logs and activity logs. VPN logs record that a user connected remotely. Authentication logs record that a user authenticated to a specific application. Neither records what the user did after authentication. For remote privileged sessions to infrastructure systems, the actions taken dimension requires session-level recording.

How Akku addresses it

Akku’s centralised authentication event log satisfies the user identity and systems accessed dimensions for all remote access events. SMARTAudit Trails satisfy the actions taken dimension for remote privileged sessions: SSH keystroke logs, SQL query capture for database sessions, and RDP screen recordings are captured at the protocol layer by AkkuReka regardless of whether the session originated locally or remotely.

The remote access origin is captured in the authentication event record through the source IP and geographic location fields. A remote session produces the same structured, complete session record as a local session, with the remote origin visible in the session metadata.

Device Compliance Verification Under Clause 20(d)

Clause 20(d) requires that remote access be restricted to authorised devices and that device compliance be verified before access is granted. The device verification must be technical, not policy-based: the access control must verify the device’s compliance state and block access from non-compliant or unregistered devices.

What the clause requires technically

Device compliance verification requires integration between the identity layer and the device management layer. When a user attempts remote access, the authentication system must query the device management platform to verify the device’s current compliance state: Is it enrolled in MDM? Is it running an approved operating system version? Is it encrypted? Has it checked in with the MDM platform recently? Only after compliance verification should access proceed.

For corporate-owned devices, enrollment in MDM and compliance with the device policy are the baseline requirements. For BYOD environments, device compliance verification must assess whether the personal device meets the minimum security requirements for remote access to corporate systems.

The verification must occur at each access attempt, not only at enrollment. A device that was compliant at enrollment may have fallen out of compliance through OS updates that break policy, antivirus deactivation, or MDM check-in failures. The at-access verification catches compliance drift that enrollment-time verification misses.

The most common gap

The most common Clause 20(d) gap is certificate-based device verification that checks enrollment but not current compliance state. A device is issued a client certificate at enrollment. The certificate is presented at remote access to confirm the device is enrolled. But the certificate does not reflect the device’s current compliance state: an enrolled device that has not checked in with MDM for 60 days and is running outdated software still presents a valid certificate.

Real compliance verification queries the MDM platform in real time to assess the device’s current state, not only its enrollment status.

How Akku addresses it

Akku’s contextual access controls integrate device compliance verification at the authentication layer. Device-based access restrictions query MDM enrollment and compliance status before access is granted. A device that is not enrolled in Akku MDM or that has failed compliance checks is blocked from accessing in-scope applications regardless of whether the user’s credentials are valid.

MDM device compliance policies cover OS version, encryption status, passcode requirements, MDM check-in recency, and app compliance. A device that fails any configured compliance criterion is flagged non-compliant and blocked from remote access until compliance is restored.

The device compliance check result is logged alongside the authentication event, creating a record showing that compliance verification occurred and what the result was for each remote access attempt. This log is the Clause 20(d) evidence.

Akku’s RBI compliance mapping shows Mobile Device Manager addresses Clauses 20(c), 20(d), 23(d), and 25(b), and GPO Manager addresses the same clauses across the endpoint security layer.

The Complete Clause 20 Implementation

Satisfying all four Clause 20 sub-clauses requires the four controls to operate as an integrated system, not as separate deployments.

Centralised authentication under Clause 20(a) provides the single identity layer that all remote access routes through. MFA under Clause 20(b) enforces authentication assurance at that identity layer for all remote access to critical systems. Session logging under Clause 20(c) captures the complete remote session record, from authentication through to session activity, in the centralised audit trail. Device compliance verification under Clause 20(d) gates access at the identity layer based on real-time device compliance status from MDM.

When these four controls operate together through a single platform, the remote access session produces a complete, structured record: device compliance verified, MFA completed, session authenticated, session activity recorded. This is the evidence chain that an RBI IS audit of Clause 20 expects to find for every remote session to a critical system.

Diagnostic Questions

Does every remote access session to a critical information system route through a centralised identity provider that applies consistent authentication controls, or do some systems accept direct authentication bypassing the centralised layer?

For remote access sessions by privileged users to production servers and databases, is there a session activity recording capturing commands executed and queries run, not only a VPN or authentication log confirming the connection?

Does your device compliance verification assess the device’s current compliance state in real time at each access attempt, or does it verify only that the device is enrolled based on a certificate issued at enrollment time?

Can you produce for any remote access session to a critical system in the last 90 days: the device compliance verification result, the MFA authentication record, the session activity log, and the source network context, all from a single queryable audit trail?

Have you tested whether remote access to critical infrastructure systems, specifically SSH and direct database connections, requires MFA enforcement, or whether these access paths can be established from remote networks without the centralised MFA challenge?

CTAs

See how Akku addresses RBI Clause 20 teleworking and remote access requirements across centralised authentication, MFA enforcement, session logging, and device compliance verification.

Book a conversation with the Akku team to assess your current remote access infrastructure against RBI Clause 20’s technical obligations.

FAQs

Does RBI Clause 20 apply only to employees working from home, or to all remote access scenarios?

Clause 20 covers all remote access to information systems, not only work-from-home scenarios. Remote access includes any access from outside the corporate network: employees working from home, staff travelling and accessing systems from hotels or airports, third-party vendors accessing systems remotely for support or maintenance, and any other access that originates outside the corporate network perimeter. The clause is technology-neutral: it applies regardless of whether remote access is through VPN, direct internet access to cloud-hosted systems, or any other remote connectivity method.

What is the difference between VPN-based remote access and the centralised authentication Clause 20(a) requires?

VPN provides network-level connectivity: it extends the corporate network to the remote device, allowing the device to reach systems on the corporate network. VPN does not provide application-level authentication controls. A user on VPN can still authenticate to individual applications using direct credentials, bypassing any centralised identity provider. Clause 20(a) requires centralised authentication at the application and session layer, not only network-level connectivity. VPN may be a component of the remote access architecture, but it does not substitute for centralised authentication. The centralised identity provider must sit between the remote user and every application or system they access, regardless of whether VPN connectivity is also used.

Does Clause 20(b) require MFA for video conferencing and productivity tools accessed remotely, or only for critical information systems?

Clause 20(b) requires MFA specifically for remote access to critical information systems. The critical information systems definition covers systems whose compromise would have a material impact on operations: core banking platforms, payment processing systems, production databases, and network management infrastructure. Standard productivity tools including email, video conferencing, and document management are not typically classified as critical information systems for Clause 20(b) purposes unless they hold regulated data or are critical to operational continuity. However, MFA for all corporate applications is a security best practice that most regulated entities implement regardless of the specific Clause 20(b) scope.

How does Clause 20(d)’s device compliance requirement apply to BYOD environments where employees use personal devices for remote work?

For BYOD remote access, Clause 20(d) requires that device compliance be verified before access is granted. For personal devices, the compliance baseline must be appropriate to the device type: OS version currency, passcode enforcement, encryption, and MDM enrollment or at minimum a managed work profile on Android devices. Access from personal devices to systems classified as critical should be treated with heightened scrutiny: either requiring higher assurance device compliance or restricting access to a limited subset of functionality through a secure browser with no data download capability. The compliance verification infrastructure must extend to personal devices: a device compliance policy that applies only to corporate-owned devices does not satisfy Clause 20(d) for BYOD environments.

Can a regulated entity satisfy Clause 20 using a cloud-based identity provider, or does the centralised authentication mechanism need to be on-premises?

Clause 20 does not require on-premises deployment of the centralised authentication mechanism. A cloud-based identity provider that routes all remote access authentication through a centralised platform satisfies Clause 20(a)’s centralised mechanism requirement. The RBI framework is technology-neutral on deployment model. The relevant assessment is whether the cloud-based platform provides the required controls: consistent authentication enforcement, MFA, session logging, and device compliance verification. Akku supports both cloud-native SaaS deployment and on-premises deployment for regulated entities with specific data sovereignty or private network requirements.

How does Clause 20’s teleworking security requirement interact with Clause 19’s privileged access requirements for remote privileged sessions?

Clauses 19 and 20 overlap for remote privileged access scenarios. A system administrator accessing a production server from home must satisfy Clause 19(a)’s need-based access requirement, Clause 19(b)’s supervision and logging requirement, Clause 19(c)’s MFA requirement, and Clause 20(a)’s centralised authentication requirement, Clause 20(b)’s remote MFA requirement, Clause 20(c)’s remote session logging requirement, and Clause 20(d)’s device compliance requirement simultaneously. The PAM architecture addresses both clause sets in a single implementation: JIT access satisfies 19(a), SMARTAudit Trails satisfy 19(b) and 20(c), PAM-layer MFA satisfies 19(c) and 20(b), centralised authentication through Akku IdP satisfies 20(a), and MDM device compliance verification satisfies 20(d)

Introduction

Zero trust is not a product category. It is an access architecture built on three principles: verify every identity before granting access, enforce least privilege for every access decision, and monitor continuously for anomalies. What makes zero trust relevant to compliance is that every major regulatory framework reviewed in this series, DPDPA, RBI, SEBI CSCRF, IRDAI ICS, ISO 27001:2022, SOC 2 Type II, and GDPR, has arrived at requirements that collectively describe zero trust architecture without using the term.

RBI Clause 19(a) requires need-based access. That is least privilege. RBI Clause 19(c) requires MFA for privileged users. That is verify every identity. RBI Clause 15 requires audit trails for every session. That is monitor continuously. SEBI CSCRF PR.AA.S7 requires authentication controls commensurate with resource sensitivity. That is risk-based verification. ISO 27001:2022 A.8.2 requires that privileged access be event-by-event and time-limited. That is JIT access with no standing privilege. DPDPA Clause 8(4) requires that access be limited to authorised purposes. That is least privilege at the data processing layer.

The convergence is not accidental. Regulators across industries and jurisdictions have independently arrived at the same access architecture requirements because the threat model they are responding to is the same: credential compromise, insider access abuse, and entitlement drift are the dominant vectors in the breaches and incidents that drive regulatory action. Zero trust architecture addresses all three.

This blog maps the zero trust principles to the specific regulatory requirements that implement them, explains why compliance frameworks are converging on this architecture, and covers what implementing zero trust means technically for regulated organisations.

Verify Every Identity: How Regulations Implement This Principle

Zero trust’s verify every identity principle requires that every access request be authenticated with assurance proportionate to the sensitivity of the resource, regardless of where the request originates. The implicit trust of the corporate network, where users inside the perimeter were trusted by default, is replaced by explicit verification for every request.

How the frameworks state it

RBI 2023 Master Direction Clause 19(c) requires MFA for privileged users accessing critical information systems. Clause 20(b) requires MFA for all remote access to critical systems. SEBI CSCRF PR.AA.S7 requires authentication controls commensurate with the sensitivity of the resource. IRDAI ICS Items 52 and 64 require MFA for network device management and critical system access. ISO 27001:2022 A.8.5 requires secure authentication procedures. SOC 2 CC6.1 and CC6.6 require logical access security software and boundary protection. GDPR Article 32(1)(b) and DPDPA Clause 8(5) require appropriate security measures for processing.

What this requires technically

Verify every identity requires adaptive, risk-based authentication that evaluates context at each access event. Device posture, geographic location, IP reputation, time of day, and behavioural baseline are the signals that determine authentication assurance at the point of access. A user accessing from a recognised, compliant device at a normal time from a known location faces a standard authentication challenge. The same user accessing from an unrecognised device, a new country, or at an unusual hour faces an escalated challenge.

This proportionate model is what SEBI CSCRF PR.AA.S7 requires. A uniform MFA enforcement applied identically to all sessions regardless of risk context does not satisfy the proportionality requirement. Adaptive MFA that escalates based on risk signals does.

For infrastructure access specifically, MFA must extend to the protocol layer. SSH sessions to servers, database management connections, and network device management interfaces must be authenticated with the same assurance as application-layer access. The infrastructure layer is where most regulated entities have an MFA coverage gap.

Akku’s Adaptive MFA implements risk-based authentication across all connected applications, with infrastructure-level MFA enforcement through PAM for privileged access scenarios.

Enforce Least Privilege: How Regulations Implement This Principle

Zero trust’s enforce least privilege principle requires that every user, service, and system has access only to what they need for their current, specific task, and that access is removed when the task is complete.

How the frameworks state it

RBI Clause 19(a) requires need-based access: users access only what their role requires. SEBI CSCRF PR.AA.S1 through S9 cover identity management, access provisioning, and least privilege enforcement. IRDAI ICS Item 50 requires access restricted to authorised personnel on a need-to-know basis. ISO 27001:2022 A.5.15 covers access control and A.8.2 requires privileged access to be event-by-event and time-limited. SOC 2 CC6.2 and CC6.3 require formal user registration and access modification based on the system of record for entitlements. DPDPA Clause 8(4) requires that processing be limited to authorised purposes. GDPR Article 25(2) requires data minimisation by default.

What this requires technically

Least privilege at the identity layer requires three controls operating together. Role-based access control that scopes access entitlements to what each role legitimately requires. SoD enforcement that prevents conflicting role combinations from accumulating in a single user. Periodic access reviews that detect and revoke entitlements that are no longer appropriate.

Least privilege for privileged access requires JIT access. No administrator holds standing credentials to servers, databases, or network devices. Access is granted for the duration of an approved, time-bound session and automatically revoked on expiry. This is what ISO 27001 A.8.2’s event-by-event, need-to-use requirement describes. It is also what RBI Clause 19(a)’s need-to-do access framing requires for infrastructure access.

AkkuArka’s per-session ephemeral credentials implement least privilege at the credential layer. Each session uses a unique credential scoped to the access level required for that session’s approved purpose. The credential cannot be reused after the session closes. This is not credential rotation. It is per-session credential lifecycle management that makes standing privilege architecturally impossible.

Contextual access controls add a further least-privilege layer by restricting access based on device compliance, IP range, geographic location, and time of day. An entitlement that is valid for a user’s role may still be blocked if the access context does not satisfy the contextual policy. This is the granular access control that frameworks like SEBI CSCRF PR.AA.S4 and RBI Clause 20 require for remote and distributed workforce access.

Monitor Continuously: How Regulations Implement This Principle

Zero trust’s monitor continuously principle requires that all access activity be logged, that anomalies be detected as they occur rather than discovered in retrospective log review, and that the audit trail be available for investigation at any time.

How the frameworks state it

RBI Clause 15 requires audit trails suitable for forensic investigation and dispute resolution. SEBI CSCRF DE.CM.S1 through S3 require continuous monitoring of system components with automated anomaly detection. IRDAI ICS Item 5 requires user behaviour monitoring to detect anomalies in login time, location, and session duration. ISO 27001:2022 A.8.15 requires logging of user activities and A.8.16 requires monitoring for anomalous behaviour. SOC 2 CC7.2 requires monitoring of system components for anomalies. GDPR Article 32(1)(d) requires regular testing and evaluation of technical security measures.

What this requires technically

Continuous monitoring requires three layers. Authentication event monitoring that detects anomalies at the login layer: MFA failure spikes, geographic anomalies, access outside defined time windows, and new device registrations. Session activity monitoring for privileged access through SMARTAudit Trails: every command, every query, every screen action captured at the protocol layer. Access governance monitoring through the IGA layer: entitlement drift detection through access reviews, SoD violation detection through the rules engine, and dormant account identification through activity monitoring.

The monitoring infrastructure must be active, not passive. Logs that are stored and reviewed periodically do not satisfy DE.CM’s continuous monitoring requirement or A.8.16’s anomaly detection requirement. The monitoring layer must evaluate events against baselines as they occur and generate alerts without waiting for a review cycle.

The audit trail must be tamper-evident and available on demand. SEBI CSCRF GV.OC.S2(G3) requires on-demand log access for SEBI examination. RBI Clause 15(c) requires tamper-protected logs. IRDAI Item 274 requires on-demand evidence production for regulatory examination. An append-only audit log with structured export capability satisfies all three simultaneously.

Why Compliance Frameworks Converge on Zero Trust Architecture

The convergence of compliance frameworks on zero trust architecture reflects the shared threat model that has driven regulatory action across industries and jurisdictions over the last decade.

The shared threat model

The incidents that drive regulatory action have consistent characteristics. Credential compromise through phishing or credential stuffing gives an attacker authenticated access with no visible breach of the perimeter. Insider access abuse exploits legitimate entitlements to access data or systems beyond what the role requires. Entitlement drift creates attack surface as users accumulate access across role changes without systematic revocation. Standing privileged credentials provide persistent access that, once compromised, cannot be revoked without disabling the account entirely.

Zero trust architecture addresses all four vectors: adaptive MFA raises the bar for credential compromise. Least privilege limits the blast radius of insider access abuse. Access reviews detect and remediate entitlement drift. JIT access and per-session ephemeral credentials eliminate standing privilege.

When regulators across different sectors, the RBI, SEBI, IRDAI, ISO, AICPA, and EU data protection authorities, independently arrive at requirements for MFA, least privilege, session monitoring, and access reviews, they are each responding to the same incident patterns in their respective regulated sectors. The technical architecture that addresses those incident patterns is zero trust.

What convergence means for regulated organisations

For organisations subject to multiple compliance frameworks, the convergence on zero trust architecture is a practical efficiency. Implementing zero trust principles satisfies the access control requirements of multiple frameworks simultaneously because the frameworks are describing the same technical architecture in different regulatory language.

An adaptive MFA deployment that satisfies RBI Clause 19(c) simultaneously satisfies SEBI CSCRF PR.AA.S7, IRDAI ICS Items 52 and 64, and ISO 27001 A.8.5. A JIT access implementation that satisfies ISO 27001 A.8.2 simultaneously satisfies RBI Clause 19(a) and SOC 2 CC6.3. A continuous monitoring infrastructure that satisfies SEBI CSCRF DE.CM simultaneously satisfies ISO 27001 A.8.16 and SOC 2 CC7.2.

The efficiency is real and measurable. Akku’s compliance mapping shows 15 DORA articles fully addressed, 41 ISO 27001 clauses mapped, 88 SEBI CSCRF compliance items covered, 79 IRDAI requirements addressed, and 36 GDPR compliance items supported, from a single platform implementing the same zero trust architecture across all frameworks.

The Zero Trust Implementation Stack for Regulated Organisations

Implementing zero trust architecture for a regulated organisation requires five technical capabilities operating together.

Centralised identity and authentication infrastructure with adaptive MFA covering all applications and infrastructure access paths. This is the verify every identity layer. Akku’s unified cloud identity store, SSO, and Adaptive MFA constitute this layer.

Role-based and attribute-based access control with SoD enforcement and contextual access restrictions. This is the enforce least privilege layer for standard access. Akku’s RBAC, ABAC, contextual access controls, and IGA SoD rules engine constitute this layer.

JIT access with per-session ephemeral credentials for privileged infrastructure access. This is the enforce least privilege layer for privileged access. AkkuArka and AkkuReka’s PAM architecture constitute this layer.

Continuous monitoring with anomaly detection at the authentication layer and session activity logging at the privileged access layer. This is the monitor continuously layer. Akku’s Adaptive MFA anomaly detection, SMARTAudit Trails, and identity and access security monitoring constitute this layer.

Automated lifecycle management with access reviews and dormant account controls. This is the continuous access governance layer. Akku’s User Lifecycle Manager, IGA access review campaigns, and automated deprovisioning constitute this layer.

Diagnostic Questions

Does your authentication infrastructure apply risk-based verification for every access request, escalating the challenge based on device posture, location, and behavioural signals, or does it apply uniform MFA regardless of access context?

Do privileged users hold standing credentials to servers and databases that are valid between sessions, or does your architecture ensure that access to critical infrastructure requires a new approval and uses a session-specific credential for every connection?

Does your monitoring infrastructure detect authentication anomalies in real time and generate alerts, or are anomalies discovered during periodic log review after the fact?

Can you produce evidence that access entitlements across all connected systems are periodically reviewed and that entitlements no longer appropriate are revoked, with a structured evidence record for every review cycle?

If a privileged user’s credentials were compromised today, how many systems would the attacker be able to access, and for how long, before the access was detected and revoked?

CTAs

See how Akku implements zero trust access architecture across identity assurance, least privilege enforcement, and continuous monitoring for regulated organisations.

Book a conversation with the Akku team to assess your current access architecture against zero trust principles and the compliance frameworks that require them.

FAQs

What is zero trust architecture, and how does it differ from perimeter-based security?

Perimeter-based security assumes that users inside the corporate network are trusted and that the security boundary is the network edge. Zero trust replaces implicit trust with explicit verification: every access request is authenticated with appropriate assurance, every access decision enforces least privilege, and every session is monitored continuously, regardless of where the request originates. The shift from perimeter to zero trust is driven by the dissolution of the network perimeter through remote work, cloud adoption, and mobile access, combined with the demonstrated failure of perimeter-based models to prevent credential compromise and insider access abuse.

Why are compliance frameworks converging on zero trust architecture if they were written independently?

The convergence reflects the shared incident patterns that drove regulatory action across sectors. Credential compromise, insider access abuse, entitlement drift, and standing privileged credentials are the dominant vectors in the breaches and incidents that regulators in financial services, insurance, data protection, and IT assurance have all observed in their respective regulated populations. The technical architecture that addresses these vectors, verify every identity, enforce least privilege, and monitor continuously, is zero trust. When regulators independently arrive at requirements for MFA, need-based access, session recording, and access reviews, they are each describing the same architecture in their own regulatory language.

Does implementing zero trust architecture require replacing existing IAM infrastructure?

Not necessarily. Zero trust is an architecture achieved through the combination of controls, not a single product replacement. An organisation can extend its existing infrastructure toward zero trust principles by adding adaptive MFA where standard MFA exists, implementing JIT access for privileged users without replacing existing identity infrastructure, adding session activity logging for privileged sessions through a PAM-layer proxy, and implementing automated access reviews through an IGA platform. The transition to zero trust architecture is typically incremental, prioritising the highest-risk access scenarios first.

How does JIT access implement zero trust’s least privilege principle for privileged users?

JIT access means that privileged users hold no standing credentials to target systems. Every privileged session requires a formal approval, uses a session-specific credential generated at approval and revoked at close, and operates within a defined time window. This implements least privilege at three levels simultaneously: the user has no access between sessions, the credential for each session is scoped to the approved purpose, and the session window limits the duration of elevated access. Standing privilege with persistent credentials is the antithesis of zero trust’s least privilege principle. JIT access operationalises the principle for every privileged session.

How does continuous monitoring satisfy the zero trust principle of assume breach?

The assume breach principle in zero trust holds that the network should be monitored as if a breach has already occurred or is imminent. This requires that all activity, not only suspicious activity, be logged and that anomalies be detected and acted upon in real time. Continuous monitoring through authentication event logging, session activity recording, and anomaly detection implements this principle technically. When an anomaly is detected, such as a privileged user accessing an unusual system or executing commands outside their normal pattern, the monitoring infrastructure surfaces it for investigation rather than waiting for an incident report. The audit trail produced by continuous monitoring also satisfies the forensic investigation requirements that RBI Clause 15, SEBI CSCRF PR.AA.S12, and ISO 27001 A.8.15 impose.

Can a single IAM deployment implement zero trust architecture across multiple compliance frameworks simultaneously?

Yes. Zero trust architecture is implemented through the combination of adaptive MFA, RBAC with least privilege enforcement, JIT access with per-session ephemeral credentials, continuous monitoring with anomaly detection, and automated lifecycle management with access reviews. These controls, implemented in a single IAM platform, satisfy the verify every identity, enforce least privilege, and monitor continuously principles simultaneously. Because compliance frameworks have converged on requirements that collectively describe this architecture, a single deployment implementing zero trust principles produces compliance evidence for DPDPA, RBI, SEBI CSCRF, IRDAI, ISO 27001, SOC 2, and GDPR from the same technical foundation.