A vulnerability scan is an automated inventory of known weaknesses across your systems. A penetration test is a scoped, human-led attempt to chain those weaknesses into real access and show what that access reaches. For a 50 to 500 person company with no security team, buy the scan first and run it on a schedule. Buy the penetration test second, for the few systems that face the internet or hold the most sensitive data, after the scan’s obvious findings are fixed.
This guide explains what each one produces, why the order matters, which test fits which situation, and what a first year looks like without an in-house team.
The difference in one table
| Vulnerability scan | Penetration test | |
|---|---|---|
| Question it answers | Which known weaknesses exist across the environment? | Which weaknesses can be combined into access an attacker would actually get? |
| How it works | Automated tooling checks software versions, configurations and patch levels against vulnerability databases | An experienced tester, working under written rules of engagement, attempts exploitation, privilege escalation and lateral movement within an agreed scope |
| Breadth or depth | Broad: many hosts, many findings, most of them low risk on their own | Deep: a small number of attack paths, each proven with evidence |
| Typical output | A ranked list of findings with severity and remediation guidance | A narrative of attack paths, the evidence behind each one, business impact and a retest plan |
| Common cadence | Recurring, at least quarterly for internet-facing systems | Annually, and after significant change such as a cloud migration or a new customer portal |
| Who does the work | Tooling run by your IT provider or a vendor, with a person triaging the results | Experienced testers, with scope and authorization agreed in writing before any test begins |
The table is the whole argument in miniature. A scan tells you what is weak. A test tells you what an attacker can do with those weaknesses together.
Why the scan comes first
A scan is the cheaper, faster, repeatable check, and it catches most of the findings a tester would otherwise spend billable hours rediscovering. Unpatched software, exposed administration panels, default credentials, expired certificates and forgotten servers show up in a scan within hours. Paying a senior tester to report those findings is paying senior rates for tool output.
The scan also produces the evidence a buyer or insurer asks for first: a dated list of findings, an owner for each one, a remediation record and a repeat schedule. An authenticated scan, one that logs in to hosts with credentials, is worth the extra setup because it can see missing patches inside a system rather than guessing from the outside.
Order matters for a second reason. A penetration test is most useful when it confirms that the important paths are closed. If the scan has not been run and the critical findings have not been fixed, the test spends its time on problems the organization already knew it had, and the report reads as a list of things to do rather than a picture of what an attacker would reach.
What a penetration test adds
A penetration test answers the question a scan cannot: how do these weaknesses combine? A low-severity finding on a file share, an over-privileged service account and a missing alert can look harmless as three separate rows in a scan report. Chained together, they can give an attacker administrative control of a cloud tenant. The tester proves that path, shows the evidence and explains which controls stopped it or failed to.
A good test also tests the controls you think are working. Multifactor authentication, network segmentation and endpoint detection each have a stated purpose. A test checks whether they actually interrupt the path, and if they do not, the finding tells you where the gap is.
DSE’s penetration testing is offered in three wave-one scopes:
- External network and web application testing, for internet-facing systems, portals and APIs.
- Cloud configuration and identity attack-path testing, covering AWS, Azure and Microsoft 365.
- AI and LLM application testing, covering prompt injection, tool abuse and data exfiltration in applications built on language models.
Internal network and assumed-breach testing are outside that offer. An organization that needs them should use a provider that offers them, and DSE will say so during scoping rather than stretch the engagement.
Frameworks and questionnaires: what they expect
NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment, is the reference most assessors use to plan both activities. It treats scanning and penetration testing as separate techniques, each with its own planning, scope and rules of engagement. Using that structure in your own paperwork makes the evidence easier for an outside reviewer to follow.
The FTC Safeguards Rule, 16 CFR Part 314, applies to covered non-bank financial institutions. It requires continuous monitoring or periodic penetration testing and vulnerability assessments. Where continuous monitoring is not in place, it calls for annual penetration testing and vulnerability assessments at least every six months. Whether the rule applies to your business is a question for your counsel.
Customer security questionnaires tend to ask two things: how often you scan, and the date and scope of your last test. An insurer’s underwriting questions often ask the same. Write the answers from your records, not from memory, and keep the scan reports and the test report in the same folder so the answer can be produced on request.
Which test fits which situation
Use this table to choose the first purchase. Work down it and stop at the first row that describes your situation.
| Your situation | Buy first |
|---|---|
| No scan results in the last 90 days, or no record of who fixed what | A vulnerability scan with tracked remediation |
| Internet-facing web applications, APIs or a customer portal | An external web application test, after critical scan findings are fixed |
| Microsoft 365 and cloud identity hold customer or payroll data | A cloud configuration and identity attack-path test |
| Language model features that read or act on customer data | An AI and LLM application test covering prompt injection and tool abuse |
| A customer or insurer requires a dated, scoped test report | A penetration test with a written report and a retest of the fixes |
If more than one row fits, the cloud identity row usually wins for a company that runs Microsoft 365. Identity is the control most attackers go after first, and it is the one a small company can most often improve in a single quarter.
A first year without a security team
The sequence below assumes one part-time owner, typically the IT lead or an outsourced provider, with an executive sponsor who approves the spend.
- Month 1. Run an authenticated vulnerability scan of every in-scope host. Name an owner for each critical and high finding, with a due date.
- Months 2 and 3. Fix the critical and high findings. Rescan and keep the dated before and after reports.
- Months 3 and 4. Scope one penetration test to the internet-facing systems and the identity layer. Write the rules of engagement, the testing window and the emergency contacts before testing starts.
- Ongoing. Scan quarterly at minimum. Retest after significant change, including a new cloud environment, a new customer-facing application or a new AI feature with access to customer data.
A company in Georgia without internal security staff can have a fractional CISO in Atlanta own this sequence and keep the findings tracked from one cycle to the next. The owner does not have to be a full-time hire to make the record reliable.
For the broader program that these tests sit inside, read what a cybersecurity risk assessment includes and costs. The assessment tells you which systems matter most, and that list is the input for choosing what the penetration test covers.
Questions buyers ask
Can a vulnerability scan replace a penetration test? A scan answers a different question. It finds known weaknesses across many systems, while a penetration test shows which weaknesses combine into access an attacker would reach. Buy the scan first because it is repeatable, cheaper to run and removes the easy findings that would otherwise fill a test report.
How often should we test? Scan on a recurring schedule, at least quarterly for internet-facing systems. Test annually and again after material change, such as a cloud migration, a new customer portal or a new AI feature with access to customer data.
Will a scan satisfy a customer or an insurer? Often it is the first requirement, and it rarely is the only one. Most questionnaires ask for both the scan cadence and the date and scope of the last penetration test. Confirm the exact wording with the requester, and with counsel where a contract or regulation is involved.
What does a penetration test cost? Scope and fixed fee are set after a scoping call, based on the systems in scope and the attack paths to test. Penetration testing is not sold from a rate card. The penetration testing page lists the three wave-one scopes so you can see what a quote will cover before the call.
Do we also need an internal test? Internal network and assumed-breach testing are outside DSE’s offer. If your risk assessment points to internal exposure, a provider that offers that scope is the right source, and the scoping call is the place to confirm the boundary before any money changes hands.
The Bottom Line
Buy the scan first, fix what it finds, and then buy a penetration test for the systems that face the internet or hold the most sensitive data. The scan gives you a repeatable record. The test shows whether the record matters, because it proves which weaknesses an attacker could actually chain together. Skipping the scan to buy the test pays senior rates for a list the scan would have produced for less.
Ready to scope the test directly? See the penetration testing page for the three wave-one scopes and how DSE leads each engagement.
Key facts
- NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment, treats vulnerability scanning and penetration testing as distinct techniques, each with its own planning, scope and rules of engagement (NIST, current).
- The FTC Safeguards Rule at 16 CFR Part 314 requires covered financial institutions to use continuous monitoring or periodic penetration testing and vulnerability assessments, with vulnerability assessments at least every six months (eCFR, current).