Methods
Handbook

5 Whys

Drill a single causal thread from a confirmed fact down to a systemic, fixable root.

Procedure

1. Start from a confirmed symptom or proximate cause — never a guess.
2. Ask why it happened; answer from evidence. If you can't evidence the answer, tag it suspected and verify before continuing.
3. Make the next "why" interrogate the previous answer.
4. Branch whenever a "why" has more than one valid answer — pursue each line.
5. Stop when the cause is systemic, within your control, and fixing it would prevent recurrence.
6. Validate by reading the chain back forward with "therefore." If a step doesn't follow, the chain is broken — repair it before you accept the root.

Common errors

• Stopping at "human error" instead of asking why the system let the error matter.
• Unevidenced links — a plausible answer is not a confirmed one.
• Taking the first satisfying answer and skipping a real branch.
• Forcing a single thread when causes actually interact (use Fishbone or Fault Tree instead).

Hand-off: often fed by a Fishbone candidate; its confirmed root feeds CAPA.

Fishbone (Ishikawa)

Surface candidate causes across categories so you don't tunnel on the first idea.

Procedure

1. Write the effect (your problem statement) at the head of the spine.
2. Draw one branch per category. IT/security set: People · Process · Technology · Configuration · Data · External.
3. Brainstorm candidate causes onto each branch; add sub-bones by asking "why" within a branch.
4. Tag each candidate evidenced or speculative.
5. Test every surviving candidate against the timeline/evidence and discard what the facts don't support. "On the diagram" ≠ "is a cause."
6. Take the survivors into 5 Whys or Fault Tree Analysis to drill to origin.

Common errors

• Treating diagram entries as confirmed causes without testing them.
• Using categories as a dumping ground and never narrowing.
• Stopping at the fishbone — it generates, it does not conclude.

Hand-off: feeds 5 Whys (single threads) or Fault Tree (combining conditions).

Fault Tree Analysis

Model a failure that required several conditions to coincide, making AND/OR logic explicit.

Gate reference

OR gate — any one input alone causes the event above it. AND gate — all inputs must occur together. Breaking any single input of an AND gate stops the event above; an OR gate requires breaking every input.

Procedure

1. Write the undesired outcome (the top event) precisely at the top.
2. Identify the immediate events/conditions that could produce it.
3. Connect them with OR or AND gates — be deliberate about which.
4. Decompose each intermediate event until you reach basic events you can't or needn't break down further (your candidate roots).
5. Derive the minimal cut sets — the smallest sets of basic events that together cause the top event.
6. Prioritize: a single basic event that alone causes the top event (a one-element cut set) is a single point of failure — fix first.

Common errors

• Choosing the wrong gate — AND where it should be OR — which inverts your conclusion about leverage.
• Stopping decomposition too high, so "basic events" are still compound.
• Ignoring cut sets and treating every leaf as equally important.

Hand-off: often built from Fishbone survivors; cut sets feed CAPA prioritization.

Pareto Analysis

Across many incidents, find the few causes responsible for most of them — so you fix those first.

Procedure

1. Fix a dataset and timeframe (e.g., last quarter's incidents).
2. Categorize each incident by its cause. Use consistent, mutually exclusive categories.
3. Count occurrences — or weight by impact if a rare cause does most of the damage.
4. Sort categories descending by count/weight.
5. Compute the cumulative percentage down the list.
6. Identify the small set of causes that reaches roughly 80% of the total — start there.
7. Run a 5 Whys on each top category to find what the cause actually is.

Common errors

• Inconsistent or overlapping categories, so counts are meaningless.
• Counting frequency when a low-frequency, high-impact cause should dominate — weight by impact.
• Treating the top bar as "the cause" — Pareto tells you where to look, not what is wrong.

Hand-off: the top categories feed individual 5 Whys / Fault Tree analyses.

Change Analysis

When something worked before and fails now, the cause is usually a change — find it by comparison.

Procedure

1. Define the failed state and a known-good baseline (same system when it worked, or a working peer).
2. List every difference: deployments, config edits, patches, new/changed accounts, network/firewall changes, data volume, certificates, upstream dependencies, time/scheduled jobs.
3. For each difference, ask: could this plausibly cause the observed failure?
4. Rank suspects by plausibility and by timing alignment with onset.
5. Test the top suspect — revert it, or compare against the baseline directly.
6. Confirm the change is the cause (the removal test), then trace why that change was harmful.

Common errors

• An incomplete baseline — you only compare what you thought to look at.
• Missing "invisible" changes: certificate expiry, an upstream provider change, gradual data growth, a scheduled job that just fired the first time.
• Assuming the most recent change is guilty without testing timing against onset.

Hand-off: the identified change becomes the starting fact for a 5 Whys.

Barrier Analysis

Identify which defenses between the threat and the asset were missing, bypassed, or failed.

Procedure

1. Name the hazard/threat and the target/asset it reached.
2. List the barriers that should sit between them — preventive, detective, and corrective. Include barriers that ought to exist but don't.
3. For each barrier, record its status: held / failed / bypassed / absent.
4. The failed and absent barriers are your candidate root causes.
5. The barriers that held are your honest statement of remaining defense — and the basis for residual-risk language (never "secure").
6. Add or strengthen the failed/absent barriers as preventive actions, each tied to the threat it addresses.

Common errors

• Only listing barriers that exist — the absent ones are often the real root.
• Reading a held barrier as proof the system is secure; it only means that one layer worked this time.
• Listing controls without a defined threat — a barrier is only evaluable against a specific adversary path.

Hand-off: failed/absent barriers feed CAPA; the layered picture feeds Bowtie.

Timeline / Event Sequencing

Reconstruct what happened in order, and mark the control gap at each step. The default lens for incidents.

Procedure

1. Gather timestamped evidence: logs, alerts, change/access records, metrics. Note source clocks (watch for skew).
2. Place events in chronological order.
3. Tag each entry confirmed or suspected; for suspected, note what would confirm it.
4. At each event, record two things: what caused it, and which control should have caught it.
5. Mark the gaps — each control that should have broken the chain and didn't.
6. Trace to the earliest point where a working control would have stopped everything downstream.

Common errors

• Reading correlation in the sequence as causation.
• Presenting gaps in evidence as established fact — keep the confirmed/suspected tags.
• Ignoring clock skew across systems, which scrambles order.

Hand-off: the control gaps feed Barrier Analysis; the sequence feeds Fault Tree and 5 Whys.

KT IS / IS-NOT

Bound the problem precisely by stating what it is and, crucially, what it is not — the contrast exposes the distinguishing factor.

Procedure

1. For each dimension — What, Where, When, Extent — state what the problem IS.
2. State a plausible IS-NOT: something it reasonably could be affecting but isn't.
3. Ask what distinguishes the IS from the IS-NOT for that dimension.
4. The distinguishing factor points at the cause or the change responsible.
5. Carry the distinctions into hypothesis generation (Fishbone / Change Analysis).

Common errors

• A vague IS-NOT, or one so unrelated it draws no useful contrast — it must be a plausible "could-be-but-isn't."
• Filling in IS only and skipping the contrast — the IS-NOT column is where the value is.

Hand-off: sharpens the problem statement; the distinctions feed Change Analysis.

Bowtie Analysis

Map, for one hazard, both how it can occur and how its impact is contained — and which control sits where.

Procedure

1. Define the central top event — the loss-of-control moment (e.g., "data breach").
2. Left side: list the threats (causes) that could lead to it.
3. Place the preventive controls between each threat and the event.
4. Right side: list the consequences that follow the event.
5. Place the mitigative / recovery controls between the event and each consequence.
6. Assess each barrier: present? effective? Note escalation factors — conditions that degrade a barrier.

Common errors

• Confusing preventive (left, before the event) with mitigative (right, after) controls.
• Listing barriers as if they're effective without assessing them.
• Ignoring escalation factors that quietly defeat an otherwise-good barrier.

Hand-off: the left side is a Fault Tree; barrier statuses feed Barrier Analysis and CAPA.

FMEA — Failure Mode & Effects Analysis

Proactively enumerate how a system could fail and rank the modes, so you fix the worst before they happen.

Procedure

1. Pick the system/process and break it into components or functions.
2. For each, list potential failure modes (how it could fail).
3. For each mode, describe the effect and rate Severity (S).
4. Identify causes and rate Occurrence (O).
5. Note current controls and rate Detectability (D) — how likely you are to catch it before impact.
6. Compute a priority figure (traditionally RPN = S × O × D), sort descending.
7. Act on the top items — reduce Severity or Occurrence, or improve Detection — then re-score.

Common errors

• Reducing Severity because a failure is easy to detect — Severity is about consequence, not catchability.
• Treating RPN as an objective number or comparing it across systems.
• Scoring once and never revisiting after controls change.

Hand-off: high-priority modes feed the hardening backlog; after a real failure, switch to RCA.