Root Cause Analysis in Action Plans

Root Cause Analysis in Action Plans: A Complete Guide for ISO/IEC 27001 Lead Auditors

Introduction
When an ISO/IEC 27001 audit closes, the auditee usually has nonconformities to address. The audit does not end with the closing meeting. The organization must produce an action plan that addresses each nonconformity, and the most important part of that plan is the Root Cause Analysis (RCA). This guide covers what RCA is, why it matters, how it works within the audit lifecycle, and how to answer exam questions about it in the PECB ISO/IEC 27001 Lead Auditor exam and similar certifications.

1. What Is Root Cause Analysis in Action Plans?
Root Cause Analysis is a structured process the auditee uses to find the fundamental, underlying reason a nonconformity occurred, as opposed to its visible symptom. In an action plan, RCA is the basis for choosing corrective actions that stop the nonconformity from happening again.

ISO/IEC 27001:2022, Clause 10.2 (Nonconformity and corrective action), requires that when a nonconformity occurs, the organization shall:
• react to the nonconformity and, as applicable, take action to control and correct it and deal with the consequences;
• evaluate the need for action to eliminate the cause(s), so that it does not recur or occur elsewhere, by:
– reviewing the nonconformity;
– determining the causes of the nonconformity;
– determining whether similar nonconformities exist or could potentially occur;
• implement any action needed;
• review the effectiveness of any corrective action taken;
• make changes to the ISMS, if necessary.

The phrase "determining the causes of the nonconformity" is the normative requirement for root cause analysis.

Key distinctions to understand:
• Correction: Immediate action to eliminate a detected nonconformity, which fixes the symptom. Example: revoking the access rights of a departed employee that were found still active.
• Corrective action: Action to eliminate the cause of a nonconformity and prevent recurrence. Example: redesigning the HR-to-IT offboarding workflow so access is revoked automatically.
• Root cause: The most basic reason which, if eliminated, would prevent recurrence. Example: no formal link existed between the HR termination process and the IT access management process.

2. Why Is Root Cause Analysis Important?
• Prevents recurrence: Without RCA, organizations only treat symptoms, and the same nonconformities return in the next surveillance audit.
• Compliance with Clause 10.2: Certification bodies expect evidence that causes were determined. Missing RCA is itself a weakness in the corrective action process.
• Supports continual improvement (Clause 10.1): RCA turns audit findings into real improvements of the ISMS.
• Credibility of certification: Under ISO/IEC 17021-1, the certification body must review the auditee's correction and corrective actions, including the cause analysis, before making a certification decision for major nonconformities.
• Resource efficiency: Fixing the true cause once costs less than repeatedly correcting symptoms.
• Identifies systemic issues: RCA often reveals that one weakness, such as poor training or unclear responsibilities, affects several controls.

3. How Does It Work? The Process in the Audit Context

Step 1: Nonconformity is raised. The audit team documents the nonconformity with a statement of the requirement, the evidence, and the nature of the nonconformity. It is presented at the closing meeting.

Step 2: Auditee prepares the action plan. Within an agreed timeframe, the auditee submits a plan. The timeframe is often 30 to 90 days for major nonconformities and may be shorter depending on the certification body. A typical plan contains:
• description of the nonconformity;
• correction (immediate containment);
• root cause analysis;
• corrective actions to address the root cause;
• responsible persons;
• deadlines;
• method for verifying effectiveness.

Step 3: Root cause analysis is performed by the auditee. Common techniques include:
• 5 Whys: Ask "why?" repeatedly, usually about five times, until the fundamental cause appears. Example: Why were backups not tested? No one was assigned. Why? The procedure did not define a role. Why? The procedure was copied from a template without adaptation. Why? There was no document review process. Root cause: an ineffective document control and review process.
• Ishikawa (Fishbone) diagram: Groups possible causes into categories such as People, Process, Technology, Environment, Materials and Management.
• Fault Tree Analysis: A top-down logical diagram of the events that led to the failure.
• Pareto analysis: Finds the few causes responsible for most problems (the 80/20 rule).
• Failure Mode and Effects Analysis (FMEA): Used more for proactive analysis.

Step 4: Auditor reviews the action plan. The auditor, often the audit team leader, evaluates whether:
• the identified root cause is plausible and logically linked to the nonconformity;
• the corrective actions actually address the root cause and not only the symptom;
• the scope considers similar nonconformities elsewhere;
• the timelines and responsibilities are realistic;
• the plan is acceptable. If it is not, the auditor requests revision.

Step 5: Follow-up and verification. Depending on severity, the auditor verifies implementation and effectiveness. For major nonconformities this is often done through an on-site follow-up audit or document review. For minor nonconformities it is typically done at the next surveillance audit.

Critical principle: the auditor's role is limited. The auditee is responsible for performing the RCA and defining actions. The auditor must not perform the RCA or prescribe solutions, because that would be consultancy and would threaten independence and impartiality (ISO 19011, ISO/IEC 17021-1). The auditor evaluates the adequacy of the plan and may explain why it is inadequate, without dictating the fix.

4. Common Weaknesses Auditors Look For
• "Human error" given as the root cause: This is rarely acceptable alone. The auditor should ask why the error was possible, for example lack of training, poor design, or no verification step.
• Restating the nonconformity as the cause: For example, "the cause is that the policy was not reviewed."
• Corrective action equals correction: For example, "we updated the document" without changing the process that allowed it to become outdated.
• "Retrain staff" as a universal fix with no evidence that training was the cause.
• No effectiveness check defined.
• No extent analysis: The plan does not ask whether the same problem exists in other departments or sites.

5. Worked Example
Nonconformity: Three of ten sampled servers lacked critical security patches older than 60 days, contrary to the patch management procedure (Annex A 8.8, Management of technical vulnerabilities).
Correction: Patch the three servers immediately.
Root cause (via 5 Whys): The servers were added after the asset inventory was last updated, so they were not enrolled in the automated patching tool. No process linked asset onboarding to patch management enrollment.
Corrective action: Integrate the server provisioning checklist with mandatory enrollment in the patching tool. Run weekly reconciliation reports between the asset inventory and the patch tool.
Extent: Check all network devices and endpoints for similar gaps.
Effectiveness: Review three months of reconciliation reports showing 100% coverage.

6. Exam Tips: Answering Questions on Root Cause Analysis in Action Plans

Tip 1: Know who does what. The auditee determines root causes and proposes actions. The auditor reviews and accepts or rejects the plan and verifies effectiveness. An answer in which the auditor performs the RCA or recommends specific solutions is almost always wrong.

Tip 2: Distinguish correction from corrective action. Exam scenarios often describe an auditee who "fixed the problem." Ask whether that fixed the symptom (correction) or eliminated the cause (corrective action). Only the latter prevents recurrence.

Tip 3: Reject superficial root causes. If a scenario gives "employee forgot" or "human error" as the root cause, the best answer usually says the analysis is insufficient and the auditor should request a deeper analysis.

Tip 4: Reference Clause 10.2. In essay or scenario questions, cite ISO/IEC 27001 Clause 10.2 and mention its elements: react, evaluate the need for action, determine causes, check for similar nonconformities, implement, review effectiveness, and update the ISMS.

Tip 5: Remember the effectiveness check. A good action plan includes how effectiveness will be verified. If an option mentions verifying effectiveness, it is often part of the correct answer.

Tip 6: Major vs. minor timelines. Major nonconformities usually require the auditor to review the correction, the RCA and the corrective action before certification is recommended, and may require a follow-up audit. Minor nonconformities typically need an accepted action plan, with implementation verified at the next surveillance audit.

Tip 7: Use structured techniques in your answers. If asked how an auditee should determine causes, mention 5 Whys, Ishikawa diagrams or Fault Tree Analysis. Show briefly how one applies to the scenario.

Tip 8: Watch for independence traps. Options such as "the auditor should help the auditee write the corrective action plan" or "the auditor should suggest buying a specific tool" violate impartiality. Pick options where the auditor evaluates and asks questions.

Tip 9: Consider extent and systemic impact. Strong answers note that RCA should check whether similar nonconformities exist elsewhere, as required by Clause 10.2.

Tip 10: Structure scenario answers clearly. A useful format is:
(1) identify the issue in the auditee's plan;
(2) state the relevant requirement (Clause 10.2);
(3) explain why the plan is or is not adequate;
(4) state the auditor's appropriate action, such as accepting it, requesting revision, or planning follow-up.

Sample exam question: During review of an action plan, the auditee states the root cause of missing access reviews was "the IT manager was too busy." The corrective action is "remind the IT manager." What should the auditor do?
Best answer: The auditor should not accept the plan. The root cause is superficial and the action addresses only a symptom. The auditor should ask the auditee to perform a deeper analysis, for example of resource allocation, role definition, scheduling mechanisms or the lack of automated reminders and oversight. The auditor should do this without prescribing the specific solution.

Summary
Root Cause Analysis is the core of an effective action plan after an ISO/IEC 27001 audit. It ensures nonconformities are permanently resolved rather than temporarily patched, it satisfies Clause 10.2, and it drives continual improvement. For the exam, remember these points:
• the auditee analyses and the auditor evaluates;
• correction is not the same as corrective action;
• superficial causes should be rejected;
• effectiveness must be verified;
• auditor independence must always be preserved.