Correcting without looking for the cause is wrong!

Link to ISO/IEC 27001:2022

There are several references to root cause analysis in ISO27001:2022.

• Clause 6.1.2 – Risk analysis and assessment for a clear understanding of threat scenarios
• Clause 9.1 – calls for the collection of reliable data and root cause analysis transforms this data into usable information for the future.
• Clause 10.2 – The main clause for managing non-conformities and creating corrective action calls for each NC to be evaluated to identify the cause and thus prevent recurrence.

The 5 Whys

The 5 Whys method involves repeatedly asking the question “Why?” to trace the symptoms of a problem back to its root cause.

By finding this root cause, we can apply corrective action that permanently eliminates the problem rather than masking its effects.

Its speed and simplicity make it a preferred tool in ISO-certified environments, because it’s simple and effective.

It has its limits when dealing with complex incidents where several independent causes interact.

How to perform a 5-Why analysis

1 – Clearly formulate the problem and write it down.
2 – Ask: “Why is this happening?” and write down the answer.
3 – Transform this answer into a new problem, then ask again: “Why is this happening?” and write down the new answer.
4 – Repeat the “Why?” question until no deeper explanation is possible; this is when the root cause is discovered.
5 – If several causes appear along the way, keep them: a single problem can have several root causes.

Fishbone Diagram (Ishikawa diagram)

The Ishikawa diagram provides a visual representation of the effect (“center edge”) and its potential causes, grouped by category (Material, Methods, Manpower, Environment, Measures, etc.).

It is recommended when an incident results from multiple interactions – typically a process failure or human error coupled with faulty technical control.

Its strength lies in stimulating collective reflection, which is useful in workshops involving several stakeholders. Its limitation is that it maps hypotheses; a validation stage is required to confirm the root cause.

It’s especially useful when a problem has several potential causes and you want to structure collective thinking.

How to create an Ishikawa diagram

1. Define the problem or effect to be analyzed. For example: understand why a series of pumps delivered to a customer frequently has defects.
2. Draw the skeleton of the diagram. In the center of the page, draw a horizontal arrow pointing to the right, representing the fish’s backbone. At the end of the arrow, like the fish’s head, write the problem statement (e.g.: common pump faults) and frame it.
3. Identify the main categories of causes. Starting from the central edge, draw oblique branches that will act as ribs. Ishikawa proposed the “6 M’s”, but encouraged the adaptation of titles to better speak to teams:

Materials: parts, ingredients, supplies.

Machinery: production equipment, handling devices, software (in some sectors, this category may be split).

Methods: procedures, techniques, processes, regulations (especially for public administration or highly regulated industries).

Measurement: key indicators, measuring instruments, data collection points.

Workforce: people, human resources, training, skills.

Milieu (Mother Nature): environment and external factors.

We sometimes add a seventh “M”: Money, i.e. operating expenses and investments.

4.explore possible causes. Based on these categories, ask: “Why is this happening?” and note each plausible cause under the appropriate branch, keeping it concise. The same cause can appear in several places if it concerns several categories.

5. Refine by iteration. Go back to each cause and ask the question “Why?” to reach deeper levels; trace sub-causes as secondary branches. The stacking of branches reflects causal relationships.

6. Complete the brainstorm. When ideas dry up, focus on branches where there are fewer causes; this may reveal overlooked factors.

7. Analyze and prioritize. Examine all the causes identified to determine which deserve action. Keep in mind that the aim is to treat the root cause, not the symptoms. It may be useful to redraw the diagram to clarify the presentation before the final analysis.

Fault Tree Analysis

FTA builds a logic tree where the undesirable event is the root and the causes are deployed using AND/OR logic gates.

This analytical approach is suitable for critical technical events, such as a major downtime of a security service.

It does, however, require statistical skills, and can become cumbersome for smaller structures.

How to create FTA (Fault Tree Analysis)

1. Clearly identify the main problem to be analyzed and define its limits.
2. Gather all relevant information about the system, and consult the relevant experts.
3. Build the tree by linking the root causes to the main problem using logic gates.
4. Analyze the paths in the tree to understand the relationships between the causes and the problem.
5. Identify the events and critical paths that most influence the probability of the problem.
6. Develop strategies to mitigate risks by acting on critical causes.
7. Document the complete analysis and share it with stakeholders.
8. Monitor the effectiveness of the measures put in place and update the tree regularly.

Causal Factor Tree Analysis

CFTA details each contributing event and its causal factors in a chronological tree.

This can be a lengthy process, requiring precise information on the chronology of events.

How to create a causal factor tree analysis.

1. Define the problem: Write down clearly what happened (the main incident or problem).
2. Information gathering: Gather information about what happened, how the system works and validate with the people involved.
3. Draw the tree: Note the events that led to the problem and connect them like a tree, with arrows to show the link.
4. Analyze links: See how events are connected and understand their sequence.
5. Identify important points: Find the causes that have had the greatest impact.
6. Look for solutions: write down ideas to prevent it from happening again.
7. Monitor and improve: Check later if the solutions are working, and update the tree if necessary.

Change Analysis

This method compares the normal state of a system with the state at the time of the incident, in order to highlight the changes that may have introduced the non-conformity.

It is particularly relevant for agile or highly virtualized environments where updates are frequent.

Its strength is to quickly target a poorly controlled change, in line with the spirit of the Change Management clause (ISO 27002-5.33), even if it depends on a reliable configuration register.

How to do a change analysis

1. Define the system: Clearly identify what is being analyzed (process, equipment, configuration, etc.).
2. Describe the state before: Note how the system worked before the change.
3. Describe the state afterwards: Note what has been changed or added.
4. Compare the two states: Identify the differences between before and after.
5. Identify impacts: Find out what these differences have caused (problems, errors, improvements).
6. Assess: Ask why these impacts have occurred and how to manage them.
7. Document the analysis: Write a summary of observations and conclusions.
8. Suggest actions: Suggest adjustments or corrections if necessary.

Barrier Analysis

Barrier analysis examines existing controls – physical, technical, organizational – and determines which have failed or are missing.

It also draws on the Swiss cheese model, assessing why several layers of protection weren’t enough, and why a barrier that was supposed to stop the incident, such as a concrete wall protecting cyclists, didn’t work as intended.

This method is recommended when the incident highlights insufficient defense in depth.

It can also be used to understand what prevents individuals from changing or adopting a new behavior.

How to perform a barrier analysis

1. Identify the incident or risk: clearly define what you want to protect, avoid or change.
2. List existing barriers: note any controls or safeguards in place (technical, human, organizational).
3. Check the effectiveness of the barriers: assess whether they are working properly and whether there are any loopholes.
4. Identify failures or gaps: look for what has failed or what is missing as a barrier.
5. Suggest improvements: suggest ways of reinforcing or adding barriers.
6. Document the analysis: write a clear summary of the results and recommended actions.
7. Monitor corrective actions: check that improvements are implemented and that they are effective.

Risk Tree

The Risk Tree is similar to the FTA, but applies a risk-oriented logic rather than pure failure.

It is used to map the combination of events leading to an unacceptable risk.

In an ISMS, it sheds light on the interaction between threats, vulnerabilities and impacts, helping to prioritize corrective actions.

Its complexity grows rapidly with the number of risk factors, and can exceed the analysis capabilities of small teams.

How to create a risk tree

1. Clearly define the risk or event you wish to analyze.
2. Identify all possible causes that could lead to this risk.
3. Break down each cause into sub-causes to better understand the origins of the risk.
4. Identify the possible consequences if the risk occurs.
5. Look for controls or barriers already in place to reduce or control the risk.
6. Represent everything in the form of a tree, linking causes, sub-causes, consequences and controls.
7. Analyze the tree to identify critical areas and decide on preventive or corrective actions.

Parent Analysis

Parent Analysis groups incidents according to common parent categories (process, technology, behavior) to identify structural trends.

It is used when several similar incidents occur over time.

Its strengths lie in the macro view it offers CISOs, useful for guiding continuous improvement plans, but its weakness is that it provides a brief and potentially hidden view of the specific items involved in a particular incident.

How to do a parent analysis

1. Incident collection
   Collect all security incidents over a given period, making sure to include enough data to detect recurring patterns.
2. Categorization of incidents
   Classify each incident into a parent category according to a common criterion: Process (e.g. failure in a procedure) Technology (e.g. vulnerability in a system or software) Behavior (e.g. human error, successful phishing)
   This step is crucial for structuring the analysis and identifying root causes.
3. Grouping similar incidents
   Group incidents that share the same parent category to highlight recurring trends or weaknesses.
4. Structural trend analysis
   Examine groups of incidents to understand common underlying causes, such as process flaws, technological shortcomings or risky behavior.
5. Macro summary for decision-makers
   Present a global view of trends, to guide continuous improvement plans and mitigation strategies.

Failure Mode and Effects Analysis (FMEA)

The FMEA lists each component of a process or asset, describes its possible failure modes and assesses their effect, severity, probability and detectability.

It is ideal for environments where safety depends on critical equipment or repetitive processes.

Source: https://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis

How to perform failure mode analysis

• Identify the process, product or system you wish to analyze.
• List process steps or product components.
• Determine possible failure modes (how it can fail).
• Identify the effects of each failure (what can happen if it fails).
• Assess the severity of each effect (from slight to critical).
• Identify the possible causes of each failure.
• Evaluate the probability of occurrence of each cause.
• Check whether controls or detections already exist, and assess their effectiveness.
• Calculate the “Risk Priority Score” (RPN) by multiplying severity × occurrence × detection.
• Prioritize corrective actions according to the highest scores.
• Document the analysis and monitor the improvements implemented.

Management Oversight and Risk Tree (MORT)

MORT is a root cause analysis method developed to investigate major events, such as industrial accidents, operational failures or safety incidents. It is different from the others:

• It doesn’t just analyze technical or human failures.
• It explores the flaws in management, supervision, decision-making and organizational systems that made the incident possible.

It seeks to answer both these questions:

1. What went wrong technically and operationally?
2. What allowed these failures to go unanticipated, undetected and uncorrected?

the MORT approach rests on two pillars:

• A logical, structured tree linking all levels of causes.
• A management assessment model that identifies systemic problems, not just visible symptoms.

How to do a simple DEATH analysis

1. Define the event or incident to be analyzed
   Be specific: nature, date, location, impact.

2. Collect data
Gather reports, interviews, recordings, procedures, logs… and create a complete picture.

3. Build the DEAD tree –Place the main incident at the top, Plug in the immediate causes (e.g. breakdown, human error, material defect) and Develop downwards the root causes (e.g. lack of training, poor quality control, managerial decisions, poor communication).

4. Explore two main areas
Control failures: Why the planned measures did not work.
Management weaknesses: Why the organization failed to prevent or correct these problems.

5. Use prioritization codes (in the complete approach)
As seen in classic MORT, use visual codes to distinguish: What is under control – What is uncertain – What represents a critical weakness.

6. Identify latent conditions
Conflicting priorities, unclear objectives, lack of leadership, performance culture at the expense of safety.

7. Formulate robust corrective recommendations

To correct technical failures, strengthen supervision, processes, culture and policies, and implement indicators to monitor changes.

Conclusion

The choice of root cause analysis method should reflect the severity and complexity of the incident, the maturity of the ISMS and the resources available.

A simple situation should use the five whys method.

Conversely, a complex or recurring incident may justify the use of tree-based approaches such as FTA, CFTA or MORT, to reveal technical and organizational interdependencies.

Whichever tool is chosen, integrating the RCA into the PDCA cycle reinforces continuous improvement, ensures the sustainability of the corrective actions provided for in clause 10.2, and ultimately consolidates the robustness of the ISMS in the face of current and future threats.