Application security
OWASP assessment vs penetration test: which one your requirement names
Suppliers use the two terms interchangeably. Contracts, insurers and regulators do not. How to read the clause you have been given before you buy the wrong thing.
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.
The formal version adds an accreditation layer on top. A recognised scheme has assessed the provider, the report follows a defined structure, and an attestation letter states the scope, the dates and the outcome in a form a third party is willing to rely on. That letter is usually the actual deliverable, in the sense that it is the thing the requirement was written to obtain.
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; the formal test is how an organisation obtains a document a third party will rely on. What each one actually contains matters less, at the point of purchase, than which of those two problems you are trying to solve.
Quick answers
Common questions
Is a penetration test always better than an assessment?
No, they answer different questions. An objective-led test tells you whether a skilled attacker could reach a stated goal, and may stop looking once it has an answer. A coverage-led assessment tells you what weaknesses a published methodology finds across the whole application, which is more useful when the aim is to fix things systematically. The better purchase is the one that matches the question, and where a requirement names an accreditation, only one of them qualifies at all.
Can you issue an attestation letter after an assessment?
No. We produce a report describing what was tested, what was found, the reasoning behind each severity, and what was verified after the fixes. We do not issue attestations, conformance statements or certifications, because no accreditation body stands behind us and a letter of that kind would be worth nothing to the party relying on it. Where a contract requires one, that is a supplier decision to make before work starts.
Our customer asked for a pentest report. What should we send?
Ask them what the requirement is for before sending anything. In a large proportion of cases the underlying need is evidence that an independent party examined the application and that the findings were addressed, which an assessment report answers directly. Where the need is a document their own auditor or insurer will rely on, only an accredited provider’s output will do, and discovering that after you have commissioned the wrong engagement is the expensive path.
Does doing an assessment first make the certified test cheaper?
Usually, though nobody should promise a figure. An accredited engagement spends part of its budget finding issues that a coverage-led review would have surfaced at a lower rate, and arriving with those already fixed lets the more expensive testers spend their time on the questions only they can answer. It also reduces the chance of a formal report landing full of findings you already knew about.