Über die weltweiten Pendants zur UN Regulierung Nr 155 ist schon viel gesprochen worden. Mit der AIS 189 führt Indien verbindliche Cybersicherheitsanforderungen für vernetzte Fahrzeuge ein, die als lokale Adaption der UN R155 gelten. Wer glaubt, das sei ein Nischenthema, unterschätzt sowohl den dynamischen Markt als auch die regulatorische Logik dahinter. Nachfolgend ein Einstieg mit den wichtigsten Informationen zur AIS 189.
Gnanagiri Balasubramanian
Lassen Sie uns mit einer ehrlichen Beobachtung beginnen: Wer in der Fahrzeug-Cybersecurity arbeitet, hat in den letzten Jahren reichlich regulatorische Erfahrungen gesammelt. Begonnen mit UNR155/156 über die GB 44495 bis zur Korea-Regulierung – weltweit ist die Fahrzeug-Cybersicherheitsregulierung in Bewegung. Und dann kommt Indien mit AIS 189 um die Ecke. „Schon wieder was Neues. Ist das etwa die R155 auf Hindi?”
Kurze Antwort: Nein.
Längere Antwort: Es ist komplizierter. Und genau das ist es wert, verstanden zu werden.
Heute ist Indien der drittgrößte Automobilmarkt der Welt.
Wer dort Fahrzeuge zulassen will – egal ob als OEM, Importeur oder Tier-1-Lieferant mit Systemverantwortung – wird künftig an der AIS 189 nicht vorbeikommen. Auch wenn sich die Regularie offiziell noch im Draft-Status befindet, sie ist bereits in 2024 veröffentlicht worden und die verbindliche Durchsetzung rückt näher.
Und die Erfahrung bei OEMs und Zulieferern gleichermaßen zeigt: Wer bei solchen Prozessen auf den letzten Drücker einsteigt, erkauft sich teuren Stress.
Daher direkt tiefer rein in das Verständnis zur AIS 189.
AIS 189 Approval of vehicles with regards to Cyber Security and Cyber Security Management System – Was ist das?
AIS steht für Automotive Industry Standard – ein Rahmenwerk unter den Central Motor Vehicle Rules (CMVR), koordiniert und entwickelt vom Automotive Industry Standards Committee (AISC) mit Unterstützung durch die Automotive Research Association of India (ARAI).
AIS-Standards bilden das technische Rückgrat der Fahrzeugzulassung in Indien, vergleichbar mit den UNECE-Regulierungen im europäischen Kontext, bzw. im UNECE-Absatzmarkt.
Also nicht verwirren lassen: Auch mit Industry Standard im Namen ist die AIS 189 als rechtsverbindliche Regulatorik und nicht nur als „State-of-the-Art-Empfehlung“ wie ein Industriestandard anzusehen.
Gleichzeitig ist die AIS 189 ist nicht isoliert zu betrachten.
Parallel zur UN R156 ist es in Indien die AIS 190, die das Software Update Management (SUMS) regelt.
Wer von Anfang versucht, beide Themen zusammen zu denken, hat das richtige Mindset.
Wie ist der aktuelle Zeitplan der AIS 189?
Zur Frage des Zeitplans: Die AIS 189 existiert bereits als Standard.
Die verbindliche Durchsetzungsmitteilung durch das Ministerium für Straßenverkehr und Autobahnen (MoRTH) folgt in einem separaten Notifizierungsprozess.
Das klingt nach Puffer, ist aber keiner.
Denn die Erfahrung aus anderen Märkten zeigt: Zwischen Bekanntgabe der verbindlichen Fristen und erstem Compliance-Nachweis bleibt deutlich weniger Zeit als man glaubt, wenn man erst dann anfängt, über CSMS-Governance nachzudenken.
Konkret zur Zeitachse lässt sich sagen, die AIS 189 wird schrittweise eingeführt:
- Ab 2024 bereiten Hersteller Governance-Strukturen vor,
- ab 2025 integrieren OEMs CSMS-Prozesse in Entwicklung und Lieferantenmanagement.
- Für 2026–2027 wird erwartet, dass Cybersicherheits-Compliance Teil der Fahrzeugzulassung wird – und damit zur faktischen Marktzugangsvoraussetzung für vernetzte Fahrzeuge.
Bin ich eigentlich von der AIS 189 betroffen? (Spoiler: Wahrscheinlich ja.)
Da Sie sich auf einem der meistgelesenen Fachblogs zu Fragen der angewandten Cybersicherheit in der Fahrzeugentwicklungs- und Automobilindustrie befinden, ist die Wahrscheinlichkeit, dass Sie früher oder später mit der AIS 189 zu tun haben werden, gar nicht so niedrig.
Aber etwas genauer:
Die AIS 189 gilt primär für Fahrzeuge der Klassen M und N – also Personenkraftwagen (M1) sowie leichte und schwere Nutzfahrzeuge (Klassen M2,M3 und N).
Darüber hinaus greift der Standard für die Klasse T, sofern mindestens eine ECU verbaut ist, und für L7-Fahrzeuge mit automatisierten Fahrfunktionen ab SAE-Level 3.
Praktisch liegt der Schwerpunkt somit auf vierrädrigen Personen- und Nutzfahrzeugen; Zweiräder und Dreiräder sind jedoch nicht ausdrücklich ausgeschlossen, inwieweit vernetzte Technologien zum Einsatz kommen, wird für die Cybersicherheitsverpflichtungen entscheidend. Es lässt sich festhalten: Je vernetzter ein Fahrzeug ist, desto relevanter werden die Cybersicherheitsvorschriften.
Für den typischen OEM oder Tier-1-Lieferanten, der vernetzte Plattformen für den indischen Markt entwickelt oder dorthin liefert, ist die Antwort damit klar: Ja, der Scope trifft Sie. Und das früher als viele denken.
Cybersicherheit wird mit der AIS 189 nun Teil der Fahrzeugzulassung in Indien.
Was viele unterschätzen: AIS 189 richtet sich nicht nur an Fahrzeughersteller.
Wer als Importeur in Indien agiert und sich auf das CSMS des ausländischen OEM verlässt, braucht dennoch ein dokumentiertes Modell für akkreditierte Vertreter, nachweisbare Zugriffsrechte auf das CSMS-Dossier sowie in Indien einsetzbare Kapazitäten für Post-Production-Monitoring und Rückrufabwicklung.
Das ist keine theoretische Anforderung – das ist die praktische Konsequenz der indischen Marktstruktur.
Umsetzung der AIS 189-Anforderungen: Was muss ich aufbauen – und was kann ich wiederverwenden?
Die häufigste Frage aus Teams, die bereits R155-konform arbeiten: Können wir unser bestehendes CSMS einfach „nach Indien übertragen”?
Die ehrliche Antwort: Zu einem guten Teil ja – aber eben nicht vollständig.
Und genau in diesem Delta steckt der Aufwand.
AIS 189 orientiert sich konzeptionell ziemlich stark an der UN R155.
Die Grundarchitektur eines Cybersicherheits-Managementsystems (CSMS) – Risikobewertung, Behandlung, Verifikation, Monitoring, Reaktion – ist identisch.
Wer hier die ISO/SAE 21434 implementiert hat, kennt die Themen bereits. Die TARA-Methodik aus Anhang D von AIS 189 liest sich vertraut.
Der Blick auf die Details der AIS 189
Wo AIS 189 jedoch einen eigenständigen Weg geht, ist die institutionelle Mechanik der Konformitätsbewertung.
In Europa, bzw. in UNECE-Absatzmärkten, prüft ein in der Regel unabhängig beauftragter technischer Dienst im Auftrag einer Genehmigungsbehörde.
In Indien übernehmen ebenfalls sogenannte Prüfstellen – allen voran ARAI und ICAT – sowohl die CSMS-Zertifizierung als auch die Typgenehmigung.
Das klingt nach einem technischen Detail, hat aber praktische Konsequenzen: So wird die Prüfstelle direkter Ansprechpartner für beides, und das Format der Nachweispakete sollte frühzeitig mit ihr abgestimmt sein.
Gilt auch mit der AIS 189: CSMS ist keine Dokumentationsübung. Es ist organisatorische Infrastruktur, die funktionieren muss wenn geprüft wird.
Was Abschnitt 7.2.2.2 von AIS 189 konkret verlangt, ist ein definierter Prozesssatz:
- interne CSMS-Governance,
- Risikoidentifikation (inklusive der Bedrohungsbaseline aus Anhang D, Teil A),
- Risikobewertung und -behandlung,
- Verifizierungsprozesse,
- fahrzeugtypspezifisches Testen,
- Aktualisierung der Risikobeurteilung,
- Monitoring- und Reaktionsprozesse
- sowie forensische Datenunterstützung.
Wer die ISO/SAE 21434 implementiert hat, findet sich hier zurecht.
Der Unterschied liegt aber im Nachweis: Die AIS 189 erwartet, dass diese Prozesse auditierfähig dokumentiert sind – und das auf eine Art, die eine indische Prüfstelle bewerten kann, nicht nur eine europäische. (zu gestiegenen Evidenz-Pflichten sei auch empfohlen, der Blick auf die Korea-Regulierung.)
Besonders hervorzuheben: Die Überwachung nach der Erstzulassung ist bei AIS 189 keine Best Practice, sondern eine explizite Compliance-Anforderung.
Das bedeutet konkret, dass Fahrzeuge nach der Zulassung weiterhin in Monitoring-Prozesse einbezogen sein müssen – inklusive log- und datenbasierter Erkennungsfähigkeiten.
Und hier trifft Cybersicherheit auf Datenschutz: Die AIS 189 verlangt ausdrücklich, dass Datenschutzrechte und Einwilligungsmechanismen bei der Fahrzeugdatennutzung berücksichtigt werden. (Ein direkte Ähnlichkeit zu dem, was UN R155 und GDPR in Bezug auf personenbezogene Daten fordern.) Wer das im CSMS-Nachweis auslässt, wird das bei der Prüfstelle merken.
AIS 189: Was erwartet die Prüfstelle?
Die AIS 189 schafft zwei miteinander verknüpfte Zertifizierungsobjekte, die man sauber auseinanderhalten muss:
- Das CSMS-Konformitätszertifikatauf Herstellerebene: Dieses bestätigt, dass der OEM über die organisatorischen Prozesse verfügt, um Cybersicherheit über den gesamten Fahrzeuglebenszyklus zu managen. Gültig für maximal drei Jahre, dann Verlängerung erforderlich. Die Prüfstelle kann die Konformität jederzeit überprüfen – und das Zertifikat entziehen, wenn die Anforderungen nicht mehr erfüllt sind.
- Die Typgenehmigung für Cybersicherheitauf Fahrzeugtypebene. Sie ist direkt an das CSMS-Zertifikat gekoppelt: Kein gültiges CSMS-Zertifikat, keine Typgenehmigung. Ein Entzug des CSMS-Zertifikats kann damit unmittelbar die Fahrzeugzulassung gefährden. Das ist keine theoretische Eskalationskette – das ist die im Standard beschriebene Realität.
Das formelle Einreichungspaket sollte enthalten:
- cybersicherheitsrelevante Fahrzeugsysteme und Schnittstellen,
- schematische Architekturdarstellung,
- CSMS-Zertifikatsnummer,
- Ergebnisse der Risikobewertung,
- implementierte Risikominderungsmaßnahmen und deren Wirksamkeit,
- Schutz dedizierter Umgebungen für Aftermarket-Software,
- verwendete Testmethoden und Ergebnisse
- sowie eine Beschreibung der Lieferkettenbetrachtungen.
Die Aufbewahrungspflicht: Die Prüfstelle hält das formelle Paket für mindestens 10 Jahre nach Produktionsende.
Der Hersteller bewahrt „zusätzliches Material” für denselben Zeitraum auf.
Das ist hier nicht als Verwaltungsdetail zu betrachten – vielmehr als eine langfristige Evidence-Management-Anforderung.
Auch die Frage, was die Prüfstelle bei der Dokumentenprüfung konkret bewertet, lässt sich aus den Ablehnungsgründen in Klausel 5.1.3 sehr gut ableiten:
- fehlende Vollständigkeit der Risikobewertung,
- unzureichende Risikominderungsmaßnahmen,
- mangelhafter Schutz dedizierter Umgebungen,
- unzureichende Vorabprüfungen.
Entsprechend der Tipp für die Praxis: Wer diese vier Punkte als Leitfaden für die eigene Gap-Analyse nimmt, ist gut aufgestellt.
Hinzu kommt die jährliche Berichtspflicht: Mindestens einmal pro Jahr muss der Hersteller der Prüfstelle über Monitoring-Ergebnisse berichten – inklusive neuer Cyberangriffe und Bestätigung der weiterhin wirksamen Gegenmaßnahmen. Wer hier oberflächliche Reports einreicht, riskiert den Entzug des CSMS-Zertifikats. Auch das sollte nicht als rein bürokratische Übung betrachtet werden, sondern als operative Compliance-Durchsetzung.
Ein Wort zur Problematik der Übergangsfristen: Die AIS 189 enthält spezifische Regelungen für Fahrzeugtypen, die vor dem sogenannten „All-Model-Implementierungsdatum” nicht vollständig im Einklang mit dem CSMS entwickelt worden sein konnten.
Für solche Legacy- oder Carry-over-Modelle sind alternative Nachweispfade vorgesehen – allerdings müssen Hersteller eine Machbarkeitsbewertung vorlegen („cybersecurity was adequately considered“).
Wer mehrere Plattformen für Indien im Portfolio hat, sollte diese Argumentation frühzeitig strukturieren.
Fahrzeugfamilien vs. einzelnes Fahrzeug? Wie definiert die AIS 189 Fahrzeugtyp-Definition im Kontext der Fahrzeugsicherheit (AIS 189 / UN R155)
Der Begriff „Fahrzeugtyp” ist im Entwurf der indischen Regulierung AIS 189 identisch mit der Definition gemäß UN R155: Als Fahrzeugtyp gelten Fahrzeuge, die sich hinsichtlich der Herstellerbezeichnung sowie der wesentlichen Aspekte der elektrischen/elektronischen Architektur und der externen Schnittstellen in Bezug auf Cybersicherheit nicht unterscheiden.
Wo wird gemäß AIS189 die Typgenehmigung auf Ebene des Fahrzeugtyps – und nicht des Einzelfahrzeugs – erteilt. AIS 189 folgt damit dem R155-Ansatz der architekturbasierten Familienbildung: Ein einmal erbrachter Cybersecurity-Nachweis ist auf alle Varianten übertragbar, die dieselbe sicherheitsrelevante Systemarchitektur teilen. Für OEMs bedeutet das die Möglichkeit zu immensen Ressourceneinsparungen im Homologationsprozess.
Dass es auch anders geht, zeigt der chinesische Regulierungsansatz, bei dem grundsätzlich jedes Fahrzeug einzeln geprüft werden muss. Dieser Unterschied hat in der Praxis erhebliche Auswirkungen: Die Möglichkeit, Nachweise über Baureihen hinweg wiederzuverwenden entfällt. Dadurch entstehen im China-Geschäft spürbar höhere Aufwände – sowohl in der Dokumentation als auch in der Durchführung der Konformitätsbewertung.
Die Entscheidung Indiens, sich mit der AIS 189 am UN-R155-Modell zu orientieren, dürfte für international aufgestellte OEMs daher eine willkommene regulatorische Kontinuität darstellen.
Was bedeutet die AIS 189 für die Lieferantenbeziehungen?
Ähnlich wie die Praxis in der UN R155 gezeigt hat, liegt hier – aus unserer Sicht – eines der am meisten unterschätzten Themen rund um die AIS 189.
Wer die AIS 189 als „technische Anforderung an das Fahrzeug” liest, übersieht, dass Klausel 7.2.2.5 explizit ein Abhängigkeitsmanagement mit Lieferanten, Dienstleistern und Unterorganisationen fordert.
Das AIS 189-Interpretationshandbuch macht das sehr konkret: Es erwartet bilaterale Vereinbarungen – sogenannte CIA-Verträge (Cybersecurity Interface Agreements) – die die Aufteilung der Verantwortlichkeiten für die CSMS-Anforderungen klarstellen. (Ein Work Product, das man auch bereits aus der ISO/SAE 21434 kennt.)
Lieferantenverträge werden damit aus Perspektive der Cybersicherheit zu auditierfähigen Artefakten, nicht zu optionalen Governance-Maßnahmen.
Was das in der Praxis bedeutet: Angebotsanfragen an Tier-1-Lieferanten müssen künftig Nachweise enthalten, die auf die Anforderungen von Anhang A abgestimmt sind. Cyber-Risikoregister für Lieferantenkomponenten, Nachweise zur Risikominderung, Testevidenzen – all das muss in die Lieferantenbewertung eingearbeitet sein. Wer das erst beim Typgenehmigungsantrag merkt, hat ein Problem.
Es kann also festgehalten werden: Lieferantenverträge, die Cybersicherheitsverantwortlichkeiten nicht klar aufteilen, sind auch gemäß AIS-189 keine Verträge – sie sind Lücken im Nachweispaket.
Besonders relevant: Das Interpretationshandbuch nennt, wie in der UN R155, ausdrücklich auch Cloud-Anbieter, Telekommunikationsdienstleister und Internet-Backend-Provider als Beispiele für abzudeckende Abhängigkeiten.
Anhang D enthält Risikominderungsmaßnahmen, die sich auf Backends beziehen – das bedeutet, dass auch externe IT-Dienste, die weit außerhalb des Fahrzeugs sitzen, vertraglich in die CSMS-Logik eingebunden sein sollten.
Dass die Kaskadierung von Anforderungen über Tier 2 und 3 hinaus in der Praxis schwierig wird, ist bekannt. Der pragmatische Weg daher: Ein zweistufiges Modell, bei dem Tier-1-Verträge verbindliche Anforderungen und Nachweisformate definieren, und ein strukturierter Mechanismus zur Aggregation von Tier-2/3-Daten, der eine Prüfung ermöglicht, ohne dass direkte Vertragsbeziehungen zu allen nachgelagerten Ebenen erforderlich werden.
Nicht-Compliance mit der AIS 189 in Indien? Was passiert dann?
Die unmittelbaren Konsequenzen der Nichteinhaltung sind eigentlich simpel.
Zum einen die Verweigerung der Typgenehmigung (was den Verkauf im Absatzmarkt unmöglich macht), zum anderen der mögliche Entzug des CSMS-Zertifikats mit der daraus folgenden Gefährdung bestehender Fahrzeugzulassungen.
Das klingt schon unangenehm genug.
Aber es kann auch komplexer werden:
Indiens Rückrufrahmenwerk – verankert in den Central Motor Vehicle Rules, insbesondere Regel 127C – erkennt ausdrücklich an, dass ein Mangel in einem Fahrzeug auch Software umfassen kann.
Das ist keine theoretische Formulierung.
Das bedeutet im Klartext: Eine entdeckte Cybersicherheits-Schwachstelle, die ein Sicherheitsrisiko darstellt und die definierten Schwellenwerte erfüllt, kann den Weg von einem Typgenehmigungsproblem zu einem formellen Rückrufvorgang nehmen.
Zuständig sind dabei Hersteller, Importeure und Nachrüster gleichermaßen.
Auch die AIS 189 fordert Forensik zur Analyse von Cyberattacken
Da die AIS 189 explizit forensische Protokollierung, Erkennungsfähigkeiten und jährliche Berichterstattung über Cyberangriffe fordert, entsteht faktisch eine Dokumentationskette, die im Rückruffall sehr relevant werden kann: Wer wusste was, wann – und was wurde dagegen unternommen?
Wer diese Prozesse sauber aufgebaut hat, ist geschützt.
Wer nicht dokumentiert hat, steht im Ernstfall schlecht da.
AIS 189 und darüber hinaus: Harmonisierung der CSMS-Bemühungen als Schlüssel für Fahrzeughersteller und Lieferanten
Für global agierende Unternehmen lohnt noch ein weiterer Blick: Die AIS 189 ist nicht der erste und nicht der letzte Markt, der eigene Cybersicherheitsanforderungen für Fahrzeuge einführt.
UN R155 in Europa und den UNECE-Absatzmärkten, die GB 44495 in China, AIS 189 in Indien – die regulatorische Landschaft wird dichter.
Wer ein modulares CSMS-Framework aufgebaut hat, das sich auf verschiedene Märkte adaptieren lässt, hat hier einen strukturellen Vorteil.
Wer für jeden Markt von vorne anfängt, hat dauerhaft zu viel zu tun.
Wer bisher gut mit der UNR155 und der ISO/SAE 21434 gearbeitet hat, bringt solide Grundlagen mit. Was die AIS 189 darüber hinaus fordert, ist vor allem in drei Bereichen spürbar:
- die prüfstellenzentrierte Governance mit eigenen Dokumentationsformaten,
- die explizite vertragliche Verankerung von Supply-Chain-Verantwortlichkeiten
- und das operative Monitoring-Regime nach der Fahrzeugzulassung.
Der wichtigste praktische Rat: Beginnen Sie die Vorbereitung als Typgenehmigungsprogramm – nicht als internes Compliance-Projekt.
Das bedeutet, frühzeitig das Gespräch mit ARAI oder ICAT zu suchen, das Dokumentationsformat abzustimmen und die Evidenzbasis in einer Struktur aufzubauen, die eine Prüfstelle tatsächlich bewerten kann.
Denn die Alternative – auf Klarheit bei den Durchsetzungsfristen zu warten und dann kurzfristig nachzuziehen – ist im Bereich Fahrzeug-Cybersicherheit erfahrungsgemäß kein Plan.
Es ist ein Risiko.
