What belongs in it
Scope and methodology come first, because a finding means nothing without knowing what was and was not examined.
- Scope: exactly which systems, environments and accounts were in scope, and the test window
- Methodology: how the testing was performed and against what reference
- Summary: what the overall picture is, readable by someone non-technical
- Findings: each one with severity, evidence, reproduction steps and remediation
- Out of scope: what was excluded, so nobody mistakes silence for assurance
- Retest: the status of each finding after fixes, when the retest has been run
What a real finding looks like
A finding needs the request that produced it, the account it came from, what came back, and the fix. That is enough for a developer to reproduce it without booking a meeting.
A finding that says "the application is vulnerable to broken access control" with a severity label and no request is a category, not a finding. You cannot fix a category.
How to spot a scanner export
The signs are consistent. Findings in tool phrasing rather than prose. Generic remediation text identical across findings. The same count as the raw scan, meaning nothing was confirmed. No mention of chaining, because tools do not chain.
And the clearest tell: no reference to your business. A report that never names what your application does cannot have tested your business logic, which is where the findings specific to you live.
What to do with it first
Read the out-of-scope section before the findings. It tells you what you still do not know, which is more important on day one than the list of what you do.
Then ask your own team what their monitoring saw during the test window. If a tester worked against your systems and nothing alerted, that is a finding of its own, independent of everything in the report.