Penetration Test Readiness: Scope, Schedule and Retest Before Audit
A penetration test finished the week before the audit leaves no time to fix and retest. This checklist sets the requirement, the boundary, the rules of engagement and the remediation owners before testing begins, so the report and the retest land inside the review period.
Identify the Requirement and Its Clock
Write one row per requirement in the accompanying obligation register: the regulation, contract or standard, its version and clause, the systems in scope, the activity it calls for, how often and on what trigger, and who owns the decision. Scans, penetration tests and segmentation tests are different activities with different cadences, and incident reporting clocks belong in their own rows.
PCI DSS v4.0.1 is the only supported version; v4.0 was retired on December 31, 2024, and the requirements that were future dated became effective on March 31, 2025. Its testing cadences are specific. Requirement 11.3.1 calls for internal vulnerability scans at least once every three months, and 11.3.2 for external scans by an Approved Scanning Vendor at least once every three months, with rescans until passing results are achieved. Requirements 11.4.2 and 11.4.3 call for internal and external penetration tests at least once every 12 months and after any significant infrastructure or application upgrade or change. Requirement 11.4.5 calls for testing segmentation controls at least once every 12 months and after changes to them, and 11.4.6 shortens that to every six months for service providers. Confirm your merchant or service provider status and the cardholder data environment boundary before setting dates.
The Order of Readiness, From Boundary to Retest
Start from the actual contract, regulator request or assessment criterion and map it to systems and dates. Record the reason for every boundary and exclusion. The asset inventory, data flows, account roles and business functions explain how the targets represent the scope; an IP list is a valid scope only when its relationship to the boundary is written down. Review the scope again after relevant changes.
The rules of engagement name the targets, the hosting provider’s permission, whether production or a test environment is used, the access roles, the techniques, the windows, the escalation path and how evidence is handled. If a nonproduction environment is tested, record how it differs from production. Agree remediation owners and the retest scope before the test starts, so a finding has somewhere to go the day it is reported.
Who Owns the Scope, Who Signs the Rules and Who Fixes the Findings
The compliance owner records the sources, versions, applicability and dates. System and business owners explain boundaries and operating constraints, and authorized owners sign the rules of engagement. The tester reviews the scope against the assignment and reports any access or coverage problem. Operations manages remediation and change windows. Counsel and the responsible officers decide legal and filing questions. Name who can stop the work, approve changes and accept evidence.
The people to brief first are the ones who will try to help. A system administrator who patches a server in the middle of the test, without telling anyone, has changed the environment the report describes. A network engineer who tightens a firewall rule because the tester is about to reach a segment has produced a clean finding that differs from the environment the assessor will review. A developer who disables a test account when the alerts start has stopped a test the rules authorized. The rules of engagement name a single escalation path for these moments, and every change made during the window is recorded.
The Gaps Auditors Find in a Test That Was Done Too Late
Keep automated scan results apart from the penetration test of approved scenarios, and state the access, method, coverage and exclusions of each. For every finding, record whether the fix was reported by its owner, checked against configuration, rescanned or retested, and what that verification covered. The report says whether each fix was reported, rescanned or independently retested.
Keep the methodology and its link to the requirement with the report, tie targets and exclusions to the boundary, and preserve the original test and the later retest as separate versions. Give every open requirement an owner and a date in the register.
Other Clocks That Sit Beside the Test Schedule
DFARS 252.204-7012, where it is in the contract, requires rapid reporting of a cyber incident within 72 hours of discovery and preservation of images of affected systems and relevant monitoring or packet capture data for at least 90 days from submission of the report. CMMC Level 2 assesses NIST SP 800-171 Revision 2 under 32 CFR 170.2, and on July 13, 2026 the Department of Defense suspended Phase II of the rollout, as carried in Class Deviation 2026-O0025 Revision 3; your solicitation and contracting officer set what applies to a given award. NYDFS Part 500 covered entities file their annual notice by April 15 and report qualifying incidents within 72 hours. HIPAA covered entities evaluate their security safeguards under 45 CFR 164.308(a)(8). Each of these is its own row in the register.
How GDF Supports Compliance Officers, Internal Auditors and Security Teams
Global Digital Forensics has delivered security testing and forensic examinations since 1992 from sixteen US offices. The engagement record states the scope, authorization, method, the testing actually performed, the evidence and the status of each finding. Remediation discussion and retesting follow the written scope, and a framework matrix connects the work to the specific criteria approved for the assignment.
Internal auditors use the matrix to populate their workpapers. The CISO uses the technical appendix to drive remediation. Counsel uses the executive narrative, and where exposure exists the engagement runs under counsel’s direction. Our clients include Fortune 1000 companies and AmLaw 100 firms, and our examiners have testified in federal and state courts when a security posture became a litigated question. The initial consultation is free. If the filing date is closer than the time you need for testing, remediation and retest, call (800) 868-8189 and we will build the calendar backward from the deadline with you on the first call.
Use the obligation register
The file penetration_testing_readiness_obligation_register.csv has one row per obligation, with the instrument and version, the systems in scope, the clause, the cadence or trigger, the trigger time, how the due date is calculated, the decision owner, the evidence, the verification and the filing status. The PCI DSS rows are filled with the v4.0.1 cadences above; complete the scope, dates and owners for your environment and add a row for every other contract, audit or insurer requirement you must meet.
The Checklist at a Glance
The same rows are in penetration_testing_readiness_checklist_workbook.csv, with columns for the owner, the date, notes, status, the evidence ID and the next action.
| Item | Who acts | Where it lives | What to confirm and when |
|---|---|---|---|
| Requirement and version | Compliance, legal or contract owner | Request, contract, standard and version | Before scoping: confirm the exact criterion and its cadence. |
| Scope and boundary | System and business owners with the tester | Inventory, data flows, accounts and exclusions | Before testing, and again after relevant changes. |
| Rules of engagement | Target and provider owners with the tester | Signed methods, access, windows, stops and handling | Sign before any activity; sign again for material changes. |
| Methodology and history | Tester and system owners | Method inputs and prior reports | Collect the prior year’s reports and open findings. |
| Vulnerability scanning | Scanning and compliance owners | Scan scope, credentials, findings and criterion | PCI DSS: internal and ASV external scans at least every three months, plus rescans. |
| Penetration and segmentation testing | Qualified tester and compliance owner | Targets, methods, dates and results for each | PCI DSS: penetration tests at least every 12 months and after significant change; segmentation every 12 months, or six for service providers. |
| Remediation and verification | Operations, tester and reviewer | Tickets, approved changes and verification record | Leave time to fix and retest inside the review period. |
| Incident and filing clocks | Incident, compliance and legal owners | Separate obligation register rows | Track discovery, determination and submission times apart from test dates. |
| Reporting and acceptance | Tester and authorized recipient | Versioned report, matrix and filing record | Keep the original report and the retest as separate versions. |
Sources
Talk to a senior examiner. The initial consultation is free, and requests are handled in confidence. Call (800) 868-8189 at any hour, write to info@evestigate.com, or request a consultation at evestigate.com/contact.
The full guide is published at https://evestigate.com/resources/penetration-testing-readiness-checklist/.