# Reporting And Retest > Use when writing up a red-team engagement and verifying fixes — producing findings the organisation can actually close, and re-testing to confirm remediation worked. - Skill: `jihedbfr-art/reporting-and-retest` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add jihedbfr-art/reporting-and-retest` - Raw SKILL.md: https://api.skillmd.com/api/skills/jihedbfr-art/reporting-and-retest/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: jihedbfr-art (https://skillmd.com/u/jihedbfr-art) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/jihedbfr-art/reporting-and-retest --- ## Prerequisites - Target system, dependencies and environment configured. ## Usage ### Purpose An engagement's value is realised only in the report and the remediation it drives — a brilliant intrusion that produces an unactionable report improved nothing. This skill covers writing red-team findings the organisation can close, and re-testing to confirm the fixes worked. It's the closing discipline that turns offensive work into defensive improvement, and it's where a lot of red-team value is won or lost. ### When to use it At the end of every engagement, and after the organisation remediates. Reporting well is what makes the engagement worthwhile; re-testing is what confirms the money and effort actually reduced risk. ### Procedure 1. **Write for the audiences — technical and executive.** Like other security reporting, a red-team report serves different readers: technical teams need the detailed findings and fixes; leadership needs the risk picture and business impact. Lead with an executive summary (what was achieved, what it means for the business, key recommendations), with technical detail below. 2. **Tell the attack narrative, mapped to ATT&CK.** The strength of a red-team report is the story: how the emulated adversary got in, escalated, moved, and achieved the objective — the full attack path, mapped to ATT&CK techniques. This narrative shows the organisation exactly how an intrusion would unfold against them. 3. **Make findings actionable — the core.** Every finding needs: what the weakness is, how it was exploited (the specific path), the impact, and — critically — a concrete, prioritised remediation. A finding without a clear fix leaves the reader to figure out the response. Prioritise by risk so the organisation fixes the highest-impact issues first. 4. **Include the defensive outcome — what was detected.** A red-team report isn't just "here's what got through"; it should say what the blue team *did* detect and where detection failed. This is often as valuable as the attack findings — it tells the organisation where their detection and response worked and where they didn't (feeding the detection/SOC domains). 5. **Emphasise systemic fixes over point fixes.** Where findings share a root cause (flat network enabling lateral movement, missing tiering enabling escalation), recommend the systemic fix that closes the class, not just the individual instances. Breaking the attack path at a chokepoint is more valuable than patching each step. 6. **Re-test after remediation — confirm the fixes worked.** A remediation that's reported as done isn't proven until verified; re-test the specific findings to confirm the fixes actually close them (the vuln-management remediation-verification discipline). Re-testing is what turns "we fixed it" into "it's actually fixed", and it's a standard part of a quality engagement. 7. **Feed lessons into the defence.** The findings should drive detection improvements (the gaps found), hardening (the weaknesses exploited), and architecture (the systemic issues) — and ideally the engagement's techniques become detection tests (purple-teaming / detection domain). The engagement improves the defence, or it was just an expensive intrusion. ### Cheatsheet ``` engagement value = the REPORT + the remediation it drives (great intrusion + unactionable report = nothing improved) report AUDIENCES: technical (findings + fixes) + executive (risk, business impact, key recs) -> lead with executive summary, technical detail below ATTACK NARRATIVE mapped to ATT&CK (how they got in -> escalated -> moved -> objective — the full path) ACTIONABLE findings (core): weakness + how exploited (path) + impact + CONCRETE prioritised remediation (no fix = reader left guessing ; prioritise by risk) DEFENSIVE OUTCOME: what was DETECTED + where detection failed (as valuable as the attack findings) SYSTEMIC fixes > point fixes (shared root cause -> fix the class ; break the path at a chokepoint) RE-TEST after remediation: reported-done != proven -> verify the specific findings are closed (turns "we fixed it" -> "it's actually fixed" ; standard part of a quality engagement) feed lessons -> detection improvements + hardening + architecture (+ techniques -> detection tests) the engagement IMPROVES the defence, or it was an expensive intrusion. ``` ### Reading the deliverable - **Findings with concrete, prioritised remediations** = an actionable report the organisation can close; the core of red-team value. A finding without a clear fix leaves the reader to work out the response and often goes unremediated. - **An unactionable report** (a narrative of the intrusion with no clear fixes) = the engagement's value largely lost; a great intrusion that improves nothing. Actionability is what matters. - **The attack narrative mapped to ATT&CK** = shows exactly how an intrusion unfolds against the organisation and lets them compare to their detection coverage; the report's storytelling strength. - **The defensive outcome included** (what was detected, where detection failed) = often as valuable as the attack findings; it tells the organisation where their detection/response worked. A report that omits this misses half the value. - **Systemic fixes recommended over point fixes** = closing classes of weakness (fix the flat network, not each movement instance) is more valuable; breaking the path at a chokepoint stops the whole chain. - **Re-test confirming fixes closed the findings** = remediation proven, not just claimed; the engagement's risk reduction is verified. Without re-test, "fixed" is unverified. ### Pitfalls - **An unactionable report.** A brilliant intrusion with vague or missing fixes improves nothing; every finding needs a concrete, prioritised remediation. Actionability is where red-team value is won or lost. - **Omitting the defensive outcome.** A report that's only "what got through" misses what the blue team detected and where detection failed — often as valuable as the attack findings. Include it. - **Point fixes over systemic ones.** Recommending a fix per finding while missing the shared root cause leaves the attack path open through other instances; recommend the systemic fix that closes the class. - **No re-test.** Reported-remediated isn't proven-remediated; without re-testing, the risk reduction is unverified and fixes may not actually close the findings. - **One report for all audiences.** Technical teams and leadership need different things; lead with an executive summary and provide technical depth below. - **Not feeding lessons into the defence.** If the findings don't drive detection, hardening, and architecture improvements, the engagement was an expensive intrusion. Close the loop. ### References - The vulnerability-management remediation-verification and reporting-to-stakeholders skills - The purple-teaming skill (techniques → detection tests) and the detection-engineering domain - MITRE ATT&CK (narrative mapping), PTES (reporting), and NIST SP 800-115 - The scoping-and-rules-of-engagement skill (objectives → report success criteria) ## Inputs - Relevant source code, logs, network traces, or system specifications. ## Outputs - Analysis findings, security audit report, or generated code artifacts.