IRDAI Cybersecurity Guidelines 2026: The Complete CXO Briefing
175 pages. 24 security domain policies. 347 audit controls. Effective from the current financial year. Here is what every insurer, intermediary, and IIB needs to know — and the 90 days that matter most.
1. IRDAI released Version 2.0 on 6 April 2026 (circular ref IRDAI/GA&HR/CIR/MISC/51/4/2026), replacing the 2023 framework. 2. Effective from the current financial year (FY 2026-27), with no explicitly defined transition period in the circular. 3. The audit checks 347 controls organised around the NIST Cybersecurity Framework, not IRDAI section numbers. Evidence libraries organised by IRDAI section create audit-navigation friction. 4. Applies to all insurers (incl. FRBs), all intermediaries, and IIB. New 3-tier intermediary classification — all ISNP and Web Aggregators are automatically Cat-2 regardless of revenue. 5. Major V2.0 changes: new IT Steering Committee, mandatory Independent External Expert on RMC, CISO independence from IT, quarterly ISRMC, formal exception hierarchy, DPDP cross-compliance, sub-outsourcing restrictions. 6. Audit must be conducted by a CISA/DISA-certified specialised firm or a CERT-In empanelled auditor — your existing statutory auditor is unlikely to meet these criteria. |
Why this matters now
On 6 April 2026, the Insurance Regulatory and Development Authority of India issued circular IRDAI/GA&HR/CIR/MISC/51/4/2026, releasing Version 2.0 of its Information and Cyber Security Guidelines. The new framework replaces the 2023 guidelines (IRDAI/GA&HR/GDL/MISC/88/04/2023 dated 24 April 2023) and was issued in response to, in IRDAI’s own words, the evolving threat landscape, feedback received from industry, and recommendations of various IRDAI committees.
The single most important sentence in the cover circular is paragraph 5: “All Insurers including FRBs, Insurance Intermediaries… shall strictly adhere to the said guidelines and ensure compliance from the current financial year.” The circular does not define an explicit transition period. Insurers will need to file their first Annexure III audit report under the new framework within 90 days of the financial year-end, or within 30 days of audit completion, whichever is earlier. Intermediaries file separately with their insurers, within 30 days of audit completion. In practical terms, organisations are expected to align within the current financial year.
This article answers the question every CXO at a regulated insurance entity is now asking: what do I need to know, what do I need to decide, and what do I need to budget for in the next 90 days?
What changed in V2.0 vs the 2023 framework
The V2.0 amendments are documented formally in Annexure A of the IRDAI release package. The headline is governance: the new framework substantially strengthens Board accountability and creates new committee structures that did not exist in 2023.
Area | Specific item | Under 2023 | Under V2.0 (2026) | Why it matters to CXOs |
Governance cadence | ISRMC frequency | Twice yearly | Quarterly | More frequent risk visibility for the Board |
Board responsibilities | Cyber budget | Implicit | Explicit duty: proportional to threat landscape | Cyber spending now has explicit regulatory backing |
Board responsibilities | Gap closure tracking | Not specified | Mandatory closure within 12 months | Director-level accountability with hard deadline |
CISO independence | Reporting line | Not restricted | Cannot report to Head of IT; no business targets | CISO becomes an independent control function, not an IT role |
CISO role | Committee participation | Not specified | Permanent invitee to IT Steering Committee | Security has visibility into IT execution decisions |
IT Steering Committee | Existence | Not mandated | NEW: ITSC mandated, quarterly, CTO convenes | New senior committee separating IT execution from risk oversight |
Independent External Expert | On RMC | Not mandated | NEW: IEE with IT/cyber expertise mandatory on RMC | External scrutiny of management’s self-reporting |
CITSO designation | Status | Existed | Removed; functions absorbed into CISO/CTO | Simpler role hierarchy, less dilution |
Exception approvals | Hierarchy | Not formalised | NEW: tiered approval (CISO/RMC/Board) | Exceptions are no longer informal — they create paper trails |
DPDP cross-compliance | Reference | Not present | NEW: explicit obligation under Section 1.10 | CXOs accountable to two laws simultaneously |
Sub-outsourcing | Restrictions | Not addressed | NEW: prior written permission required (3.2(11)) | Vendor’s vendor is now your audit problem |
Intermediary filing | Annexure III | Not specified | NEW: filed with insurers within 30 days | Insurer compliance now depends on intermediary filings |
Read together, these changes signal a clear regulatory direction. The CISO is no longer a technologist reporting to the CTO; the CISO is an independent control function with direct visibility to the Board through the Risk Management Committee. The new IT Steering Committee creates a separate forum for IT execution, freeing the ISRMC to focus on risk and assurance. And the new Independent External Expert requirement on the RMC means at least one independent voice with cybersecurity expertise must scrutinise the entire programme from outside the management chain.
The framework effectively shifts cybersecurity from an IT-managed function to a Board-governed risk function.
Who is in scope: the applicability matrix
The cover circular addresses the guidelines to a specific list of entities: all Insurers including Foreign Reinsurance Branches (FRBs), all Insurance Intermediaries — covering Brokers, Corporate Agents, Web Aggregators, TPAs, IMFs, Insurance Repositories, ISNP, Corporate Surveyors, MISPs, and CSCs — and the Insurance Information Bureau of India (IIB). Section 1.4 of the guidelines confirms the same scope and clarifies that insurance agents, micro-insurance agents, POS persons, and individual surveyors are excluded from direct compliance, although insurers remain responsible for ensuring those entities follow a minimum security baseline under a Board-approved policy.
New in V2.0 is a formal three-tier classification of intermediaries based on gross insurance revenue, set out in Annexure II. The tier determines the intensity of controls and the approval level required for exceptions.
Category | Gross Insurance Revenue | Exception approval | Notes |
Cat-1 | ≥ ₹50 Crores | Board Approved | Highest control intensity |
Cat-2 | ≥ ₹5 Crore and < ₹50 Crore | MD Approval | All ISNP and Web Aggregators are automatically Cat-2 regardless of revenue |
Cat-3 | < ₹5 Crores | MD Approval | Lighter control intensity |
The Cat-2 special rule deserves attention. Every entity operating an Insurance Self-Network Platform (ISNP) and every Web Aggregator is automatically Cat-2 regardless of gross insurance revenue. A small insurtech with ₹2 Crore in revenue running a customer-facing portal does not get Cat-3 treatment — it is pulled into Cat-2 because it operates a digital channel. The practical effect is that digital-first entities face higher control intensity than their revenue alone would suggest.
Section 2.14 then extends scope further by requiring all third-party service providers handling insurer data to provide security at a level at least as secure as the regulated entity would provide internally. The new sub-outsourcing clause (3.2(11)) requires prior written permission from the regulated entity before any further outsourcing. In simple terms, compliance no longer stops at your organisation. It extends to your vendors — and even to their vendors.
Inside the 175 pages: the 24 security domain policies
Section 2.0 of the guidelines contains 24 security domain policies. Each is a self-contained policy with its own purpose, scope, controls, and roles. The table below maps all 24 domains, with the V2.0 emphasis called out for the domains where the largest changes have occurred. Note in particular Sections 2.11, 2.14, 2.16, and 2.20 — these are where the most significant V2.0 amendments and the heaviest audit weight sit.
Ref | Domain (verbatim from source) | What it covers (and key V2.0 emphasis) |
2.1 | Data Classification | Foundation control: classification scheme, handling rules, ownership |
2.2 | Asset Management | Inventory of all IT assets; ownership and lifecycle |
2.3 | Access control | RBAC, segregation of duties, 2FA for non-org devices, session controls, audit logging with source IP |
2.4 | Human Resource Security | Background checks, joiner/mover/leaver, awareness training, disciplinary process |
2.5 | Information Systems acquisition and development | Formal secure SDLC, design pattern library, input/output validation, security requirement analysis pre-production |
2.6 | Information systems maintenance | Patching, EOL/EOS management, secure configuration baselines |
2.7 | Mobile security policy | Device management, encryption, remote wipe |
2.8 | Bring your own device (BYOD) policy | Personal device controls, data segregation, acceptable use |
2.9 | Change Control | Formal change management; pre-production testing for all changes to internet-facing assets |
2.10 | Incident and problem management | 6-hour CERT-In incident reporting; root cause analysis; CSIRT-Fin notification |
2.11 | Network Security | Perimeter firewall + IDS, network segmentation, and the WAF mandate (clause 3.4(7)) |
2.12 | Cryptographic Controls | TLS standards, key management, FIPS-aligned encryption |
2.14 | Third party service providers | NEW sub-outsourcing rule (3.2(11)); right-to-audit clauses; vendor security parity with insurer baseline |
2.15 | Physical and environmental security | Data centre access, environmental monitoring, visitor management |
2.16 | Monitoring, Logging and Assessment | 6-month VA & PT cycles by CERT-In auditors; 30/60-day remediation; 24×7 SOC; SIEM; 180-day log retention in India |
2.17 | Legal and Regulatory Compliance | Cross-regulation alignment including DPDP, IT Act, CERT-In directives |
2.18 | Situational Awareness | Threat intelligence consumption, contextual awareness of evolving threats |
2.19 | Cloud Security Policy | FIPS 140-2/3 encryption, KMIP support, data residency, exit clauses |
2.20 | Cyber Resilience | NIST-pillar structure: Identify, Protect, Detect, Respond, Recover; cyber crisis management plan |
2.21 | Email Security | DMARC, SPF, DKIM mandatory; sandboxing for inbound attachments |
2.22 | Work from Remote Location | Dedicated framework; 74 audit controls in Annexure III for remote work security and investment |
2.23 | Dealing room operations | Sector-specific controls for trading and dealing room environments |
2.24 | IT (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021 | IGDM cross-regulation; 13 dedicated audit controls in Annexure III |
A note on structure: the WAF mandate sits inside Section 2.11 (Network Security), specifically clause 3.4(7). Application-layer protection controls are distributed across Sections 2.5 (secure SDLC), 2.11 (Network Security including WAF), and 2.16 (Monitoring, Logging and Assessment), and the audit checks them as a single integrated set across the NIST function codes. The WAF mandate is covered in detail in the companion article in this series on Section 2.11.
The audit framework: how the 347 controls actually work
If you remember only one thing from this article, make it the next paragraph. Internal compliance teams often organise their evidence libraries around the IRDAI section numbers they have been reading (Section 2.1, Section 2.2, Section 2.11, etc.). The auditor will not. The Annexure III auditor’s report — the document the CERT-In empanelled audit firm uses to score your compliance — is structured around the NIST Cybersecurity Framework function codes: Identify, Protect, Detect, Respond, Recover. If your internal control inventory does not have a NIST mapping, your auditor will spend the engagement asking you to remap your evidence on the fly.
The single most important fact in this article The IRDAI cyber security audit is structured around the NIST Cybersecurity Framework, not around the IRDAI section numbers in the 175-page document. If your internal compliance organisation is mapped to Section 2.x headings, you risk significant friction and re-work during the audit — even if your underlying controls are sound. Re-map to NIST function codes (ID, PR, DE, RS, RC) before your audit firm arrives. |
Here is what the audit actually looks like in practice. Annexure III evaluates 347 distinct audit controls structured primarily around the NIST Cybersecurity Framework, with two additional IRDAI-specific categories for Work From Remote Location and the IGDM Rules 2021. The breakdown below is verified directly from the Annexure III control table.
Category | Code prefix | Controls | Sub-areas |
Detect | DE.* | 104 | Anomalies & Events, Continuous Monitoring, Detection Processes |
Identify | ID.* | 47 | Asset Mgmt, Business Environment, Governance, Risk Assessment, Risk Mgmt, Supply Chain |
Protect | PR.* | 72 | Access Control, Awareness & Training, Data Security, Information Protection, Maintenance, Protective Tech |
Respond | RS.* | 33 | Analysis, Communications, Improvements, Mitigation, Response Planning |
Recover | RC.* | 4 | Communications, Improvements, Recovery Planning |
Work From Remote Location | WFRL / WFRL.IN | 74 | Remote work security and investment controls |
IGDM Rules 2021 | IGDM | 13 | Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021 |
Total |
| 347 | All audit controls in Annexure III |
Note: The full Annexure III control list is publicly available as part of the IRDAI release package on the IRDAI website. Internal compliance teams should download it directly and begin the NIST mapping exercise as part of their first 90 days under the new framework.
The audit report is structured in three parts — and each one matters
Annexure III is structured in three parts.
Part A (Background Information) captures the auditor’s identity, the activities performed by the regulated entity, and the applicable sections of the framework.
Part B (Overall Status of Findings) is the scoring table — the auditor records, for each of the 347 controls, whether it is Not Applicable (NA), Applicable (AC), and if applicable, whether the rating is High (H), Medium (M), Low (L), or Complied (C).
Part C (Details of Non-Compliances) documents each non-compliance individually with the control number, the audit questionnaire, the auditor’s observation, and the assigned risk rating.
The risk scoring is not subjective — it is formula-driven
Every audit produces a numeric risk score, calculated by an explicit formula in Annexure III: Risk Mark = (H × 3) + (M × 2) + (L × 1) + (C × 0). This means the audit does not produce a pass/fail verdict; it produces a number that the Board, the ISRMC, and IRDAI can track over time. A regulated entity with a Risk Mark of 50 is in a measurably worse position than one with a Risk Mark of 20. Year-on-year improvement in the Risk Mark becomes a Board-level KPI.
The risk rating logic itself depends on two dimensions: whether the control is designed adequately and whether it is operating effectively. A control that is neither designed nor operating earns a High rating (must be designed and implemented). A control designed but not operating effectively earns High or Medium depending on the auditor’s judgement. A control operating but not designed adequately earns Low or Medium. A control both designed and operating earns Complied.
Auditor eligibility is narrowly defined
Annexure IV defines who can perform the audit. The eligible firms are narrow. A Chartered Accountant firm must be a Partnership or LLP, with at least five years of continuous practice and a minimum of four partners. At least one partner must hold the CISA or DISA certification, at least one must be a Fellow Member of ICAI, and at least one must have three or more years of experience in cybersecurity audit specifically in Insurance Companies, Banks, or Mutual Funds. The alternative path is a CERT-In empanelled external systems auditing organisation also holding CISA or DISA certifications.
There are two practical consequences for CXOs. First, your existing statutory auditor almost certainly cannot perform this audit — these are specialised firms, and the eligible pool is small. Engagement letters need to be in place well before the audit window. Second, the audit cannot rely on management representations or on the work of other auditors. Annexure IV explicitly states that the auditor must perform interviews, document verification, compliance checks, and substantive testing personally. There are no shortcuts.
Filing timelines matter more than most teams realise
Insurers must submit the Annexure III audit report — duly signed by the auditor and accompanied by Board comments — to IRDAI within 90 days of the end of the financial year, or within 30 days of audit completion, whichever is earlier. Intermediaries must file Annexure III with their insurers within 30 days of audit completion. The compounding effect is that an insurer’s audit posture now depends not only on its own filing but on receiving filings from every intermediary in its distribution network.
Governance and Board obligations
The 2026 framework treats cyber security governance as a Board-owned function. The Board approves the Information and Cyber Security Policy, allocates budget proportionate to the threat landscape (a new explicit obligation in V2.0), and reviews the status of non-conformities from the annual cyber security assurance audit. Audit gaps must be closed within 12 months of reporting, and the Board owns that timeline.
The CISO role has been substantially strengthened. The CISO must report directly to the top executive overseeing the risk management function, or in their absence to the CEO directly. The CISO shall not have a direct reporting relationship with the Head of IT Function and shall not be given any business targets. This is a control independence requirement, equivalent in spirit to the independence required of internal audit. The CISO is also a permanent invitee to the IT Steering Committee, ensuring that IT execution decisions are visible to the security function.
The Information Security Risk Management Committee (ISRMC) now meets at least quarterly (up from twice yearly under 2023), with a quorum of the CISO and at least two members. The newly mandated IT Steering Committee operates at senior management level, is convened by the CTO, also meets at least quarterly, and provides updates to the RMC and CEO. And the Risk Management Committee itself must now include at least one Independent External Expert with substantial IT or cybersecurity expertise — a structural check on management’s self-reporting.
Exceptions follow a new approval hierarchy: exceptions not exceeding three months are approved by the CISO, exceptions exceeding three months are approved by the RMC, and exceptions exceeding one year require Board approval. Any exception request exceeding twelve months must undergo a reassessment and re-approval process. All exceptions must formally document the associated risk.
Cross-regulation interactions
The 2026 framework does not exist in isolation. It explicitly cross-references and layers on top of several other regulatory regimes that CXOs must satisfy simultaneously.
Digital Personal Data Protection Act (DPDP): Section 1.10 of the guidelines makes DPDP compliance an explicit obligation for regulated entities. This is new in V2.0. The interaction matters because DPDP creates obligations around consent, data principal rights, breach notification, and data fiduciary responsibilities that overlap with the IRDAI incident reporting and data protection clauses. CXOs are now accountable to two laws simultaneously through these guidelines.
CERT-In directives: The 6-hour incident reporting requirement, the 180-day log retention obligation within Indian jurisdiction, the Responsible Disclosure Framework, and CERT-In’s role as a CVE Numbering Authority are all incorporated by reference. CERT-In directives can change independently of the IRDAI framework, and the guidelines require continuous adherence.
NIST Cybersecurity Framework: Annexure I of the guidelines confirms the applicability of the NIST framework to all regulated entities, and the audit structure in Annexure III is built directly on NIST function codes. NIST is not optional context — it is the framework the auditor will use.
IT Act and IGDM Rules 2021: The Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021 are inside the audit scope as a dedicated 13-control category in Annexure III. CXOs at intermediaries with digital touchpoints must satisfy IGDM compliance as part of the IRDAI audit, even though IGDM is a separate regulation.
Compliance with IRDAI 2026 is no longer an isolated obligation — it is the intersection of four overlapping regulatory regimes.
Consequences of non-compliance
The guidelines and the cover circular together establish a clear compliance enforcement chain, even without invoking IRDAI’s broader powers under the Insurance Act. The chain works as follows.
Audit results are filed with IRDAI within 90 days of FY-end, signed by both the auditor and accompanied by Board comments. Non-conformities observed in the annual cyber security assurance audit are tracked at director level — the Board receives the status of non-conformities and is responsible for approving timelines for gap closure. Gaps must be closed within 12 months of reporting. The ISRMC reports the status of non-conformities to the RMC, which in turn escalates serious non-conformities to the Board.
Two consequences follow directly from the framework itself, before any IRDAI enforcement action is required. First, the Risk Mark calculated under Annexure III becomes a year-on-year tracked metric visible to the Board and to IRDAI. A worsening Risk Mark is not a private problem. Second, intermediaries file their Annexure III with insurers as well as with IRDAI, which means an insurer with weak intermediaries inherits their gaps in its own compliance posture. The downstream cascade is structural.
The cover circular language is explicit: “shall strictly adhere to the said guidelines and ensure compliance from the current financial year.” This is the regulator’s standard formulation for a binding obligation, and it leaves no room for interpretation about whether compliance is optional in year one.
The first 90 days: a CXO action plan
For CXOs at insurers, intermediaries, and IIB-related entities, the next 90 days are the window in which the foundation for the first audit cycle gets laid. The action plan below is organised by phase, with each phase building on the previous one.
Days 1–15: Establish the baseline
Confirm your category. For insurers and FRBs, this is straightforward. For intermediaries, identify which of Cat-1, Cat-2, or Cat-3 you fall into based on gross insurance revenue and the ISNP/Web Aggregator special rule. The category determines your control intensity and your exception approval hierarchy.
Identify your CISO and verify the reporting line. The CISO must report directly to the top executive overseeing risk management (or to the CEO in their absence), must not report to the Head of IT, and must not carry business targets. If these conditions are not currently met, this is the first structural gap to close — and it requires Board action, not IT action.
Convene the ISRMC under the new quarterly cadence and document its membership. Identify a candidate Independent External Expert with IT or cybersecurity expertise to add to the RMC. Formally constitute the new IT Steering Committee with the CTO as convener and the CISO as a permanent invitee. Request the latest version of the 175-page guidelines and Annexure III from your compliance team or download the official package directly from the IRDAI website.
Days 16–45: Map the gap
Map your current control inventory to the 347 NIST-coded audit controls in Annexure III. This is the single most important technical activity in the entire 90-day plan. Your existing control inventory is almost certainly organised by IRDAI section number or by ISO 27001 control. Re-map it to the NIST function codes in Annexure III. Identify the controls where you have evidence and the controls where you do not.
Pay particular attention to the Detect (DE) and Protect (PR) categories. These are the largest control sets in Annexure III — 104 Detect controls and 72 Protect controls between them — and they cover monitoring, detection processes, access control, data security, and protective technology. If you have gaps here, the Risk Mark will be heavily affected.
Review your data classification baseline (Section 2.1). A formal data classification scheme is the foundation that every downstream control depends on — without it, evidence for access control, encryption, retention, and monitoring becomes harder to demonstrate against Annexure III. Inventory your vendor and sub-vendor contracts and identify which need updating to satisfy the new sub-outsourcing clause (3.2(11)) and right-to-audit requirements. Identify candidate audit firms that meet the Annexure IV eligibility criteria — this pool is small and engagement letters need to be in place early.
Days 46–90: Prioritise, budget, and begin remediation
Present the gap analysis to the Board with a proportional budget request. The Board’s new explicit duty under V2.0 is to allocate budget proportional to the threat landscape, which means the Board now has a regulatory basis to approve security spending that was previously discretionary.
Identify which gaps can be addressed with existing tools, which need new tools, and which need consulting support. Engage an Annexure IV-eligible audit firm for a pre-audit gap assessment. Begin remediation on the largest infrastructure decisions: the WAF requirement under Section 2.11, the 24×7 SOC and SIEM requirement under Section 2.16, the 180-day log retention requirement (also Section 2.16), and the secure SDLC framework under Section 2.5.
Document an exception register and set up the new approval hierarchy. Establish the DPDP cross-mapping with your privacy and legal teams. Schedule a tabletop exercise for the cyber crisis management plan under Section 2.20. By day 90, you should have a Board-approved gap closure plan, an engaged audit firm, and remediation underway on the top three or four highest-risk areas.
Compliance used to be checklist-driven. IRDAI 2026 has made it runtime-driven.
Reality check: what most organisations will get wrong in Year 1
The four navigation failures below follow logically from the structure of the 2026 framework. None is a consequence of the regulation being unclear — they are consequences of implementation teams working from the IRDAI section structure rather than from Annexure III. Here is the shortlist, and what to do about each one.
Mistake 1: Mapping controls to IRDAI section numbers instead of NIST function codes
This is the mistake with the largest audit-day cost. If your internal compliance team has built its evidence library around the IRDAI section structure in the guidelines document, the auditor will arrive with Annexure III, which is structured around NIST function codes, and the result is audit time spent re-mapping evidence under pressure. Fix this before your audit firm engagement begins, not during it.
Mistake 2: Underestimating application-layer risk
Teams that organise security around perimeter and network controls will discover the application-layer gap during the PR.PT and DE.CM portions of the audit. Application-layer protection is not a perimeter firewall configuration item, and the weight it carries in Annexure III means underinvestment here is visible in the Risk Mark.
Mistake 3: Ignoring intermediary and sub-vendor dependencies
Section 2.14 and the new sub-outsourcing clause (3.2(11)) make the insurer responsible for compliance across the entire vendor and sub-vendor chain. If your organisation focuses on its own internal controls and treats vendor controls as out of scope, the gap will surface during the audit. Visibility into your TPAs’ web application security posture — let alone their sub-contractors’ — is a prerequisite to Year 1 compliance, not a nice-to-have.
Mistake 4: Delaying audit firm engagement until the end of the financial year
The eligible auditor pool under Annexure IV is small — a CISA/DISA-certified specialised CA firm or a CERT-In empanelled external systems audit organisation. Engagement letters need to be in place months before the audit window opens. CXOs who wait until Q4 of the financial year to start procurement will find themselves competing for limited auditor capacity and potentially missing the 90-day filing window.
None of these four mistakes is technical. All four are organisational and procedural. All four can be addressed in the first 90 days of the framework being in force.
The bottom line
The IRDAI Information and Cyber Security Guidelines 2026 represent the most substantial cybersecurity regulatory change for the Indian insurance industry since the original 2017 framework. Version 2.0 strengthens governance, formalises the audit framework around NIST CSF, introduces 347 specific audit controls, narrows the eligible auditor pool, layers DPDP compliance into the same instrument, and creates Board-level accountability for closure of non-conformities within 12 months.
The organisations that will navigate this well are the ones that treat the regulation not as a compliance exercise but as an architecture decision. They will re-map their internal control inventories to NIST function codes. They will engage a specialised audit firm early. They will rebuild their CISO reporting line if it is not already independent of IT. They will make security a Board-level conversation, not an IT-budget conversation. And they will use the new explicit Board duty to allocate proportional cyber budget as the basis for the investment decisions they have been deferring.
The organisations that will struggle are not the ones with the weakest controls — they are the ones that delay structural decisions. By the time the first audit finding appears, the Risk Mark is already visible, the gap closure clock is already running, and the next reporting cycle is already in motion.
IRDAI 2026 is not just a cybersecurity upgrade — it is a structural reset of how risk is governed in the Indian insurance industry.
For a deep-dive on the WAF mandate
This briefing covers the IRDAI 2026 framework as a whole. For a focused analysis of the web application security mandate specifically — Section 2.11 clause 3.4(7), the WAF requirement, and how to evaluate WAF solutions for IRDAI compliance — see the companion article in this series: “IRDAI Cybersecurity Guidelines 2026: Why WAF Is No Longer Optional for Indian Insurers.”
Sources and references
- IRDAI Information and Cyber Security Guidelines, Version 2.0, April 2026 (175 pages)
- Cover circular IRDAI/GA&HR/CIR/MISC/51/4/2026 dated 6 April 2026, signed by A. R. Nithiyanantham, Executive Director (GA & HR), IRDAI
- Annexure A — Summary of Amendments to the 2023 framework
- Annexure I — Applicability of NIST Framework to All Regulated Entities
- Annexure II — Classification of Insurance Intermediaries
- Annexure III — Auditors Report (90 pages, 347 controls)
- Annexure IV — Eligibility Criteria for the Audit Firm
Disclaimer: This article is for informational purposes and does not constitute legal or regulatory advice. Organisations should consult qualified legal counsel and CERT-In empanelled or Annexure IV-eligible audit firms for specific compliance requirements. All clause references and quotations are taken directly from the official IRDAI release package dated 6 April 2026.
How PageNTRA can help
PageNTRA Infosec is the maker of SiteWALL, a cloud-delivered Web Application Firewall built for the IRDAI 2026 framework. SiteWALL deploys inline in blocking mode from day one, inspects all traffic including encrypted HTTPS, includes 180-day log retention within Indian jurisdiction in the base license, and can support audit evidence preparation aligned to the NIST-structured Annexure III review. For the application-layer protection required by Section 2.11 clause 3.4(7), the monitoring and logging obligations under Section 2.16, and the 30-day high-risk remediation window, SiteWALL is built to satisfy the audit on day one — not on day ninety.
Request a SiteWALL demo | Download the datasheet | Read the WAF deep-dive Article 2
|