Much has already been said about the global counterparts to UN Regulation No 155. With AIS 189, India is introducing mandatory cybersecurity requirements for connected vehicles, positioned as a local adaptation of UN R155. Anyone who thinks this is a niche topic underestimates both the dynamic market and the regulatory logic behind it. Below is an introduction covering the most important information about AIS 189.
Gnanagiri Balasubramanian
Let’s start with an honest observation: anyone working in vehicle cybersecurity has accumulated plenty of regulatory experience over the past few years. Starting with UN R155/156, through GB 44495, to the Korean vehicle security regulation – vehicle cybersecurity regulation is on the move globally. And then India comes around the corner with AIS 189. “Here we go again. Is this basically R155 in Hindi?”
Short answer: No.
Longer answer: It’s more complicated. And that’s precisely what makes it worth understanding.
Today, India is the third-largest automotive market in the world.
Anyone looking to register vehicles there – whether as an OEM, importer, or Tier-1 supplier with system responsibility – will not be able to bypass AIS 189 going forward. Even though the regulation is still officially in draft status, it was already published in 2024, and mandatory enforcement is drawing closer.
And the experience at OEMs and suppliers alike shows: those who enter these kinds of processes at the last minute are buying themselves expensive headaches.
So let’s dive straight into understanding AIS 189.
AIS 189 – Approval of Vehicles with Regards to Cyber Security and Cyber Security Management System: What Is It?
AIS stands for Automotive Industry Standard – a framework under the Central Motor Vehicle Rules (CMVR), coordinated and developed by the Automotive Industry Standards Committee (AISC), with support from the Automotive Research Association of India (ARAI).
AIS standards form the technical backbone of vehicle type approval in India, comparable to UNECE regulations in the European context, or within UNECE member markets.
So don’t be misled: despite having “Industry Standard” in its name, AIS 189 should be viewed as legally binding regulation – not merely as a “state-of-the-art recommendation” in the way an industry standard might be.
At the same time, AIS 189 should not be viewed in isolation.
Parallel to UN R156, it is AIS 190 in India that governs Software Update Management (SUMS).
Anyone who tries to think about both topics together from the outset has the right mindset.
What Is the Current Timeline for AIS 189?
On the question of timeline: AIS 189 already exists as a standard. The mandatory enforcement notification by the Ministry of Road Transport and Highways (MoRTH) follows in a separate notification process.
That may sound like a buffer – but it isn’t.
Because experience from other markets shows: between the announcement of binding deadlines and the first compliance proof, there is significantly less time than you’d expect if you only start thinking about CSMS governance at that point.
Concretely on the timeline, AIS 189 is being introduced in phases:
- From 2024: Manufacturers are preparing governance structures.
- From 2025: OEMs are integrating CSMS processes into development and supplier management.
- 2026–2027: Cybersecurity compliance is expected to become part of vehicle type approval – and thus a de facto market access requirement for connected vehicles.
Am I Actually Affected by AIS 189? (Spoiler: Probably Yes.)
Given that you’re reading one of the most widely read expert blogs on applied cybersecurity in vehicle development and the automotive industry, the likelihood that you will, sooner or later, have to deal with AIS 189 is actually quite high.
But to be more specific:
AIS 189 applies primarily to vehicles in categories M and N – meaning passenger cars (M1) as well as light and heavy commercial vehicles (categories M2, M3, and N).
Beyond that, the standard applies to category T vehicles, provided at least one ECU is installed, and to L7 vehicles with automated driving functions at SAE Level 3 or above.
In practical terms, the focus is on four-wheeled passenger and commercial vehicles; however, two-wheelers and three-wheelers are not explicitly excluded – the extent to which connected technologies are deployed will be decisive for cybersecurity obligations. One conclusion holds: the more connected a vehicle, the more relevant the cybersecurity requirements become.
For the typical OEM or Tier-1 supplier developing connected platforms for the Indian market, or supplying into it, the answer is clear: Yes, you are within scope. And sooner than many expect.
With AIS 189, Cybersecurity Becomes Part of Vehicle Type Approval in India.
What many underestimate: AIS 189 is not directed solely at vehicle manufacturers.
Anyone operating as an importer in India and relying on a foreign OEM’s CSMS still needs a documented model covering accredited representatives, verifiable access rights to the CSMS dossier, and in-country capacities for post-production monitoring and recall management.
This is not a theoretical requirement – it is the practical consequence of India’s market structure.
Implementing AIS 189 Requirements: What Do I Need to Build – and What Can I Reuse?
The most common question from teams already working in compliance with R155: Can we simply “transfer” our existing CSMS to India?
The honest answer: To a large extent, yes – but not entirely.
And that gap is exactly where the effort lies.
AIS 189 is conceptually closely aligned with UN R155. The fundamental architecture of a Cybersecurity Management System (CSMS) – risk assessment, treatment, verification, monitoring, response – is identical. Anyone who has implemented ISO/SAE 21434 will already be familiar with the topics. The TARA methodology from Annex D of AIS 189 will read as familiar territory.
A Closer Look at the Details of AIS 189
Where AIS 189 takes its own distinct path is in the institutional mechanics of conformity assessment.
In Europe, and in UNECE member markets, a technical service – typically engaged independently – conducts the assessment on behalf of an approval authority.
In India, designated testing agencies – most notably ARAI and ICAT – handle both CSMS certification and type approval.
That may sound like a technical detail, but it has practical consequences: the testing agency becomes the direct point of contact for both, and the format of the evidence packages should be aligned with them early on.
This holds true under AIS 189 as well: a CSMS is not a documentation exercise. It is organizational infrastructure that must function when it is audited.
What Section 7.2.2.2 of AIS 189 specifically requires is a defined set of processes:
- Internal CSMS governance
- Risk identification (including the threat baseline from Annex D, Part A)
- Risk assessment and treatment
- Verification processes
- Vehicle-type-specific testing
- Updates to the risk assessment
- Monitoring and response processes
- Forensic data support
Anyone who has implemented ISO/SAE 21434 will find their bearings here. The difference, however, lies in the evidence: AIS 189 expects these processes to be documented in an audit-ready manner – and in a way that an Indian testing agency can evaluate, not just a European one. (On the topic of increased evidence obligations, it is recommended to take a look at the Korean regulation)
Worth highlighting in particular: post-approval monitoring under AIS 189 is not a best practice – it is an explicit compliance requirement.
This means concretely that vehicles must remain subject to monitoring processes after approval – including log- and data-based detection capabilities.
And here cybersecurity meets data privacy: AIS 189 explicitly requires that privacy rights and consent mechanisms be considered in the context of vehicle data usage. (A direct parallel to what UN R155 and the GDPR require regarding personal data.) Anyone who omits this from their CSMS evidence package will notice that gap when engaging with the testing agency.
AIS 189: What Does the Testing Agency Expect?
AIS 189 creates two interlinked certification objects that must be clearly distinguished:
- The CSMS conformity certificate at the manufacturer level: This confirms that the OEM has the organizational processes in place to manage cybersecurity across the entire vehicle lifecycle. Valid for a maximum of three years, after which renewal is required. The testing agency may review conformity at any time – and may revoke the certificate if requirements are no longer met.
- The cybersecurity type approval at the vehicle type level. This is directly tied to the CSMS certificate: no valid CSMS certificate means no type approval. Revocation of the CSMS certificate can therefore immediately jeopardize vehicle registration. This is not a theoretical escalation scenario – it is the reality described in the standard.
The formal submission package should include:
- Cybersecurity-relevant vehicle systems and interfaces
- Schematic architecture representation
- CSMS certificate number
- Risk assessment results
- Implemented risk mitigation measures and their effectiveness
- Protection of dedicated environments for aftermarket software
- Testing methods used and results
- A description of supply chain considerations
Retention requirements: The testing agency retains the formal package for at least 10 years after the end of production. The manufacturer retains “additional material” for the same period. This should not be treated as an administrative detail – it is a long-term evidence management requirement.
The question of what the testing agency specifically evaluates during document review can also be clearly inferred from the rejection grounds in Clause 5.1.3:
- Incomplete risk assessment
- Insufficient risk mitigation measures
- Inadequate protection of dedicated environments
- Insufficient pre-approval testing
A practical tip accordingly: anyone who uses these four points as a guide for their own gap analysis is well positioned.
In addition, there is an annual reporting obligation: at least once per year, the manufacturer must report to the testing agency on monitoring results – including new cyberattacks and confirmation that countermeasures remain effective. Anyone who submits superficial reports risks revocation of the CSMS certificate. This too should not be viewed as a purely bureaucratic exercise, but as operational compliance enforcement.
A Note on the Transitional Period Issue
AIS 189 contains specific provisions for vehicle types that could not have been developed in full compliance with the CSMS prior to the so-called “all-model implementation date.”
For such legacy or carry-over models, alternative paths for demonstrating compliance are provided – however, manufacturers must submit a feasibility assessment (“cybersecurity was adequately considered”).
Anyone with multiple platforms in their India portfolio should structure this argumentation early.
Vehicle Families vs. Individual Vehicles: How Does AIS 189 Define Vehicle Type in the Context of Vehicle Cybersecurity?
The term “vehicle type” in the draft of India’s AIS 189 regulation is defined identically to UN R155: a vehicle type comprises vehicles that do not differ with respect to the manufacturer’s designation and the essential aspects of the electrical/electronic architecture and external interfaces relevant to cybersecurity.
Under AIS 189, type approval is granted at the vehicle type level – not at the level of the individual vehicle. AIS 189 therefore follows the R155 approach of architecture-based family grouping: cybersecurity evidence established once is transferable to all variants sharing the same safety-relevant system architecture. For OEMs, this means the potential for significant resource savings in the homologation process.
That things can work differently is illustrated by the Chinese regulatory approach, which requires each vehicle to be assessed individually as a matter of principle. This difference has considerable practical implications: the ability to reuse evidence across model lines is eliminated. As a result, the China business involves noticeably higher workloads – both in documentation and in conducting conformity assessments.
India’s decision to align AIS 189 with the UN R155 model will therefore likely represent a welcome degree of regulatory continuity for internationally operating OEMs.
What Does AIS 189 Mean for Supplier Relationships?
As experience with UN R155 has shown in practice, this is – in our view – one of the most underestimated topics surrounding AIS 189.
Anyone who reads AIS 189 as a “technical requirement for the vehicle” overlooks the fact that Clause 7.2.2.5 explicitly mandates dependency management with suppliers, service providers, and sub-organizations.
The AIS 189 interpretation manual makes this very concrete: it expects bilateral agreements – so-called CIA contracts (Cybersecurity Interface Agreements) – that clarify the allocation of responsibilities for CSMS requirements. (A work product already familiar from ISO/SAE 21434.)
Supplier contracts thereby become audit-ready artifacts from a cybersecurity perspective – not optional governance measures.
What this means in practice: requests for proposals to Tier-1 suppliers must going forward include evidence aligned with the requirements of Annex A. Cyber risk registers for supplier components, evidence of risk mitigation, test evidence – all of this must be incorporated into supplier evaluations. Anyone who only realizes this at the point of filing a type approval application has a problem.
It can therefore be stated plainly: supplier contracts that do not clearly allocate cybersecurity responsibilities are not contracts under AIS 189 either – they are gaps in the evidence package.
Particularly relevant: the interpretation manual explicitly names, as in UN R155, cloud providers, telecommunications service providers, and internet backend providers as examples of dependencies to be covered.
Annex D contains risk mitigation measures that relate to backends – meaning that external IT services located well outside the vehicle should also be contractually integrated into the CSMS framework.
The fact that cascading requirements down through Tier 2 and Tier 3 and beyond is difficult in practice is well known. The pragmatic approach therefore: a two-tier model in which Tier-1 contracts define binding requirements and evidence formats, combined with a structured mechanism for aggregating Tier-2/3 data that enables auditability without requiring direct contractual relationships with every downstream level.
Non-Compliance with AIS 189 in India – What Happens Then?
The immediate consequences of non-compliance are actually straightforward.
On one hand, denial of type approval – which makes selling in the market impossible. On the other hand, potential revocation of the CSMS certificate, with the resulting risk to existing vehicle registrations.
That already sounds unpleasant enough.
But it can get more complex:
India’s recall framework – anchored in the Central Motor Vehicle Rules, specifically Rule 127C – explicitly recognizes that a defect in a vehicle can also encompass software.
This is not theoretical language.
In plain terms, it means: a discovered cybersecurity vulnerability that poses a safety risk and meets the defined thresholds can travel the path from a type approval issue to a formal recall process.
Manufacturers, importers, and aftermarket modifiers are equally subject to this.
AIS 189 Also Requires Forensics for Cyberattack Analysis
Since AIS 189 explicitly requires forensic logging, detection capabilities, and annual reporting on cyberattacks, a documentation chain is effectively created that can become highly relevant in the event of a recall: who knew what, when – and what was done about it?
Those who have built these processes properly are protected.
Those who failed to document are in a weak position when it matters most.
AIS 189 and Beyond: Harmonizing CSMS Efforts as the Key for Vehicle Manufacturers and Suppliers
For globally operating companies, one further perspective is worth taking: AIS 189 is neither the first nor the last market to introduce its own cybersecurity requirements for vehicles.
UN R155 in Europe and UNECE member markets, GB 44495 in China, AIS 189 in India – the regulatory landscape is becoming denser.
Those who have built a modular CSMS framework that can be adapted to different markets have a structural advantage.
Those who start from scratch for every market will permanently have too much on their plate.
Anyone who has been working effectively with UN R155 and ISO/SAE 21434 brings solid foundations. What AIS 189 requires beyond that is most noticeably felt in three areas:
- Testing-agency-centric governance with its own documentation formats
- The explicit contractual anchoring of supply chain responsibilities
- The operational post-approval monitoring regime
The most important practical advice: Begin preparation as a type approval program – not as an internal compliance project.
This means engaging with ARAI or ICAT early, aligning on documentation formats, and building the evidence base in a structure that a testing agency can actually evaluate.
Because the alternative – waiting for clarity on enforcement deadlines and then scrambling to catch up at the last minute – is, in the area of vehicle cybersecurity, not a plan based on experience.
It is a risk.
