What Is RCA?
How to Write Root Cause Analysis Using 5W1H

IT problems that keep coming back after being "fixed" are a clear sign that the team is addressing symptoms, not the root cause. RCA (Root Cause Analysis) is the process that helps IT teams dig down to the true origin of a problem — so they can fix it properly and prevent it from recurring. This article explains what RCA is and how to write one using the 5W1H framework, in a way that works in real IT Support environments.

What Is RCA?

RCA stands for Root Cause Analysis — the practice of systematically answering "Why did this problem really happen?" rather than just "What did we do to make it go away?" It is a core process in IT Service Management (ITSM) and Problem Management under both ITIL and ISO 20000.

A clear example: an employee reports that their computer won't start. IT restarts it, the problem goes away, and the ticket is closed. But the same thing happens again next week. An RCA would reveal the real cause — a failing power supply — requiring a component replacement rather than just another restart.

Why Must IT Support Do RCA?

• Eliminate repeat incidents — Problems with a documented root cause don't come back.
• Build a Knowledge Base — Well-written RCAs can be converted into FAQ articles so employees can self-resolve similar issues in the future.
• Develop the team — RCA helps new support staff learn from real incidents in the organization.
• Reduce costs — Incidents that don't recur = hours saved.
• Meet ITSM standards — Both ITIL and ISO 20000 require a Problem Management process that includes RCA.

The 5W1H Framework for RCA

The most practical and memorable framework for IT teams is 5W1H — six questions that cover every dimension of a problem.

Real RCA Example: Office-Wide Internet Outage

The 5 Whys Technique: Drill Down to the Real Cause

The 5 Whys technique involves asking "Why?" repeatedly until you reach a cause that can actually be fixed and prevented. In practice, 3–5 iterations are usually sufficient. The key is not to stop at the first answer.

The final answer is something that can actually be fixed and prevented — add cron job monitoring and a permanent log rotation policy. Simply deleting the logs and closing the ticket would guarantee the same problem returns.

RCA and the Knowledge Base — Turning Insights into Assets

A well-written RCA can be converted into a FAQ Article that employees can search and follow themselves in the future — especially the "How" section, which should be written as clear step-by-step instructions. A good ITSM system lets support staff click "Publish FAQ" directly from the RCA without rewriting anything.

Tickets with complete RCA data also help AI work more accurately — for instance, suggesting resolution approaches automatically for new tickets with similar symptoms.

Common Mistakes in Writing RCA

• Stopping at the first symptom — e.g., concluding the cause was "computer hanging" without digging into why it hung.
• Blaming people instead of processes — Good RCA asks "Which process failed?" not "Who is at fault?"
• Not documenting preventive measures — Resolving the problem without prevention means it will recur.
• Writing the RCA after forgetting the details — Write it immediately or within 24 hours of resolving the incident.
• Not sharing it with the team — An RCA nobody reads is the same as no RCA at all.

RCA in ITSM: How Does a Good System Help?

An ITSM system with built-in RCA features ensures that this process actually happens in the organization — not just in policy documents. What the system should provide:

• A 5W1H RCA form that's easy to complete within the ticket
• AI-assisted RCA suggestions — pulling data from similar past tickets as a starting point
• A "Publish as FAQ" button — converting the How section into a Knowledge Article directly
• Reports showing which closed tickets still lack an RCA

1StopService includes a 5W1H RCA Form with AI suggestions drawn from past tickets, along with a complete ITSM Checklist every IT team should know.