The UN R155 audit: what evidence the assessor actually opens
The dossier an assessor reads — and the difference between describing a process and proving it ran
What an assessor is actually looking for
A UN R155 assessment turns on one distinction: the difference between an evidence pack that describes a process and one that proves the process ran. Teams that fail their first assessment almost always have the former — a well-written policy manual — and almost none of the latter. The assessor is not there to grade your prose. They are there to open records and confirm that what your procedures claim happens actually happened, on a real programme, with dates and owners attached.
UN R155 requires a Certificate of Compliance for the Cyber Security Management System, valid three years, on top of a per-vehicle-type approval. The CSMS certificate is a judgement about your organisation's management system; the type approval is a judgement about a specific vehicle. Both draw on the same underlying discipline, and both are assessed against evidence rather than intent.
The two layers of the dossier
Think of the dossier in two layers. The first is the management-system layer: the governance, roles, risk-management method, supplier-management approach, monitoring and incident-response processes that make up the CSMS. The second is the demonstration layer: the records that show those processes producing outputs on an actual vehicle type.
An assessor moves between the two constantly. They will read a process description, then ask to see it exercised. If your risk-management procedure says a TARA is reviewed at defined gates, they will ask for a TARA and its review records at those gates. If your supplier procedure says cybersecurity requirements flow down through interface agreements, they will ask to see a signed agreement and the supplier evidence that came back.
| Layer | What it is | What the assessor opens |
|---|---|---|
| Management system | The defined CSMS processes and governance | Policies, role definitions, the risk-management method, supplier-management procedure, monitoring and incident-response processes |
| Demonstration | Records that the processes ran | Completed TARA, risk-treatment decisions, verification/validation results, supplier evidence, monitoring logs, incident records |
| Type-specific | Evidence tied to the vehicle type under approval | The type's TARA, RxSWIN declaration, cybersecurity case, residual-risk acceptance |
The records that carry the most weight
A few artefacts do most of the work in an assessment, because they are where description and demonstration meet.
The TARA is the centrepiece. Under ISO/SAE 21434 the threat analysis and risk assessment (clause 15) is where assets, threat scenarios, impact, attack feasibility and risk come together, and it is the evidence that your cybersecurity goals were derived rather than assumed. The assessor will not only read the TARA — they will check that it was maintained as the design changed, and that its outputs flowed into requirements and verification. A TARA that was written once and never touched again is a common and visible weakness, as covered in the gaps that fail a first UN R155 CSMS assessment.
Risk-treatment records show what you decided to do about each risk and who accepted the residual. This is where UN R155 Annex 5 does quiet work: the annex catalogues threats and vulnerabilities across categories — back-end servers, communication channels, update procedures, unintended human actions, external connectivity, and the vehicle's own data and targets — with mitigations in its later parts. An assessor uses Annex 5 as a coverage check. If a relevant threat category has no corresponding analysis or treatment, that gap is visible immediately.
Verification and validation results prove that the mitigations you claimed were actually tested. Penetration-test reports, requirement-based test results and review records belong here. They are the difference between "we require message authentication on the powertrain bus" and "here is the test that confirmed it."
Supplier evidence matters because the OEM carries the approval but depends on the supply chain for much of the substance. Cybersecurity interface agreements and the returned evidence from Tier-1 and Tier-2 suppliers are opened directly. A CSMS with strong internal records but no supplier trail is only half-assessed.
Monitoring records close the loop. UN R155 expects the CSMS to detect and respond to attacks and to monitor across post-production, so the assessor looks for evidence that a monitoring capability exists and produces output — triage records, vulnerability assessments, and the link back into update decisions. This is where a vehicle security operations centre earns its place in the dossier.
Describing versus proving
The single most useful test to apply to your own dossier before an assessment is this: for every claim in a process description, can you point to a dated record with a named owner that shows the claim being met? If the answer is "we would do that" rather than "here is where we did that," the item is not yet assessable.
This is why a dry-run assessment is worth the effort. Reading your own evidence pack in the order an assessor will — process, then demonstration, then type-specific record — surfaces the gaps while there is still time to close them. It also forces the organisational habit that a three-year certificate depends on: producing records as a by-product of doing the work, not reconstructing them the week before the audit.
Where the assessment fits in India
For Indian programmes the same evidence logic applies, but the route runs through the domestic regime. The CSMS assessment sits alongside vehicle type approval, handled by a test agency, with the approval body reading the same kind of dossier. How that submission-to-certificate flow works in practice — and where the cybersecurity assessment slots into it — is set out in how an Indian type approval actually gets assessed. The regulation may be AIS-189 rather than UN R155, but the assessor still opens records, not intentions. For the wider picture of what a CSMS is and what the approval authority checks, see UN R155 explained.
The AutoSifu view
AutoSifu treats the audit dossier as the deliverable, not an afterthought. Working with CIRT as one route — compliance, solutioning and CoC/VTA support with the approval body in the room — means the evidence is built to be opened, in the order the assessor will read it. The aim is simple: when the assessor asks to see the process running, the record is already there.
Sources
Questions
- What evidence does a UN R155 audit require?
- A UN R155 assessment requires both process descriptions and records that show those processes actually ran on a real programme. The assessor expects to see your governance and risk-management procedures, but also the completed TARA, risk-treatment decisions, verification and validation results, supplier evidence, and post-production monitoring records tied to specific vehicle types. Describing a process is not enough — the records must prove it was followed.
- What is the CSMS assessment?
- The CSMS assessment is the audit an approval authority (or a technical service acting for it) performs to confirm that a manufacturer's Cyber Security Management System meets UN R155. It results in a Certificate of Compliance for the CSMS, valid three years, which is a precondition for the per-vehicle-type approval. The assessment looks at both the management system and evidence that it operates across development, production and post-production.
- How is a CSMS certificate issued?
- Once the assessor is satisfied that the CSMS is defined and demonstrably operating, the approval authority issues a Certificate of Compliance for the CSMS, valid for three years. That certificate underpins the separate per-vehicle-type approvals, each of which draws on type-specific evidence such as the TARA and RxSWIN. The CSMS certificate is not permanent — it must be maintained and re-assessed.
