UN Regulation No. 155
UNECE source page for cyber security and the cyber security management system regulation. Confirm the applicable series and amendments for the type-approval question at hand.
Open UNECE source →Free working worksheet · No email gate
R155 and IEC 62443 evidence map
Use this worksheet to organize the evidence behind a vehicle or industrial-system cybersecurity decision. It connects governance, engineering, supplier and operational questions to records a review team can examine.
Use it as a working map, not a compliance checklist. R155 applies in a vehicle type-approval context; IEC 62443 addresses industrial automation and control systems. The frameworks are not interchangeable, and this worksheet does not determine conformity or certification. Confirm applicable jurisdiction, edition, amendment series, product or system scope, and contractual obligations against the current source texts.
Review checkpoints
Make the evidence and decision traceable
Mark a checkpoint when its evidence is assembled. Use the notes column to record the owner, repository, open gap or next review date. The worksheet stays in your browser; nothing entered here is sent or stored.
| Checkpoint | Potential evidence to assemble | Decision question | Review status and notes |
|---|---|---|---|
| Scope and authority | System or vehicle boundary; lifecycle state; asset and interface inventory; accountable owners; scope rationale. | What is in scope, which interfaces matter, and who can authorize the relevant security decision? | |
| Risk context | Threat and risk assessment; operational and safety consequences; assumptions; treatment decisions; residual-risk owner. | Which credible threat and failure paths are addressed, and who accepts any residual risk? | |
| Architecture and controls | Trust boundaries; zones and conduits where applicable; security requirements; identity and access design; verification results. | What enforces the boundary in the deployed configuration, and what test evidence shows it works? | |
| Supplier and service-provider interfaces | Defined roles; security responsibilities; engineering and maintenance access; supplier evidence; change and escalation records. | What evidence must cross the supplier boundary, and who retains operational authority? | |
| Operations and maintenance | Monitoring and incident procedures; patch and change records; backup and recovery evidence; support status; compensating measures. | Can changes be authorized and recovery performed safely under actual availability constraints? | |
| Vulnerability handling | Intake and triage records; exposure analysis; exploitability rationale; mitigation; customer or operator communications; reassessment triggers. | What conditions make a finding actionable, and when must the risk decision be revisited? | |
| Updates and released state | Software identity and provenance; authorization; integrity and compatibility checks; deployment evidence; rollback or recovery conditions. | Does the authorized software state match what is actually installed and supported? | |
| Assurance and review | Audit and test results; deviations; corrective actions; decision records; evidence owner; review cadence and change triggers. | What could disprove the current assurance claim, and what event triggers a new review? |
Evidence examples are prompts for a review conversation, not a complete statement of regulatory or standards requirements. Map each decision to the applicable legal text, licensed standards, organization-specific risk process and approved engineering baseline.
Primary references
Check the source texts for your scope
IEC 62443-2-1:2024
Asset-owner security-program requirements for IACS in operation, including operational and legacy-system context.
Open IEC publication page →IEC 62443-2-4:2023
Security-program requirements for IACS service providers, useful when reviewing integration and maintenance boundaries.
Open IEC publication page →IEC 62443-3-3:2013
System security requirements and security levels for IACS; apply with the relevant system scope and risk process.
Open IEC publication page →Want a concise weekly case study? Get the Weekly Brief: three real incidents, the engineering consequence, and the decision that matters.