Reporting security assessments

The idea

An assessment report explains scope, methods, limitations, findings, impact, and recommendations. Each finding should identify affected resources, reproducible behavior, minimal supporting evidence, and the conditions required. Prioritization includes business context, not only a generic severity label. Provide remediation options and a retest expectation. Avoid exposing unnecessary sensitive data in screenshots or report attachments.

In practice

A lab finding describes missing object-level authorization, shows the denied behavior expected after a fix, and recommends server-side permission checks.

A common misunderstanding

A successful demonstration is not enough if the owner cannot reproduce, understand, or remediate the weakness.

Check your understanding

What should a retest confirm?

Think it through: That the original issue and relevant variations are prevented without breaking legitimate use.

Turn evidence into a decision

A useful finding separates observation, interpretation, and recommendation. The observation states what happened under documented conditions. Interpretation explains the security boundary that failed and the plausible consequence. The recommendation describes the control that should change, ideally with enough detail for the responsible engineering team to choose an implementation. Mixing these layers makes assumptions look like established facts.

Imagine a fictional booking service where account A retrieves account B's synthetic invoice. The finding should identify the affected endpoint, account privileges, relevant request fields, and the expected ownership check. A redacted response containing the synthetic invoice identifier is sufficient evidence. A screenshot of an unrelated administrative page adds little and may confuse the issue.

Severity and confidence are different

A technically severe weakness can have limited current exposure, while a moderate weakness can matter greatly in a sensitive workflow. Explain those contextual factors separately. CVSS describes technical severity through defined metrics; an organization still needs asset importance, exposure, compensating controls, and operational consequences to make remediation decisions. Do not present a score as a complete business risk assessment.

Confidence should also be explicit. 'Confirmed using two test accounts' is stronger than 'a banner suggests an affected version.' Record untested assumptions, unavailable accounts, excluded services, and time constraints. These limitations help readers understand what the assessment establishes without implying exhaustive coverage.

Make closure measurable

A remediation ticket should say how the owner can verify success. For the invoice example, account A must be denied access to B's invoice, while B retains legitimate access. Retesting should include nearby variations such as another invoice endpoint or export workflow when those share the same authorization logic. A single patched route may leave the underlying design flaw elsewhere.

Practice by drafting a one-page finding with synthetic evidence and separate fields for affected component, prerequisites, observed behavior, consequence, recommendation, and retest criteria. Ask a peer to explain the issue without a verbal walkthrough. Anything they cannot reconstruct is a useful reporting improvement.

Keep exploring

• Penetration testing
• Incident reporting and handover
• Vulnerability management