Report
Write the security assessment report: executive summary, evidenced findings with severities, the remediation and residual risk — the document that certifies the work.
The security assessment report is the deliverable that carries all your work to the people who decide what to do with it — and it's the artifact that, in the real world, gets you hired to do this again. It must serve two audiences at once: an executive who needs the risk in a paragraph, and an engineer who needs to reproduce and fix every finding.
The report structure
- 1Executive summary (½ page): what was assessed, the overall risk posture in plain language, the number and severity of findings, and the bottom line — is this system safe to run, and under what conditions? A non-technical reader should grasp the stakes here and nowhere else.
- 2Scope & method: what was in/out of bounds, the authorization, and how you assessed (threat model + attack campaign). Establishes credibility and repeatability.
- 3Findings — the core. Each: title, OWASP category, severity (with the likelihood × impact reasoning), reproduction steps, evidence, and impact. Ordered by severity. This is what engineers act on.
- 4Remediation: what was fixed, how (defense in depth), and the before/after posture with the re-attack proof. The critical-actions-at-zero result, front and center.
- 5Residual risk: what remains — accepted low-severity items, the honest limits ('injection is mitigated, not eliminated; a novel payload could still produce a flagged-but-harmless output'), and recommended ongoing practices (the red-team suite in CI, periodic access review, monitoring).
The tone that earns trust
- Precise, not alarmist. 'Critical: indirect injection via product reviews could trigger unauthorized refunds' — specific, evidenced, actionable. Not 'the AI is dangerous!!!'. Fear isn't a finding.
- Honest about residual risk. The strongest report says clearly what it did not solve. A report claiming total security is either naive or dishonest, and a good reviewer distrusts it — you learned this in every eval report you've written.
- Reproducible. Every finding an engineer can re-run. Every posture number from a suite they can execute. Assessment is science, not assertion.
Review my security assessment report as the CTO who has to decide whether to ship this system: [paste]. Is the executive summary clear enough to decide from? Is any finding's severity mis-rated? Is the residual-risk section honest, or is it hiding something with optimism? What's the one question I'll ask that the report doesn't answer?
The report is written for a decision-maker; test it against one. The 'question it doesn't answer' is usually about residual risk or the cost of a recommended control — answer it before you present.
A security assessment with a clear executive summary, evidenced findings, proven remediation, and honest residual risk is rarer and more impressive than working code — it demonstrates you can find, fix, and communicate AI risk. It's the thing to bring when an employer asks 'have you secured an AI system in production?'