In IT infrastructure, maintaining a strict security posture and operational resilience is paramount. Every change is subject to scrutiny, security is built in layers, access controls are strictly governed, and risk appetite is usually conservative.
And yet, despite all of this, incidents can still occur.
When they do, there’s a natural tendency to look at people. Who missed the configuration? Who approved the change? Who deployed it? Who should have noticed the issue sooner?
These questions are understandable – and human – but are often the wrong place to start.
The myth of the error-free engineer
One of the most persistent assumptions in technology is that sufficiently experienced engineers should be able to avoid mistakes entirely.
In reality, this expectation is impossible.
Humans are fallible. Illness, fatigue, physical and emotional stress, context switching, expectation bias (for example – “this worked in dev, test, and pre-production”, and “Peer review didn’t highlight any concerns”), can all affect judgement. Experience can reduce the likelihood of mistakes, but can never eliminate them entirely.
Engineering is ultimately about building systems that remain safe when things go wrong. This is where guardrails come in: controls, policies, automation, and processes designed to prevent a single oversight from becoming a significant incident.
The question should never be “how do we eliminate human error?”.
The question should instead be: “How do we design systems that assume human error will occur?”
This idea isn’t new. A paper published by James Reason in the year 2000 titled “Human error: models and management“, describes these concepts.
Incidents are rarely caused by a single failure
James Reason put forward a theory that became known as the Swiss Cheese Model. The principle of the theory is that systems are like multiple layers of Swiss cheese. Each layer has holes in different places, and when the layers are stacked together, they cover one another’s weaknesses.
Organisations follow this principle by creating multiple layers of defence designed to protect the organisation in depth. Each layer is effective, but imperfect. A given layer of security has its own weaknesses, or gaps. Examples of this could be perimeter firewalls, Just-in-Time access, and policies to deny undesirable configurations – to name a few.
In most cases, the gaps don’t matter because one layer will catch the issue before harm is caused. However, it must be noted that the layers of defence themselves aren’t infallible, as the layers can line up to open up an attack trajectory.
Incidents don’t occur because a single control fails. They occur when a series of systems, controls, assumptions, processes, or safeguards all fail to intercept the problem.
Why didn’t the system catch it?
When reviewing incidents in postmortems, organisations often focus on the action that immediately preceded the event, however, when taking a wider look at the incident, a more valuable question is:
“Why was the mistake able to progress through the system?”
Consider the following layers usually present in organisations:
- Infrastructure as Code validation in deployment pipelines – highlighting misconfigurations as soon as code is run via code scanning tools, and stopping further processing if found
- Policy guardrails – platform policies such as Azure Policy or AWS Config that deny the ability to create vulnerabilities – for example:
- Disallowing enabling public access
- Disallowing public IPs on network interfaces
- Disallowing security groups with 0.0.0.0/0 or “*”
- Peer reviews and change approval processes – the Four eyes principle – where at least two people independently review the change.
If an issue reaches the environment, it’s rarely because of one specific system or individual, it’s because every opportunity to detect or prevent the issue was either missing, ineffective, or bypassed.
Building systems that expect human error
Most mature engineering organisations invest heavily in controls that reduce risk and improve detection.
Some organisations will separate the responsibility of non-prod and production environments, so two entirely distinct teams push to non-prod and prod respectively.
Or, they may invest heavily in code scanning tools, and ensure that these mechanisms will stop deployment pipelines from progressing if a vulnerability is found.
Other examples include:
- RBAC controls and Just-in-Time access to environments, along with disabling the ability to create manual changes ungoverned by Infrastructure as code.
- Automated Infrastructure as Code drift detection and resolution
- Automated policy enforcement and automatic remediation
- Mandatory n+1 peer reviews on Pull Requests
Knowledge is a control
Prevention is only half of the solution. Organisations also need effective recovery mechanisms when controls fail.
There’s a balance between prevention and recovery. No matter how many controls are put in place, some incidents will still require remediation, rollback, or recovery actions. This is where organisations often discover a hard truth: recovery knowledge tends to concentrate in the small number of engineers who have dealt with previous incidents.
While practical experience is invaluable, it introduces organisational risk – excessive reliance on tribal knowledge is a detriment. If recovery depends on a specific individual being available, resilience is lower than the organisation would like to believe.
The counter to this is effective documentation – disaster recovery runbooks, clear documentation, high and low level designs of the system, proven processes and procedures, and regular disaster recovery exercises should all be in the organisation’s operational wheelhouse.
Resilience isn’t the absence of incidents; it’s the ability to recover from them effectively regardless of who’s available.
Final thought
Human error isn’t a sign of incompetence. It’s a characteristic of every complex system operated by people. The objective of operational resilience is not perfection. The objective is to build systems that anticipate mistakes, detect them quickly, limit their impact, and recover safely when they occur.
The strongest organisations are not those that avoid every incident.
They are the organisations that assume incidents will happen and design accordingly.