Root-Cause Analysis Process

Document control

Field	Value
Owner	Ron Benisty — CTO & CSO (ron.b@iontwrks.com)
Status	Approved
Version	1.0
Classification	Confidential
Approved by	Ron Benisty — CTO & CSO
Approval date	2026-05-26 (Tuesday)
Last reviewed	2026-05-26
Review cycle	Annual — next review due May 2027
Parent policy	Secure SDLC (SSDLC)

Satisfies NIST SSDF RV.3 (root-cause analysis of vulnerabilities to prevent recurrence); supports ISO/IEC 27001:2022 A.5.27 (learning from information-security incidents) and SOC 2 CC4.2 (monitoring + control effectiveness). Closes Gap 15 of the SSDLC gap analysis.

---

1. Purpose

Treat incidents and verified findings as data. Identify the underlying cause — not just the symptom — and feed structural fixes back into the codebase, controls, and policies so the same class of issue does not recur.

2. Triggers

An RCA is required for:

• Every Sev 1 or Sev 2 incident (per Incident Response §3).
• Every verified critical or high vulnerability finding (per Vulnerability Management Policy).
• Every recurring vulnerability class — third occurrence of the same root cause within a rolling 12 months.
• Production rollbacks triggered by health-check failure.
• Failed backup-restore tests (see Backup & Recovery §4).

An RCA is optional but encouraged for:

• Sev 3 / Sev 4 incidents — required when the same Sev 3 surfaces twice.
• Significant near-misses.

3. Process

1. Open the RCA within 2 business days of incident close or finding verification.
2. Reconstruct the timeline from the incident record + system evidence (CloudTrail, audit logs, Logz.io, GitHub history).
3. 5-whys — drive each contributing factor down to a structural cause. Stop at the layer S.E.T can change (code, control, process, vendor).
4. Classify the root cause:
   • Code defect — logic, validation, race, crypto misuse, etc.
   • Control gap — a policy did not exist, or existed but did not run.
   • Process gap — a step was unclear, untimed, or skippable.
   • Vendor / sub-processor — root cause is upstream.
   • Environmental — capacity, dependency, third-party outage.
5. Identify the structural fix — the change that would prevent the entire class, not just this instance. Examples: a new lint rule, a new pipeline gate, a contract clause, an architectural change.
6. File the fix as PRs (Change Management) and link them to the RCA.
7. Close within 5 business days of opening, or escalate to the CTO & CSO with a target date.

4. Blameless discipline

Names appear only as roles ("the on-call engineer," "the reviewer"). The RCA examines the system — the conditions that allowed the failure — not the individual. The point is to make the right action the path of least resistance next time, not to apportion fault.

5. RCA template

## Summary
<!-- One paragraph: what happened, when, blast radius. -->

## Timeline
<!-- Reconstructed from the incident record + evidence. -->

## 5-whys
1. Why did X happen? Because …
2. Why? Because …
3. Why? Because …
4. Why? Because …
5. Why? Because …
→ **Root cause:** …

## Classification
- [ ] Code defect
- [ ] Control gap
- [ ] Process gap
- [ ] Vendor / sub-processor
- [ ] Environmental

## Contributing factors
<!-- Anything that made the root cause more likely or harder to detect. -->

## Structural fix
<!-- The change that prevents the class, not just the instance. -->

## Linked PRs / tickets
<!-- Each fix as its own PR per Change Management. -->

## Lessons + policy changes
<!-- Are any SSDLC policies, runbooks, or training materials affected? -->

6. Outputs feed forward

• Code / control fixes → Change Management PRs.
• Recurring-class detections → updates to the Secure Coding Standard or new pipeline gates (Release Gate Criteria).
• Vendor-rooted causes → sub-processor review (and contract escalation where warranted).
• Recurring process failures → revisions to the relevant SSDLC sibling policy + this RCA process itself.

7. Evidence

The RCA write-up is the evidence. Retained ≥ 24 months per the Evidence Collection & Retention Policy.

8. Document change history

Version	Date	Author	Description of change	Approved by
1.0	2026-05-26	Ron Benisty (CTO & CSO)	Initial version — establishes the RCA process.	Ron Benisty (CTO & CSO)