GRCIDE
    Back to briefings
    Briefing

    ECE R155 vs ISO 21434: Five Common Misreads That Get Caught in Audit

    R155 mandates the framework; ISO 21434 describes how to build it. Treating them as interchangeable is where most first-time audits go sideways.

    Compliance10 Jul 20265 min read

    ISO/SAE 21434:2021UN Regulation No 155
    On this page

    R155 and ISO 21434 are deeply related — but they are not the same thing, and treating them interchangeably is a common reason a CSMS audit produces unexpected major findings.

    R155 is a UN regulation that most automotive markets have made law. It tells the OEM what must exist: a documented Cybersecurity Management System (CSMS), evidence the CSMS covers the vehicle's full lifecycle, and a process for risk treatment. ISO 21434 is a standard that explains how to actually build that. R155 enforces. ISO 21434 describes.

    That distinction matters because you can pass an ISO 21434 internal review and still flunk an R155-driven OEM audit. The OEM's auditor cares about R155 outcomes. ISO 21434 is the path you walked to get there — but the auditor judges you against the regulation, not the standard.

    Here are the misreads that most often surface when an audit window is two months away.

    1. Treating "scope" as the ECU portfolio

    Most teams scope their CSMS as "the ECUs in vehicle X." That's an ISO 21434 mindset. R155 cares about the vehicle type as the unit of homologation, including the OTA/SUMS interaction, supplier governance, and post-production monitoring. If your CSMS scope diagram is just a list of ECU part numbers, you've already lost.

    Fix: draw the scope around the vehicle type as defined for type approval. Then map ECUs and external interfaces (V2X, telematics, OTA, diagnostic) onto it. ECUs are inside the scope, not equal to it.

    2. Doing TARA once, in the design phase

    ISO 21434 §8, Continual cybersecurity activities, feeds ongoing risk assessment across the lifecycle. The TARA methods themselves sit in §15, Threat analysis and risk assessment methods 1. Most teams treat TARA as a one-time deliverable produced during concept phase — which is enough to satisfy a clause-by-clause ISO 21434 walk-through, but is fatal at R155 audit time.

    R155 expects evidence that risk is being re-evaluated whenever something material changes — a new CVE that affects an in-vehicle component, a new attacker capability published in research, a software update that adds attack surface. If your last TARA refresh is dated 14 months ago and the vehicle has shipped four OTA campaigns since, expect a finding.

    Fix: establish a TARA review trigger list (CVE feed updates, OTA campaign starts, supplier change notifications) and document the trigger evaluations even when they conclude "no change required."

    3. Confusing "evidence" with "documentation"

    Auditors do not want to read your 80-page CSMS handbook. They want to see, for one randomly selected ECU and one randomly selected vulnerability event, the actual artifacts your process produced: the TARA, the verification report, the response decision, the OTA package, the post-deployment monitoring evidence.

    If your CSMS is a Word document and your evidence is "we have meetings about it," you have documentation but no evidence trail. ISO 21434 won't catch this. R155 audits absolutely will.

    Fix: for each clause of your CSMS, identify the artifact that proves it ran (a Jira ticket with a specific status, a signed-off TARA spreadsheet, a deployment record). Link them. Auditors should be able to walk a single CVE from intake → TARA delta → fix → deployment → post-deployment monitoring in under 15 minutes of clicking.

    4. Letting suppliers self-attest

    R155 §7.2.2.5 holds the OEM responsible for cybersecurity across the supply chain. It requires the manufacturer to demonstrate how its CSMS manages dependencies with contracted suppliers, service providers and sub-organisations 2. The nearest equivalent in ISO/IEC 27001:2022 is the supplier-relationship set its Annex A references, ISO/IEC 27002:2022 §5.19–§5.22 3. Tier-1s often interpret "supplier governance" as "we sent them a questionnaire and they said yes." That works there. It does not work for R155.

    The expectation is that you have a CSMS-aligned cybersecurity interface agreement (CIA) with your suppliers, you know what their TARA covered, and you have a way to verify their CVE response timeline matches what your overall vehicle-level response timeline requires.

    Fix: any supplier inside your CSMS scope needs a CIA, not just an NDA + spec. The CIA references their CSMS, names their cybersecurity contact, and commits to specific notification timelines.

    5. Treating post-production monitoring as "we have a SOC"

    "We monitor for incidents" is not what R155 requires. R155 expects that you can detect and respond to cybersecurity events in the deployed vehicle fleet — which is a different problem than monitoring your IT environment.

    The auditor will ask: how do you know if a CAN bus replay attack is being attempted against a 2023 model-year vehicle in Spain right now? If your answer is "we'd see it when the customer brought the car to the dealer," you don't have post-production monitoring; you have a customer service workflow.

    Fix: identify at least one signal that flows from the field back to your security organization in something faster than days. Telematics anomaly events, OTA failure rates, diagnostic-trouble-code clusters — pick a signal that reaches you in hours, not weeks. Document the response process and run a tabletop on it before the audit.

    The pattern

    The thread running through all five: ISO 21434 lets you describe a system. R155 makes you operate one. Audit success comes from building the operating muscle, not from polishing the document. Two weeks before audit, the right question is not "is our CSMS document complete?" — it is "can we walk an auditor through one real, recent cybersecurity event from detection to closure, end to end, in the time it takes to have lunch?"

    If the answer to that is no, no amount of clause-by-clause documentation review will save the audit.

    If you're inside that two-week window right now, the things that move the needle most are: (1) pick one recent CVE and walk the full response trail end-to-end, fixing gaps in real time; (2) get one supplier CIA in place with a real cybersecurity contact named; (3) stand up a single field signal feed even if it's manual.

    References

    Sources

    1. 1ISO/SAE 21434:2021, Introduction · verified 2026-09-03
    2. 2UN R155, EUR-Lex CELEX 42021X0387 · verified 2026-09-03
    3. 3ISO/IEC 27001:2022 and 27002:2022 Contents · verified 2026-09-03