Buyers usually arrive at this question with a sentence somebody else wrote. A clause in a customer contract, a line in an insurance schedule, a row in a questionnaire, a paragraph from a regulator. The sentence names one of these things, and the market sells both under either name, which is how companies end up paying for a competent piece of work that does not satisfy the requirement that prompted it.
This is a comparison written for that moment: what each product is, where they genuinely overlap, and how to tell which one the sentence in front of you is asking for.
The terms are not standardised
There is no authority that defines what may be sold as a penetration test. The phrase covers a twenty-minute automated scan with a logo on the front page and a three-week engagement by a specialist team, and both invoices will say the same thing. Nothing prevents either supplier from using the words.
What is defined, in specific contexts, is the surrounding paperwork. Certain schemes accredit providers and set out what their reports contain. Some regulations state criteria a tester must meet before their work counts. Card-payment rules require testing on a stated cadence with defined scope. When a requirement points at one of those, it is pointing at the accreditation, not at the technique.
The distinction that costs money is almost never technical. It is whose name is on the report and what body stands behind it.
What an OWASP-based assessment is
It is coverage-led. The engagement works systematically through a published methodology, typically the Web Security Testing Guide and the Application Security Verification Standard, so the deliverable can state which categories were examined and which were excluded. The value proposition is completeness against a public reference.
That framing suits a product team. It produces a list of things to fix, ordered, with reproduction steps and a retest, and it can be repeated later against the same reference so the second report is comparable with the first.
What a formal penetration test is
It is objective-led. The engagement is defined by a goal rather than by a checklist: reach cardholder data, obtain administrative control of the environment, move from the public interface to an internal system. Coverage is a means, and the tester is free to abandon a promising-looking area that turns out not to lead anywhere.
Penetration testing does not inherently require accreditation. Some procurement contracts and assurance schemes specify a qualified tester, accredited provider or particular report format. Confirm those requirements with the requester. Scope, rules of engagement, methodology and evidence determine the work; any credential requirement is an additional procurement condition.
Side by side
| OWASP-based assessment | Certified penetration test | |
|---|---|---|
| Question it answers | Does this application exhibit the weaknesses a published methodology looks for? | Can a skilled attacker achieve a stated objective against this target? |
| How scope is set | By coverage: named categories across a named application and its API. | By goal: whatever the agreed target includes, often reaching beyond the application. |
| Who may perform it | Any practitioner working to the public methodology. No body stands behind the work. | A provider accredited under a recognised scheme, or one meeting criteria a regulation sets out. |
| Principal deliverable | Reproduced findings, severity reasoning, remediation guidance and a verification pass. | A structured report plus an attestation naming scope, dates and outcome. |
| What it satisfies | Most security questionnaires, internal assurance, and evidence a customer’s risk assessment can rest on. | Contract clauses, insurers and regulatory requirements that name a certified test. |
| Typical trigger | A launch, an architecture change, or a buyer asking what testing you do. | A clause, a renewal, a scheme requirement or a supervisory expectation. |
| Repeatability | High. The same reference produces comparable reports over time. | Lower by design. Each engagement is shaped by its objective and its intelligence. |
| Whether we offer it | Yes. | No. We hold no accreditation for it and do not bid for that work. |
How to read the clause you were given
Four questions resolve nearly every case, and all four can be asked of the person who sent you the requirement.
- 01Does the wording name a scheme, an accreditation, a certification or a specific standard? If it does, the requirement is about the provider and no amount of technical quality substitutes for it.
- 02Does it ask for an attestation, a certificate or a letter, as opposed to a report or a summary of findings? Those nouns are the tell.
- 03Does it specify who may perform the test, or only what must be tested? A requirement that constrains the tester is not satisfied by a different tester doing better work.
- 04Is the requirement about evidence of testing, or about a document somebody downstream has to file? The second is far more common than suppliers assume, and it is the case where the paperwork genuinely is the point.
Regulated buyers are where this matters most. A financial entity subject to threat-led testing obligations is bound by criteria that describe the tester as much as the test, and an assessment does not become one by being thorough.
When the assessment is the right purchase
- You want to know what is wrong with your application and fix it, and no external document is required.
- A questionnaire asks for independent testing with findings and remediation evidence, without naming an accreditation.
- You are preparing for a formal test later and would rather not pay accredited rates to discover the obvious problems first. This sequence saves money reliably.
- You have changed something structural, particularly in authentication or authorisation, and want it examined before it meets a customer.
When it is not, and what to do instead
If the requirement names a certified test, an accredited provider or a formal attestation, an OWASP-based assessment will not satisfy it. We are not an accredited penetration-testing provider, we are not a notified body under any European regulation, and we issue no conformance statements or certifications. A buyer in that position needs a different supplier, and the useful thing we can do is say so on the first call rather than at the report stage.
It is worth knowing that a third product exists as well. Red teaming is objective-led like a penetration test but adversarial about detection too, testing whether your monitoring notices and how your people respond. It answers a question about the defenders rather than about the code, and buying it before the application has been examined at all is an expensive way to be told what a cheaper engagement would have found.
The honest summary is that these are complements more often than alternatives. The assessment is how a product team finds and fixes things on a repeatable cadence; a penetration test explores attack paths within agreed rules, and some buyers additionally require specific provider credentials or reporting. What each one actually contains matters less, at the point of purchase, than which of those two problems you are trying to solve.