Free through lesson 3

Writing Security Assessment Reports

From knowing your readers and stating the scope, through work logs and evidence, CVSS risk ratings, findings and the executive summary, to the debrief and the retest. In 30 lessons you learn to report findings so the reader can actually fix them.

Start from lesson 1 Unlock every course

Curriculum

The 30 lessons are grouped into six chapters. Working through from chapter 1 is recommended, but you can also dip into the parts you need. * Every example comes from an assessment of the fictional Sample Corp. Standard-library Python runs right in the browser.

Chapter 1 — What a report is for, and who reads it (lessons 1–5)

An assessment is only worth what its readers can act on. This chapter covers who you are writing for, what they need, and how to settle the scope and structure.

What an assessment report is for

The three jobs of a report: decisions, fixes and accountability. Why the report is the only thing an assessment leaves behind.

Free

Know your readers

What executives, developers, operations and auditors each want from a report, and how to write the same finding for each of them.

Free

Assessment types and how their reports differ

Vulnerability assessments, penetration tests, red team exercises and configuration audits. What the job checks decides what the report centres on.

Free

Stating scope, period, assumptions and limits

The authorisation reference, what was in and out of scope, assumptions, and what could not be done. Making clear where "no issues" actually applies.

How the whole report is structured

Cover, version history, executive summary, findings list, each finding, appendices. A structure that gets more detailed the further you read.

Chapter 2 — Records and evidence (lessons 6–10)

A good report grows out of the records kept during the assessment. This chapter covers work logs, evidence, and how to keep sensitive data out of the report.

Keeping a work log

Log time, target, type of work and result, one line each. State the time zone and record anomalies and pauses as they happen.

Collecting and keeping evidence

Manage screenshots and log excerpts that back up findings with naming rules and hash values, and decide up front how they are stored and destroyed.

Keeping sensitive data out

Keep personal data, credentials, tokens and card numbers out of the report: masking with regular expressions, then a final check by eye.

Writing verification steps

Write at a level developers can use to check their own fix: observable facts and expected results, not attack steps.

Building findings from your records

One root cause, one finding. When to merge, when to split, and how to write a finding that spans several targets.

Chapter 3 — Rating the risk (lessons 11–15)

How urgently the same issue needs fixing depends on the situation. This chapter covers rating with CVSS and adjusting for the business context.

Severity is not priority

Keep technical severity and business priority apart. Why CVSS measures severity rather than risk, and how to state a recommended fix-by date.

CVSS v3.1 base metrics

The eight base metrics and the vector string. Implementing the specification's equations and the Roundup function in Python, checked against known vectors.

What changed in CVSS v4.0

Four metric groups, the new Attack Requirements metric, the end of Scope, and names such as CVSS-B. How scores come from a lookup, and reporting alongside v3.1.

Adjusting ratings for the business and environment

Adjusting F-01 with the Security Requirements in the Environmental metrics. How to treat compensating controls, and the evidence needed before lowering a rating.

Confidence levels and false positives

Showing how certain each finding is with three levels: confirmed, likely and unconfirmed. Never pasting raw tool output, and recording what you ruled out as false positives.

Chapter 4 — Writing findings (lessons 16–21)

Findings are the most-read part of any report. This chapter turns writing a single finding, from its title through impact, fix and references, into a repeatable pattern.

The shape of a finding

Eight fields: title, severity, affected asset, summary, impact, evidence, remediation and references. How each reader uses them, with F-03 written out in full.

Writing titles and summaries

A title says what is wrong and where, in one sentence. Fixing weak titles, writing a three-sentence summary, naming the affected asset, and keeping terms consistent.

Writing impact in business terms

Translating technical impact into effects on customers, revenue and legal obligations. Who could be affected and how, the conditions involved, and avoiding exaggeration.

Writing the remediation

Separating root fixes, interim measures and defence in depth. Writing at an actionable level, down to setting names, and adding a way to verify the fix.

Adding references

When to use CWE, the OWASP Top 10, ASVS, vendor documentation and JVN. Why the version matters, with references for F-01 to F-07.

Fixing common bad findings

Rewrite three typical bad findings, a pasted tool output, an overstated impact and a vague fix, as before and after.

Chapter 5 — Summaries and the big picture (lessons 22–26)

A list of findings alone does not show the big picture. This chapter covers the executive summary, root causes, tables, and machine-readable appendices.

Writing the executive summary

One page that executives read in a few minutes. Lead with the conclusion, translate the jargon, and keep it to three recommendations.

Overall trends and root causes

Group the seven findings by what they share and trace them back to gaps in the development process, writing assumptions as assumptions.

Showing the whole with tables and charts

Tally findings by severity and by target with Python, and avoid comparing risk by counts alone.

Machine-readable appendices (CSV and JSON)

Export the findings list with the csv and json modules, for importing into ticket systems, and where SARIF fits.

Quality checks and review

Have someone else review on three axes, technical, writing and sensitive data, and catch inconsistent terms with Python.

Chapter 6 — After delivery (lessons 27–30)

Handing over the report is not the end. This chapter covers the debrief, retests and tracking fixes, and ends with building your own template.

Running the debrief

Timing a 60-minute debrief, answering questions, and separating facts from opinions. Record what was decided.

Retests and updating the report

Report retest results as a status per finding, and issue a new version while keeping the original ratings.

Tracking fixes and accepting risk

One finding per ticket, with deadlines by severity. Record risk acceptance with the approver, the reason and a review date.

Building your own report template

Pull the whole course together into a template, a finding skeleton, a style guide and a pre-delivery checklist.

Once you have finished all 30 lessons, look at the other side of the job, receiving a report and fixing what it says, in the Blue Track courses. The course order is on the security track page. Membership unlocks every course.