Describe your business, leave with a checklist you can assign

The vehicle manufacturer or its duly accredited representative applies to the approval authority designated by the Contracting Party for a CSMS assessment. On satisfactory completion and receipt of a signed declaration in the Annex 1 Appendix 1 model, a CSMS certificate of compliance in the Annex 4 model is granted. It is valid for a maximum of three years from issue unless withdrawn. The manufacturer must apply for a new or extended certificate in due time before expiry and must inform the approval authority or its technical service of any change affecting the relevance of the certificate, which then decides whether new checks are needed.

Evidence: CSMS certificate of compliance (Annex 4 model) and a validity tracker; Signed manufacturer declaration in the Annex 1 Appendix 1 model; CSMS assessment report and non-conformity closure records; Lead-time management record for renewal or extension applications; Notifications of changes affecting certificate relevance and the authority responses

The manufacturer must identify the critical elements of the vehicle type, perform an exhaustive risk assessment for that type and treat or manage the identified risks appropriately. The assessment must consider the individual elements of the vehicle type and their interactions, and must further consider interactions with any external systems; it must cover all the threats listed in Annex 5 Part A as well as any other relevant risk. Failure to perform the exhaustive assessment, including failure to consider all Annex 5 Part A threats, is a ground for the approval authority to refuse approval.

Evidence: Inventory of critical elements and definition of system boundaries for the vehicle type; TARA report with an item-by-item mapping to the Annex 5 Part A threats; Risk analysis for interactions with external systems (cloud platform, charging infrastructure, mobile app, V2X); Risk treatment decisions and residual risk acceptance records; Process and re-assessment records keeping the risk assessment current

The manufacturer must demonstrate that its CSMS has processes to monitor for, detect and respond to cyberattacks, cyber threats and vulnerabilities on its vehicle types, and to assess whether the implemented measures remain effective against newly identified threats. Monitoring must be continual, must include vehicles after first registration, and must include the capability to analyse and detect threats, vulnerabilities and attacks from vehicle data and vehicle logs while respecting the privacy rights of owners and drivers, particularly regarding consent. Threats and vulnerabilities requiring a response must be mitigated within a reasonable timeframe, and the manufacturer must have processes to provide relevant data to support the analysis of attempted or successful attacks.

Evidence: Vehicle security operations centre (VSOC) design and on-duty procedures; Threat intelligence source list, vulnerability severity scheme and response time targets; Documentation of vehicle log collection scope, minimisation and consent mechanisms; Sample monitoring alerts, response tickets and closure records; Retention and provisioning process for data supporting attack analysis

AI incident and serious incident reporting record (register plus report drafts)

The manufacturer must protect the vehicle type against the risks identified in its risk assessment by implementing proportionate mitigations, which must include all mitigations referred to in Annex 5 Parts B and C that are relevant to the identified risks. Where such a mitigation is not relevant or not sufficient, another appropriate mitigation must be implemented. For type approvals prior to 1 July 2024 an alternative mitigation could be used where the Annex 5 measure was technically not feasible, with the feasibility assessment provided to the approval authority.

Evidence: Traceability matrix mapping Annex 5 Part B and C mitigations to the implementation in the vehicle type; Justification where a mitigation is not relevant or not sufficient and description of the substitute; Verification and penetration test reports for the mitigations; Where applicable, the technical feasibility assessment and the record of its submission to the approval authority

The manufacturer must demonstrate how its CSMS manages dependencies that may exist with contracted suppliers, service providers or its own sub-organisations in respect of the requirements of paragraph 7.2.2.2 (risk identification, verification of risk management, cybersecurity testing, keeping the risk assessment current, monitoring, detection and response). In practice this means embedding cybersecurity requirements in purchasing specifications and contracts, auditing suppliers, and agreeing vulnerability notification and investigation cooperation duties.

Evidence: Supplier cybersecurity requirement set (cybersecurity interface agreement or equivalent); Supplier audit plan, audit reports and non-conformity closure records; Vulnerability and incident notification clauses, response deadlines and exercise records; Documented responsibility split and interface definitions for sub-organisations

Supplier and subcontractor ESG and security due diligence questionnaire (for use as the buyer)

After a satisfactory assessment by the approval authority or its technical service and receipt of a signed declaration in the Annex 1 Appendix 1 model, a SUMS certificate of compliance in the Annex 4 model is issued, valid for a maximum of three years from issue unless withdrawn. At the end of the validity period the authority issues a new certificate or extends it for a further three years after a positive assessment, and issues a new certificate where changes brought to its attention have been positively re-assessed. Information relevant to the Regulation must be documented and securely held at the manufacturer and made available to the authority or technical service on request.

Evidence: SUMS certificate of compliance (Annex 4 model) and validity tracker; Signed manufacturer declaration in the Annex 1 Appendix 1 model; SUMS assessment report and non-conformity closure records; Procedure for securely holding and retrieving the documentation relevant to the Regulation

The RXSWIN is a dedicated identifier defined by the manufacturer representing information about the type-approval relevant software of the electronic control system. Each RXSWIN must be uniquely identifiable and must be updated when the manufacturer modifies type-approval relevant software in a way that leads to an extension or a new approval. Each RXSWIN must be easily readable in a standardised way through an electronic communication interface, at least the OBD port. Where RXSWINs are not held on the vehicle, the manufacturer must declare the software versions of the vehicle or individual ECUs and their link to the relevant approvals to the approval authority, update that declaration at each version change, and still make the versions readable in a standardised way through an electronic interface. The manufacturer must protect the RXSWINs and software versions on the vehicle against unauthorised modification and provide the protection means confidentially at type approval.

Evidence: RXSWIN definition document and the mapping of vehicle type to RXSWIN to type approval; Verification record for reading the RXSWIN through the OBD or electronic interface; Confidential design description and test report for tamper protection of RXSWINs and software versions; Where RXSWINs are not held on the vehicle, the software version declarations to the approval authority and their update log

The manufacturer must have a process to assess, identify and record whether a software update affects any other system required for the safe and continued operation of the vehicle, or adds or alters vehicle functionality compared with when it was registered. For every RXSWIN there must be an auditable register describing all software relevant to that RXSWIN before and after an update, including the software versions and their integrity validation data. Together these form the working papers for deciding whether an OTA update requires an extension or a new approval.

Evidence: Update impact assessment template and per-release assessment records; Auditable software register per RXSWIN, with pre- and post-update versions and integrity validation data; Conclusions on whether an extension or new approval is needed, and the related submissions; Access control and retention policy for the register

For over-the-air updates the manufacturer must ensure that the vehicle can restore systems to their previous version if an update fails or is interrupted, or that the vehicle can be placed into a safe state. The manufacturer must have a process by which the vehicle user can be informed about updates, and must provide any instructions that help the user safely execute the update. These two requirements drive the OTA release strategy for exported fleets: update windows, prohibition of updating while driving, user confirmation and prompt wording.

Evidence: Design description for rollback or safe state on failure, with interrupted-power and lost-connection test reports; User notification process and finalised prompt copy in each language; Safe execution instructions (preconditions, duration, whether the vehicle can be used); Staged rollout and rollback drill records

Apply for ALKS type approval for M1 vehicles under this Regulation, defining the vehicle type with regard to ALKS (vehicle features significantly influencing ALKS performance, and the system characteristics and design of the ALKS). Once activated the system must perform the driving task instead of the driver, manage all situations including failures without endangering occupants or other road users, and remain overridable by the driver at any time. A safe handover of the driving task must be implemented, with a minimum risk manoeuvre bringing the vehicle to a stop where the driver does not respond appropriately.

Evidence: Vehicle type definition for ALKS covering performance-relevant vehicle features and system design; Boundary definition of operating conditions (road type, speed, weather, traffic scenarios) and the exit strategy when boundaries are exceeded; Failsafe response design and fault injection test reports; Design and test records for the transition demand and the minimum risk manoeuvre; Human-machine interface design description, with evidence that non-driving-activity displays are suspended on a transition demand

For the software and hardware employed in the system, the manufacturer must demonstrate to the type approval authority, in terms of a safety management system, that effective processes, methodologies and tools are in place, up to date and actually followed within the organisation to manage safety and continued compliance throughout the product lifecycle (design, development, production, operation, decommissioning). The design and development process must cover the safety management system, requirements management, requirements implementation, testing, failure tracking, remedy and release. The manufacturer must also put suitable arrangements in place with suppliers — contractual arrangements, clear interfaces, quality management systems — so that supplier safety management systems comply with the corresponding requirements.

Evidence: Safety management system manual and lifecycle process map (design, development, production, operation, decommissioning); Process records and traceability matrix for requirements management, implementation, testing, failure tracking and release; Process audit report and non-conformity closure records; Safety interface agreements with suppliers, quality management system evidence and audit records

Every ALKS-equipped vehicle must be fitted with a DSSAD enabling the determination of interactions between the ALKS and the human driver. The DSSAD must record the defined occurrences, that is actions or instances of arising events or incidents that require storage in the data storage system. The manufacturer must demonstrate fulfilment of paragraph 8 to the technical service during the inspection of the safety approach as part of the Annex 4 assessment, and an operational DSSAD is one of the conditions for the system to be activated.

Evidence: DSSAD design specification and mapping of the defined occurrences; Test reports on DSSAD record integrity, tamper resistance and retrieval method; Verification record that an operational DSSAD is a condition for system activation; DSSAD retention period, access authorisation and authority-disclosure procedure

The manufacturer must have processes to monitor safety-relevant incidents, crashes and collisions caused by the engaged automated lane keeping system, a process to manage potential safety-relevant gaps after registration (a closed loop of field monitoring) and to update the vehicles, and must report critical incidents — for example collisions with other road users and potential safety-relevant gaps — to the type approval authority. This requires wiring overseas fleet incident data collection, analysis and remediation into the OTA release process.

Evidence: Field safety incident monitoring process and severity criteria defining a critical incident; Incident ledger and root-cause analysis reports; Records and acknowledgements of critical incident reports sent to the type approval authority; Closed-loop records linking safety gap remediation to OTA releases

AI incident and serious incident reporting record (register plus report drafts)

Compare each existing robot model clause by clause against the 2011 and 2025 requirements, list the clauses requiring redesign, revalidation or documentation updates only, and produce a migration plan and schedule. For models already sold abroad, define the cut-off between continuing to declare against the 2011 edition and upgrading to the 2025 edition, and state the standard edition and year consistently in customer specifications and tender documents.

Evidence: Clause-level gap analysis between the 2011 and 2025 editions; Migration plan with owners, milestones and the list of affected models; Revalidation test plan and results; Agreed wording for the standard edition cited in external specifications and tenders

Robot conformity is not application conformity: under ISO 10218-2 the specific application and robot cell — end-effector, workpiece, peripheral equipment, guarding and safety devices, and human access routes — must be risk assessed at integration level, safeguarding measures and the collaborative operation mode must be determined, and every use restriction listed by the robot manufacturer in its declaration of incorporation must be implemented or substituted.

Evidence: Robot cell integration risk assessment report with layout drawings and human access analysis; Safety function inventory with performance level (PL/SIL) justification; Item-by-item record showing how the robot declaration of incorporation restrictions were implemented; Rationale for the collaborative operation mode chosen and the speed, separation or force limit parameters used

ISO 10218-1 does not apply to underwater, law-enforcement, military (defence), airborne or space robots, nor to medical robots, healthcare robots, prosthetics and other aids for the physically impaired, service robots, consumer products, or equipment lifting or transporting people. Before claiming ISO 10218 conformity externally, verify the product falls inside the scope, avoid unsustainable conformity claims for embodied-AI service, delivery or companion robots, and define a separate standards and safety-argument route for those categories.

Evidence: Mapping of product categories to standard scope; Review record (legal/compliance sign-off) for external conformity claims; Alternative standards and safety-argument route documented for out-of-scope categories