Product CSMS as a management system

Scope: the CSMS behind a vehicle type approval · Who: the officer who owns the certificate · Prerequisites: a defined vehicle type and a sponsor · First result: one operating quarter

1. Why this exists (the failure mode it prevents)#

An organisation that already runs an information security management system usually builds its second one badly. The cyber security management system UN Regulation No. 155 requires arrives as a document set for the assessment.

The regulation invites the mistake, because it states requirements as demonstrations. The manufacturer has to demonstrate that the processes in its cyber security management system ensure security is adequately considered. That includes the risks and mitigations listed in Annex 5 ¹. Read quickly, that asks for process descriptions. Read as written, it asks for processes that ran.

Four symptoms travel together. The process set exists on paper with no operating record. The risk assessment is produced once, in the concept phase, although the regulation asks for a process keeping it current. Supplier dependencies are covered by a questionnaire rather than a managed interface. Post-production monitoring produces no signal from the field.

All four surface in the same place. The assessment for the Certificate of Compliance checks that the manufacturer has the necessary processes, against a signed declaration and the documents describing the system ². An assessor who cannot see processes running has nothing to certify. No certificate then means no type approval, except the 7.3.1 route: Category L approvals first issued before 1 July 2029 may instead show cyber security was adequately considered in development. A certificate already held lasts at most three years and can be withdrawn earlier if the requirements stop being met ³.

The fix is structural. Treat it as a management system on the clause pattern the organisation already runs next door: scope, leadership, planning, operation, evaluation, improvement. Let the regulation's paragraphs supply the requirements. This playbook does that, and marks where the pattern has no regulatory backing.

2. Definitions (only the ones that cause disputes)#

Six terms account for most arguments with an approval authority. Standard requirements are paraphrased; the regulation's definitions are as published.

Term	Working definition	Source
Cyber Security Management System	A systematic risk-based approach defining organisational processes, responsibilities and governance to treat risk from cyber threats to vehicles.	Paragraph 2.3 4
Vehicle type	Vehicles not differing in the manufacturer's designation, or in essential aspects of the electric and electronic architecture and external interfaces for cyber security.	Paragraph 2.1 5
Certificate of Compliance for CSMS	Granted by an approval authority after assessing the manufacturer, on the model in Annex 4. Valid at most three years from deliverance unless withdrawn.	Paragraphs 6.5 to 6.7 6
The three phases	Development, before a type is approved; production, its duration; post-production, from the end of production until no vehicle of that type is operational.	Paragraphs 2.5 to 2.7 7
TARA	Threat analysis and risk assessment: the Clause 15 methods, described there as generic modules invocable from any point in an item's lifecycle.	ISO/SAE 21434:2021 clause 15.1 8
Continual cybersecurity activities	Clause 8: monitoring, event evaluation, vulnerability analysis and vulnerability management, performed in all phases and possibly outside any project.	ISO/SAE 21434:2021 clause 8.1 9

The pattern borrowed below is the clause order of ISO/IEC 27001:2022, set out in full in building an ISMS people actually use. Scope sits at 4, leadership at 5, planning at 6, operation at 8, evaluation at 9, improvement at 10 ¹⁰. That is a design choice, not a claim the regulation requires it.

3. The method — the CSMS as a management system#

Ten steps: the first nine follow the management-system order, the tenth keeps the system current. Each names input, activity, output and owner.

3.1 Fix the scope: vehicle types, phases, organisations, suppliers#

The regulation fixes three of the four scope dimensions itself. It applies to vehicles of Categories L, M, N and O fitted with at least one electronic control unit ¹¹. The system has to apply to the development, production and post-production phases ¹². It also has to reach dependencies with contracted suppliers, service providers and sub-organisations. What remains to decide is the internal boundary: which entities, sites and functions operate the processes. Clause 4.3 of ISO/IEC 27001:2022 gives that statement its shape ¹³.

• Input: the vehicle types in development and in the field, the organisation chart, the site list, the supplier list.
• Activity: state which entities and functions operate the system; list the types covered; confirm all three phases; name every interface crossing the boundary and its governing agreement.
• Output: CSMS scope statement, approved, listing entities, sites, vehicle types and phases.
• Owner: the product security officer drafts; top management approves.

A scope drawn around control units rather than vehicle types is the first defect an assessor finds.

3.2 Turn leadership into assigned authority#

The regulation states its organisational requirement in one phrase inside the process list: the processes used within the manufacturer's organisation to manage cyber security. That is thin, and the assessment is not. Clause 5 of ISO/SAE 21434:2021 is explicit: a cybersecurity policy carrying executive commitment, rules and processes, assigned responsibilities with matching authority, and resources ¹⁴. Clauses 5.1 and 5.3 of ISO/IEC 27001:2022 give it management-system wording ¹⁵.

• Input: draft policy, proposed role model, resourcing estimate, the disciplines that interact with cyber security.
• Activity: have executive management approve the policy; assign responsibilities and matching authority; provide named resources; establish channels to functional safety, privacy and information security.
• Output: cyber security policy, signed and dated; roles and authorities matrix; interdisciplinary interface record.
• Owner: top management; the product security officer prepares.

The standard also asks for a cyber security culture and continuous improvement, with competence and awareness held by the people in the roles ¹⁶. Records per person, not per session.

3.3 Build the process set the regulation names#

Paragraph 7.2.2.2 is the load-bearing requirement. It lists eight process areas, and an assessment works through them one at a time. Each row paraphrases a point and names the artefact proving it ran.

Point	What the process covers	Evidence it produces
(a)	Managing cyber security within the manufacturer's organisation	Policy, rules, roles, decisions
(b)	Identifying risks to vehicle types, considering the threats in Annex 5 Part A and other relevant threats	Records citing Annex 5 Part A
(c)	Assessing, categorising and treating the risks identified	Risk register with categories and treatment decisions
(d)	Verifying that identified risks are appropriately managed	Verification records per risk
(e)	Testing the cyber security of a vehicle type	Test plans and results per type
(f)	Keeping the risk assessment current	Dated reassessments with the trigger for each
(g)	Monitoring for, detecting and responding to attacks, threats and vulnerabilities, and assessing whether measures remain effective	Monitoring outputs, triage, response records
(h)	Providing relevant data to support analysis of attempted or successful attacks	Log and forensic data retention records

Two adjacent paragraphs bind that list. Threats and vulnerabilities requiring a response are to be mitigated within a reasonable timeframe, based on the categorisation from points (c) and (g) ¹⁷. Monitoring under point (g) has to be continual, covering vehicles after first registration and including the capability to analyse and detect threats from vehicle data and logs ¹⁸.

• Input: the scope statement, the existing engineering and quality processes, the standard's clause structure.
• Activity: write one process per point, each with an owner, a trigger, a record and a retention rule; map each onto engineering activity that already exists.
• Output: process map naming an owner and an output record per point.
• Owner: the product security officer; each process has a named owner.

Clause 6 is where that set meets a programme, through a cybersecurity plan stating each activity's objective, dependencies, responsible personnel, resources, timing and work products ¹⁹.

3.4 Run risk as a process, not as a deliverable#

The regulation asks for two risk activities and teams merge them. At system level, points (b), (c), (d) and (f) ask for processes. At type level, paragraph 7.3.3 asks the manufacturer to identify the critical elements of the type and perform an exhaustive risk assessment. It covers individual elements, their interactions, interactions with external systems, and all the threats in Annex 5 Part A ²⁰.

Clause 15 defines seven modules: asset identification, threat scenario identification, impact rating, attack path analysis, attack feasibility rating, risk value determination and risk treatment decision ⁸. The treatment decision selects one or more of avoiding, reducing, sharing or retaining the risk ²¹. Clause 6.1 of ISO/IEC 27001:2022 has the same shape ²².

• Input: the item definition, the Annex 5 Part A threat list, architecture and interface documentation, field information.
• Activity: run the seven modules; record a treatment decision and named owner per threat scenario; define the trigger list that re-opens an assessment; log every evaluation, including the null ones.
• Output: TARA register per vehicle type, versioned; trigger evaluation log.
• Owner: the product security officer owns the process; a named risk owner accepts each retained risk.

Point (f) turns the register into a process. A register whose last version predates several software releases fails it.

3.5 Manage supplier dependencies, do not survey them#

Paragraph 7.2.2.5 requires the manufacturer to demonstrate how the system will manage dependencies with contracted suppliers, service providers or its own sub-organisations. That demonstration is made in regard of the requirements of paragraph 7.2.2.2 ²³. That back-reference is operative: all eight process areas have to hold across the boundary. At type level, paragraph 7.3.2 requires supplier-related risks to be identified and managed ²⁴, and the authority verifies by document check that supplier-related information is collected and verified through the supply chain ²⁵.

Clause 7 of the standard gives the instrument. Customer and supplier specify the distributed activities in a cybersecurity interface agreement. It covers points of contact, the activities each performs, joint tailoring, the information and work products shared, milestones, and the end of cyber security support ²⁶. Supplier capability is evaluated, which supports selection ²⁷.

• Input: the contracted supplier list, the scope statement, the process map, existing quality agreements.
• Activity: classify each supplier by the process areas it touches; agree the interface agreement before distributed work starts; record what each supplier's own risk assessment covered.
• Output: supplier dependency register, one row per supplier with its agreement reference and covered process areas.
• Owner: procurement holds the contract; the product security officer owns the register.

Tiering and reassessment are solved on the information-security side, in third-party risk across the contract lifecycle. Specific here is the back-reference: an agreement naming a contact but leaving the eight areas unallocated has not managed the dependency.

3.6 Operate across development, production and post-production#

The three phases are the operational spine, and the standard supplies a clause for each. Clauses 10 and 11 cover product development and cybersecurity validation ²⁸. Clause 12 asks for a production control plan applying the cyber security requirements for post-development and preventing vulnerabilities being introduced during production ²⁹. Clause 13 covers incident response and field updates; Clause 14 the end of cyber security support and decommissioning ³⁰.

Running through all three is Clause 8. Monitoring triages collected information against defined triggers, and event evaluation decides whether an event indicates a weakness. Vulnerability analysis decides whether a weakness is exploitable, and vulnerability management tracks treatment until support ends ⁹. Sources are selected and triggers maintained ³¹.

• Input: the process map, the TARA register, field data sources, the production plan, the supplier agreements.
• Activity: stand up at least one field signal reaching the security function in hours, and define the triggers that turn information into an event. Keep an incident response plan with remedial actions, communications, responsibilities, progress measurement and closure criteria ³².
• Output: monitoring source and trigger list; event and vulnerability records; incident response plan; production control plan.
• Owner: the product security officer for monitoring and response; manufacturing for the production control plan.

The regulation adds the measures the type itself carries: detecting and preventing attacks, supporting the monitoring capability, and providing forensic capability ³³.

3.7 Assemble the evidence the vehicle type needs#

Paragraph 7.3 is the type-level requirement set, and an approval turns on it. Paragraphs 7.3.1 to 7.3.8 read as a sequence of duties ³⁴. They require a valid certificate for the type, managed supplier-related risks, and the exhaustive risk assessment. They require proportionate mitigations, including the relevant Annex 5 ones, and another appropriate mitigation where a listed one is not relevant or not sufficient. They require secured environments for aftermarket software where provided, testing of effectiveness before approval, vehicle-level detection and forensic measures, and cryptographic modules in line with consensus standards or justified.

Annex 1, item 9, sets out what the information document carries ³⁵. The items are the construction characteristics relevant to cyber security, a schematic representation of the type, and the certificate number. They continue with the risk assessment outcome, the mitigations, protection of aftermarket environments, the tests and their outcome, and the supply chain. That package stays available for at least ten years after production of the type is definitively discontinued ³⁶. Annex 5 has three parts, and all three are to be considered ³⁷. Part A is the baseline threats, vulnerabilities and attack methods; Part B mitigations for vehicles; Part C mitigations for areas outside vehicles, such as back-end systems.

• Input: the TARA register, verification and test results, the supplier dependency register, the certificate.
• Activity: assemble the Annex 1 information document; trace each Annex 5 Part A threat to a treatment and a test result; record the justification wherever a Part B or Part C mitigation was replaced.
• Output: vehicle-type evidence pack, indexed to Annex 1 item 9.
• Owner: the product security officer, with engineering supplying test evidence.

The refusal grounds say the same from the authority's side: no exhaustive risk assessment, unprotected risks, unsecured aftermarket environments, or insufficient testing before approval ³⁸. Testing is verified on a vehicle of the type, sampled towards risks assessed as high ³⁹.

3.8 Evaluate the system — and note what the regulation does not ask for#

This is where the borrowed pattern has to be labelled honestly. The word audit does not appear anywhere in the text of UN Regulation No. 155 [2025/5]. It prescribes no internal audit programme and no management review. What it prescribes is external. The approval authority may at any time verify that the requirements for the certificate continue to be met ⁴⁰. Conformity of production checks run at a normal frequency of once every three years ⁴¹.

Two sources fill the gap. The standard requires a cyber security audit performed independently, judging whether the organisational processes achieve its objectives ⁴². At project level it requires a rationale-based decision on whether to perform a cyber security assessment, and an independently appointed assessor. The assessment report recommends acceptance, conditional acceptance or rejection ⁴³. ISO/IEC 27001:2022 supplies the programme shape at clause 9.2: planned internal audits with defined criteria, and auditors selected to preserve objectivity and impartiality ⁴⁴. Clause 9.3 supplies the review shape ⁴⁵.

• Input: the process map, previous findings, the certificate expiry date, the monitoring reports.
• Activity: plan an internal programme covering all eight process areas across the certificate cycle; keep the auditor independent of the process audited; record cause, action and an effectiveness check per finding.
• Output: internal audit programme and reports; finding register.
• Owner: an auditor independent of the audited process.

Say plainly, in the system description, that these two are adopted practice. Presenting them as regulatory requirements is an inaccuracy an assessor will notice.

3.9 Run the certificate cycle as a calendar, not an event#

Every date in the certificate lifecycle is in the regulation. The application comes from the manufacturer or an accredited representative, with documents describing the system and a signed declaration on the model in Appendix 1 to Annex 1 ⁴⁶. The manufacturer informs the authority of any change affecting the certificate's relevance, and the authority decides whether new checks are needed ⁴⁷. Renewal is neither automatic nor late-binding.

The manufacturer applies for a new certificate or an extension in due time, so the authority can finish its assessment before validity ends. A positive assessment extends validity three further years ⁴⁸. Expiry or withdrawal is treated as a modification of approval for the affected types, and the approval may itself be withdrawn ⁴⁹.

• Input: the certificate with its date of deliverance, the change log, the assessment lead time agreed with the authority.
• Activity: put three dates in the calendar per certificate — readiness gate, application, expiry; raise a change notification whenever a modification affects relevance; keep the annual report on its own recurring date.
• Output: certificate calendar with named owners and dated gates.
• Owner: the product security officer.

The annual obligation belongs here too. The manufacturer reports the outcome of its monitoring at least once a year, or more often where relevant, including information on new attacks. The same report confirms that mitigations remain effective ⁵⁰. Where reporting or response is insufficient, the authority may withdraw the certificate ⁵¹.

3.10 Keep it alive#

The regulation's own text changes. The Official Journal republished UN Regulation No. 155 in consolidated form in January 2025, incorporating text up to Supplement 3. Two differences from the 2021 publication reach a scope statement. The earlier text applied to Categories M and N, and to Category O if fitted with at least one electronic control unit ⁵². It also reached Categories L6 and L7 equipped with automated functionalities from level 3 onwards, as ECE/TRANS/WP.29/1140 defines them ⁵³. The earlier transitional relief was framed as type approvals prior to 1 July 2024 ⁵⁴. The consolidated text separates Categories M, N and O first approved before 1 July 2024 from Category L first approved before 1 July 2029. It also extends the relief to each extension of those approvals ⁵⁵.

The neighbouring regulation moves on its own schedule. Software update management under UN Regulation No 156 is a separate approval. Its amendment history does not track this one, and the current position sits at the R156 amendment entry on the radar. Cite a supplement level only from the depositary or status record.

The horizontal regime stops at the type-approval boundary. The Cyber Resilience Act does not apply to products with digital elements covered by Regulation (EU) 2017/745, Regulation (EU) 2017/746 or Regulation (EU) 2019/2144 ⁵⁶. The third is the vehicle general safety regulation, the route by which R155 binds in the Union. The exclusion follows the legal act applying to the product, not the company making it, so a back-end product can still be in the Act's scope.

4. Deliverables#

Retention is an organisational choice except the ten-year row, which the regulation fixes.

Deliverable	Required by	Format	Retention
CSMS scope statement	Paragraphs 7.2.2.1 and 7.2.2.5	document	current plus one certificate cycle
Process map, one entry per point (a) to (h)	Paragraph 7.2.2.2	register	whole cycle
TARA register and trigger evaluation log	Paragraphs 7.2.2.2(f) and 7.3.3	register, versioned	every version, whole cycle
Supplier dependency register and interface agreements	Paragraph 7.2.2.5; ISO/SAE 21434:2021 clause 7.4.3	register plus agreements	contract term
Monitoring and response records	Paragraph 7.2.2.4; ISO/SAE 21434:2021 clauses 8.3 and 13.3	records	whole cycle
Vehicle-type evidence pack, indexed to Annex 1 item 9	Paragraph 3.2.1 and Annex 1 57	document set	at least ten years after production ends
Annual monitoring report; certificate calendar	Paragraphs 7.4.1, 6.7 and 6.10	report; calendar with owners	whole cycle

5. What the assessor will ask#

Each question traces to a cited R155 paragraph: a record first, then the decision behind it.

6. Failure modes and how they surface#

7. Mapping#

ISO/IEC 27001:2022 clause	UN R155 paragraph	ISO/SAE 21434:2021 clause	Evidence sampled
4.3 Determining the scope 13	1.1 categories; 7.2.2.1 phases	Clause 6, project dependent cybersecurity management	Scope statement naming types and phases
5.1 Leadership and commitment; 5.3 roles and authorities 58	7.2.2.2(a)	5.4.1, cybersecurity governance	Approved policy; roles matrix
6.1 Actions to address risks and opportunities 22	7.2.2.2(b) to (d); 7.3.3	Clause 15, threat analysis and risk assessment methods	TARA register with owners and decisions
8.1 Operational planning and control 59	7.2.2.2(e), (h); 7.3.6	Clauses 10 to 12, development, validation, production	Test results; production control plan
8.2 Information security risk assessment 60	7.2.2.2(f), (g); 7.2.2.3; 7.2.2.4; 7.3.7	Clause 8, continual cybersecurity activities	Trigger log; monitoring, event and vulnerability records
Annex A, information security controls reference 61	7.2.2.5; 7.3.2	Clause 7, distributed cybersecurity activities	Interface agreements; supplier dependency register
9.2.2 Internal audit programme; 9.3.3 Management review results 62	not prescribed	5.4.7 audit; 6.4.8 cybersecurity assessment	Audit programme; review record with decisions
10.2 Nonconformity and corrective action 63	7.4.2, remedy of detected ineffectiveness	8.6, vulnerability management	Finding register with cause, action, verification

8. Checklist#

Each item is observable in a record.

• The scope statement names the vehicle types, the entities and all three phases, and is approved.
• The policy carries executive approval, and the incident response plan names actions, owners and closure criteria.
• The process map has one entry per point (a) to (h), each with an owner and an output record.
• The TARA register is versioned per type, with a named owner per retained risk and a published trigger list.
• Every Annex 5 Part A threat traces to a treatment decision, any substitution is justified, and test results predate the application.
• Every supplier in scope has an interface agreement allocating the eight process areas, and the register records what each supplier assessed.
• At least one monitoring signal originates from vehicles after first registration, with a recorded response path.
• The evidence pack is indexed to Annex 1, item 9, and the annual report's sending is recorded.
• The certificate calendar holds the readiness gate, the application date and the expiry.
• The finding register records cause, action and an effectiveness check date.
• The system description states which practices are adopted rather than required by the regulation.

References#

Primary sources only. The regulation was read in the Official Journal text at the EU Publications Office. The standard was read in a licensed copy: clause numbers, titles and paraphrases are taken from it, and no requirement sentence is reproduced.

1. United Nations Economic Commission for Europe. UN Regulation No. 155 — Uniform provisions concerning the approval of vehicles with regards to cyber security and cyber security management system [2025/5]. OJ L, 2025/5, 10.1.2025. CELEX 42025X0005. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:42025X0005 ⁶⁴
2. United Nations Economic Commission for Europe. UN Regulation No 155 [2021/387]. OJ L 82, 9.3.2021, p. 30. CELEX 42021X0387. Cited only for what changed. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:42021X0387 ⁶⁵
3. ISO and SAE International. Road vehicles — Cybersecurity engineering. ISO/SAE 21434:2021, first edition, 2021-08. https://www.iso.org/standard/70918.html ⁶⁶
4. ISO/IEC. Information security, cybersecurity and privacy protection — Information security management systems — Requirements. ISO/IEC 27001:2022. Clause titles read on the ISO Online Browsing Platform. https://www.iso.org/obp/ui/#iso:std:iso-iec:27001:ed-3:v1:en ⁶⁷
5. European Parliament and Council. Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). OJ L, 2024/2847, 20.11.2024. CELEX 32024R2847. https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng ⁵⁶

Calendar gates, register formats and the audit cadence are organisational choices, not requirements.