Scan, assessment, test
A scan is a tool run against a target list. It produces findings, including findings that are not real.
An assessment scopes the work, runs the tooling, confirms what the tooling reported, removes what cannot be confirmed, and ranks what is left against your environment rather than against a generic severity score. A penetration test then goes further and proves exploitability on a narrower scope.
Why confirmation is most of the value
Automated tooling over-reports. A raw scan of a moderately sized estate routinely produces hundreds of findings, a meaningful share of which are wrong, duplicated, or irrelevant because of a compensating control the tool cannot see.
Handing that file to an engineering team is worse than handing them nothing, because it burns their trust in the next report too. Confirmation is the step that turns volume into a work queue.
What severity should account for
A vendor severity score describes the vulnerability in the abstract. Your severity depends on where it sits.
- Is the affected system reachable from the internet, or only internally
- What would an attacker gain, specifically, in your architecture
- Does an existing control reduce the practical risk
- How much effort does exploitation take
- How hard is the fix, and does fixing it break something else
What arrives at the end
Findings across the systems you put in scope, each ranked by severity, each with remediation steps, plus one retest once the fixes are in.
The retest matters more than it sounds. It is the difference between a closed ticket and a verified fix, and a surprising number of fixes do not hold the first time.