Stakeholders

Sections of the report

Skeleton of the report

Putting all of the above:

| Sections | Content | %of report | Target Audience/Stakeholder | | --- | --- | --- | --- | | Section-1 | Summary | 5-10% | Business + Security | | Section-2 | Vulnerability Write-ups | 70-90% | Technical | | Section-3 | Appendices | 10-20% | Security |

Report Section 1: Summary

Although the summary typically appears at the start of the report, it is written last because it is difficult to write it without completing other sections of the report first.

Summary Structure

• [OVERVIEW]

  What was tested? Type of system or application, Goal of this test, Scope, Level of coverage achieved

• [RESULTS]

  Findings. What did the assessment uncover? Is the system secure? Explain.

• [IMPACT]

  Real-world impact:

  What does it mean for our business or system?

  Is it exploitable by internal or external threat, given where and how the system is deployed?

  What if the impact if the issue remains unaddressed?

• [REMEDIATION DIRECTION]

  What next? What actions should the organisation next to eliminate or mitigate the issue?

Summary of a Summary

Break down summary into the following two parts, if a single summary can’t meet the needs of business as well as security stakeholders:

• Executive Summary
  • Aim at business stakeholders
  • Avoid technical jargon
  • Overall security posture
  • Focus on business risk
• Findings & Recommendation
  • Aim at security stakeholders
  • Highlight nuances such as - a combination two-or-more low-scored risks has higher business impact

Report Section 2: Vulnerability Write-Ups

The largest section of the report.

Structure of a Good Write-UP

• Title - A short, descriptive heading
• Risk Rating - A risk rating for the discovered vulnerability. Vulnerabilities should always be rated in isolation, as if all other vulnerabilities did not exist and should either use the client's risk rating matrix or a public one, such as CVSS.
• Summary - A brief explanation of the vulnerability and its potential impact in plain language.
• Background - Provide additional context to explain the vulnerability and why this vulnerability happens to exist in our system and why addressing it matters?
• Technical Details & Evidence - Where and how the issue was found? Include requests, responses, payloads, and screenshots or code snippets if needed.
• Impact - What an attacker could realistically do with this vulnerability.
• Remediation Advice - Clear, actionable steps to resolve the issue.
• References - (Optional) Links to relevant vendor documentation or guidance to support the fix.

Report Section 3: Appendices

Thinks of appendices as audit trail.

It shows the work done, backs up findings, allows for informed follow-ups, long after the initial assessment is over.

Appendices don’t usually follow a particular format, but at least include the following two appendices always.

Assessment Scope

• Record how close the assessment was to what was originally scoped in the Rules of Engagement

Assessment Artefacts

• List out changes made during the testing.
  • Which of the changes were permanently required, which were temporary
  • Which of the temporary changes were reverted back, and which needs to be reverted back at a future time - at a specific day/time or when specific conditions are met or when specific situations are arrived at