What Is Penetration Testing? A 2026 Buyer's Definition

The short definition

The National Institute of Standards and Technology (NIST) defines penetration testing as "security testing in which evaluators mimic real-world attacks in an attempt to identify ways to circumvent the security features of an application, system, or network."

In practice, that means a skilled operator is given written permission to attack a defined set of your systems, and does so the way an adversary would: looking for a way in, moving from one weakness to the next, and recording exactly how far they get. The output is not a list of theoretical problems. It is a record of what was actually reachable, with the evidence to prove it.

Penetration test or vulnerability scan?

The two are often confused, and they answer different questions.

A vulnerability scan is automated. It compares what it can see against a database of known issues and reports anything that might be a weakness. It is fast, repeatable and cheap to run often, and it produces a long list that includes false positives and issues that are not reachable in practice.

A penetration test is performed by a person. The operator uses scanners as one input, then confirms which findings are real, which can be exploited, and which chain together into something worse than any single issue. A misconfigured storage bucket and an over-permissive service account might each look minor on a scan. Together, they might be the route to your customer data.

The practical difference for a buyer: a scan tells you what might be wrong; a penetration test tells you what an attacker could actually do, and in what order you should fix it.

What gets tested

Most engagements focus on one or more of these scopes:

• External network. The systems you expose to the internet: remote access, mail, web servers and anything else an outsider can reach.
• Internal network. What an attacker could do after gaining a foothold inside, such as through a compromised laptop or a malicious insider.
• Web applications and application programming interfaces (APIs). Authentication, authorization, session handling, input handling and business logic, tested against the way the application is actually deployed.
• Cloud environments. Identity and access configuration, storage, network exposure and the permissions granted to workloads and services.
• AI applications. Assistants and agents built on large language models, including what their tools, permissions and retrieved data allow them to be steered into doing.

The Open Worldwide Application Security Project (OWASP) publishes a widely used Web Security Testing Guide for application scopes, and MITRE ATT&CK catalogues the techniques real adversaries use once they are inside a network. Both are useful references for what a thorough test should cover.

Testers can also be given different levels of starting knowledge. In a black-box test they start with nothing but a target; in a white-box test they have documentation, source code or architecture diagrams; grey-box sits between the two. More starting knowledge usually means more coverage in the same amount of time.

How an engagement runs

A professional penetration test follows the same shape every time, and nothing is touched until the first three steps are complete.

1. Scope. Agree the systems, objectives, exclusions and constraints. This is where a good tester will tell you if a smaller engagement would answer your question.
2. Rules of engagement. Fix the testing window, the permitted techniques, the intensity, the escalation contacts on both sides and the conditions under which testing stops.
3. Written authorization. Obtain signed permission from someone able to grant it, naming the specific systems. Where a system is run by a third party, such as a cloud or hosting provider, their own requirements are confirmed as well.
4. Testing. The operator works the agreed scope inside the agreed boundaries. A serious finding is raised with your escalation contact when it is found, not held until the report.
5. Reporting. Findings are written up with evidence, business impact and remediation guidance.
6. Retest. After you fix the agreed findings, they are tested again to confirm the fixes hold.

These steps are usually recorded in a statement of work (SOW) and a separate rules-of-engagement document. Our approach page describes each one in more detail.

What you should receive

The report is the product. A useful one is written for two readers at once:

• An executive summary for the people who fund the fix: what was tested, what was found, and what it means for the business, without jargon.
• Technical findings for the people who make the fix: each issue with its severity, the affected systems, step-by-step reproduction, evidence, and specific remediation guidance.

Severity should reflect what an attacker can actually reach, not just how an issue scores in isolation. A report should also state its limits plainly: the scope, the testing window and anything that was out of bounds.

Penetration testing and compliance

Some frameworks require penetration testing explicitly. The Payment Card Industry Data Security Standard (PCI DSS) version 4 includes penetration testing requirements covering internal and external testing and the controls that separate the cardholder data environment from other networks. Others, such as System and Organization Controls 2 (SOC 2), do not mandate a penetration test by name, but a report is commonly used as evidence that security controls have been tested.

If a report needs to satisfy an auditor or a customer's security review, say so during scoping. The scope and the evidence the report must show are much easier to agree before testing than to reconstruct afterwards.

What to confirm before you hire a tester

Put these questions to every tester you are considering, in the request for proposal (RFP) or the first call:

A reputable tester will insist on written scope and signed authorization before starting, and will say no to testing systems you are not authorized to have tested.

Cost is driven mostly by scope: the number and complexity of systems, the depth of testing, and any compliance evidence required. Our pricing page publishes starting prices for each type of engagement.

Sources

1. 01NIST, Glossary: penetration testingAccessed 2026-09-25
2. 02NIST, Special Publication 800-115, Technical Guide to Information Security Testing and AssessmentAccessed 2026-09-25
3. 03PCI Security Standards Council, Document library (PCI DSS)Accessed 2026-09-25
4. 04OWASP, Web Security Testing GuideAccessed 2026-09-25
5. 05MITRE, ATT&CKAccessed 2026-09-25