What is a penetration test?

The US National Institute of Standards and Technology (NIST) describes penetration testing as security testing in which evaluators mimic real-world attacks to find ways around the security features of an application, system or network. NIST also notes that most tests look for combinations of vulnerabilities that give more access than any single one would. That second point is the heart of it: a penetration test is about consequences, not lists.

Three things separate a real penetration test from other security activities. It is authorized in writing, with an agreed scope and rules of engagement. It is adversarial, meaning a human is actively trying to achieve an attacker's goal, such as reading another customer's data. And it is evidence-based: every reported finding comes with proof that it works, not a guess that it might.

Methodologies differ in names, but nearly every credible test, including the phases described in NIST SP 800-115 and the OWASP Web Security Testing Guide, follows the same arc:

1. Scoping and authorization. You agree which systems, accounts and techniques are in bounds, the testing window, emergency contacts and what happens if testers find something serious mid-test.
2. Reconnaissance. Testers map your attack surface: domains, exposed services, application features, user roles and integrations.
3. Discovery. They look for weaknesses, using tools for breadth and manual review for the logic that tools cannot understand.
4. Exploitation and chaining. They try to use what they found, and combine low-severity issues into a realistic attack path, for example a leaked identifier plus a missing authorization check equals access to someone else's records.
5. Reporting. Each confirmed finding is written up with impact, evidence, reproduction steps for your engineers and specific remediation advice.
6. Retesting. After you fix, the tester repeats the attack to confirm it no longer works. See retesting and fix verification.

A good tester stays in contact throughout. If they find something critical, such as exposed customer data, you should hear about it the same day rather than in a report weeks later.

Tests are usually described by the surface being attacked and by how much the tester is told in advance.

By knowledge level, a black-box test starts with nothing, a gray-box test starts with user accounts or documentation, and a white-box test includes source code or architecture access. Gray box is the most common choice for applications because it spends the budget on finding issues rather than on guessing credentials. The trade-offs are covered in black box, gray box and white box testing.

Duration is set during scoping and, as the NCSC notes, is usually expressed in tester days. It depends on the number of applications, user roles, endpoints and hosts, whether source code is reviewed, and how many environments are included. A single small web application is a very different job from a multi-product cloud estate.

Plan for time on either side of active testing as well: scoping and paperwork before, and report review, fixes and a retest after. Preparing accounts, test data and allow-listing in advance is the single biggest thing you can do to avoid lost days. See how to prepare for a penetration test.

The main deliverable is a report. NCSC guidance says it should contain the issues found, the tester's risk assessment of each, and a method to resolve them. In practice a useful report includes:

• An executive summary that a non-technical leader can act on.
• Each finding with severity, often scored with the Common Vulnerability Scoring System (CVSS), plus a plain explanation of business impact.
• Evidence such as screenshots or request and response pairs, and reproduction steps your engineers can follow.
• Specific remediation guidance, not generic advice.
• Scope, dates and method, so an auditor or customer can see what was and was not covered.
• Retest results showing which findings are confirmed fixed.

If you have never read one, how to read a penetration test report walks through each part.

Common triggers are a customer security questionnaire, an upcoming audit, a major release, a fundraise or acquisition, or simply holding data that would hurt to lose. Compliance is often what starts the conversation:

• The Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 explicitly requires internal and external penetration testing at least once every 12 months and after significant changes (Requirement 11.4).
• SOC 2 does not strictly mandate a pentest. The AICPA Trust Services Criteria list penetration testing as one possible form of evaluation under CC4.1, and many auditors and customers expect one.
• ISO/IEC 27001 requires managing technical vulnerabilities but does not prescribe a pentest; many organizations use one as evidence.

Details are in penetration testing for compliance, and frequency is covered in how often to penetration test.

A test is a snapshot. The NCSC is direct about this: a pentest can only show that systems were not vulnerable to known issues on the day of the test. New code, new infrastructure and newly disclosed vulnerabilities appear the next morning. It is also bounded by scope and time, so a clean report on one application says nothing about the systems that were left out.

That is why mature teams pair periodic tests with continuous scanning and, increasingly, continuous penetration testing for systems that change weekly.