Review, Audit, Assessment: Who Checks the Safety Work?

Three invitations land in a project calendar in the same quarter: a confirmation review, a functional safety audit and a functional safety assessment. Many teams read them as three sizes of the same thing, a small review, a bigger review and a very big review, and prepare for all three by polishing documents. That misreads what each one is for.

ISO 26262-2:2018, Clause 6.4 groups the three as confirmation measures, and they differ in what they look at and in the question they answer. The review's subject is a single work product, the audit's subject is how the work gets done, and the assessment's subject is the item as a whole. One small change in a real project shows the difference better than any definition.

The example

A supplier develops the battery management system for an electric car. Take the highest ASIL among its safety requirements as ASIL C. One safety goal is about overcharge: a lithium-ion cell pushed past its voltage limit can go into thermal runaway. The technical safety concept answers it with a cell monitoring chip that measures every cell, and a rule that the BMS opens the main contactors when any cell crosses 4.25 V.

The review: is this work product convincing evidence?

The technical safety concept is one of the work products ISO 26262 lists for a confirmation review. The reviewer does not retest the design. The question is whether version 2.1, as written, gives sufficient and convincing evidence that it contributes what it should to functional safety, measured against what the standard expects a technical safety concept to achieve. Here the reviewer finds two minor gaps, the authors close them, and the review passes.

A confirmation review is easy to mix up with the verification review the engineering team runs anyway. Verification asks whether the concept meets the project's own requirements. The confirmation review asks whether it meets the standard's objectives. The two can be held as one meeting if the reviewer is independent enough, but they answer different questions. The report names the revision it examined, and that detail matters a few months later.

The audit: is the work done the way the plan says?

During hardware and software development, the vehicle team asks for more usable range. Change request CR-14 raises the cell limit to 4.30 V. The software team implements it and updates the safety concept to version 2.3. Nobody runs an impact analysis, and nobody asks for the review to be repeated, even though a change to a reviewed item means its confirmation measures have to be repeated or extended.

The auditor does not decide whether 4.30 V is safe. That is not the audit's question. The auditor reads the safety plan, sees how change management is supposed to work, samples several change requests, and finds that two steps of the defined process were skipped for CR-14. The report records the gap and recommends a fix, here a gate in the change tool that blocks implementation until the impact analysis exists. This is why an early audit is worth more than a late one: it finds a broken process while there is still time for the process to catch something.

The assessment: is the item functionally safe?

The assessment has the widest object. It is planned early, carried out progressively as the project moves, and finished before release. The assessor works through the safety plan and what it required, how the processes ran, whether the safety measures actually work, the safety case, and what the reviews and the audit found. On that basis the report recommends one of three outcomes: acceptance, conditional acceptance with named conditions, or rejection.

For our BMS, the assessor sees a reviewed concept that is no longer the one in the product and an audit finding that explains why. The recommendation is conditional acceptance: repeat the review on version 2.3, and show with cell data that 4.30 V still leaves enough margin to open the contactors before the cell reaches an unsafe state.

The assessor recommends. The release for production is approved by the person responsible for release, on the evidence available: the confirmation reports and the safety case. Treating the assessment report as the release itself, or the assessor as the one who signs it, is a quiet way to blur who owns the decision.

Three questions, kept apart

Seen through the BMS, each measure caught something the others could not. The review was right about the document it saw. Only the audit could explain why the document in the product was a different one. Only the assessment could weigh the two findings and say what had to happen before release. The audit and the assessment come into play when the item's highest ASIL is B or above, and the independence each measure needs grows with the ASIL.

The Confirmation Measures concept page covers the independence each measure needs for every ASIL and work product, how to plan the measures inside the safety plan, review techniques, audit and assessment checklist categories, tool qualification, the documentation a record needs, and the best practices and pitfalls that decide whether the measures find anything.