The Insurance Regulatory and Development Authority of India’s Information and Cyber Security Guidelines, 2023 apply to all insurers, re-insurers, and IRDAI-regulated intermediaries operating in India. The guidelines contain 348 checklist items in Annexure III covering identity and access management, endpoint security, privileged access, audit trails, user behaviour monitoring, and remote access controls. They are not advisory. Compliance is mandatory and subject to IS audit examination.
Most insurance IT teams are familiar with the guidelines at a summary level. The detailed technical implementation requirements within the 348-item checklist are less commonly mapped. Item 14 requires centralised authentication, not just SSO deployment but a specific architectural requirement with audit evidence implications. Item 52 requires MFA for network device management, an infrastructure-level requirement that many insurers have not extended beyond application-layer MFA. Items 144 and 145 require session-level audit trails for privileged access, not authentication logs alone.
This blog covers the IRDAI ICS Guidelines’ key technical requirements by category, what each requirement means at the implementation level, and how IAM controls address them. All item references are drawn directly from the IRDAI ICS Annexure III checklist and Akku’s IRDAI compliance mapping documentation, which covers 79 unique compliance requirements with 97 overlapping control mappings across the platform.
The IRDAI ICS Guidelines contain requirements for physical security, governance, disaster recovery, VAPT, and network controls that are outside the scope of IAM platforms. What follows covers the IAM-addressable technical controls layer specifically.
Scope and Applicability of IRDAI ICS Guidelines
The IRDAI ICS Guidelines apply broadly across the insurance sector. Understanding the full scope of applicability is important before mapping technical requirements, as the guidelines cover not only insurers but intermediaries and service providers operating within the sector.
Who the guidelines apply to
The guidelines apply to all insurers registered with IRDAI, including life insurers, general insurers, health insurers, and re-insurers. They also apply to insurance intermediaries including insurance brokers, corporate agents, web aggregators, and insurance marketing firms. Third-party administrators and other entities in the IRDAI-regulated ecosystem are expected to maintain equivalent security standards under their contractual and regulatory obligations.
Framework structure
The guidelines are structured around domains including identity and access management, endpoint security, network security, application security, data security, incident management, business continuity, and governance. Annexure III contains the 348-item compliance checklist that IS auditors use to assess compliance. Items are grouped by domain, and each item specifies a control requirement that must be technically implemented and evidenced.
Akku’s IRDAI compliance mapping covers 79 of the 348 checklist items, representing the IAM and endpoint security addressable subset of the framework. The remaining items cover network infrastructure, VAPT, physical security, governance, and disaster recovery requirements outside IAM scope.
Authentication and Access Control Requirements
Authentication and access control requirements appear across multiple checklist items in the IRDAI ICS Guidelines. The requirements extend from centralised authentication infrastructure through to MFA for specific access scenarios and need-based access governance.
What the guidelines require
Item 14 requires that all access to organisational systems be authenticated through a centralised authentication mechanism. Fragmented authentication, separate credentials per application, inconsistent MFA coverage, and siloed identity stores, does not satisfy this requirement. Centralised authentication implies a single identity source and a unified authentication layer across all systems.
Item 50 requires that access to systems processing sensitive data be restricted to authorised personnel on a need-to-know basis. Access must be role-based and reviewed periodically.
Item 52 requires MFA for managing network devices and for privileged access to critical systems. This is an infrastructure-level MFA requirement that extends beyond application-layer authentication.
Item 64 and Item 65 require MFA for remote access to organisational systems and for access to critical applications from outside the corporate network.
Item 135 requires that password policies enforce complexity, length, expiry, and history requirements. Password policies must be technically enforced, not policy-stated.
Item 148 requires step-up authentication for access to high-sensitivity systems, reflecting the same proportionate authentication model that SEBI CSCRF PR.AA.S7 requires.
How Akku addresses it
Akku’s unified cloud identity store and SSO infrastructure provide the centralised authentication mechanism Item 14 requires. All connected applications authenticate through the Akku identity layer. A single identity source eliminates fragmented credential infrastructure. Akku’s IRDAI mapping shows Cloud Directory and SSO together address Items 14, 50, 135, 176, 204, 298, and 300.
Adaptive MFA satisfies Items 52, 64, 65, 135, 148, 182, and 270. For infrastructure-level MFA required by Item 52, Akku extends authentication assurance to privileged sessions through PAM, enforcing MFA at the IAM layer before any session proxy connection opens to network devices, servers, or databases.
RBAC and ABAC enforce need-based access at the role level. Contextual access controls restrict access by device, IP, time-of-day, and location. Access Manager addresses Items 5, 87, 102, 111, 155, 157, 171, 175, 202, 204, 266, 298, and 299 across 13 total mappings.
Endpoint and Device Security Requirements Under Items 11 to 31
The IRDAI ICS Guidelines contain detailed endpoint security requirements that map to GPO and MDM controls. These items address session lockout, removable media, peripheral device governance, and URL filtering, reflecting the guidelines’ recognition that endpoint controls are a critical layer of data protection for insurance environments.
What the guidelines require
Item 11 requires automatic session lockout after a defined period of inactivity. This must be technically enforced at the endpoint, not policy-stated.
Item 15 requires controls on removable media including USB storage devices. Unauthorised USB usage is a data exfiltration vector that the guidelines specifically address.
Item 18 requires controls on the use of personal devices for accessing organisational systems. For BYOD environments, this maps to work profile isolation and device compliance enforcement.
Item 27 and Item 28 require that Bluetooth and wireless peripheral usage be controlled on managed endpoints, limiting data transfer and pairing risks.
Item 31 requires URL filtering to restrict access to high-risk or non-business web categories. This is a network-level control at the endpoint layer.
Item 36 and Item 37 require that screen capture and printing be restricted in environments processing sensitive data.
How Akku addresses it
Akku’s GPO Manager and MDM together address 31 of the 97 total IRDAI control mappings, the highest combined module count in the IRDAI mapping. This reflects how heavily the guidelines weight endpoint and device security controls.
GPO Manager enforces session lockout policies (Item 11), USB storage restrictions (Item 15), Bluetooth limitations (Item 28), screenshot and screen capture controls (Item 36 and 37), and URL filtering via DNS-based filtering (Item 31). Policies are defined centrally and enforced across Windows, macOS, and Linux endpoints from a single dashboard without dependence on Active Directory.
MDM addresses BYOD and corporate mobile device requirements including device enrollment and approval workflows, work profile isolation on Android devices preventing cross-profile data movement, app whitelisting, remote work-profile wipe, and device compliance enforcement. MDM and GPO together address 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.
Privileged Access and Session Monitoring Requirements
The IRDAI ICS Guidelines contain specific requirements for privileged access governance and session monitoring. Items 32, 52, 144, 147, and 151 together define a privileged access management standard that goes beyond credential storage to require session-level controls and audit evidence.
What the guidelines require
Item 32 requires that privileged access be granted only to authorised personnel and that privileged accounts be separately identified and managed.
Item 52 requires MFA for privileged access to critical systems and network devices, as noted above.
Item 144 requires that all privileged sessions be logged with sufficient detail to enable reconstruction of activities performed. Authentication records alone do not satisfy this requirement.
Item 147 requires that privileged access be reviewed periodically and that access no longer required be revoked promptly.
Item 151 requires that privileged credentials not be shared and that each privileged user have individual, accountable credentials.
Item 190 requires that privileged session activity be monitored in real time, not only retrospectively reviewed.
Item 206 requires that privileged access to production systems follow a formal request and approval process.
How Akku addresses it
AkkuArka generates per-session ephemeral credentials for every privileged session. No privileged user holds standing credentials to target systems. Each session uses a unique credential generated at approval and permanently revoked on close. This directly satisfies Item 151’s individual, non-shared credential requirement and Item 32’s separately managed privileged account requirement.
The session approval workflow satisfies Item 206. Every privileged session request includes target system, access level, duration, and justification. Approval decisions are logged with approver identity and timestamp. No session opens without approval when the workflow is enabled.
SMARTAudit Trails satisfy Item 144’s session-level logging requirement. SSH sessions produce full screen recordings and complete keystroke logs. Database sessions produce full screen recordings and structured SQL query capture. RDP sessions produce full screen video recordings. All recordings are stored encrypted, indexed for forensic search, and accessible from the Akku admin console.
Real-time session monitoring satisfies Item 190. Administrators view all active privileged sessions from the Akku admin console and can terminate any session instantly. Termination is recorded in the audit log.
Periodic access review and re-certification campaigns satisfy Item 147. Akku’s IRDAI mapping shows Privileged Access Manager addresses Items 32, 52, 144, 147, 151, 190, 202, 206, 266, and 274 across 10 total mappings.
Audit Trail and User Behaviour Monitoring Requirements
The IRDAI ICS Guidelines contain specific requirements for audit trail maintenance and user behaviour monitoring that go beyond standard authentication logging. Items 2, 5, 35, 54, and 55 together define an audit and monitoring standard that requires both structured log infrastructure and anomaly detection capability.
What the guidelines require
Item 2 requires that audit trails be maintained for all access to systems processing sensitive data, with sufficient detail for forensic investigation.
Item 5 requires that user behaviour monitoring be implemented to detect anomalies in login time, login location, session duration, and access patterns. Alerts must be generated when behaviour deviates from established baselines.
Item 35 requires that audit logs be protected against tampering and unauthorised modification. Logs must be retained for a defined period and available for regulatory examination.
Item 54 and Item 55 require that security events including failed authentication attempts, privilege escalation events, and policy violations be logged and reviewed.
Item 274 requires that audit trail evidence be producible for regulatory examination on demand.
Item 302 requires that access to audit log infrastructure itself be restricted and logged, preventing privileged users from modifying or deleting audit records.
How Akku addresses it
Akku’s centralised audit log architecture is append-only and tamper-evident. Existing records cannot be modified or deleted. This is the log integrity standard Items 35 and 302 require. Logs are exportable in JSON and CSV format for regulatory submission, satisfying Item 274’s on-demand evidence requirement.
SMARTAudit Trails provide the session-level logging that Item 2 requires for privileged access to sensitive data systems. Every privileged command and database query is captured, indexed, and searchable by timestamp, command string, or SQL query.
Akku’s identity and access security monitoring layer captures authentication anomalies for Item 5’s user behaviour monitoring requirement. Login time anomalies, geographic location changes, access outside configured time windows, and MFA failure spikes are surfaced through risk and audit dashboards. Configurable alerts notify administrators of behavioural deviations without waiting for manual log review.
Authentication event logging captures failed authentication attempts and MFA failures with actor identity, timestamp, source IP, and outcome, satisfying Items 54 and 55. Akku’s IRDAI mapping shows Audit Logs addresses Items 2, 5, 35, 54, 55, 144, 145, 274, and 302 across nine total mappings.
How IAM Addresses IRDAI ICS Technical Obligations
Akku’s IRDAI ICS compliance mapping covers 79 unique compliance requirements from the 348-item Annexure III checklist, with 97 overlapping control mappings across nine platform modules. The coverage reflects defence-in-depth across the identity, access, endpoint, privileged access, and audit trail layers of the guidelines.
The GPO Manager and MDM combination carries the highest combined mapping count at 31, reflecting the guidelines’ detailed endpoint security requirements. Access Manager carries 13 mappings across authentication, access control, and session management items. Privileged Access Manager carries 10 mappings across the privileged access governance and session monitoring items. Audit Logs carries nine mappings across the audit trail and user behaviour monitoring items.
An important scoping note: Akku covers IRDAI’s core identity and access security requirements. Exclusions are limited to non-IAM areas including physical security, governance, disaster recovery, VAPT, and network infrastructure controls. Akku does not guarantee full regulatory compliance on its own but provides a strong technical security baseline aligned with IRDAI expectations. Broader regulatory needs including governance, physical security, and network controls require additional measures addressed during implementation planning.
Questions Insurance IT Teams Ask About IAM Technical Controls Under IRDAI ICS Guidelines 2023
Which IRDAI-regulated entities are subject to the ICS Guidelines 2023?
The guidelines apply to all insurers registered with IRDAI including life, general, health, and re-insurers, as well as insurance intermediaries including brokers, corporate agents, web aggregators, and insurance marketing firms. Third-party administrators and other entities in the IRDAI-regulated ecosystem are expected to maintain equivalent standards under contractual and regulatory obligations. The 348-item Annexure III checklist is the assessment instrument IS auditors use to evaluate compliance across all in-scope entities.
What does Item 14 require for centralised authentication, and how is this different from simply deploying SSO?
Item 14 requires that all access to organisational systems be authenticated through a centralised authentication mechanism. SSO deployment satisfies part of this requirement by providing single sign-on across connected applications. Full satisfaction requires a single identity source, a unified authentication layer that all applications route through, consistent MFA enforcement across all systems, and a centralised audit trail of all authentication events. An SSO deployment that coexists with separate application-level credentials, or that covers only some systems, does not satisfy the centralisation requirement Item 14 imposes.
Why does Item 52 require MFA for network device management specifically, and what does this mean technically?
Network devices including routers, switches, and firewalls are high-value targets for attackers because compromising them enables broad lateral movement and traffic interception. Item 52 requires MFA for managing these devices because a stolen administrator password without a second factor provides unrestricted network access. Technically, this requires MFA enforcement at the infrastructure management layer, not only at application login screens. Akku extends MFA to infrastructure sessions through PAM, enforcing authentication at the IAM layer before any privileged session to network management interfaces opens.
What does Item 5 require for user behaviour monitoring, and how is this different from standard authentication logging?
Item 5 requires detection of anomalies in login time, login location, session duration, and access patterns, with alerts generated when behaviour deviates from established baselines. Standard authentication logging records that a login occurred. User behaviour monitoring requires a baseline of normal behaviour per user or user group and continuous comparison of new events against that baseline. Deviations, logging in from a new country, accessing systems at unusual hours, or session durations significantly longer than normal, must trigger alerts rather than being discovered during manual log review.
How does Akku’s SMARTAudit Trails capability satisfy IRDAI Item 144’s session logging requirement?
Item 144 requires that all privileged sessions be logged with sufficient detail to enable reconstruction of activities performed. SMARTAudit Trails capture every privileged session at the protocol layer through AkkuReka: full screen recordings for SSH and RDP sessions, complete keystroke logs per command for SSH, and structured SQL query capture for database sessions. Recordings are stored encrypted, indexed for forensic search by timestamp, command string, or SQL query, and accessible for in-browser playback. This session-level evidence satisfies the reconstruction requirement that authentication logs cannot provide.
Can a single IAM deployment address both IRDAI ICS and DPDPA requirements simultaneously?
Yes. The overlapping technical controls are substantial. IRDAI ICS Item 14 and DPDPA Clause 8(5) both require appropriate technical security measures including centralised authentication. IRDAI ICS Item 144 and DPDPA Clause 8(5) both require audit trail infrastructure for privileged access to sensitive data systems. IRDAI ICS Item 50 and DPDPA Clause 8(4) both require need-based access controls for sensitive data. A single Akku deployment implementing these controls produces compliance evidence for both frameworks from the same technical infrastructure.
