In this article
A useful PCI DSS calendar connects each activity to a responsible person, the systems it covers and the evidence it produces. Start with your agreed assessment scope and applicable requirements, then schedule the work early enough to investigate findings and verify fixes. A booked test is not evidence that the control operated successfully.
This guide highlights testing and evidence-management examples for PCI DSS v4.0.1. It is not a complete control calendar or an assessment of your environment. Use the current standard and applicable SAQ or ROC to determine the full set of activities, including logging, access reviews, training and incident response.
Does an annual assessment cover the work between assessments?
No. Recurring controls and change-triggered tests need their own owners and records throughout the year. A report of the assessment does not schedule the next scan, remediate a new finding or validate a changed network boundary. Use the calendar below to connect those activities to the applicable requirements and evidence.
Keep scans and penetration tests on separate schedules
The following minimum intervals apply where the cited requirements are applicable. Additional requirements or contractual commitments may call for more frequent work.
- 11.3.1: Run internal vulnerability scans at least every three months; resolve high-risk and critical findings and verify the fixes with rescans.
- 11.3.2: Obtain passing external ASV scans at least every three months, including remediation and rescans as needed.
- 11.3.1.3 and 11.3.2.1: Perform internal and external scans after significant changes. These are separate from the recurring scan schedule.
- 11.4.2 and 11.4.3: Perform internal and external penetration tests at least every 12 months and after significant infrastructure or application upgrades or changes.
- 11.4.5: When segmentation isolates the CDE, test those controls at least every 12 months and after changes to segmentation controls or methods.
- 11.4.6: Service providers using segmentation have an additional six-month testing interval, as well as the change trigger.
- 11.4.4: Correct exploitable penetration-test findings according to the assessed risk, then repeat testing to verify the corrections.
Track patch deadlines separately from scan dates
Under Requirement 6.3.3, patches or updates for critical vulnerabilities must be installed within one month of release. Other applicable patches need time frames based on the risk to your environment. Requirement 6.3.1 provides the vulnerability identification and risk-ranking process; PCI SSC FAQ 1597 explains how it connects to scanning and remediation.
Do not wait for the next quarterly scan to handle a critical patch. Record the release date, affected systems, assigned risk, owner, due date and verification evidence in the remediation register. Keep unsuccessful deployments and open exceptions visible until they are resolved.
Verify vulnerability remediation time frames
Use risk-based frequencies only where permitted
Some requirements explicitly allow an activity frequency supported by a targeted risk analysis under Requirement 12.3.1. Use that flexibility only for the requirements that provide it. Document the reasoning for the chosen frequency; a general risk register does not replace the required analysis or override a fixed testing interval.
Give every calendar entry an evidence owner
For each applicable activity, keep a record that someone else can follow without reconstructing the work from email. The readiness checklist includes a downloadable evidence register you can adapt to your scope.
- Requirement and scope: which control, systems, payment flows and locations the activity covers.
- Owner and reviewer: who performs the work, who checks the result and who covers an absence.
- Due date and triggers: the recurring deadline plus changes that require additional action.
- Evidence location: dated reports, approvals and records accessible to the assessment team.
- Outcome and follow-up: findings, remediation owners, retest results and the next due date.
As a practical management routine, review upcoming work and overdue findings with the responsible teams. When a payment integration, network boundary or provider changes, check the scope and testing impact during change planning. Preserve the original records rather than recreating a clean calendar just before an assessment.
Illustrative change review: a new connection to the CDE
Before adding a network connection, record the intended access, systems involved, control owner and proposed go-live date. Have the responsible team review the scope impact and applicable testing triggers. Link the approved change, test results, remediation and verification evidence in the register. This example is a planning aid, not a determination that a particular change meets PCI DSS.
Arrange the testing identified in your calendar
Related PCI DSS guides
Ask 443 Labs to help map your assessment scope to testing activities, evidence owners and remediation milestones.
Get in TouchOfficial sources
Related Services
