Penetration Test Readiness: Scope, Schedule and Retest Before Audit

Global Digital Forensics checklist. Edition 2026-11-03, November 3, 2026. 24/7 hotline (800) 868-8189.

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.

ItemWho actsWhere it livesWhat to confirm and when
Requirement and versionCompliance, legal or contract ownerRequest, contract, standard and versionBefore scoping: confirm the exact criterion and its cadence.
Scope and boundarySystem and business owners with the testerInventory, data flows, accounts and exclusionsBefore testing, and again after relevant changes.
Rules of engagementTarget and provider owners with the testerSigned methods, access, windows, stops and handlingSign before any activity; sign again for material changes.
Methodology and historyTester and system ownersMethod inputs and prior reportsCollect the prior year’s reports and open findings.
Vulnerability scanningScanning and compliance ownersScan scope, credentials, findings and criterionPCI DSS: internal and ASV external scans at least every three months, plus rescans.
Penetration and segmentation testingQualified tester and compliance ownerTargets, methods, dates and results for eachPCI DSS: penetration tests at least every 12 months and after significant change; segmentation every 12 months, or six for service providers.
Remediation and verificationOperations, tester and reviewerTickets, approved changes and verification recordLeave time to fix and retest inside the review period.
Incident and filing clocksIncident, compliance and legal ownersSeparate obligation register rowsTrack discovery, determination and submission times apart from test dates.
Reporting and acceptanceTester and authorized recipientVersioned report, matrix and filing recordKeep the original report and the retest as separate versions.

Sources

PublisherDocument
PCI SSCPCI DSS v4.0.1 publication and v4.0 retirement
PCI SSCDocument library (PCI DSS v4.0.1, free download after accepting the licence)
eCFRDFARS 252.204-7012, Safeguarding Covered Defense Information and Cyber Incident Reporting
eCFR32 CFR Part 170, CMMC Program (170.2 incorporates NIST SP 800-171 Revision 2)
DoDClass Deviation 2026-O0025 Revision 3 memorandum
NYDFSCybersecurity resource center (23 NYCRR Part 500)
eCFR45 CFR Part 164 Subpart C, HIPAA Security Rule

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/.