From CVE to RCA: Pentest Reports That Drive Change

A pentest is only as valuable as what happens after it. The technical work of finding vulnerabilities is table stakes. The harder — and more impactful — work is translating findings into decisions that organisations actually act on.

Why Most Reports Fail

The typical pentest report lists vulnerabilities with CVSS scores and generic remediation advice. The CISO forwards it to engineering. Engineering files tickets. Tickets sit in the backlog behind feature work. Six months later, the same vulnerabilities appear in the next pentest.

The failure is structural. Technical reports speak to security practitioners. Remediation happens at the engineering and product level, where the language is sprint capacity, deployment risk, and business impact — not CVSS vectors.

The RCA Framing

Root Cause Analysis forces a different question: not "what is broken" but "why did this get built this way and what would prevent the next one?"

For every critical or high finding, a useful RCA answers:

• What is the vulnerability? Plain-language description, one sentence.


• How was it found? Attack path from initial access to exploitation.


• What is the business impact? Not "information disclosure" — "an attacker can read every customer record without authentication."


• Why does it exist? Missing code review gate? No threat model? Framework misuse?


• What is the fix? Specific code change or config, not "implement input validation."


• What prevents recurrence? The systemic control — a lint rule, a policy, a library change.

A Concrete Example

Finding: IDOR in /api/documents/{id} — no ownership check.

Poor remediation advice: "Implement proper access controls."

RCA-framed advice:


• Fix: In DocumentController.get(), add if (doc.ownerId !== req.user.id) return 403 before returning.


• Root cause: The API was scaffolded without a base controller that enforces ownership. All endpoints in this service have the same gap.


• Recurrence prevention: Add an integration test fixture that asserts ownership checks exist for all document endpoints. Add a code review checklist item for resource ownership in any new CRUD endpoint.

The difference: the first advice produces one ticket. The second produces one ticket plus a systemic improvement that covers the next ten similar endpoints.

Report Structure That Gets Read

1. Executive summary (1 page): Risk posture before and after. No jargon. Numbers where possible ("4 critical → 0 in 14 days").
2. Finding index: Sorted by severity. Each finding links to its detail section.
3. Finding detail (per-finding): Proof of concept with screenshots, impact narrative, specific fix, RCA if applicable.
4. Remediation roadmap: Grouped by sprint-sized batches with priority order. Acknowledges that not everything can ship at once.
5. Verification plan: How to confirm fixes before the next engagement.

Making It Actionable in Practice

Before delivering the report, walk the engineering lead through the top three findings verbally. Answer "how long would this take to fix?" for each. If the answer is "a sprint," it ships. If the answer is "a quarter of architectural work," it needs a risk acceptance decision at the leadership level.

The report formalises what was already agreed in the verbal debrief. By delivery day, there should be no surprises — and the first ticket should already be in progress.