What Is Penetration Testing?
- A penetration test is an authorised simulated attack on your own systems, performed to find out what an attacker could actually achieve.
- The defining feature is exploitation: a pentest PROVES a flaw is reachable, where a scan only reports that one might exist.
- Most organisations need one because a customer, an auditor, or a framework asked - and the useful version answers a sharper question than that.
- The traditional model is periodic and priced in human hours; continuous testing changes both.
A penetration test is an authorised, simulated attack on your own systems, carried out to find out what a real attacker could achieve. Someone with permission attempts to break in the way an adversary would, then documents what worked, how far it reached, and how to close it. The authorisation is what separates it from a crime, and the exploitation is what separates it from a scan.
That is the whole definition. Everything below is the part that actually decides whether a test was worth buying. What that looks like as a delivered engagement is on our web and API penetration testing.
What makes it different from a vulnerability scan
This is the single most useful distinction in the field, and it gets blurred constantly by people selling one as the other.
A vulnerability scan compares your systems against a catalogue of known issues and reports matches. It is fast, cheap, and it produces possibilities. A penetration test attempts to use those weaknesses, chains them together, and reports what it achieved. It produces facts.
The practical difference shows up in who does the work afterwards. A scan hands you a list and your engineers spend days establishing which entries are real. A test hands you a shorter list where each entry has already been proven, along with the steps to reproduce it.
| Vulnerability scan | Penetration test | |
|---|---|---|
| Method | Matches known signatures | Attempts and chains exploits |
| Output | Possibilities to triage | Confirmed, reproduced findings |
| Finds multi-step flaws | No, tests inputs in isolation | Yes, that is the point |
| Triage burden | Yours | Largely removed |
Put plainly: a scan tells you which doors might be unlocked. A test tells you which ones it opened, what was in the room, and which door it reached from there.
What a pentest actually looks for
Not mainly exotic memory corruption. In web applications the findings that matter are usually mundane and severe at the same time.
- Broken authorisation. Reaching data or actions belonging to another user or another tenant. The most common serious finding, and invisible to a test without credentials.
- Authentication and session weaknesses. Password reset flows that let you choose the target, tokens that are not properly validated, sessions that outlive logout.
- Injection. Getting the application to treat your input as instructions - into a database, a template, a command, or a request to another service.
- Business logic abuse. Driving a legitimate workflow in an illegitimate order or quantity. Applying a discount twice, skipping the payment step, cancelling after fulfilment.
- Exposure. Debug endpoints, verbose errors, backups, and administrative interfaces reachable from the internet.
The one that most rewards a good tester is business logic, because there is no signature for it. It requires understanding what the application is supposed to do.
Who needs one, and why they usually buy
Most organisations commission their first penetration test because someone external asked: an enterprise customer sent a security questionnaire, an auditor requested evidence, or a framework named it. That is a perfectly respectable reason and it produces a specific risk - buying the cheapest artefact that satisfies the request rather than the test that tells you something.
The sharper reason is the one worth holding on to. You want to know whether a stranger on the internet can reach your customers' data, and if so, how. If a report cannot answer that in a sentence, the exercise was compliance theatre.
On the compliance side specifically, frameworks differ more than people expect: PCI DSS requires testing outright, SOC 2 expects it without naming it, and DORA distinguishes general testing from human-led TLPT. We keep that mapped framework by framework.
What the report should give you
Three things. Reproduction steps your own engineers can follow without the tester in the room. A clear line between what was proven and what was suspected. And a retest after the fixes ship, agreed up front rather than hoped for.
A report that grades you without showing its work is not evidence of anything.
Why the traditional model is under strain
Nothing above is a criticism of testers. The constraint is arithmetic: a traditional test is priced in human hours, so it happens rarely and its scope gets trimmed to fit a budget. Both consequences are structural. Every deploy after the test date is untested, and the part of the application that was cut was never examined.
That constraint is what changes when the marginal cost of another test collapses - which is what we build, and what our platform page sets out, including the part we do not claim to have solved.
Frequently asked questions
What is penetration testing in simple terms?
It is an authorised simulated attack on your own systems. Someone with permission tries to break in the way a real attacker would, then reports what worked, how far it reached, and how to fix it.
What is the difference between a penetration test and a vulnerability scan?
A scan matches your systems against a catalogue of known issues and reports possibilities. A penetration test attempts to exploit weaknesses and chain them together, and reports what it actually achieved. The scan gives you triage work; the test gives you confirmed findings.
How often should you run a penetration test?
The traditional answer is annually, or after a significant change, which reflects what human-hour pricing allowed rather than what risk requires. If you deploy frequently, every release after the test date is untested, which is the argument for testing triggered by change instead of by the calendar.
Is penetration testing required for compliance?
It depends on the framework. Some require it outright, some treat it as expected evidence without mandating it, and a few specifically name human-led exercises. The differences matter, so we map the position for each framework rather than giving a single answer.