Type to search across the blog, guides, tools, and services.
A vulnerability assessment is an automated scan that lists known weaknesses across your systems. A penetration test is a manual, hands-on attempt to exploit those weaknesses, chain them together, and prove real business impact. Most compliance frameworks and enterprise vendor reviews require a penetration test specifically. A scan alone does not satisfy SOC 2, PCI DSS, or most security questionnaires.
These two terms get used interchangeably in sales conversations, which is exactly how companies end up buying a $200/month scanning tool when an auditor is asking for a penetration test, or paying pentest rates for what is really just a scan with a logo on it.
They're related, not the same thing, and the difference is the method: software checking for known signatures versus a person trying to break in.
A vulnerability assessment runs automated tooling against your systems and compares what it finds to a database of known vulnerabilities and misconfigurations: missing patches, outdated software versions, weak TLS configurations, exposed services. It is fast, cheap, repeatable, and finds a real and useful list of issues. It cannot tell you whether those issues are exploitable, and it cannot find flaws that don't match a known signature, things like business logic errors, broken access control between two user accounts, or an authorization gap that only shows up when someone deliberately tries to break the intended flow.
A penetration test starts where the scan stops. A tester manually works through the application or network the way an attacker would: chaining a low-severity finding with a second one to reach something serious, testing whether one customer's account can reach another's data, and validating exploitability rather than just flagging a version number as out of date. The output is a report of confirmed, reproducible findings with real business impact, not a list of theoretical possibilities.
| Vulnerability assessment | Penetration test | |
|---|---|---|
| Method | Automated scanning tools | Manual testing by a human, tool-assisted |
| Finds | Known CVEs, missing patches, misconfigurations | Business-logic flaws, broken access control, chained exploits, plus the same known issues |
| Proves exploitability | No: flags theoretical risk | Yes: findings are demonstrated, not assumed |
| Typical cost | Low: often a monthly tool subscription | Higher: a scoped, one-time or annual engagement (see the cost guide) |
| Typical frequency | Continuous or weekly/monthly | Annually, or after major changes |
| Accepted for SOC 2 / PCI DSS / vendor reviews | Rarely, on its own | Yes: this is usually the specific artifact requested |
If you want ongoing visibility into new CVEs and misconfigurations as they appear, or you're not yet at the stage where a full manual test is justified, a scanning tool run on a regular schedule is the right starting point. It's also the right complement to a pentest, not a replacement for it. Most mature security programs run continuous scanning between annual penetration tests, so new known vulnerabilities don't sit undetected for a year.
You need a penetration test specifically, not just "a security check," when a compliance framework or an enterprise customer's vendor review asks for one by name (SOC 2's CC4.1/CC7.1, PCI DSS Requirement 11.4, a HIPAA-relevant risk assessment, or a security questionnaire), when the application handles sensitive data or money and a scan alone wouldn't catch a broken authorization boundary, or before a major launch where the cost of a missed business-logic flaw is high.
In most mature setups, yes, and they feed each other. Continuous vulnerability scanning catches new known issues fast and cheaply between engagements; the annual (or post-major-change) penetration test is where a human finds what the scanner structurally cannot. If you can only afford one right now and a compliance deadline or customer review is the driver, get the penetration test. It's the artifact being requested, and it will usually surface the scan-level findings too, just not on a continuous schedule.
Almost never on its own. SOC 2 auditors and PCI DSS QSAs typically expect an independent penetration test specifically, because a scan cannot demonstrate that a finding is exploitable or test business logic. Some auditors will accept a scan as a supplement to a pentest, not as a replacement for one.
Because it is a person's time, not a tool subscription. A scan runs the same automated checks in minutes regardless of how many customers use it; a penetration test requires a skilled tester manually working through your specific application or network for days, which is why the cost tracks scope and complexity rather than a flat monthly fee.
It shouldn't. A pentest is a point-in-time snapshot: accurate the day it's delivered, and gradually less so as new CVEs are disclosed and your systems change. Continuous or scheduled scanning is what keeps you covered in between tests; the two are complementary, not substitutes.
A common baseline: continuous or at least monthly automated scanning, and a full manual penetration test annually or after any significant change (a new major feature, an architecture change, or a new compliance requirement). Compliance frameworks sometimes set the exact cadence explicitly, so check what your specific SOC 2, PCI DSS, or contractual requirement states.
Book a free 30-minute scoping call. We agree the scope, timeline, and a fixed price up front, with no obligation and no surprises for your deadline.