How a penetration test runs: from scoping to retest

A penetration test is often bought as a line item and received as a PDF. What happens in between matters more than the report itself. A well-run test follows a method you can explain to your assessor, your board and your clients. This article walks through that method, phase by phase, and maps it to what PCI DSS v4.0.1 expects under requirement 11.4.

Why the method matters

PCI DSS does not let you test any way you like. Requirement 11.4.1 asks for a penetration testing methodology that is “defined, documented, and implemented” and based on “industry-accepted penetration testing approaches” (requirement text). The same requirement lists what the method must cover:

• the entire cardholder data environment (CDE) perimeter and critical systems;
• testing from both inside and outside the network;
• validation of any segmentation and scope-reduction controls;
• application-layer testing that looks, at a minimum, for the vulnerabilities listed in requirement 6.2.4;
• network-layer testing of all components that support network functions and operating systems;
• a review of threats and vulnerabilities experienced in the last 12 months;
• retention of test and remediation results for at least 12 months.

Common reference frameworks include NIST SP 800-115, which organizes testing into planning, discovery, attack and reporting, the OWASP Web Security Testing Guide for applications and APIs, and MITRE ATT&CK to describe attacker techniques in a shared vocabulary. The PCI SSC’s own Penetration Testing Guidance remains the most useful single document for scoping and reporting.

Phase 1: scoping and authorization

Most failed tests fail here. Before any traffic is sent, the tester and the client agree on:

• Targets. External IP ranges and domains, internal network segments, applications, APIs and the segmentation boundaries to be validated.
• Rules of engagement. Testing windows, what is off limits, how to handle production systems, and who to call if something breaks.
• Written authorization. A signed authorization from someone with the authority to grant it, including for systems hosted by third parties.
• Points of contact. One person on each side, reachable during the test.
• Approach. Black box (no prior information), grey box (user-level credentials, as recommended for most applications) or white box (documentation and source access).

A good scope starts from your data flows, not from a list of IP addresses. If card data or sensitive personal information passes through a system, it belongs in the conversation.

Phase 2: reconnaissance and enumeration

The tester maps the attack surface: exposed services, technologies and versions, application functions and API endpoints, user roles and trust relationships. External testing simulates an attacker with no access. Internal testing simulates an attacker who already has a foothold, such as a compromised workstation. Both are required by PCI DSS, under requirements 11.4.2 (internal) and 11.4.3 (external).

Phase 3: testing and exploitation

This is where a penetration test differs from a scan. Automated tools identify candidate weaknesses. The tester then validates them by hand, removes false positives and tries to exploit what is real. The question is not “is this version outdated?” but “what can an attacker actually reach from here?”

• Network layer: weak services, misconfigurations, default credentials, missing patches, lateral movement between segments.
• Application layer: injection, broken access control, authentication and session flaws, insecure APIs, business logic abuse.
• Segmentation: attempts to reach the CDE from out-of-scope networks, as required by 11.4.5 when segmentation is used to reduce scope.

Exploitation is controlled. The goal is to demonstrate impact with evidence, not to cause an outage.

Phase 4: reporting

A useful report has two audiences. Management needs a short summary of overall risk and priorities. Technical teams need each finding with:

• a description and the affected systems;
• evidence (requests, screenshots, commands) so the result can be reproduced;
• a severity rating, commonly based on CVSS and adjusted to your context;
• clear, practical remediation guidance.

The report should also state what was tested, when, from where and under what constraints. An assessor will look for that before reading a single finding.

Phase 5: remediation and retest

Requirement 11.4.4 is explicit: exploitable vulnerabilities and security weaknesses are corrected according to your risk ranking, and “penetration testing is repeated to verify the corrections” (requirement text). A test without a retest leaves you with a list of problems and no proof they were fixed. Plan the retest window when you plan the test.

How often, and by whom

• At least once every 12 months, and after any significant infrastructure or application upgrade or change.
• By a qualified internal resource or a qualified external third party.
• With organizational independence from the systems tested. The tester does not need to be a QSA or an ASV.

Service providers that rely on segmentation must validate it every six months (requirement 11.4.6).

Questions to ask before you sign

• Which methodology do you follow, and can we see it?
• Is the testing manual, or mostly automated scanning?
• Does the price include a retest?
• How do you handle a critical finding discovered mid-test?
• What will the report contain, and can we see a sanitized sample?

For the difference between scans and penetration tests, see our comparison. To scope a test, visit our security testing page or contact us. Ubitrak performs internal, external, application and segmentation testing, and you can see sample reports.

Sources

• PCI SSC Information Supplement: Penetration Testing Guidance v1.1
• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
• OWASP Web Security Testing Guide
• MITRE ATT&CK
• FIRST: Common Vulnerability Scoring System
• Microsoft Learn: PCI DSS Requirement 11 (requirement text)
• PCI SSC: Just Published: PCI DSS v4.0.1