Assurance reviews, exceptions, and change

Review the claim being made

Before starting a review, define the review question, the exact system and release scope, the criteria being assessed, the required level of independence, the evidence period covered, the methods and sampling used, known limitations, and who holds final decision authority. A design review, a security test, an operational readiness review, and a regulatory audit answer different questions — naming which one is happening prevents a narrow review from being read as broader assurance than it provides.

Exceptions

An exception is a deliberate, time-bound decision to proceed despite an unmet control objective. Record the unmet requirement, the affected scope and versions, the rationale, the accepted risk, compensating controls, monitoring during the exception window, the accountable owner, the approver, start and expiry dates, and the criteria that will close it.

Treat expiry as a hard stop: an expired exception should block continued reliance on the associated control unless it is explicitly reviewed and renewed by the same authority that granted it. An exception with no expiry is a permanent, unreviewed risk acceptance wearing a temporary label.

Material change

Define triggers that force reassessment before existing evidence can be treated as still valid: changes to the model, prompt, corpus, policy, identity model, tool registry, runtime, infrastructure, supplier, intended purpose, user population, operating geography, or a new incident, finding, or performance regression. Use impact analysis (see Controlled change and versioning) to decide which specific controls and evidence require renewal rather than re-running the entire assurance package for every change.

Independent challenge

A reviewer must be able to trace every claim back to its original evidence, inspect excluded or failed cases rather than only passing summaries, test a sample directly, and disagree with a proposed release without organizational pressure to approve it. Independence is as much organizational — reporting lines, incentives, and the authority to block a release — as it is technical.

Continuous assurance

Operational signals from Observability and operational evidence do not replace periodic or event-driven review; they provide ongoing evidence that approved properties continue to hold in production and early warning when an assumption has changed. Feed incidents, exceptions, drift, and control failures back into the system passport and the next release decision rather than treating them as separate from the assurance record.