A barrier can have different states in an incident, mostly divided into four types: 1) Missing barriers 2) Failed barriers 3) Inadequate barriers and 4) Effective barriers. There are considerable differences in interpretation of these states, and when one or the other should be used. Here I'd like to give another interpretation, because the existing definitions don't really work for me.

Missing barrier

For me, a barrier is missing if it has never been fully implemented. For instance, a fire extinguisher that was specified in a standard, but never acquired. Implementing a barrier is a long process. It requires identifying the need for it, specifying it, acquiring it, installing it and activating it. If this process breaks down anywhere before the barrier is activated, I call it a missing barrier.

Most people can see the logic in this definition. However, before you accept it, think about the most extreme example. If I install a smoke detector, but forget to turn it on, I would call it a missing barrier because it has never been fully implemented. Even though it is physically present, the implementation failed at the last moment. This can be difficult for people to accept, because if a barrier is physically present, it's difficult to see it as 'missing'. But it is consistent. We can also ask the question: 'Could this barrier at one point have performed according to its specification?'. If the answer is no, it's a missing barrier.

If a barrier was never identified as necessary in the first place (when it should have been because it was an industry best practice for instance), I don't call it a missing barrier. It's not useful in an incident analysis to include barriers that were never identified in the organisation at all. Those things should be turned into recommendations.

Failed barrier

Most barriers in an incident analysis will be failed barriers. These barriers are correctly implemented at some point, and then for whatever reason stop performing their function. This can be because the barrier is removed, is turned off, breaks when challenged or is broken continuously. If the barrier isn't missing, we can ask: 'Has this barrier worked according to it's specification?'. If the answer is no, the barrier has failed.

Inadequate barrier

There are also barriers that work according to their specification, but do not stop the incident from progressing. They might have no effect or a minor effect. These barriers are classified as inadequate. A barrier can be inadequate for various reasons. It can be specified but designed incorrectly (it will perform its intended function, but will be insufficient for the scenario). It can be designed within certain design limits and fail because of extreme circumstances. It can also be designed correctly but still fail because the context within which it operates changes. This can happen if management of change isn't done correctly.

It is difficult to predict when a barrier will be inadequate, because it depends on the circumstances. A barrier can be adequate for one scenario, and completely inadequate for another. We can ask the question: 'Has this barrier worked according to its specification, and stopped the incident?' If the answer is no, the barrier is inadequate.

Effective barrier

Effective barriers are easier. These are the reason an incident doesn't escalate further. We can ask the same question we asked for inadequate barriers: 'Has this barrier worked according to its specification, and stopped the incident?' If the answer is yes, the barrier is effective in these particular circumstances. If multiple barriers are required to stop an incident, I would classify all of them as effective, even if any single barrier wouldn't have stopped it on its own.

Why this is better

So why would this interpretation be better? First, I just find these classification rules easier to work with than others I've come across. Second, we actually get some meaning from categorising our barriers like this. It allows us to count how many missing barriers we have, and use that as a quality measure of our implementation process. We can count failed barriers, and use it as an indication of how our barriers perform in operations. We can count inadequate barriers, and use it as a measure of our design process (both initial design and within change management), and finally we can count effective barriers and make sure they keep working, because they're apparently the only ones that work.