Risk Register vs Exception Register vs Safety Decision Log: Which Record Should Govern High-Risk Work?

A high-risk job can have a current risk register, a signed permit, and an approved deviation while nobody can explain who accepted the remaining exposure or why the control was considered good enough. That is not a documentation problem alone. It is a governance problem.

Risk registers, exception registers, and safety decision logs answer different questions. The risk register describes what can harm people and how the operation intends to control it. The exception register records where the intended control is not available or not being followed. The safety decision log preserves the reasoning, owner, conditions, and expiry behind a consequential choice. When leaders collapse these records into one spreadsheet, the record becomes busy while accountability becomes unclear.

Why the three records should not be merged

The temptation to use one master register is understandable because teams want a single source of truth. The problem is that the three records have different time horizons and different tests of quality. A risk register should remain useful even when no deviation exists. An exception register should make temporary weakness visible rather than normalize it. A decision log should show how a leader resolved uncertainty, not merely restate the hazard.

James Reason's work on latent failures helps explain why this distinction matters. A serious event rarely begins with one visible mistake. It develops through decisions, conditions, and missing barriers that line up over time. A single merged record hides that sequence because it treats a standing risk, a temporary deviation, and a judgment call as if they were the same object.

Andreza Araujo makes a similar point in Sorte ou Capacidade, where risk is not something an operation bravely takes on. It is something leaders must calculate, reduce, and manage with method. The record system should therefore make unmanaged exposure difficult to hide.

Risk register: the record of designed exposure

A risk register answers, “What exposure exists in this operation, and what controls are supposed to keep it within the organization's tolerance?” It should describe the work or hazard, credible consequences, affected people, critical controls, control owners, verification expectations, and the conditions that would require reassessment.

The risk register is a design record. It describes the intended relationship between the hazard and the controls before the job becomes an exception. Its quality depends less on the number of rows than on whether a supervisor can connect each important exposure to a control that is observable in the field.

For a plant manager, the most useful risk-register question is not whether every hazard has a score. It is whether the highest-consequence exposures have named controls whose failure would trigger a clear response. A low numerical score does not compensate for an unowned barrier, because the score cannot perform the control.

Exception register: the record of temporary weakness

An exception register answers, “Where is the intended control unavailable, degraded, bypassed, or replaced, and what keeps that condition contained?” It should include the specific deviation, reason, affected work, compensating control, responsible manager, approval boundary, start date, expiry date, and closure evidence.

An exception is not a new risk category. It is a break in the operating design. That distinction matters because a deviation that remains open for months starts to look like the normal process, especially when the same workaround appears in several permits. The register must make duration and recurrence visible.

The strongest exception records describe the operational condition in plain language. “Guard unavailable” is weaker than “interlock is bypassed during calibration, with the access boundary controlled by a named maintenance lead and a restoration check required before production restart.” The second description gives the next reviewer something to verify.

In 100 Objeções de Segurança, Andreza frames personal protective equipment as a secondary line of defense rather than a substitute for stronger controls. The same logic applies to exceptions. A temporary administrative instruction may contain exposure for a defined window, but it does not restore the engineered or organizational control that was supposed to make the work safe.

Safety decision log: the record of judgment

A safety decision log answers, “What consequential decision was made, by whom, with what evidence, under which constraints, and until when?” It is useful when leaders approve a restart, accept residual exposure, defer a capital fix, change a control owner, or decide that an incident requires escalation.

The decision log should not duplicate the entire risk register. It should capture the decision that changes how the risk is governed. A concise entry names the decision, alternatives considered, evidence available, unresolved uncertainty, approving authority, conditions, review date, and the signal that would reverse the decision.

This record is particularly important when the decision appears reasonable at the time but is questioned after an event. On Headline Podcast conversations, Dr. Thomas Krause has described how serious-event analysis can make an employee's action look obviously wrong until the earlier management decisions that shaped the conditions are examined. A decision log preserves that earlier context, which helps an investigation examine the system without erasing individual responsibility.

Which record should lead in each situation?

The right record depends on the decision a leader is trying to make. If the question concerns the normal design of work, start with the risk register. If the question concerns a control that is not currently available, start with the exception register. If the question concerns a judgment under uncertainty or competing business pressures, start with the decision log.

How executives should compare the three systems

Executives should evaluate the records against five dimensions. First, they should ask whether the record identifies a person who can change the condition. Second, they should ask whether the record has a clear expiry or review trigger. Third, they should ask whether the evidence can be checked in the work area. Fourth, they should ask whether repeated entries are converted into a design or investment decision. Finally, they should ask whether the record would help an investigator reconstruct the decisions that preceded an event.

A risk register performs well when it exposes critical control dependence. An exception register performs well when it shortens the life of deviations. A decision log performs well when it makes uncertainty and tradeoffs discussable before the next event. None of them is a substitute for field verification, because a clean record can coexist with a failed control.

What usually goes wrong in implementation

The first trap is using the risk register as a storage cabinet for every concern. When routine observations, temporary deviations, and strategic decisions all sit in one list, leaders cannot see which items require immediate containment.

The second trap is closing exceptions administratively. A signature, email, or revised procedure does not prove that the original control was restored. Closure should show the physical, technical, or organizational change that removed the exception.

The third trap is logging decisions without recording the uncertainty that shaped them. A decision that appears obvious after the fact may have involved incomplete evidence, schedule pressure, or conflicting signals. Recording those conditions does not excuse a weak decision. It makes the review more honest.

The fourth trap is assigning every owner to EHS. EHS can set the governance standard and challenge evidence, while the line function must own the control it operates. That separation is essential if the record is meant to change work rather than document advice.

A practical governance model for a monthly review

A monthly review can use the three records without creating three disconnected meetings. Start with the risk register and identify the highest-consequence exposures whose controls lack recent evidence. Move to the exception register and identify deviations that are aging, recurring, or spreading to other work. Finish with the decision log and review approvals whose conditions are expiring or whose assumptions have changed.

The review should produce decisions, not a longer list. One decision may restore an engineered control. Another may stop work until evidence is available. A third may assign capital or maintenance resources. The meeting is successful when the next review contains fewer unresolved exceptions and clearer ownership, not when every row has a green status.

On Headline Podcast, Michael Emery has emphasized that the department running the work must own the practical fix, because agreement from a safety specialist does not make a control durable. That principle gives the review a useful test. If the action cannot be carried by the operation that owns the task, it is probably still an observation or recommendation rather than a control decision.

The decision rule leaders can use tomorrow

Use the risk register to describe the exposure you intend to control. Use the exception register to contain the control you do not currently have. Use the safety decision log to preserve the judgment that changes the risk posture. When an item moves from one record to another, keep the link between them so the organization can see the original design, the deviation, and the decision that followed.

That structure gives leaders a more honest view of high-risk work. It also protects the frontline from a familiar failure mode in which a temporary workaround becomes permanent because nobody owns the return to the intended design.