Bow‑tie Safety Barrier Management: How to Keep Records

Why keep a register of hazards and barriers at all

When there is no single registry, hazards and protections spread across different files: one spreadsheet with an engineer, another with a supervisor, a third in email. Versions get lost, checks are missed, and problems appear only after an incident or audit. The worst part is that no one can clearly answer: what exactly should have acted and why it didn't.

Safety barriers are not "general HSE measures" like a briefing or a wall poster. A barrier is a specific protection that must interrupt the scenario. It can be technical (guarding, interlocks, ventilation), organizational (permits, two‑person rule) or behavioral (mandatory checklist). A barrier has an owner, a clear operability criterion and regular checks.

A site manager almost never needs "ten files." He needs one simple answer for his area: where is the risk rising right now. On a shop floor this is obvious in everyday examples. There is an operation lifting heavy equipment. The barrier is a working lifting device and a pre‑shift inspection. If the inspection is overdue, the "dropped load" scenario becomes noticeably closer, even if "measures are in place" overall.

A proper barrier register answers several basic questions: what can happen (hazard and scenario) and exactly where; what barriers prevent or mitigate it; which checks and evidence confirm operability; what is overdue or failed, who is responsible and by when it must be fixed.

When these answers are in one place, guessing disappears. Discipline appears: you can see which barriers actually work, which exist only "on paper", and what must be done today to avoid an event tomorrow.

Bow‑tie in simple terms: what the diagram contains

Bow‑tie is a simple way to lay out risk: what can go wrong, how we hold it back, and what happens if it does.

At the centre of the diagram is the hazard. This is not an "incident" but a source of potential harm. Example: a site stores flammable liquids. They are not an accident by themselves, but they create fire potential.

To the left of the hazard are threats (causes) that can lead to the key event (for example, ignition). To the right are consequences, i.e. what will happen if the event occurs.

Where barriers live in the Bow‑tie

Barriers are divided into two types.

Preventive (left) prevent a threat from causing the event. For example: intact grounding, control of ignition sources, storage procedures.

Mitigating (right) reduce harm after the event. For example: automatic fire suppression, training on fire response, evacuation routes.

The point of the diagram is that barriers are tied to a specific threat or consequence, not to a vague "risk". Management becomes practical: you can see exactly which barrier covers what.

Why a barrier "weakens": degradation factors

Even a good barrier can stop working. Bow‑tie highlights degradation factors — reasons a barrier loses effectiveness. Simple example: there is a fire extinguisher, but the seal is broken, the inspection is overdue, it is not at its designated location, or people do not know how to use it.

A useful practice: for each barrier answer two questions in advance:

• What can degrade the barrier? (degradation)
• How will we notice it in time? (control, check, alarm)

Bow‑tie helps to avoid confusing causes and consequences: left is always "why it happened", right is "what comes next". This reduces arguments during investigations and clarifies requirements for checks and owners.

How to store hazards and scenarios: minimum data set

For Bow‑tie to work in real life, hazards and scenarios must be stored as simple records that are easy to find, update and pull into a report for a particular site. The main rule: minimal fields, but each must support a decision.

A hazard card answers where the source is and who is responsible. If a card is not tied to a location and an owner, it quickly becomes an "abstract hazard" and does not help manage risk.

A minimal hazard card could include:

• Object and process (e.g. "paint shop", "solvent storage")
• Boundaries (what is in scope and what is out, to avoid disputes during checks)
• Site and area (for addressable reports and tasks)
• Owner (position / name who receives notifications)
• Date of last review and next review

A scenario links a hazard to how things can go wrong. In Bow‑tie it's convenient to store a scenario as the chain "threat — unwanted event — consequences". Later you can easily link barriers and checks to the unwanted event.

For a scenario record store:

• Threat (what triggers the situation, e.g. "error during pumping")
• Unwanted event (what happens, e.g. "spill of flammable liquids")
• Consequences in four aspects: people, assets, environment, production
• Location (same site/area as the hazard card)
• Conditions when the scenario is realistic (when, how often, during which operations)

You don't need complex scales for consequences. Often three levels suffice: "minor", "serious", "critical" — separately for people, assets, environment and production. For example, for the "spill" scenario people might be "serious" (burns/poisoning), production "critical" (line stop).

If records are kept this way, a site manager can open the registry, see only their hazards and scenarios, and quickly navigate to related barriers, checks and overdue items without unnecessary detail.

How to describe barriers so they can be managed

Barriers are often recorded with broad phrases: "personnel training", "guarding", "instruction". The problem is such descriptions can't be managed: it's unclear what must be in place, who owns it and how to check. Better to treat each barrier as a separate card with clear fields.

Barrier card: the minimum without which the registry collapses

Start with the barrier's purpose (what it should prevent or mitigate) and type. Keep type in three categories: technical (equipment, automation, interlocks), organizational (procedures, permits, planning), behavioral (people's actions relying on discipline and skills). This helps immediately understand how to check: measurement, document or observation.

Next you need an operability criterion. Not "guarding is installed" but a checkable condition: "guarding covers the zone, fixings intact, no gaps greater than X mm, door locked, key with the supervisor." For behavioral barriers the criterion should also be observable: "before starting the machine the operator completes a 5‑point checklist and signs the log."

Separate roles. The barrier owner ensures the barrier exists, is fit and has resources (order repair, update instruction, arrange training). The check owner carries out regular control and records the result. In small sites these can be the same person, but roles should still be specified so responsibility isn't lost during shift changes.

Criticality and Bow‑tie links

To highlight key barriers without complex math, use a simple A/B/C scale:

• A — if this barrier fails, risk rises sharply immediately (no second layer or severe consequences)
• B — there is redundancy or time to react
• C — supporting barrier

This is enough for prioritising checks and responses to overdue items.

The most important thing is links. The card must state which Bow‑tie scenario the barrier belongs to and which part of the chain it covers: prevents the cause (left) or mitigates consequences (right). Example: scenario "server overheat leads to service outage". Prevention barrier — "temperature sensor with alarm at threshold"; mitigation barrier — "power redundancy and failover procedure". When links are filled, you immediately see which scenario lacks protection and which checks matter.

Barrier checks: schedule, results and evidence

A barrier is "alive" only while you can show it works. Therefore each barrier needs a clear check schedule and a unified result format. This is the basis of management, not mere "ticks" in a log.

Types of checks and how not to confuse them

The check type depends on the barrier. One may need only a visual inspection, another testing or calibration. Predefine acceptable check types for each barrier so executors don't choose "as they are used to."

Common types:

• inspection (is the barrier physically present, any damage, seals, markings)
• functional test (does the device or procedure work in practice)
• calibration (measurements, setpoints, sensors within norm)
• procedure audit (rule is followed and remains relevant)
• drill/training (people readiness to act to the scenario)

Frequency and the "grace" window before overdue

Store frequency as a number (e.g. "every 30 days") so the system calculates the next check date. Set a tolerance window for when the check can still be done without an "overdue" status. Example: frequency 30 days, window 5 days. The barrier becomes "near overdue" on day 31 and "overdue" on day 36.

What to keep as evidence

Reporting fails if a record lacks minimal evidence. Even without attachments, the record should be self‑contained.

Minimum fields per check:

• date and time performed (and planned date to see deviation)
• executor (name/role/contractor)
• result status: done, done with remarks, not done
• comment: what exactly was checked and what was found
• evidence: report number, photo, test protocol, scan, file (if any)

If result is "done with remarks", record whether the remark affects barrier operability. Otherwise the site manager cannot judge if it's cosmetic or a risk increase.

How to separate "check" and "repair" so reports don't confuse them

A check answers "does the barrier work now?" A repair or corrective action answers "what are we doing to restore or improve it?" They are different entities.

Practical rule: one check record — one final status. If a problem is found, create a separate task for repair/correction with an owner and due date, and put the task ID in the check record (e.g. work order number). Then the "overdue checks" report shows control discipline, and the corrective actions report shows remediation discipline.

How to implement Bow‑tie and barrier registry: step‑by‑step plan

Start small. The main mistake is trying to describe all the company's hazards at once. For a pilot pick one area and 1–2 most critical hazards where risk is clear and protections already exist.

Good pilot choices: handling flammable liquids in a warehouse or maintenance of rotating equipment in a repair area. There you usually have technical protections, procedures and training — things you can turn into manageable barriers.

Five practical steps

1. Pick a pilot priority. Choose a risk that is not the rarest or most abstract, but one where incidents or near‑misses have happened and the site manager is willing to participate.

2. Collect real scenarios and current measures. Don't start with the "ideal diagram." Pull existing instructions, permits, maintenance rules, patrol routes and logs. From these, identify causes (what triggers the event), consequences (what can happen) and what already stands between them.

3. Assign barrier owners and operability criteria. Each barrier must have one responsible (a role, not just a name) and a clear answer to: how do we know the barrier works? Example: "guarding is in place and secured", "gas detector passed calibration", "operator trained and authorised". If a criterion cannot be checked, it's not a barrier but a wish.

4. Set up a check calendar and a simple recording form. For each barrier set frequency (shift, week, month), who checks and what evidence is required (photo, report number, log mark, test result). Start with the minimum: date, status (ok/not ok/not checked), comment, evidence.

5. Start regular review of overdues and failures, then expand coverage. A short weekly meeting at the area beats a pretty dashboard. In the review act on practical items: which checks are overdue, which barriers are unfit, who will restore them and by when, and what temporary measures are needed until the barrier is fixed.

When the pilot works (there is checking discipline and clear actions for deviations), scale up: add the next hazard and area. Add automation after rules are simple and uniform across shifts.

Barrier failure as an event: how to record and investigate

Record a barrier failure as a separate event, not as a note in a log. This shows which protections actually work and which only exist on paper. For barrier management this is one of the most valuable data sources.

Agree first on terms. "Barrier did not act" and "barrier not inspected" are different. If a check is overdue you don't know if the barrier would work, but a failure is when the barrier should have acted in a real situation (or test) and did not.

What to record in a failure event

The event card should be short but unambiguous. Minimum set:

• barrier identifier (name and type, e.g. "gas detector, alarm and shutdown") and related Bow‑tie scenario
• date and time, location (area, unit, room), shift
• description: what happened and when it became clear the barrier failed
• consequences (if any): shutdown, leak, injury, quality deviation, "no consequences"
• detection source: incident, test, audit, patrol, system alarm

Short example: during compressor start an alarm triggered on gas level, but automatic shutdown did not occur. The operator stopped it manually, no consequences. This is a failure of the "auto‑shutdown" barrier, even though the detector and siren worked.

How to analyse cause and what to do next

When analysing cause don't start by hunting for who is to blame. Choose one primary category and, if needed, a secondary one: human factor (error, fatigue, training), technical condition (fault, calibration, wear), procedure (unclear step, missing), external conditions (temperature, dust, vibration, power).

After classification the event should lead to corrective actions. Often four fields suffice: who is responsible, what to do, due date, status. Add an "effectiveness check" (how we will ensure this doesn't repeat) in one short sentence.

Then use failure statistics to improve management. If a barrier fails more often than expected, increase check frequency, tighten acceptance criteria (what counts as "works"), review spare parts and training. If failures are rare but checks are regularly overdue, it's a sign the schedule is unrealistic or responsibility is diffused.

Example "overdue barriers" report for a site manager

Such a report should let a manager understand in 2–3 minutes where on the site risk rose because protections were not checked on time and who to assign tasks to. It contains only facts: which barrier is overdue, how long, how important it is and what has been done.

Below is a sample structure. In a real system rows are typically built from the Bow‑tie: hazard -> scenario -> barrier -> check.

Summary (week, your area): total barriers: 128; overdue: 9; overdue critical: 3; new overdues this week: 4.

Make the report filterable and grouped, not full of long comments. Typical sorts: by criticality (High first), by owner (see who accumulates overdues), by area and by barrier type (technical, organizational, behavioral).

A good header rule: if any High overdue is more than 7 days, it should go to daily control and action status cannot be "not assigned."

Common mistakes that make a registry fail

The main reason is simple: the registry is built "for reporting", not for day‑to‑day decisions. It becomes a table no one trusts or uses.

Most common mistake — trying to build the perfect model with dozens of fields. People spend time filling forms instead of focusing on meaning: what hazard, which scenario, which barrier, when to check and what counts as a failure. Better start with a usable minimum and add only what is actually used.

Second pain point — no barrier owner. If a barrier has no concrete responsible (position and name), overdues become "nobody's." Practically this looks like a supervisor seeing an overdue extinguisher or interlock, but the system has no one assigned to close the action and confirm restoration.

Third mistake — vague operability criteria. Entries like "ok" don't help if it's unclear how that was checked. Each barrier needs a short, testable sign: what exactly is checked, what result is acceptable, and what evidence is recorded (photo, report number, reading, log mark).

Fourth mistake — mixing checks, repairs and incidents in one status. A check answers "is the barrier working now?" Repair — "what was done to restore it?" Incident or barrier failure — "what went wrong and what could it lead to?" If all are in one "status" column, deadlines, causes and responsibility get lost.

Another typical problem — monthly reports. In a month overdues become normal and the manager sees the problem too late. Prefer short weekly (and daily for critical barriers) overviews of overdues.

Signs the system is already "sinking":

• checks are back‑dated without evidence
• the same barriers are always in overdues but no one is assigned
• fields are filled inconsistently because there are no rules
• green status exists but it's unclear what was actually checked
• incidents are hidden inside "repairs" and not analysed

To quickly revive the registry start with basics: assign owners, cut the card to a minimum, make check criteria clear, separate event types and enable frequent overdue reports for area managers.

Quick checklist and next steps

To avoid the registry becoming a "table for the sake of a table", verify basic conditions. If any element is missing, the barrier is almost impossible to manage.

5‑minute checklist

Answer yes/no for each barrier:

• owner assigned (role or name) and it's clear who decides on overdue actions
• operability criterion exists (what "barrier works" means and how to see it)
• next check date (or frequency) set and data source clear
• current status available (ok, overdue, unavailable, under repair) and reason if not ok
• one record per barrier and one result per check (no duplicates or aggregated rows)

If many records lack an owner or next check date, start fixing those first. That brings order fastest.

Minimum rhythm that keeps the system alive

A simple routine works: a short weekly overdue review and immediate investigation of failures. For example, the area foreman checks overdue items for 10 minutes every Monday and assigns actions; when a barrier "fails" they record the event and run an investigation without waiting until month end.

How to start small and not drown

Run a pilot on one area with 10–20 key barriers that truly affect risk. In 2–3 weeks you'll see where data are missing, who is overloaded with checks and which criteria need refinement.

Next steps: choose a registry platform (at least a single register and checks log), assign owners and update rules. If deploying organization‑wide, plan infrastructure and support: reliable servers and workstations, backups, shift access, 24/7 support. Sometimes it's easier to engage an experienced systems integrator. For example, GSE.kz (gse.kz) does system integration and data‑centre infrastructure, and manufactures servers and workstations in Kazakhstan, which is convenient for projects requiring local hosting and long‑term support.