When your segmentation test starts in February but doesn't finish until May, which date triggers the six-month clock for your next test? PCI DSS v4.0.1 doesn't explicitly answer this question, but page 25 offers a critical clue: compliance activities must be "performed consistently via a regularly scheduled and repeatable process." This suggests fixed scheduling based on start dates, not completion dates.
This checklist guides you in establishing a defensible segmentation test schedule that your QSA can validate and your team can manage effectively.
Prerequisites
Before implementing this scheduling approach, ensure:
- Your organization performs segmentation testing as required by PCI DSS Requirement 11.4.6 (service providers) or 11.5 (merchants with segmented environments).
- You have documented your CDE scope and segmentation controls.
- You maintain a compliance calendar or ticketing system (like Jira or ServiceNow) to track recurring activities.
- Your QSA has reviewed your current segmentation testing methodology.
Scheduling Checklist
1. Define Your Test Initiation Date
Done when: You've documented the specific calendar date when segmentation testing activities begin.
If your test starts on February 2, that's your anchor date. Your next test starts six months later on August 2 (or the nearest business day within a two-day window).
What good looks like: A calendar entry or ticket created exactly six months from the initiation date, regardless of test completion time. Your compliance calendar shows predictable, fixed dates that don't shift based on project completion.
2. Set Calendar Reminders at Fixed Intervals
Done when: You've created automated reminders (calendar invitations, Jira recurring tickets, or compliance platform alerts) that trigger on the initiation anniversary.
What good looks like: Your February 2 test automatically generates an August 2 reminder without manual intervention. The system doesn't require you to calculate "six months after we finished last time."
3. Document Your Scheduling Rationale
Done when: You've added a procedure note to your compliance documentation explaining why you start the clock at initiation rather than completion.
Reference page 25 of PCI DSS v4.0.1 and the language about "regularly scheduled and repeatable process." Your QSA needs to see that you've made a deliberate, standards-based decision.
What good looks like: A one-paragraph policy statement in your segmentation testing procedure that reads: "The six-month interval begins on the date testing activities commence, ensuring consistent scheduling as required by PCI DSS v4.0.1. This approach maintains a fixed calendar that supports reliable resource allocation and audit preparation."
4. Establish Maximum Test Duration Limits
Done when: You've set an internal deadline for completing segmentation tests that's shorter than your recurring interval.
If you test every six months, your internal deadline might be 90 days. This prevents the scenario where a test drags past the next scheduled start date.
What good looks like: A project plan template that includes milestone dates and an escalation trigger if testing isn't complete within your defined window. Your team knows that a test starting February 2 must conclude by early May, well before the August 2 next-test date.
5. Plan for Extended Testing Scenarios
Done when: You've documented what happens if a test exceeds your maximum duration and overlaps with the next scheduled test.
The only compliant option: initiate the next test on schedule while completing the previous one. This isn't ideal, but it maintains your "regularly scheduled" commitment.
What good looks like: A written procedure stating: "If segmentation testing from [previous period] remains incomplete when the next scheduled test date arrives, we will initiate the new test on schedule. Both testing efforts will proceed in parallel with separate documentation until the prior test concludes."
6. Validate With Your QSA
Done when: You've presented your scheduling approach to your QSA during an interim call or planning session.
Ask directly: "We start our six-month clock when testing begins, not when it ends. Does this align with your interpretation of the 'regularly scheduled' language in the standard?"
What good looks like: Written confirmation (email or assessment notes) from your QSA that your scheduling methodology meets the standard's intent. You're not surprised by a finding during your ROC or SAQ validation.
Common Mistakes
Starting the clock at completion. This creates a sliding schedule where your test dates drift later each cycle if projects run long. You lose the "regularly scheduled" predictability the standard requires.
Failing to define "start date" clearly. Is it when you send the kickoff email? When the testing team logs in? When you receive the scoping questionnaire? Pick one definition and document it.
Not accounting for test overruns. If your tests routinely take four months but you're testing every six months, you're setting yourself up for overlapping projects. Either shorten your test duration or extend your interval.
Treating this as a technical decision instead of a compliance decision. Your network team might care when testing finishes. Your compliance program cares when it starts. These are different concerns.
Next Steps
- Review your last three segmentation tests and identify the initiation dates.
- Calculate whether fixed-interval scheduling from those dates would have created any overlaps.
- If you find overlaps, either streamline your testing process or extend your interval (annual instead of semi-annual, if your entity type allows).
- Update your compliance calendar with fixed dates for the next 18 months.
- Schedule a 15-minute call with your QSA to validate your approach before your next assessment.
Your segmentation testing schedule isn't just a calendar exercise. It's evidence that your compliance program operates with the consistency and predictability that PCI DSS v4.0.1 requires. Fixed scheduling from initiation dates makes that evidence easy to demonstrate.
