What if the report we received is just a scanner export?

Ask which findings were manually validated and how. A tool result without a reproduced path is a candidate, not a finding. If the provider cannot answer, that is your answer.

Does a penetration test report satisfy SOC 2?

It supports a control rather than satisfying the criteria by itself. An auditor wants the scope, the dates, the findings and the evidence that the findings were remediated or accepted. A report with no retest record usually generates a follow-up question.

Should findings carry CVSS scores?

Only if you use CVSS. A score copied from a database without adjusting for your environment is misleading, because the same vulnerability behind an authenticated admin page and on a public endpoint are not the same risk.

What should a retest cover?

The findings you agreed to fix, on an environment that still matches the tested scope. The record should separate resolved, partially resolved and outstanding rather than reporting a single pass.

What a Penetration Test Report Should Contain

A usable penetration test report names the assets and the window tested and states what was out of scope. Every finding carries reproducible evidence and a retest status. Sorami sends a report back when the scope section lists only a tool name, because a result without stated coverage cannot tell you what it does not cover.

Illustrative example. Not a client report.

Read the nine parts below against a real document. This 19-page example uses synthetic findings only, with no real company, person or IP address in it.

Download the illustrative report (PDF)

The nine parts

If a section is missing, the report is hard to give to an engineer or an auditor.

Cover and labelling. Named organisation, dates, classification. If it is an example, it must say so on the cover.
Document control and authorisation. Environment, Rules of Engagement, tester source addresses. Without this, you cannot prove the test was allowed.
Executive summary. One page: overall risk, count by severity, what a non-specialist should do next.
Scope and method. Assets and roles, the standard followed, and what was out of scope.
Findings table. ID, title, severity, status. Readable in one minute.
Findings with evidence. Description and affected asset. Request and response evidence. Impact, likelihood and a recommended fix. Retest notes.
Positive observations. What held. Stops the report reading as if nothing works.
Retest section. Empty until fixes land, then filled. A report with no retest path is unfinished work.
Appendix. Severity model, tooling list, glossary. Keep it short.

Scanner export vs manual report

Check	Scanner dump	Usable report
Length	Dozens of pages of headers, SSL flags, and CVE lists.	Findings you can count. Informational noise omitted or in an appendix.
Evidence	Tool screenshot or a plugin id.	A request and response an engineer can replay, with a second role or tenant where it matters.
Fix	"Update the library" or "sanitise input".	Which check, which role, which object. Named control, not a slogan.
Auth	Unauthenticated or a single session that died at MFA.	Two accounts per role. Cross-tenant ids tried on purpose.

What auditors usually check

A dated window and named assets. A method beyond a tool name. Findings mappable to a control, and retest status. They rarely accept a CSV of CVEs as the annual test. Confirm the exact wording in the request you received. Do not assume.

Send it back if

There is no reproduced path, only a scanner id.
Roles and tenants were never tested.
Production was tested without written authorisation in the pack.
The fix line is generic and cannot be assigned to an owner.
There is no retest offer for reported items.

Ask for those five things in writing. If the vendor cannot supply them, you bought a scan.

What to do next

Read the scoping guide so the next test is sized by assets and roles. If you need the test itself, use the penetration testing page and start a scoping conversation.

What a penetration test report should contain.