Penetration testing

What is penetration testing?

Penetration testing is a security test in which a person, with written permission, attacks your systems to find out how far they can get. NIST SP 800-115 defines it as testing in which evaluators "mimic real-world attacks" to find ways around the security features of an application, system or network.

Two things separate a pentest from most other security checks. First, the tester exploits what they find: a suspected flaw becomes a demonstrated one, with the request and response to prove it. Second, the tester combines weaknesses. NIST notes that most penetration tests look for combinations of vulnerabilities that give more access than any single one would. A missing rate limit, a verbose error message and a predictable ID are three low findings on a scanner report. Together they can be one account takeover.

The test is bounded by a signed rules of engagement document that sets targets, dates, techniques and stop conditions. Without that authorization, the same activity is an attack.

How is a pentest different from other security testing?

A pentest answers "what can an attacker actually do here?" within an agreed scope and time. Other methods answer narrower or broader questions.

The line between a scan and a pentest matters most to buyers, and it is where vendors blur terms. See vulnerability scanning vs penetration testing for how to tell them apart.

What happens during a penetration test?

Most tests follow the same arc: agree the scope, map the target, find weaknesses, exploit them, report, and retest the fixes. NIST SP 800-115 compresses this into four phases (planning, discovery, attack, reporting) with a loop back from attack to discovery each time new access reveals more of the system. The Penetration Testing Execution Standard splits the same work into seven sections.

In practice:

1. Scoping and authorization. Targets, exclusions, test accounts, windows and contacts go into the RoE.
2. Reconnaissance. The tester maps hosts, endpoints, roles and data flows.
3. Vulnerability analysis. Scanners and manual review produce candidate weaknesses.
4. Exploitation. The tester tries each candidate and keeps what works.
5. Post-exploitation. From each foothold, the tester looks for what else is reachable: more privileges, other tenants, internal systems.
6. Reporting. Each confirmed finding is written up with evidence and a fix.
7. Retest. After fixes ship, the tester confirms each one. See pentest retest.

The standards and the detail of each phase are covered in penetration testing methodology.

What kinds of penetration tests are there?

Tests are classified by what is attacked and by how much the tester knows going in. By target, the common types are external network, internal network, web application, API, mobile, cloud, wireless, social engineering and physical. Types of penetration testing compares what each covers and when you need it, and internal vs external penetration testing covers the split compliance frameworks care most about.

By knowledge, tests are black-box (only a target), gray-box (accounts and specs) or white-box (source code and architecture). The trade-offs are in black-box, gray-box and white-box testing. A separate choice is whether the tester logs in. Most of a SaaS product sits behind authentication, which is why authenticated penetration testing is the default for application work.

What does a pentest finding look like?

A good finding lets an engineer reproduce the issue in minutes and tells a manager how bad it is. Here is a condensed example from a gray-box API test, with invented data:

ID:        PT-07
Title:     Project members can list files in other tenants' projects
Severity:  Medium, CVSS 3.1 base 6.5
           (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)
Affected:  GET /api/projects/{project_id}/files on api.example
Accounts:  user_a (tenant A, member), user_b (tenant B, member)
Impact:    Any logged-in user can read file names and download links
           for any project whose ID they know or guess. IDs are sequential.
Fix:       Check that the caller belongs to the project's tenant before
           returning files. Apply the check in shared middleware.
Retest:    Pending

The evidence attached to it is the exchange that proves the flaw, sent with user_b's session against a project owned by tenant A:

GET /api/projects/project_1043/files HTTP/1.1
Host: api.example
Authorization: Bearer <user_b token>

HTTP/1.1 200 OK
Content-Type: application/json

{"project_id": "project_1043", "tenant": "tenant_a",
 "files": [{"name": "demo-export.csv", "url": "/files/f_2201"}]}

A scanner would rarely flag this: the response is a normal 200 with valid JSON. It takes a second account and the knowledge that user_b should not see tenant A's data. This class of flaw is explained in broken object level authorization.

The full report wraps findings like this in an executive summary, a scope and method statement, and a list of what was tested and found clean. Customers usually receive a penetration test attestation letter in its place.

What are the benefits of penetration testing?

The main benefit is evidence: you learn which weaknesses are exploitable in your real system, which tells you what to fix first. The others follow from that.

• It finds what automation misses. Broken access control between users and tenants, business logic abuse and chained low-severity issues need a tester who understands what the application is supposed to do. See business logic vulnerability.
• It proves impact, which sets priorities. A scanner's "high" may be unreachable; a pentest's proven medium may expose customer data. A demonstrated issue is also harder to argue down the backlog than a theoretical one.
• It tests detection and response. NIST lists defenders' ability to detect attacks and respond among the things a pentest can show. If the SOC never noticed a week of testing from known IPs, that is a finding.
• It produces evidence others accept. Customers' security reviews, PCI DSS assessors and FedRAMP authorizing officials ask for a recent test by a qualified, independent party.
• It checks your fixes. A retest confirms a patch closed the hole and did not just move it.
• It shows the skill an attacker needs. NIST notes a pentest can indicate the level of sophistication required to compromise a system, which helps decide where more controls are worth the money.

A pentest also has limits. It covers only the agreed scope and dates. A clean report says the testers did not get in during that window with that access, not that no flaw exists. Code shipped the week after is untested, which is the argument behind continuous testing models.

How often do you need a penetration test?

At least once a year and after significant changes, if you follow the most common compliance rules. PCI DSS v4.0.1 requirements 11.4.2 and 11.4.3 call for internal and external penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change, by a qualified internal resource or qualified external third party with organizational independence. Requirement 11.4.4 requires exploitable findings to be corrected and the testing repeated to verify the corrections. FedRAMP's guidance requires a 3PAO test before initial authorization and at least every 12 months after. SOC 2 and ISO 27001 do not name penetration testing as a requirement, though auditors commonly ask for one as evidence.

Outside compliance, the useful question is how much has changed since the last test. A product that ships weekly accumulates untested code quickly. Budget and pricing models are covered in penetration testing cost.

Common mistakes

• Scoping the test around what is easy to test, not where the sensitive data and privileged functions are.
• Providing one test account, so authorization between roles and tenants is never exercised.
• Treating the report as the end: findings without owners and a retest date stay open.
• Accepting a scan report labeled as a pentest. Ask for proof of exploitation on each finding.

Written by Parameter · Last reviewed September 27, 2026