Regulated teams usually need both. A vulnerability scan finds known weaknesses across many systems on a frequent schedule. A penetration test is a human-led attempt to break in, which finds chained and logic problems scanners miss. Two US financial rules mention both together, with different frequencies.
What each one does
A vulnerability scan compares what you run against databases of known flaws and misconfigurations. It is fast, repeatable and broad. It tells you what is publicly known to be wrong.
A penetration test tries to reach a goal, such as access to customer data, by combining weaknesses. A tester may find that two low-rated issues together give full access, or that an authorization check is missing in a way no database lists.
| Question | Vulnerability scan | Penetration test |
|---|---|---|
| Who or what runs it | Tool, often automated | Qualified person or team |
| Coverage | Broad | Targeted, deep |
| Frequency | Frequent to continuous | Periodic, often annual |
| Finds | Known flaws and misconfigurations | Chains, logic flaws, process gaps |
| Output | Long list ranked by severity | Narrative report with proof |
| Cost of a miss | Late fixes | Missed attack paths |
What the rules say
The FTC Safeguards Rule, for institutions it covers, calls for continuous monitoring or periodic penetration testing and vulnerability assessments. Without effective continuous monitoring, it asks for annual penetration testing and vulnerability assessments at least every six months and after material changes.
New York's financial services rule asks for penetration testing from inside and outside system boundaries by a qualified internal or external party at least annually, and automated scans plus manual review of systems the scans miss at a frequency set by the risk assessment, and promptly after material system changes.
So scans and pen tests are paired in both. Neither stands in for the other. This is general information, not legal advice.
Planning both without duplicating effort
- Run scans continuously on code, dependencies and images, and on a schedule for deployed hosts.
- Use scan output to set the pen test scope, so testers do not spend days rediscovering known issues.
- Give testers the architecture and a list of known open findings, then ask them to focus on abuse paths.
- Feed pen test findings back into the same tracker, with the same deadlines.
- Retest after fixes and keep the retest evidence.
Our post on DAST versus pen testing covers the tooling side.
Qualifications and independence
New York's text says a qualified party, internal or external. For other contexts, choose testers who were not involved in building the system, and write down how you assessed their qualifications.
Common mistakes
- Treating a scan report as a pen test.
- Running a pen test the week before an audit, then not fixing results.
- Scoping the test only to the web front end while the risk sits in an internal API.
- Leaving test findings outside the vulnerability tracker.
Where tooling helps
Safeguard covers the scan side with dependency, container, code and API scanning plus reachability analysis, and tracks findings against policy. It does not replace a human penetration test, and the two work together.
Quick check
Can automated scanning replace an annual pen test?
Under the text of the two rules above, the pen test is named separately from scanning. Check with counsel for your situation.
Should pen test findings follow the same SLAs?
Yes. One tracker and one set of deadlines keeps results from sitting in a PDF.
Sources
Last reviewed: 19 October 2026.
