Reporting

Core principles

• State the tested surface, assumptions, authorization and time window clearly.
• Write each finding so technical teams can reproduce it without guessing.
• Explain exploitability and business impact together instead of treating them as separate stories.
• Offer remediation paths that are operationally realistic and prioritized.
• Document retest boundaries so unresolved exposure stays visible.

Report architecture

A strong assessment report separates decision-ready context from the technical record without weakening either layer.

• Executive summary: objectives, material exposure, likely business outcomes and the few decisions that need attention now.
• Scope and method: tested assets, exclusions, assumptions, authorization, time window, constraints and validation approach.
• Finding register: one stable identifier per issue, affected assets, status, severity and accountable remediation owner.
• Technical findings: reproducible evidence, attack narrative, impact, root cause and a practical remediation path.
• Appendices and retest: evidence inventory, limitations, tooling notes, change log and explicit closure criteria.

Reproducible finding template

1. Observation: state what was verified, where it exists and under which tested conditions.
2. Evidence: preserve the minimum request, response, command output or timeline needed to prove the claim.
3. Attack path: explain prerequisites and the shortest validated sequence from entry condition to security impact.
4. Impact: connect confidentiality, integrity, availability or trust loss to the affected process and asset owner.
5. Remediation: distinguish the immediate containment step from the durable design or control change.
6. Validation: define the observable result that will count as fixed during retest.

Severity and remediation priority

Technical scoring is an input, not the complete decision. Record the scoring method and vector, then add the environment-specific facts that change real exposure.

• Separate severity from remediation priority; a moderate issue on a critical trust path may need action before a higher-scored isolated weakness.
• Document exploit prerequisites, privilege level, user interaction, repeatability, detection likelihood and realistic blast radius.
• Account for asset value, data sensitivity, internet exposure, compensating controls and chained findings.
• State uncertainty and untested assumptions instead of converting them into false precision.

Evidence quality and handling

• Timestamp evidence and map it to an in-scope asset, account and finding identifier.
• Redact secrets and personal data while preserving enough context for independent verification.
• Prefer the smallest decisive proof; avoid destructive demonstrations when a safe control test establishes impact.
• Store raw material separately from the distributed report and apply the agreed retention and deletion schedule.
• Use captions and annotations so screenshots support the narrative rather than replace it.

Delivery and retest workflow

• Run a technical fact check with system owners before final publication without negotiating away verified risk.
• Present executives with exposure, decisions and ownership; present engineers with evidence, root cause and acceptance criteria.
• Track accepted risk, deferred work and compensating controls as explicit outcomes rather than silent omissions.
• During retest, verify the original path, plausible bypasses and adjacent instances, then record fixed, partially fixed or unresolved status.

Selected public references

• first.org · CVSSfirst.org/cvss/
• OWASP Risk Rating Methodologyowasp.org/www-community/OWASP_Risk_Rating_Methodology
• pentest-standard.readthedocs.io · Reporting.htmlpentest-standard.readthedocs.io/en/latest/reporting.html
• OWASP WSTG · 5 Reportingowasp.org/www-project-web-security-testing-guide/latest/5-Reporting/