Pendulum Effect on Design: Security Overkill

The Pendulum Effect on Design: Security Overkill

In the years before 2001, it was possible to ask if the captain of an airplane would permit you to go ‘upfront’ to the cockpit. But after 9/11, that changed. Airport and aircraft security received greater emphasis. Measures described in this account include X‐ray screening of bags, restrictions on liquids above 100 ml, closed cockpits with no passengers allowed and other measures ‘behind the scenes’. I am sure many changes in the design of airport security measures have helped reduce the likelihood of passengers planting a bomb or hijacking an aircraft. That said, this has been at the expense of a huge amount of time, cost and disruption, often borne by the mostly innocent travelling public.

If we turn our attention to online security, we regularly see software upgrades that contain ‘critical security’ updates for the computers and systems we use. We must also type in passwords to access our online data and information, with instructions and guidance about secure passwords.

However, the more safeguards you put in place to secure buildings and IT systems, etc., the harder it can be for legitimate users to gain access. A rigorous design for security can therefore create a spin‐off problem where we need to have password recovery protocols and ‘workarounds’ (e.g. if we forget our password, we might have it written down somewhere).

It's the same with security passes for office buildings. In theory, staff are supposed to show their access pass each time they go in and out of a building; but suppose they forget their pass on some occasions. In that case, they might be ‘waved through’ by security staff because they know the person (but strictly, they shouldn't do this because the person concerned may have just left ‘under a cloud’).

Bruce Schneier highlighted the challenge of getting the right mindset towards security measures in his book ‘Beyond Fear: Thinking Sensibly About Security in an Uncertain World’. He argues that the design of security measures after terrible events such as 9/11 can easily turn into overkill and, paradoxically, create gaps elsewhere.

Sandeep Das (Head of Internal Audit, St John Ambulance) offers his perspective on being on the receiving end of a significant regulatory and compliance burden:

‘For some organisations I have come across in the past, where resources are plentiful, it is easy for them to over‐engineer new processes and procedures, especially when a new regulation is launched. And then, after a few years, it becomes clear that the new measures are so burdensome that they are either a tick box, where no one really knows what the checks and signoffs are for, or they become subject to workarounds or exceptions.

Over time, attitudes towards compliance shift, and a new “status quo” may evolve. However, if this is done as part of a managed process, then a new “real‐world” process design can be established where there is still discipline and a sense of minimum standards but where “theatre” and overload are avoided.

But if shortcuts occur, without any “stock‐take”, there can be inconsistency in what an organisation does and – worst of all – an absence of control in some areas because “nothing bad has happened”. Of course, when an issue does “blow up”, everyone asks, “How did that happen?” when it was an open secret that standards had declined over time.’

While there will inevitably be new regulations, processes, etc., after a crisis, it is essential to recognise they can act as a heavy weight on day‐to‐day operations. Amilcar Zambrano (Global Practice Lead of Inspections and Root Cause Analysis, DNV Energy Systems) explains:

‘Regulators have a difficult job. Something terrible happens, and they want to create a solid framework that will guarantee the same or similar problems won't occur again. But if they are not careful, it's easy for regulators, or policy owners, to underestimate or misunderstand the practical human dimension.

If you over‐design things, the operators who must implement these requirements pick up that what is being asked of them is unrealistic. This may create scepticism and either a degree of resistance or a sense of needing to “go through the motions”.

This matters because regulations and procedures are often written for a point in time, but this can fall behind good practice as it evolves. This is a dangerous combination because if things are designed so that operators go on “auto pilot” and stop thinking about risks, you have a greater chance of problems.’

A Human Factors expert (who wishes to remain anonymous), working with High‐Reliability Organisations, offers their perspective on how to design things appropriately:

‘When I work with clients who want to implement a new process or way of working, I will often ask that we ground any discussion about what is wanted in the future upon two key pillars. First, what, in practice, are staff at the operational level currently doing? What can we learn from their experiences? It requires us to watch what's happening in detail and engage with users on what they think about what they are doing. Second, if new ways of working are envisaged, what exactly does it mean practically? This is the “task analysis” phase. It's crucial because it's where “the rubber hits the road”, and it is where errors and mistakes can happen at the design stage, detached from the reality of those who do the work, day in and day out.

This is where user groups and operator groups are so important. My goal with clients is to understand and then help to engineer out any potential practical problem areas from the beginning and provide the functionality that users need and expect.

A policy, procedure, new system or new building, or piece of equipment may look good on the surface, but the most critical question to ask is, “Will it work? Is it practical? Will operators see an improvement?”.’

I cannot stress enough how often what appear to be good designs on paper can turn out to be a root cause of problems because they underestimate the human side of what is needed to make them work in practice. Aviation offers an example: during critical tasks, pilots use checklists covering key actions rather than consulting 40‐page policies. Likewise, in the healthcare sector, protocols and checklists are regularly used for life‐and‐death situations.