AIS-189 explained: India's automotive CSMS standard

What AIS-189 is

AIS-189 is India's automotive Cyber Security Management System standard. It sets out what an OEM must have in place to design, produce and maintain vehicles securely across their lifecycle, and it is aligned to UN Regulation No. 155 (Cyber Security). It was published by ARAI for the Automotive Industry Standards Committee (AISC), which sits under the CMVR Technical Standing Committee — the same machinery that produces the wider body of Automotive Industry Standards.

The word to hold onto is management system. AIS-189 does not ask for a report that says a vehicle is secure. It asks for evidence that the organisation runs a repeatable process — one that identifies cyber risks, treats them, verifies the treatment, and keeps watching after the vehicle is on the road. That distinction is what most first-time programmes underestimate.

Scope: the whole lifecycle, not the launch

A CSMS under AIS-189 spans three phases that the regulation treats as one continuum:

• Development — risk assessment (TARA), cybersecurity requirements, secure architecture, verification and validation.
• Production — controls at the plant and end-of-line, where firmware is flashed and keys are handled. This is frequently the least-watched surface and squarely in scope.
• Post-production — monitoring the fleet for new attacks and vulnerabilities, responding to incidents, and feeding fixes back through software updates.

Because AIS-189 mirrors R155, the substance an assessor expects is the same substance ISO/SAE 21434 describes: item definition, cybersecurity goals, a maintained threat analysis, risk treatment, and records that the process actually ran on a real programme. The standard is the what; ISO/SAE 21434 supplies most of the how.

How AIS-189 maps to UN R155

At the level that matters to an engineering team, the two are close. Both centre a CSMS that must be assessed, both expect the threat landscape of R155 Annex 5 to be addressed, and both tie the approval to a governed set of processes rather than a static artefact. The differences are institutional rather than technical.

Dimension	UN R155	AIS-189
Instrument	UNECE regulation under the 1958 Agreement	Indian national standard (AIS) under CMVR
Issued / maintained by	UNECE WP.29	ARAI for AISC under CMVR-TSC
Assessed by	Approval authority / technical service in a Contracting Party	Indian test agency named under the CMVR
Recognition	Travels among Contracting Parties	Confers Indian approval
Enforcement date	EU: new types Jul 2022, all vehicles Jul 2024	India: draft G.S.R. 503(E) — phased Oct 2026 → Oct 2029, not yet final

The practical reading: an Indian OEM that already holds an R155 CSMS certificate has done most of the engineering AIS-189 will look for, but still has to be assessed under the Indian regime. The reverse also holds. We go clause-by-clause on this in AIS-189 vs UN R155.

What an OEM actually has to build

Five things carry the weight of an AIS-189 CSMS.

1. Governance. A named owner, a policy, and a cybersecurity organisation with defined responsibilities. An assessor will ask who owns the CSMS and expect a person, not a committee.

2. Risk management. A TARA methodology applied to each vehicle type and kept current — asset identification, threat scenarios, attack feasibility, risk determination and treatment. A TARA that was done once and never revisited is a classic finding.

3. Supplier flow-down. Most of a vehicle's software comes from Tier-1s and Tier-2s. AIS-189 expects requirements and evidence to flow down the chain through interface agreements, because the OEM carries the approval but depends on supplier proof.

4. Verification and evidence. Process descriptions are necessary but not sufficient. The dossier has to show the process ran: risk-treatment records, test results, and traceability from goal to requirement to verification.

5. Post-production monitoring. A means to detect and respond to attacks after launch, feeding vulnerability management and software updates. This is where AIS-189 and India's software-update standard, AIS-190, meet.

The assessor question that catches teams out

Being named in the CMVR as a test agency is not the same as holding cybersecurity competence. AIS-189 clause 5.3.1 requires the assessing agency to hold automotive cybersecurity and risk-assessment competence of its own. In other words, the regulation itself separates who may test a prototype from who is competent to assess a CSMS. For an OEM this matters when choosing where and with whom to run the assessment — the agency in the room needs the domain depth, not only the listing. We cover how the Indian agencies fit together in CIRT, ARAI, ICAT: how an Indian type approval actually gets assessed.

On dates: what is honest to say

It is tempting to plan against a single fixed deadline. For AIS-189 there is now a draft one rather than a final one. MoRTH draft G.S.R. 503(E) (17 June 2026) inserts Rule 125-T and proposes a phased schedule — new Level-3+ automated models from 1 October 2026, existing ones from 1 April 2027, OTA-capable vehicles across 2028, reaching all software-update-capable vehicles by 1 October 2029 — but it is open for public comment and not yet finalised in the gazette, so the exact dates can still move. The sound planning position is unchanged: a real, evidenced CSMS takes months to build regardless of the final date, so the work should start on its own timeline rather than waiting for the notification. The full phase table is in India's automotive cybersecurity timeline.

The AutoSifu view

AutoSifu treats AIS-189 as one route, not three handoffs: compliance, secure solutioning, and CoC/VTA support, delivered together and with the approval body in the room. Working with CIRT as a strategic partner, we help an OEM take a CSMS from scoping to an assessable state — the process, the architecture, and the evidence an assessor actually opens. The aim is a programme that would pass whether the notification lands early or late.