Month: July 2026

Zero Trust for Insurance: A 4-Level IRDAI Compliance Framework (2026)

On April 6, 2026, IRDAI notified revised information and cybersecurity guidelines that apply to every insurer, reinsurer, intermediary, and TPA operating in India. The guidelines mandate board-level oversight, an independent CISO reporting line, 6-hour breach notification to IRDAI and CERT-In, 180-day log retention, and comprehensive vendor risk management. Penalties for failure to implement reasonable security safeguards reach ₹250 crore under the DPDP Act.

For a life insurer with 8 million policyholders and 14 regional offices, this is not a checkbox exercise. It is a rearchitecting problem.

What Changed in April 2026

IRDAI’s April 2026 guidelines replace the 2023 circular and introduce three structural requirements that most insurers cannot satisfy with their current architecture.

The 6-hour breach notification requirement is the most operationally demanding. To notify CERT-In within 6 hours, you must detect the breach within roughly 4 hours, which means your SIEM must have ingested and correlated the relevant logs before the incident was confirmed. Most insurers in India run SIEM with 24 to 48-hour log ingestion delays from branch systems. That architecture cannot meet a 6-hour clock.

The independent CISO requirement specifying that the CISO shall not report to the Head of IT forces an organizational change that triggers an architecture review. CISOs who previously lived inside the IT cost center now have board visibility and procurement authority. The security controls they could not justify previously are now their mandate.

The vendor risk management requirement extends security obligations upstream. Before engaging any vendor with access to policyholder data, insurers must conduct cybersecurity due diligence and confirm compliance with IRDAI guidelines. This covers cloud providers, TPAs, broking platforms, and health data aggregators.

Why Zero Trust Is the Right Response

Traditional perimeter security cannot satisfy these requirements. Perimeter security assumes that traffic inside the network is trusted. Modern insurance environments have no meaningful perimeter: branch offices connect over public internet, TPAs access policy systems from their own networks, and cloud-hosted customer portals interact with on-premise policy administration systems.

Zero trust security assumes that no traffic, user, or device is trusted by default, regardless of network location. Every access request is authenticated, authorized against policy, and logged. This architecture produces the continuous monitoring and log completeness that IRDAI’s 6-hour notification requirement demands.

IRDAI’s 6-hour breach notification requirement is not a reporting problem it is a detection architecture problem. Zero trust solves the detection problem.

The Insurance Zero Trust Implementation Ladder (IZTIL)

IZTIL is a four-level maturity model for Indian insurers implementing zero trust against the April 2026 guidelines. Each level is a stable operating state, not a transition phase. An insurer can operate at Level 2 and meet most of the mandatory controls. Level 4 is the target for insurers with more than 5 million policyholders or significant digital distribution channels.

Level 1: Data Classification and Identity Foundation

No zero trust implementation can start without knowing where personal data lives. An insurer that cannot identify which systems hold personal data cannot implement zero trust. The data classification comes before the network segmentation.

At Level 1: classify all data stores by sensitivity (policyholder PII, health data, financial data, claims records); deploy identity provider with MFA enforced on all privileged accounts; disable shared service accounts and replace with machine identities; complete an asset inventory covering on-premise systems, cloud workloads, and third-party integrations.

Completion criterion: every system with personal data is tagged, owned, and accessible only via individual authenticated identities.

Level 2: Microsegmentation and SIEM Baseline

At Level 2: implement network microsegmentation between personal-data systems and general administrative networks; deploy SIEM with log ingestion from all systems hosting personal data at under 2-hour latency; establish 180-day log retention with immutable storage; and configure alerting thresholds for anomalous access patterns (off-hours access to claims systems, bulk record downloads, and new device access to underwriting systems).

This is the minimum level at which an insurer can credibly meet the 6-hour notification requirement. It is achievable in 4 to 6 months for a mid-sized insurer with a dedicated security engineering team.

Level 3: Continuous Verification and Vendor Governance

At Level 3: implement device posture checks on all endpoint access to policyholder systems; deploy privileged access management (PAM) with session recording for all administrative access; implement vendor risk assessment workflow covering IRDAI compliance confirmation, security questionnaire, and annual audit rights; extend SIEM ingestion to vendor-operated systems accessing insurer data.

The vendor governance component is frequently underestimated. Most mid-tier Indian insurers work with 40 to 80 vendors with some form of data access. Conducting due diligence across that vendor population takes 3 to 5 months even with automation.

Level 4: Adaptive Access and Automated Response

At Level 4: implement risk-based adaptive access policies that adjust authentication requirements in real time based on user behavior, device posture, and data sensitivity; deploy automated incident response playbooks for common breach scenarios (ransomware containment, credential compromise, and unauthorized data export); and integrate security telemetry with the board-level Cybersecurity Committee reporting dashboard.

Level 4 is where zero trust becomes a genuine business capability rather than a compliance posture.

The Legacy Policy Administration System Problem

Most insurers treat their legacy policy administration system as untouchable. Zero trust architecture disagrees.

The policy administration system (PAS) in most Indian life insurers is an on-premise Oracle or custom-built system running on hardware that is 8 to 15 years old. It holds the most sensitive data in the enterprise every policyholder record, every claim, every beneficiary designation. It also has the weakest security controls: broad shared database credentials, no MFA, minimal audit logging.

IZTIL Level 2 does not require replacing the PAS. It requires wrapping it. Deploy an API gateway between the PAS and all consuming systems. Enforce authentication at the gateway layer. Log all PAS access through the SIEM via the gateway. Implement network segmentation that blocks direct database access from outside the PAS VLAN.

This is less elegant than a modern microservices architecture, but it is achievable in 8 to 12 weeks without touching the PAS codebase. Attempting a full PAS modernization as part of a zero trust project doubles the risk and adds 18 to 24 months to the timeline. Separate the concerns.

DPDP Act Interaction: What Changes in May 2027

The DPDP Rules notified in November 2025 bring substantive compliance requirements into effect in May 2027. For insurers, the relevant obligations compound the IRDAI guidelines: consent for processing health data, data localization requirements for personal data stored in cloud, right-to-erasure workflows for lapsed policyholders.

The zero trust data classification work done under IZTIL Level 1 directly accelerates DPDP compliance. An insurer that has tagged every personal data store, assigned ownership, and inventoried all data flows is 60 to 70 percent of the way to DPDP readiness. Run both programs under the same data governance team.

What This Means for Insurance Leaders

The April 2026 guidelines give the CISO organizational authority that was previously unavailable. Use it now. The three decisions with the highest compliance leverage in the next 90 days are: deploy MFA on all privileged accounts (days 1 to 14, no architecture change required), standing up SIEM with 2-hour log ingestion from PAS and customer data systems (weeks 4 to 8), and completing vendor data access inventory (weeks 6 to 12).

These three steps get you to IZTIL Level 2 and put you in a defensible position for IRDAI examination. Everything else, like microsegmentation, PAM, and adaptive access, can follow in priority sequence. Do not attempt all four levels simultaneously. The implementation risk of a big-bang security rearchitecture in a regulated insurer exceeds the compliance risk of a phased approach.

More Blog: AIS 189 Compliance: What Automotive Engineers Must Do Now

Automotive CI/CD Is a Different Engineering Discipline. Build It That Way.

The engineering teams building this software need an Automotive CI/CD platform that does not exist in a standard DevOps toolkit. A software-defined vehicle runs on 100 to 150 million lines of code. It must satisfy functional safety standards (ISO 26262), cybersecurity requirements (ISO 21434, AIS 189 in India), and regulatory type approval while shipping OTA updates to vehicles in the field every 6 to 8 weeks. The engineering teams building this software need a CI/CD platform that does not exist in a standard DevOps toolkit.

An automotive engineering services firm in Pune managing embedded software delivery for a German OEM’s body control and ADAS module programs learned this the hard way. Their initial approach adapting a Jenkins and GitHub Actions pipeline from a prior cloud software project collapsed at the hardware-in-the-loop testing stage. Build validation times ran 14 hours. Safety certification traceability was manual. OTA staging had no rollback automation.

The problem was not their engineers. The problem was a web DevOps mental model applied to an automotive software problem.

Why Standard DevOps Fails in SDV Programs

SDV development has three properties that break standard web DevOps toolchains.

Safety lifecycle integration. ISO 26262 requires traceable links from system requirements through software design, implementation, unit test, integration test, and verification for every safety-critical function. This traceability cannot be an after-the-fact audit activity it must be captured as part of the build pipeline. Standard CI tools have no native concept of functional safety classification or ASIL (Automotive Safety Integrity Level) tagging.

Compilation and build complexity. An ECU software stack built on Classic AUTOSAR or Adaptive AUTOSAR compiles against hardware-specific tool chains (usually from Vector, ETAS, or Green Hills Software). These tool chains are not containerized, are often Windows-only, require hardware dongles for licensing, and take 30 to 90 minutes per full rebuild. Treating them like a Node.js or Python build system produces pipelines with 8 to 14-hour cycle times.

Hardware-in-the-loop (HIL) testing. Software validation in automotive requires running code on physical hardware rigs or certified simulation environments. HIL rigs cannot be spun up on demand like cloud VMs. They are physical assets, expensive to procure, and shared across teams. Managing HIL rig scheduling, utilization, and queuing is a platform engineering problem as important as the CI pipeline itself.

Automotive CI/CD is not web CI/CD with ISO 26262 annotations added at the end. The safety lifecycle has to be embedded in the pipeline, not bolted onto it.

Automotive CI/CD Maturity Model (SDMS)

SDMS is a five-level maturity model for automotive software CI/CD programs. Each level adds a specific capability that the previous level’s infrastructure supports. Moving from Level 1 to Level 5 typically takes 18 to 30 months for a program with 30 to 100 embedded software engineers.

Level 1: Version Control and Build Reproducibility

Automotive CI/CD enables automated safety traceability, OTA package creation, and rollback validation. Every software component lives in a version control system (Git with large-file storage for binary artifacts). Every build is reproducible from a pinned toolchain version and dependency lockfile. AUTOSAR tool chain versions are managed as team assets, not as individual developer installations.

Many automotive programs in India are still at this level or below. Individual engineers maintain tool chain installations on local Windows machines. Build reproducibility depends on which machine the build ran on. This is not a DevOps problem it is a configuration management problem that blocks all subsequent automation.

Level 2: Automated Build and Static Analysis

At this stage, Automotive CI/CD automates builds, static analysis, and artifact management for safety-critical software. At Level 2: automated builds trigger on every commit; static analysis tools (MISRA C compliance, Polyspace, QAC) run in the build pipeline against every changed component; build artifacts are stored in a binary artifact repository (Artifactory or Nexus) with ASIL classification tags.

The safety classification tagging at Level 2 is the investment that pays dividends at Level 4 and 5. Teams that skip it discover at certification time that they cannot produce the required tool qualification evidence for their CI system. Add it now.

Level 3: HIL Scheduling and Software-in-the-Loop Integration

At Level 3: software-in-the-loop (SIL) testing runs automatically in the CI pipeline using simulation environments (dSPACE HIL simulators, MATLAB/Simulink test automation, or CARLA for ADAS); HIL rigs are inventory-managed with a rig scheduling system that queues test jobs and reports utilization; test results flow into a test management system (qTest, TestRail, or custom) with links to requirements.

The build time problem in automotive is not a Jenkins configuration problem. It is a hardware-in-the-loop test farm scaling problem. Level 3 forces the program to treat HIL rigs as shared infrastructure with SLA commitments, not as lab equipment that someone books via email.

Level 4: Safety Traceability Automation and OTA Pipeline

At Level 4: requirements traceability is automated CI pipeline links every build artifact to the requirements it covers, the tests that verified it, and the ASIL level it satisfies; OTA update packages are generated, signed, and staged automatically from successful CI builds; rollback capability is tested as part of every OTA pipeline execution.

An OEM that cannot do OTA rollback in under 15 minutes does not have a software-defined vehicle program it has a very expensive field-service liability. Level 4 makes rollback a tested, documented capability, not an emergency procedure.

Level 5: Continuous Deployment to Vehicles and Telemetry Loop

At Level 5: validated updates flow automatically to a shadow fleet of instrumented test vehicles; vehicle telemetry feeds back into the CI system, triggering regression builds when anomalous behavior patterns are detected in the field; deployment ring management (alpha vehicles, beta fleet, general release) is automated with automatic hold triggers based on error rate thresholds.

Level 5 is the operational definition of software-defined. Most programs reach it at month 24 to 30 of a sustained SDMS improvement program.

The Adaptive AUTOSAR Transition Makes This Urgent

Classic AUTOSAR the dominant ECU software architecture for the past 15 years runs on microcontrollers with fixed scheduling and no operating system abstraction. Adaptive AUTOSAR, introduced for high-compute ADAS and infotainment domains, runs on Linux/QNX with a service-oriented architecture, dynamic service discovery, and containerized components.

The DevOps implications are significant. Adaptive AUTOSAR components can be containerized, which means they can be built and tested in standard CI infrastructure, not just on proprietary hardware-specific tool chains. This is the architectural change that makes automotive CI/CD tractable with modern DevOps tooling.

Programs still on Classic AUTOSAR should plan the SDMS progression as described above. Programs migrating to Adaptive AUTOSAR have an opportunity to build the CI infrastructure on a more modern foundation but they still need HIL rig management and safety traceability; the architecture change does not eliminate those requirements.

India’s SDV Engineering Opportunity

India has the strongest embedded software engineering pool for SDV outside of Germany. Tata Elxsi, Tata Technologies (with the recent WHIS partnership), and Tech Mahindra are building SDV engineering practices that compete with traditional Tier-1 suppliers. The constraint is not engineering talent it is DevOps tooling maturity.

Programs that build SDMS Level 3 and 4 capabilities now will win the SDV outsourcing contracts that are moving out of German and Japanese OEM in-house teams over the next 3 years. OEMs evaluating Indian engineering services partners will audit CI/CD maturity as a qualification criterion before awarding embedded software programs.

The SDV Summit in Bangalore this October will be the most important automotive engineering event in India in 2026. The firms presenting SDV DevOps capabilities at Level 4 or above will win the conversations that follow.

What This Means for Automotive Engineering Leaders

If you are running an embedded software program whether inside an OEM or as an Tier-1 or Tier-2 engineering services supplier assess your current SDMS level before committing to new program bids. The assessment takes one day and produces a concrete gap list.

Three decisions to make this month: identify your current tool chain installation management practice and determine whether it can support Level 1 reproducible builds; confirm whether your HIL rigs are scheduled via a management system or via ad hoc team coordination; and determine whether your OTA pipeline has automated rollback tested on a representative vehicle configuration.

If any of the three answers are “no” or “we don’t have that,” your program has SDMS Level 1 or 2 gaps. Closing them before the next OEM program review is worth more than any tooling investment you make elsewhere.

More Blog: Bima Sugam Phase 2 (2026): 7 Best Modernization Steps

Introduction

Bima Sugam Phase 2 is expected to go live in 2026, adding claims intimation, third-party integrations with hospitals and TPAs, health data APIs via ABDM, and policy portability workflows to the platform that IRDAI is positioning as India’s “UPI moment” for insurance. For a private life insurer, Tier-2 by premium volume, this is not a product decision. It is a systems architecture decision, because the question is not whether to integrate with Bima Sugam but whether your policy core can expose the APIs that Phase 2 requires. For more than 70% of Indian insurers still running legacy policy administration systems, the answer today is no, and the time to address that gap is now, not when Phase 2 audits begin.

What Bima Sugam Phase 2 Actually Requires from Your Backend

The first phase of Bima Sugam handled policy issuance and KYC through standardized APIs against India Stack. Phase 2 goes further and exposes the latency limitations of legacy batch architectures:

Claims intimation API: Accept a claim notification from a policyholder through the Bima Sugam interface, validate the policy, and return a claim acknowledgment with a reference number. The latency expectation is real-time, not batch.

TPA and hospital integration: For health insurance, route claim pre-authorization requests to TPAs via the platform’s standardized interface and receive approval or rejection within a defined SLA.

Portability workflows: Allow policyholders to initiate porting of a policy from one insurer to another through the platform, requiring your system to expose policy data in IRDAI-specified formats on request.

Health data APIs: Integrate incoming health records from ABDM-connected providers as supporting evidence for claims, requiring your system to receive structured health data and associate it with the correct policy record.

Each of these requires your policy core to respond to external API calls synchronously. If your core system runs on batch processing cycles, a claims intimation call at 11:47 AM may not be processed until the next batch window at 2:00 PM.

> Bima Sugam does not care about your batch claims processing cycle. It expects an API that returns in under two seconds.

This is the architectural mismatch that Phase 2 exposes. Legacy policy administration systems were designed around overnight batch cycles and internal screen-based access. Bima Sugam’s API model assumes real-time, event-driven policy data availability.

The Layered Modernization Trap

The standard advice for insurers who cannot afford a five-to-seven-year core replacement is layered modernization: build a digital experience platform on top of the legacy core and expose APIs from the DXP layer that translate between Bima Sugam’s expectations and the core’s batch processing reality.

This approach works for Phase 1. Phase 2 tests its limits directly.

A DXP sitting above a legacy core can make the core’s data available through an API. It cannot change the underlying processing model. If the legacy core writes a claims record to the database at the end of a batch job, the DXP can surface that record via API, but it cannot surface it before the batch job completes.

For claims intimation under Phase 2, this creates a visible SLA gap. Insurers who respond slowly will face customer complaints that aggregate on the Bima Sugam platform, visible to IRDAI. The platform’s design, like UPI, is intended to create transparent competitive pressure through published performance data across all participants.

> Layered modernization is not a strategy. It is a temporary architectural position with a deadline.

The deadline, in this case, is the first Bima Sugam compliance audit cycle after Phase 2 launch. Phase 1 compliance will not exempt you from Phase 2 performance requirements.

What Event Sourcing Changes

The modernization path that extends the useful lifetime of a layered approach is event sourcing at the core. Instead of a legacy system that writes final state to a policy record, an event-sourced system records every state transition as an immutable event. The current policy state is derived by replaying the event log.

This matters for Bima Sugam integration because: claims intimation triggers a state transition event that is written synchronously, so the claim acknowledgment can be returned immediately before downstream processing completes. Portability requests become a stream of events that can be replayed on the receiving insurer’s system to reconstruct policy history without a direct database export. IRDAI audit requirements for data lineage are satisfied by the event log itself, rather than requiring separate audit trail tables or retrofitted logging.

We worked with a private life insurer, Tier-2 by premium volume, preparing for Bima Sugam Phase 2 with approximately 3.4 million active policies on a legacy policy administration system from 2009. A full core replacement was budgeted for 2028. The Phase 2 requirement exposed a gap they could not bridge with layered modernization alone, specifically the claims processing latency SLA.

The approach: introduce an event streaming layer (Apache Kafka) between the legacy core and the DXP, instrument the legacy core to emit events on every write operation through a change data capture connector, and build the Bima Sugam integration against the event stream rather than directly against the legacy database. Claims intimation calls write to Kafka synchronously. The legacy core consumes events and updates its records in the background. The DXP reads from the event stream.

Claims acknowledgment latency dropped from batch-cycle hours to under 800 milliseconds. The legacy core continued to operate unchanged. The core replacement project continued in parallel on its original timeline.

This is not a permanent solution. It is a structural bridge that achieves Phase 2 compliance while the replacement program runs in parallel.

The Insurance Core Modernization Sequence (ICMS)

This is the four-phase sequence we use with insurance clients facing simultaneous Bima Sugam compliance pressure and longer-term core replacement plans:

Phase 1: API Façade (2 to 4 months): Build a managed API gateway above the legacy core. Expose policy inquiry, claim status, and KYC verification endpoints that Bima Sugam Phase 1 requires. No changes to the core system. This phase delivers Phase 1 compliance and provides the integration surface that Phase 2 will extend.

Phase 2: Event Bridge (3 to 6 months): Introduce an event streaming layer. Instrument the legacy core to emit events on write operations, using change data capture where direct instrumentation is not feasible. Build the Bima Sugam Phase 2 integration against the event stream for low-latency claims intimation and portability flows. This phase achieves Phase 2 API latency compliance without core replacement.

Phase 3: Strangler Fig Migration (12 to 36 months): Migrate core policy administration capabilities to a modern system, one product line or functional domain at a time. Route traffic to the new system as each domain is validated. The event stream becomes the integration backbone between old and new systems during migration.

Phase 4: Legacy Decommission

Retire the legacy core when all traffic has migrated. The event log becomes the long-term archive for historical policy data, satisfying IRDAI record retention requirements.

> A core replacement takes five to seven years. A Bima Sugam integration built on a legacy core can be rendered obsolete in the first Phase 2 audit.

The ICMS delivers immediate Bima Sugam compliance through Phases 1 and 2 while building toward decommission through Phases 3 and 4, rather than treating them as programs that compete for budget and attention.

IRDAI Data Governance Requirements Add Compliance Pressure

Beyond Bima Sugam, IRDAI’s data governance mandates are tightening in parallel. The “Insurance for All by 2047” vision requires standardized data across rate regulation, claims governance, and coverage design. IRDAI mandates around data storage, consent, and auditability require insurers to adopt compliant digital architectures with unified data foundations.

For legacy system insurers, this translates to a concrete requirement: every policy operation must be auditable, with a record of who made what change, when, and why. Legacy systems built for internal screen-based access do not always produce the audit trail granularity that IRDAI digital compliance requires. Retrofitting audit logging to a legacy core is expensive and often incomplete.

The event sourcing layer in the ICMS serves double duty: it enables real-time Bima Sugam integration and produces the immutable audit trail that IRDAI compliance requires, as a structural property of the architecture rather than a separate logging system bolted on.

Reading the Bima Sugam Phase 2 Rollout for Engineering Signals

Bima Sugam Phase 2 is adding third-party integrations with hospitals and TPAs, health data API connections through ABDM, and policy portability workflows. Each of these integration categories has specific technical implications:

Hospital and TPA integration requires your claims routing logic to map procedure codes to the correct TPA based on policy type and network agreements. If this logic lives in a legacy system with no API surface, it cannot be called in real time from the Bima Sugam platform.

ABDM health data integration requires your system to accept structured health records in the FHIR format that ABDM-connected providers generate. Legacy systems that store claims supporting documents as scanned PDFs have no mechanism to ingest structured health data without a purpose-built integration layer.

Policy portability requires your system to export a complete, structured policy history in IRDAI-specified formats within a defined response time. This is not a report that runs overnight. It is an API call that must complete in seconds.

What this means for Insurance and InsurTech leaders

Bima Sugam Phase 2 is not the last API surface IRDAI will require. It is the first one with a hard latency test that legacy batch architectures fail by design.

The step you can take this week: ask your policy administration team how long it takes your system to acknowledge a claims intimation request, from the moment a policyholder submits to the moment your system returns a reference number. If the answer is measured in minutes or hours, or if no one knows the precise answer, that gap is the ICMS Phase 2 problem stated in concrete terms.

More Blogs: DIKSHA 2.0 Added Offline Downloads Last Week. Building What Comes Next Takes More