How to Test Whether a Safety Rule Works at the Point of Work in 10 Days

A safety rule can be technically correct and still fail at the point of work. The fastest way to find out is not another document review. It is a short field test that shows whether people can understand the rule, apply it under real conditions, and stop when the rule no longer protects them.

This ten-day method helps an EHS manager, site leader, or frontline supervisor test one important rule without turning the exercise into a compliance campaign. The result is a decision-ready record that shows what the rule controls, where it breaks, and what must change before the organization asks people to rely on it again.

What you need before starting

Choose one rule that affects a meaningful exposure, such as isolation, vehicle-pedestrian separation, confined-space entry, line breaking, or work at height. Avoid choosing a rule only because it is easy to audit. The purpose is to test whether the rule performs a protective function when production, maintenance, weather, staffing, or contractor conditions make the work less predictable.

Bring the current rule, the related risk assessment, one recent field observation, and the name of the person who owns the rule. Include the supervisor and at least one person who must use it. ISO 45001:2018 expects operational controls to be planned and maintained, while the field test checks whether that expectation is visible in the work itself.

Step 1: State the exposure the rule is meant to control

Write one sentence that describes the exposure in operational terms. Name the task, the source of harm, the people who may be exposed, and the condition that makes the event possible. “Prevent accidents” is too broad to test. “Prevent stored pressure from reaching the person opening the line” gives the team something observable.

Ask the rule owner what changes the exposure. The answer may include a night shift, a temporary layout, unfamiliar contractors, a blocked access route, a production restart, or a communication failure. Record those conditions because a rule that works only in the ideal scenario is not a dependable control.

Step 2: Translate the rule into a protective action

Separate the written instruction from the action that should reduce exposure. “Complete the checklist” describes paperwork. “Confirm the correct isolation point, test for zero energy, and keep the boundary identified until the task is complete” describes protection.

Ask what the worker must see, do, or decide. If the answer contains only verbs such as attend, sign, review, or acknowledge, the rule may be measuring participation rather than control. Andreza Araujo makes this distinction central to her work on safety culture because compliance can look strong while the operating decision remains weak.

Step 3: Watch the rule being used in normal work

Observe the rule during a task that the team considers routine. Do not announce every detail of the test in advance, because the goal is to see how the rule fits the work rather than how people perform during an inspection.

Record the sequence without judging it too early. Note where the rule appears, who introduces it, what information the user needs, which steps are skipped or reordered, and where the task pauses. A deviation is evidence about the design of the rule. It is not automatically evidence of poor intent or poor character.

Step 4: Ask the user to explain the rule in their own words

After the observation, ask the person who used the rule to explain what it was meant to prevent and what would make it unsafe to continue. Listen for the decision boundary. The user should be able to describe the condition that requires a pause, escalation, or change in plan.

Use open questions such as, “What were you checking here?” and “What would have made you stop?” Avoid asking whether the person understood the rule, because a yes answer reveals very little. A person may understand the words while missing the control logic.

Step 5: Test the rule against a changed condition

Introduce one realistic change that the work could face, such as a late crew member, a missing tool, a changed access route, a different material, or a failed communication channel. Do not create an unsafe condition. Ask the team how the rule should be applied now.

This step reveals whether the rule guides judgment or only describes a fixed sequence. A usable rule identifies what remains non-negotiable, who can authorize an adaptation, and when the task must stop until a higher-level decision is made. James Reason's distinction between active and latent failures is useful here because a predictable field difficulty can expose a weakness in the surrounding system, not only a mistake by the person at the task.

Step 6: Check the handoffs that make the rule work

Map the handoffs between operations, maintenance, contractors, supervision, and EHS. For each handoff, record what information must transfer, who confirms it, and what happens when the confirmation is missing.

Many rules fail between roles rather than within a single action. Operations may release equipment while maintenance still believes the boundary is provisional. A contractor may receive the instruction without receiving authority to stop. A supervisor may assume that a form proves the field condition was checked. These are design gaps that a field test should make visible.

Step 7: Define the evidence that proves the rule worked

Choose evidence that matches the protective action. A signature can confirm participation, but it cannot prove that an isolation was effective. A training record can confirm attendance, but it cannot prove that a person can recognize a changed condition.

Use a small evidence set that the line organization can repeat. It may include a field observation, a functional check, a demonstrated task, a clear stop decision, and a record of the issue that was corrected. The evidence should answer one question, namely whether the rule reduced uncertainty at the point where people had to decide.

Step 8: Repair the rule with the people who use it

Bring the observed users and the rule owner together to review the gaps. Ask which wording is unclear, which step does not fit the sequence, which resource is missing, and which decision is being pushed to the wrong role.

Rewrite only what the evidence supports. Add a visual cue when the problem is recognition, clarify an authority boundary when the problem is escalation, change the sequence when the problem is workflow, and redesign the control when the rule depends on memory in a high-pressure task. A longer rule is not automatically a stronger one.

Step 9: Run a second field check

Use the revised rule in a comparable task and observe the same points. The second check should show whether the wording, sequence, handoff, or resource changed the decision in practice.

Do not declare success because the new version received approval. Compare the first and second observations. Look for clearer ownership, fewer improvised steps, faster recognition of the stop condition, and better evidence that the critical action occurred. If the same failure remains, the rule may be compensating for a design or equipment problem that belongs elsewhere.

Step 10: Decide whether to keep, change, or retire the rule

Close the ten-day test with one explicit decision. Keep the rule when it controls the stated exposure, fits the work, and gives people a reliable response to changed conditions. Change it when the protective intent is sound but the wording, sequence, handoff, or evidence is weak. Retire or replace it when the rule cannot control the exposure without depending on unrealistic behavior.

Assign an owner, a review trigger, and a date for the next verification. The trigger should include meaningful changes such as new equipment, a process redesign, a serious incident, repeated deviations, or a contractor interface that changes the work. In more than 250 cultural transformation projects, Andreza Araujo's practical lesson is consistent: a rule becomes part of culture only when operating decisions repeatedly confirm that it matters.

Field-test checklist

• The exposure is described in operational terms.
• The rule is linked to a protective action rather than a paperwork activity.
• A real user can explain the control and the stop condition.
• One realistic changed condition has been tested safely.
• Handoffs, authority, and missing confirmations are visible.
• Evidence proves the control was present and usable.
• The revised rule has been checked in comparable work.
• An owner, trigger, and review date are recorded.

A field test does more than identify whether people followed a rule. It shows whether the organization gave them a rule that can carry the exposure, the workflow, and the decision pressure present in real work. That is the point at which written intent becomes a reliable safety control.