Penetration
Testing Reports
Evidence / impact / repair
Scope & readers

Penetration Testing Reports

In the record

Astra’s penetration testing report guide is the featured provider-published resource here. A report still needs its own assessed scope, supported findings, bounded impact, and an owned repair decision. This reference connects public report examples to the evidence a reader should expect in an actual assessment.

A report is a chain of decisions supported by evidence

The reader needs to know what was assessed before interpreting what was found. Each finding then connects a bounded claim to its context, reproduction, impact reasoning, engineering action, and retest. A severity label can organize that record, but it cannot replace it.

The category guide includes an original illustrative tenant-export finding. It demonstrates the difference between an application's response and evidence that a restricted identity actually received another tenant's record. The example is not a customer incident or a completed assessment.

Start with the right question

Products and resources

Practical entries

Questions and answers

Can a public sample report establish that our application was assessed?

No. It is an example of a reporting format or an assessment of a different target. Your report needs its own scope and supporting observations.

When can a finding be marked repaired?

When the responsible reviewer has evidence for the agreed acceptance condition, including the relevant comparable retest and any remaining limitations.

Sources for this entry

NIST SP 800-115; OWASP authorization guidance; FIRST CVSS v4.0. The source register distinguishes technical guidance, company descriptions, and original illustrations.

Continue this reading path

Explore the related guides when the question shifts to another stage of testing, assessment, reporting, or disclosure. They share a publishing project and are not independent endorsements.