# UN R155 audits: what testers need to deliver

What a UN R155 assessment expects from the test side: traceable test cases, versioned evidence, coverage, clean results, residual risk and supplier deliverables.

Source: https://auto-st.com/insights/un-r155-audit-what-testers-need · Updated: 2026-10-07

For a UN R155 assessment, the test side has to show three things: that every relevant risk from the risk assessment was tested, that the tests showed the security measures work, and that the results can be traced and reproduced. The regulation does not prescribe test methods. It requires the manufacturer to identify risks, treat them and verify that the measures are effective, and the assessor then follows the chain from risk to measure to test to result. Testers who deliver test cases with identifiers, linked to threat scenarios, with dated and versioned evidence and an explicit statement of what was not tested make that chain easy to follow. Testers who deliver a PDF with "no critical findings" make it hard.

## What R155 asks, in short

UN R155 has two parts that matter here. Paragraph 7.2 covers the cyber security management system (CSMS) of the manufacturer: the processes for risk identification, assessment, treatment, testing and monitoring. Paragraph 7.3 covers the vehicle type: the manufacturer has to carry out a risk assessment for the type, protect it against the identified risks with proportionate measures, and test the effectiveness of those measures before type approval. Annex 5 lists threats and mitigations the risk assessment has to consider.

ISO/SAE 21434 is the usual engineering framework behind it. The testing obligations sit in Clause 10 (integration and verification), Clause 11 (cybersecurity validation) and the TARA in Clause 15. Distributed development with suppliers is handled in Clause 7.

## The chain an assessor follows

| Link | What the tester provides |
| --- | --- |
| Threat scenario (TARA, Annex 5 reference) | The test case identifiers that address it |
| Cybersecurity requirement | The pass criterion that shows it is met |
| Test case | Steps, preconditions, expected result, coverage |
| Result | Date, software version, tester, tool version, raw evidence |
| Finding | Rating with rationale, fix status, residual risk decision |

If one link is missing, the assessor asks. The most common gap we see in audit support is the link from test case back to threat scenario: the tests were run, but nobody can show which risk each test addressed.

## Evidence that holds up

Evidence for an audit is raw, dated and attributable. For each test case, keep:

- The software and hardware version of the item under test, as the ECU reports it, for example from `22 F1 89` and `22 F1 91`.
- The request and response, or the log of the campaign, not just the verdict. A line such as `2E F1 8C ... -> 7F 2E 33` proves a write was refused.
- The date, the tester, the tool and its version, the bench configuration.
- For fuzzing: seed, iteration count, services in scope, the monitors used. A campaign that cannot be repeated is weak evidence.

Clean results count. "SecurityAccess level 1: lockout after three invalid keys (`7F 27 36`), delay enforced (`7F 27 37`), seed passed the randomness checks" is the evidence that the brute-force mitigation works. Assessors read negative results as proof of coverage.

## Coverage and limits

State the coverage in numbers and the limits in words. "All service identifiers `0x00` to `0xFE` in sessions `01`, `02` and `03`" or "DID range `0xF100` to `0xF1FF`" tells the assessor how far the test went. Exclusions are equally important: if hardware attacks, firmware extraction or the telematics backend were out of scope, write it down, with a reference to where those risks are covered.

## Residual risk and re-test

Every finding needs an end state: fixed and verified on a named software version, mitigated by another measure, or accepted as residual risk by a named role on a date. Open findings without a decision are the second most common audit question. Plan the re-test from the start and keep test case identifiers stable, so that the re-test on the new software version shows the same case passing.

## What suppliers should hand over

A Tier-1 supporting an OEM's R155 approval is usually asked for the TARA or its relevant part, the cybersecurity requirements it implemented, the test specification and results with traceability, open findings with their status, and the vulnerability management arrangement after start of production. Agree on the format early in the cybersecurity interface agreement. Handing over a PDF without the test case identifiers forces the OEM to redo the mapping, and that is where audit findings come from.

## How AutoST supports this

AutoST produces the repeatable part of this evidence: test runs with the ECU, interface and session scope, coverage figures, every finding with its request and response bytes, a PDF report and a SARIF export per run, and a Fix Plan that keeps status, assignee, risk acceptance and an ALM/PLM reference per finding across re-tests. It does not run a CSMS, write the TARA or issue any approval, and it does not replace the penetration test that Clause 11 validation usually includes. Its job is to make the test results traceable and repeatable, release after release.

## FAQ

**Does UN R155 prescribe specific security tests?**

No. The regulation asks the vehicle manufacturer to test the effectiveness of the implemented security measures and to treat the risks it identified, with Annex 5 listing threats and mitigations to consider. Which tests prove that is left to the manufacturer, which is why traceable test cases matter so much.

**Is a supplier audited under UN R155?**

The approval is granted to the vehicle manufacturer, not to the supplier. Suppliers are drawn in because the manufacturer has to manage supplier risks and needs their evidence, so a Tier-1 will be asked for test results, traceability and its own cybersecurity work products.

**Can a test tool make a vehicle R155 compliant?**

No. A tool produces test results and evidence. Compliance comes from the manufacturer's cybersecurity management system and its type approval, which a technical service and an approval authority assess.

## Sources

- [UN Regulation No. 155: Cyber security and cyber security management system](https://unece.org/transport/documents/2021/03/standards/un-regulation-no-155-cyber-security-and-cyber-security)
- [ISO/SAE 21434:2021 Road vehicles, Cybersecurity engineering, Clauses 7, 10, 11 and 15](https://www.iso.org/standard/70918.html)
- [ISO 14229-1:2020 Road vehicles, Unified diagnostic services (UDS), Part 1](https://www.iso.org/standard/72439.html)

## Related

- [UN R155 (UN Regulation No. 155, Cyber Security)](https://auto-st.com/glossary/un-r155)
- [CSMS (Cybersecurity Management System)](https://auto-st.com/glossary/csms)
- [Traceability in an ISO 21434 audit: making fuzzing count](https://auto-st.com/insights/traceability-iso-21434-audit)
- [ISO/SAE 21434 verification evidence from security testing](https://auto-st.com/insights/iso-21434-verification-evidence)
- [AutoST for ISO/SAE 21434 Compliance Managers: Test Evidence You Can Trace](https://auto-st.com/for/iso-21434-compliance-managers)
- [Evidence for your 21434 work, on tap.](https://auto-st.com/iso-21434-testing)

---
AutoST by Zyberum. Canonical page: https://auto-st.com/insights/un-r155-audit-what-testers-need