The 5 Whys turns Major Incidents into opportunities to learn, reduce recurrence and strengthen operational resilience.
The 5 Whys technique is a valuable tool in Major Incident Management.
It helps teams cut through surface-level symptoms and uncover the deeper issues that cause recurring incidents and problems in IT environments.
By integrating the 5 Whys into the incident response process, Major Incident Managers can support more effective resolution, stronger post-incident reviews and better long-term outcomes.
Used well, the 5 Whys can help organisations identify whether they need a workaround, a permanent fix, or both.
It also supports continuous improvement by turning Major Incidents into opportunities to strengthen systems, processes and team performance.
The 5 Whys is a root cause analysis technique where teams ask “why?” five times, or as many times as needed, to identify the true root cause of a problem.
Why the 5 Whys is effective in Major Incident Management
The 5 Whys technique works well in Major Incident Management because it provides structure without unnecessary complexity. When teams are working under pressure, a simple, practical method can help keep the investigation focused, factual and collaborative.
Simple to apply
The technique is easy to understand and does not require advanced tools or complex analysis. This makes it especially useful during the urgency of a Major Incident, when teams need a clear way to guide investigation and make progress quickly.
Effective at preventing superficial fixes
In IT, teams may resolve the immediate symptom without addressing the underlying issue. For example, restarting a server may restore service, but it may not resolve the memory leak that caused the server to crash.
The 5 Whys helps teams move beyond the first obvious answer and explore what really needs to change.
Collaborative
Major Incidents often involve multiple teams, including network, application, infrastructure, service desk, security, suppliers and business stakeholders.
The 5 Whys gives each team a structured way to contribute evidence, context and technical insight, helping the Major Incident Manager build a clearer picture of what has happened.
Structured
The technique gives discussions a clear direction. This is critical in high-pressure environments, where conversations can drift, assumptions can escalate and teams can lose focus.
A structured approach helps keep the investigation aligned to the facts.
Valuable for documentation and learning
The outputs from a 5 Whys analysis can be documented as part of the incident record or post-incident review.
This creates useful learning that can help prevent future incidents, reduce recurrence and improve operational resilience.
How to apply the 5 Whys in Major Incident Management
Use this as a practical step-by-step structure.
1. Identify the problem clearly
Start by stating the problem in a clear and concise way.
For example: the database server is down, causing outages across our e-commerce platform.
This problem statement matters. If the starting point is unclear, the investigation can quickly become confused or misdirected. A good problem statement should describe what has happened, which service is affected and what the business impact is.
2. Ask the first “why?”
Once the problem is clearly stated, ask why it happened.
For example: Why is the database server down?
Answer: “The server ran out of memory and crashed.”
This gives the team a starting point, but it is not yet the root cause.
3. Continue asking why
Drill deeper by asking “why?” again. Repeat the process up to five times, or more if needed, with each answer building on the previous one.
For example: Why did the server run out of memory?
A memory leak in the application consumed all available memory.
Why did the memory leak occur?
The application has a bug that wasn’t detected during testing.
Why wasn’t the bug detected during testing?
The specific use case that triggered the bug wasn’t covered in our test cases.
Why wasn’t this use case covered in testing?
The test scenarios were incomplete because of time constraints.
4. Find the root cause
By the fifth “why”, teams have often reached the true root cause of the problem. In this example, the root cause may be insufficient testing procedures.
This insight allows the organisation to move beyond fixing the immediate technical issue and focus on improving the testing approach to prevent similar incidents in the future.
However, Major Incidents require service to be restored as quickly as possible. That means the Major Incident Manager must balance root cause investigation with immediate service restoration.
In some cases, the right response is to apply a workaround quickly.
In other cases, if the time required to fix the root cause is similar to the time required to implement a workaround, it may be appropriate to resolve the root cause directly.
The key is to make a clear, informed decision based on impact, urgency and risk.
5. Develop an action plan
Once the root cause has been identified, create an action plan that addresses both the immediate issue and the underlying cause where possible.
Using the example above, the action plan may include: fixing the memory leak restoring the affected service
- updating the testing process
- adding the missing use case to future test scenarios
- reviewing release governance
- documenting the learning in the post-incident review
This ensures the organisation does not simply recover from the incident, but learns from it.
Best practices for using the 5 Whys in IT
Involve multiple teams
In Major Incidents, the root cause often spans multiple systems, teams or layers of technology. Network, application, infrastructure, supplier, security and service management teams may all hold part of the answer. Involving the right experts helps ensure each “why” is answered accurately.
Stay objective
Focus on facts, not assumptions. The 5 Whys works best when each answer is based on evidence, verified data or confirmed technical insight.
Document the process
Record each step, including the question, answer and rationale. This supports incident resolution and creates a valuable reference for the post-incident review.
Don’t overcomplicate it
Although it is called the 5 Whys, teams do not always need exactly five questions.
The aim is not to hit a fixed number. It is to keep asking why until the team reaches a cause that can be clearly evidenced and actioned.
Example of using the 5 Whys in a Major IT Incident
Let’s walk through a hypothetical example of a Major IT Incident in an e-commerce organisation.
Incident example: The checkout system crashed during peak traffic, preventing clients from completing purchases.
Why did the checkout system crash?
The payment processing service became unresponsive.
Why did the payment processing service become unresponsive?
The service reached its maximum number of concurrent connections.
Why did the service reach its maximum number of concurrent connections?
The load balancer failed to distribute traffic properly.
Why did the load balancer fail?
The configuration was incorrect, causing too much traffic to be routed to one server
Why was the configuration incorrect?
A recent update to the load balancer was not properly tested.
Root cause:
Insufficient testing of configuration changes in the load balancing system, which led to one server becoming overloaded.
This example shows how the 5 Whys can help teams move from the visible symptom, the checkout crash, to the deeper process issue that allowed the incident to happen.
