The SUMS documentation UN R156 expects

Documentation is the deliverable

A SUMS — Software Update Management System — is assessed on its documentation, so the documentation is not a by-product of the work; it is the work as the approval authority sees it. UN R156 requires a manufacturer to hold a Certificate of Compliance for its SUMS, and that certificate is earned by showing two things: that defined processes exist, and that those processes actually ran. The second half is where most first assessments struggle, because it is easy to write a procedure and hard to prove it was followed on a real release.

The distinction to hold onto throughout is the one between describing a process and evidencing it. A binder of well-written procedures with no records behind them describes an intention. The assessor is looking for the trace that shows the intention became practice.

The two layers of a SUMS document set

Every element of a SUMS documentation set exists at two layers: the process description that says how something is done, and the records that show it was done. Both are required. The table below sets out the core elements and what each layer looks like.

Element	Process description	Records that evidence it
Software configuration	How the software of each type is identified and controlled	Current configuration of each type, mapped to RxSWIN
RxSWIN management	How the regulation-relevant scope is defined and changed	RxSWIN change history tied to specific software changes
Update assessment	How an update's effect on regulated functions is judged	The recorded decision for each update, and any approval extension
Integrity controls	How update authenticity and integrity are protected	Signing and verification evidence for released packages
Dependencies	How update compatibility and dependencies are managed	Records of dependency checks for a release
Delivery and installation	How updates reach and install on vehicles safely	Per-campaign delivery records and pre-conditions applied
Update records	What is retained per vehicle	What was updated, when, on which vehicle, with what outcome

Read across any row and you see the assessment in miniature: a claim in the left column, and the proof in the right that an assessor will ask to see.

RxSWIN sits at the centre

The RxSWIN threads through almost every element above, which is why it is treated as the spine of the SUMS rather than one document among many. The software configuration records map to it, the update-assessment records reference it, and the per-vehicle update records tie back to it. If the RxSWIN documentation is weak — scope undefined, change history missing, mapping incomplete — the weakness propagates through the whole set, because everything else is anchored to it. We cover building and maintaining that anchor in generating and managing RxSWIN for R156.

Records of the update process running

The records that most reliably decide an assessment are the ones showing an update actually went through the process end to end. For a chosen release, the SUMS should be able to produce: the decision that assessed its effect on regulated functions, the RxSWIN change (if any) and its justification, evidence the package was signed and its integrity verified, the delivery record showing which vehicles received it and when, and the outcome including any rollback or recovery. This is the same evidence-over-description standard that governs an R155 audit — the assessor traces a real event, not a template.

Where ISO 24089 helps

ISO 24089:2023, the software update engineering standard, is the practical source for how these processes are structured and what records they should produce. R156 states the obligation; ISO 24089 provides the organisational and project-level process detail that turns the obligation into a repeatable, documentable practice. Building the SUMS documentation on ISO 24089 is not legally mandatory, but it is the most defensible way to arrive at a document set that maps cleanly onto what an assessor expects to trace.

The failure modes

SUMS documentation fails an assessment in a small number of predictable ways. Process without records: the procedures are immaculate but nothing shows they were applied. RxSWIN gaps: the scope is undefined or the change history does not match the software history. Broken traceability: an update can be described but not traced from decision to per-vehicle record. Missing outcomes: deliveries are recorded but failures, rollbacks and recoveries are not. Each of these is a documentation gap rather than an engineering one, and each is closed the same way — by holding the records the process is supposed to generate, and by rehearsing the trace before the assessor does it for you.

A dry run is worth more than a rewrite

The single most useful preparation is to trace a real update through the document set yourself, exactly as an assessor would, and see where the trace breaks. It almost always breaks somewhere — a missing signing record, an RxSWIN change with no justification, a delivery log that cannot be tied to specific vehicles. Finding those gaps in a dry run is cheap. Finding them at the assessment, with a certificate and a vehicle-type approval waiting behind it, is not.

The AutoSifu view

We build SUMS documentation as a traceable evidence set, not a binder of procedures: mapped to R156, AIS-190 and ISO 24089, structured so a real update traces cleanly from decision to record, and prepared for CoC and VTA on one route. With CIRT working alongside us, the approval body sees the document structure while it is still being shaped, and the dry run happens with the assessor's expectations already in the room rather than discovered at audit.