What Is Penetration Testing?

Most people meet the term for the first time when a customer, an insurer or a procurement form demands one. That is an awkward way to meet it, because the word covers everything from a twenty-minute automated scan sold as an assessment to three weeks of manual work by someone who reads your traffic like a language.

The gap between those two things is enormous, and the invoice does not always tell you which one you bought. So it is worth understanding what the work actually involves.

The definition, stated plainly

A penetration test is an authorised, simulated attack against a system, carried out to establish what an attacker could actually achieve against it. The word that carries the weight is authorised. The same activity without written permission is a crime in most jurisdictions, which is why every legitimate engagement begins with a signed scope.

A tester behaves like an attacker but reports like an auditor. That combination is the whole point. Breaking in is not useful on its own — the value is in the written record of how it was done, and what it would take to stop it.

How it differs from a vulnerability scan

This is the distinction that costs organisations the most money when they get it wrong. Both have a place. They answer different questions.

A scanner recognises patterns it has been taught. It will not notice that one customer's ID in a URL returns another customer's invoice, because nothing about that request looks malformed. It is a perfectly well-formed request that happens to return data it should not. Only a person who understands what the application is for will catch that.

The findings that end up mattering are almost never the ones a tool flags. They are the ones that require someone to ask: what happens if I do this in the wrong order?

What actually gets tested

For a web application, the surface breaks down into areas that each get worked through in turn. A test that skips several of these is not a penetration test, whatever the cover page says.

• Reconnaissance. Every reachable host, route, locale, API endpoint and static asset. You cannot test what you have not found, and this stage regularly turns up things the client did not know were public.
• Configuration. Transport security, response headers, cookie attributes, HTTP methods, exposed repository or backup files, and how the application behaves when it errors. Covered in depth in our security headers checklist.
• Authentication. Whether the login reveals which accounts exist, how throttling works per address and per account, whether multi-factor is actually enforced rather than merely offered.
• Session handling. Cookie flags, whether logout revokes the token server side or only clears the browser, session fixation, and idle timeout behaviour.
• Authorisation. Whether protected endpoints refuse anonymous callers, whether one account can reach another account's data, and whether a low-privilege role can cross into a higher one.
• Input validation. Cross-site scripting, SQL injection, host header injection, open redirect, path traversal, and how the application handles malformed JSON or a deliberately wrong content type.
• Business logic. The part no tool reaches. Can a step be skipped? Replayed? Run out of order? Can a discount be applied twice?

The phases of an engagement

Structure varies between firms, but the shape is consistent and follows the Penetration Testing Execution Standard reasonably closely.

1. 1Scoping and rules of engagement. What is in scope, what is explicitly excluded, the testing window, and the actions the tester will not take. Denial-of-service testing is normally excluded against production. So is anything that charges a real account or sends a message to a real customer.
2. 2Reconnaissance. Mapping the reachable surface without touching anything actively.
3. 3Configuration review. Transport, headers, methods, exposed files, error behaviour.
4. 4Active testing. Authentication, sessions, authorisation, input handling, business logic.
5. 5Remediation and verification. Findings go to your team, fixes get made, and each one is re-tested against the running system.
6. 6Reporting. The written record, with evidence.

Step five is the one that gets quietly dropped by firms selling on price. It should not be optional. A finding is not closed because somebody merged a pull request — configuration drifts between environments, and a route can go quiet without actually being disabled.

Black box, grey box, white box

These describe how much the tester is told before starting.

Black box is the usual starting point and the easiest to justify, because it mirrors the real threat. It also has a blind spot the size of everything behind your login. We go through the trade-off properly in black box or grey box.

What you should receive at the end

A report you can hand to two very different audiences: an executive who needs to know whether to worry, and an engineer who has to fix it on Thursday.

• An executive summary that states the overall risk in plain language
• Each finding with a severity, a CVSS v3.1 vector where the weakness can be modelled, and the evidence behind it
• A specific recommendation per finding, not a link to a generic article
• The full test checklist — including the checks that passed
• An honest statement of what the method could not reach

That fourth point catches people out. A report listing only failures tells you nothing about coverage. If forty checks passed and six failed, you want to see all forty-six, because otherwise you have no idea whether the tester looked at your authorisation model at all. What a penetration test report should contain covers this in more detail.

What a penetration test will not tell you

Worth saying, because the limitations get glossed over in sales conversations.

• It is a snapshot. It describes the system on the days it was tested, not the system you deploy next month.
• Black box testing cannot see how passwords are stored or compared. That needs the database.
• Scope is a real boundary. Infrastructure, staff and physical security are usually excluded, and excluding them is not the same as clearing them.
• A clean report is evidence of a decent security posture. It is not proof that nothing is wrong.

A tester who does not volunteer these is selling you certainty they cannot supply.

How often to run one

Annually is the common baseline, and it is a defensible answer for a stable application. Change is the better trigger though. Re-test after anything that touches your edge configuration, your authentication flow, or a payment or billing integration.

Those three areas share a property: they are easy to weaken by accident. A Content-Security-Policy gets loosened when a third-party script is added under deadline, and nobody notices for a year.