Penetration testing.

What a penetration test actually is

A penetration test is a deliberate, authorised attempt to break into a system the way a real attacker would, carried out under a written scope and rules of engagement. The point is not to list theoretical weaknesses but to prove which ones can actually be chained together to reach something that matters: a database, an admin account, a customer record, a payment flow. A tester follows the same path an intruder would, but with permission and a defined boundary, so the organisation learns where it would fail before someone hostile does. The authorisation is what separates a penetration test from a crime; without a signed scope, the same actions are simply intrusion.

Engagements are framed along a few axes that the scope has to fix up front. Knowledge level runs from black box, where the tester starts with nothing but a name or an IP range, through grey box, where they get a low-privilege account or partial documentation, to white box, where they receive source code, architecture diagrams and full credentials. Vantage point is either external, simulating an attacker on the internet, or internal, simulating someone who has already landed inside the network or is a malicious insider. Target type separates application testing, which probes a web or mobile app and its logic, from infrastructure testing, which goes after hosts, services and network configuration. Most real programmes mix these to match the threats they actually worry about.

How it differs from a scan and from a red team

The most common confusion is between a penetration test and a vulnerability scan, and the two are not the same thing. A vulnerability scan is automated and optimised for breadth: a tool sweeps every reachable asset, matches what it finds against a database of known issues, and produces a long list. It is fast, repeatable and cheap, but it cannot tell you whether a given finding is genuinely exploitable in your environment or a false positive.

A penetration test is human-led and optimised for depth: a tester validates findings by actually exploiting them, chains several lower-severity issues into a real compromise, and tests the business logic and trust assumptions that no scanner understands. Scanning tells you what might be wrong; a penetration test tells you what an attacker could really do with it.

At the other end sits the red team, which is also frequently confused with penetration testing. A red team engagement is longer, often running for months, and it is objective-based rather than coverage-based: the goal is to reach a specific outcome, such as exfiltrating a defined data set or reaching a particular system, while staying undetected and testing whether the defenders notice and respond. A penetration test aims for coverage within a scope and is usually known to the relevant teams; a red team aims for a single deep objective and deliberately tests detection and response as much as the controls themselves.

Where it sits in a security programme

A penetration test is a point-in-time check, not a control by itself. Its real value is realised after the engagement, when the report feeds the remediation backlog. A good report does more than list findings: it ranks them by exploitability and business impact, gives reproducible evidence, and recommends fixes. Those findings become tickets, owners and deadlines inside the wider vulnerability management process, and a retest confirms the fixes actually closed the holes rather than moving them. Without that follow-through, a test is just an expensive document.

Penetration testing also shows up explicitly in standards and regulation. An information security management system aligned to ISO/IEC 27001 treats technical testing as a way to verify that controls work in practice, and frameworks for payment, critical infrastructure and financial services increasingly expect regular, scoped testing of internet-facing and critical systems. ENISA and national agencies such as ANSSI publish guidance on commissioning testing responsibly, and the offensive skill set is formalised in credentials for ethical hackers. What practitioners actually deliver is a recurring rhythm: scope the engagement, agree rules of engagement and a written authorisation, test, report, remediate, retest, and repeat as the environment changes.