
The service
Penetration testing and red teaming
Every finding reproduced by hand, ranked, and re-tested after the fix.
Compare
A vulnerability scan is automated breadth worth running continuously; a penetration test is a person chaining findings toward an objective.
Option A
Penetration test
Option B
Vulnerability scan
Overview
A vulnerability scan and a penetration test are different instruments that answer different questions, and the difference decides what gets found, what you pay for, and whether the report satisfies an auditor or an enterprise customer's security questionnaire.
A vulnerability scan is software: it fingerprints your systems and matches them against a catalogue of known weaknesses, missing patches, outdated versions, exposed services, and common misconfigurations. A penetration test is a person: someone who tests your systems by hand, exploits what they find, and chains individually minor weaknesses into an attack path with an objective at the end.
Scans are cheap enough to run against everything you own, continuously, and they catch the drift that accumulates between tests. A penetration test answers the question a scan cannot: what could a determined person do to us? Black Shard uses scanners inside tests as instruments, and findings are manually verified before they are reported.

| Dimension | Penetration test | Vulnerability scan |
|---|---|---|
| What it finds | Exploitable attack paths, including the classes no signature describes: business-logic flaws, broken access control, authentication weaknesses, tenancy-isolation failures, and chains of minor issues that combine into a major one. | Known, catalogued weaknesses: missing patches, outdated software versions, exposed services, weak TLS configurations, and common misconfigurations matched against a signature database. |
| False positives | Findings are manually verified against your systems before they are reported. | False positives are built in. Scanners infer from version banners and response patterns, so the output always needs human triage. |
| Exploitation depth | Findings are exploited and chained toward an objective. A verbose error message, a predictable identifier, and a weak password-reset flow are three low-severity entries to a scanner and one account takeover to a tester. | Detection stops at identification. A scanner flags a weakness; it does not exploit it, cannot combine it with anything else, and cannot tell you what it is worth to an attacker. |
| Reporting | Ranked findings with severity, business impact, reproduction steps a developer can follow, and a fix for each. | A machine-generated list, typically ordered by generic CVSS score with no view of what the weakness would cost your business. Useful as a work queue. |
| Compliance acceptance | What auditors and enterprise security questionnaires mean when they ask for penetration testing: a human-led test with a named methodology, a dated report, and evidence. We test against the OWASP testing guides and ASD guidance. | Satisfies continuous-monitoring and patch-verification expectations, and supports vulnerability-management controls. Rarely accepted as a substitute where a penetration test has been asked for by name. |
| Cost basis | Priced on scope. We run offensive work as a fixed-scope engagement with a defined target and timeframe, so the scope is settled before the work starts. | Tooling or subscription pricing, low enough per asset to run across your whole estate. That low cost is what makes continuous coverage affordable. |
| Cadence | Point in time. Annually for most businesses, and after anything material changes: a new application, a major release, a re-platform, an acquisition. | Continuous or scheduled. Weekly or monthly at minimum, plus after every patch cycle, so that regressions and drift are caught within days. |
What it finds
Penetration test
Exploitable attack paths, including the classes no signature describes: business-logic flaws, broken access control, authentication weaknesses, tenancy-isolation failures, and chains of minor issues that combine into a major one.
Vulnerability scan
Known, catalogued weaknesses: missing patches, outdated software versions, exposed services, weak TLS configurations, and common misconfigurations matched against a signature database.
False positives
Penetration test
Findings are manually verified against your systems before they are reported.
Vulnerability scan
False positives are built in. Scanners infer from version banners and response patterns, so the output always needs human triage.
Exploitation depth
Penetration test
Findings are exploited and chained toward an objective. A verbose error message, a predictable identifier, and a weak password-reset flow are three low-severity entries to a scanner and one account takeover to a tester.
Vulnerability scan
Detection stops at identification. A scanner flags a weakness; it does not exploit it, cannot combine it with anything else, and cannot tell you what it is worth to an attacker.
Reporting
Penetration test
Ranked findings with severity, business impact, reproduction steps a developer can follow, and a fix for each.
Vulnerability scan
A machine-generated list, typically ordered by generic CVSS score with no view of what the weakness would cost your business. Useful as a work queue.
Compliance acceptance
Penetration test
What auditors and enterprise security questionnaires mean when they ask for penetration testing: a human-led test with a named methodology, a dated report, and evidence. We test against the OWASP testing guides and ASD guidance.
Vulnerability scan
Satisfies continuous-monitoring and patch-verification expectations, and supports vulnerability-management controls. Rarely accepted as a substitute where a penetration test has been asked for by name.
Cost basis
Penetration test
Priced on scope. We run offensive work as a fixed-scope engagement with a defined target and timeframe, so the scope is settled before the work starts.
Vulnerability scan
Tooling or subscription pricing, low enough per asset to run across your whole estate. That low cost is what makes continuous coverage affordable.
Cadence
Penetration test
Point in time. Annually for most businesses, and after anything material changes: a new application, a major release, a re-platform, an acquisition.
Vulnerability scan
Continuous or scheduled. Weekly or monthly at minimum, plus after every patch cycle, so that regressions and drift are caught within days.
Penetration test
You run bespoke code: a customer-facing application, an API, a client portal. Scanners match signatures; your business logic has no signature.
An enterprise customer or an auditor has asked for your latest penetration test report. A scan export will not close that request.
Vulnerability scan
Budget forces a choice and nothing has ever been scanned. Scan first, fix the obvious, then bring in a human to test what remains. Testing before basic hygiene wastes tester hours on findings a scanner would have handed you cheaply.
In depth
A scanner probes your hosts and applications, fingerprints what is running, and compares the results against a database of known weaknesses: unpatched software, deprecated protocols, exposed administrative interfaces, default credentials, weak cipher suites. It can sweep an entire estate overnight and repeat the sweep every week without fatigue.
For known, patchable weaknesses, a scanner finds them faster and cheaper than any human ever will.
The limits are structural. A scanner detects what has a signature. It cannot understand what your application is for, so it cannot see that an invoice endpoint returns other customers' invoices when the identifier is changed. It cannot exploit what it finds, so it cannot tell you which of three hundred flagged items combine into a path to your data. Broken access control is the clearest example: the flaw is in what your application permits, it leaves no trace in what it runs, and no signature can describe it.
A tester starts with an objective: reach the client data, take over an account, cross the tenancy boundary. They exploit what they find, then use each foothold to look for the next one, chaining findings a scanner would score as trivial into paths a scanner cannot represent at all.
We work to the OWASP testing guides, take only the access the work requires, and document exactly how far we got and how.
You get a ranked report where every finding has been manually verified, with the reproduction steps, the business impact, and a fix for each. When your team has shipped the fixes, we re-test to confirm them.
The two answer different questions on different clocks. A scan answers: is anything known-broken exposed right now? That question needs asking continuously, because estates drift, patches get missed, and new services appear without ceremony. A penetration test answers: what could a determined person do to us?
That question needs asking at least annually, and whenever something material changes, because the answer depends on how your systems fit together; no single weakness determines it.
The mature pattern is a human-led test on an annual or per-change cadence, with continuous scanning in between. The scan keeps the known weaknesses swept up so the next test spends its hours on the flaws only a human can find.
No. A scan is software matching your systems against a catalogue of known weaknesses. A penetration test is a person exploiting and chaining weaknesses toward an objective, including whole classes a signature cannot describe: business logic, access control, authentication flows. The confusion persists because both produce a findings report. The resemblance ends there.
Ask who is doing the testing and for how many days, whether every finding comes with reproduction steps a developer can follow, and whether a re-test of the fixes is included. A scan has no human hours to account for and exports generic vulnerability descriptions in place of reproduction steps.
A scan costs a fraction of a test, which is exactly why it should run continuously. A penetration test is priced on what the engagement has to cover: how much attack surface, how many environments, how many tenancies. Both the scope and the price are fixed before testing begins.
Scan continuously, or monthly at minimum, plus after every patch cycle. Test annually, or after any material change: a new application, a major release, a re-platform. Between tests, the scan catches regressions and drift.
Yes, as instruments for coverage. Raw tool output is not forwarded. Findings are manually verified against your systems before they are reported, written up with reproduction steps and a fix, and ranked by impact. On fixed-scope offensive work, a re-test of your fixes is included.
Go deeper

The service
Every finding reproduced by hand, ranked, and re-tested after the fix.