PCI DSS compliance calendar: which tasks recur and how often
A contract, acquirer or assessor that asks for dated evidence of recurring PCI DSS activity is asking for proof that the calendar runs, not just that the controls exist. The standard fixes the frequency of a set of recurring tasks: daily log review, weekly change detection, quarterly internal and external scans and retention checks, six-monthly reviews of network security controls and user access, and annual penetration and segmentation testing. The organization owns every one of these tasks, even when a partner prepares the tooling, the procedures or the records. Your job is to know which tasks apply to your environment, who performs each one, and where the dated output lives so an assessor can sample it. The calendar changes with your position and scope. A service provider has a shorter segmentation test cycle than a merchant, so the same environment can carry different dates depending on which role the entity holds. The number of in-scope systems, the log sources feeding Requirement 10.4.1, and the file integrity monitoring coverage in Requirement 11.5.2 all grow with scope, so an expansion of the cardholder data environment usually adds work to every row. A customized approach or a targeted risk analysis under 12.3.1 can change a frequency, but only when the entity documents the reasoning and the analysis itself. Confirm with your acquirer or the payment brand which entity type and validation route apply before you set any dates. DeployOpen can help prepare systems, schedules, tooling and evidence for these tasks inside your own infrastructure. It does not issue reports, attestations or certifications. Start by building a single register that lists each recurring task, its frequency, its owner, the system it covers and the evidence it produces, then ask your QSA to confirm the frequencies against your scope before the first assessment cycle.
The calendar at a glance: frequency, task and requirement
This table lists the recurring PCI DSS activities by frequency, from daily log review to annual penetration and segmentation testing, with the requirement number that sets each one. Read each row as a task the organization owns and must evidence on its own calendar, then confirm the wording and frequency against the current standard text before you build the schedule.
| Frequency | Recurring task | Requirement |
|---|---|---|
| Daily | Review logs from cardholder data systems, critical components and security functions such as firewalls, IDS/IPS and authentication servers | 10.4.1 |
| Weekly (at least every seven days) | Run change-detection (file integrity monitoring) comparisons on critical files and alert on unauthorized changes | 11.5.2, 11.6.1 |
| Every three months | Run internal vulnerability scans and rescan after resolving high-risk and critical findings | 11.3.1 |
| Every three months | Run external scans through an Approved Scanning Vendor (ASV) | 11.3.2 |
| Every three months | Verify that stored account data past its retention period has been securely deleted or made unrecoverable | 3.2.1 |
| Every six months | Review network security control configurations for continued relevance and effectiveness | 1.2.7 |
| Every six months | Review all user accounts and privileges, including third-party and vendor accounts, and act on inappropriate access | 7.2.4 |
| Every 12 months | Perform internal and external penetration tests | 11.4.2, 11.4.3 |
| Every 12 months (six months for service providers) | Test segmentation controls; service providers test every six months | 11.4.5, 11.4.6 |
Daily and weekly tasks: what assessors sample first
Daily and weekly activities produce the most frequent evidence an assessor will request, so they are usually the first records sampled. The four cards below cover daily log review, weekly change detection, the seven-day payment page cadence, and the records each one leaves behind.
Daily log review under 10.4.1
Requirement 10.4.1 expects logs from every component that stores, processes or transmits cardholder data or sensitive authentication data, every critical system component, and every component that performs a security function, such as network security controls, IDS/IPS and authentication servers, to be reviewed every day. Assessors typically pick a sample of those components and ask for review records covering several recent days. A gap looks like a log source that was never reviewed, reviews that only confirm a job ran without showing findings, or alerts that were raised but never closed. Confirm with your assessor which components they consider in scope.
Weekly change detection under 11.5.2
Requirement 11.5.2 calls for a change-detection mechanism, such as file integrity monitoring, that alerts on unauthorized changes to critical files and compares those files at least once a week. Assessors check that the tool covers the files the organization has defined as critical, that comparison runs actually completed, and that alerts were investigated. Typical evidence is the list of monitored files, weekly comparison reports and alert tickets with a disposition. A gap is a monitored file list that does not match the systems in scope, or alerts that were silenced rather than reviewed.
Seven-day cadence under 11.6.1
Requirement 11.6.1 applies the same weekly rhythm to payment pages. The mechanism must detect changes to the HTTP headers and script content of pages that receive cardholder data, and it must run at least once every seven days, or at a frequency set by a targeted risk analysis under 12.3.1. This requirement became mandatory on 31 March 2025. Assessors sample the tool configuration, the schedule and the alert history. A gap is a schedule that quietly lapsed after a change in hosting, or a page that a marketing tag added outside the monitored list.
Evidence each task produces
Each recurring task should leave a dated record that a second person can read. For log review, that means reviewer sign-off and the findings raised. For change detection and payment page monitoring, that means comparison reports, alert tickets and the approved change that explains each legitimate difference. Ask your team which system holds these records and how long they are kept. Assessors often trace one alert from the tool to the ticket to the change approval, so the chain should work end to end.
How to run the quarterly cycle without a missed scan
This sequence turns the quarterly PCI DSS tasks into a dated, evidenced cycle, so each internal scan, external scan, rescan and retention check is run, recorded and signed off before the next quarter starts. It gives the assessor a clear trail from scheduled activity to completed output.
Set the quarterly dates in the calendar
The compliance lead records the scan windows and the retention-check date for the quarter in the shared compliance calendar, with a named owner for each activity. Each entry links to the scope it covers, such as the in-scope network ranges and the stored-data repositories. The calendar entry is complete when every quarterly activity has an owner, a date and a place where its output will be filed.
Schedule internal vulnerability scans
The security team schedules internal scans of the in-scope components under Requirement 11.3.1, which asks for internal scans at least once every three months. The scans must be run by qualified, independent testers, although a QSA or ASV is not required for internal scans. The output is the scan report for each in-scope range, showing the scan date, scope and tester, which goes into the evidence folder.
Schedule external ASV scans
Under Requirement 11.3.2, external scans of internet-facing components must be performed by an Approved Scanning Vendor. Confirm that the chosen ASV appears on the PCI SSC Approved Scanning Vendor list before the scan is booked, since the list is the authoritative check. The output is the ASV scan report for each external address range, which the ASV delivers after the scan.
Resolve high-risk and critical findings
Engineering teams fix every high-risk and critical vulnerability found in either scan, and document the fix or an approved compensating control where a fix is not possible. Requirement 11.3.1 expects these findings to be resolved and then rescanned to confirm the fix. The output is a remediation log linking each finding to its change ticket and its rescan result, reviewed by the security lead.
Confirm rescans pass
Each remediated external finding must be shown to be resolved by a rescan. For the external scans, PCI SSC FAQ 1152 explains the four-passing-scans requirement, and FAQ 1087 covers how quarterly scan timing is measured. Ask the ASV to confirm the passing status in writing before the scan cycle is closed. The output is the rescan evidence and the ASV attestation of a passing result, filed alongside the original reports.
Run the three-monthly retention deletion check
The data owner runs the check required by Requirement 3.2.1, which confirms that stored account data past its defined retention period has been securely deleted or made unrecoverable. The check covers databases, backups, logs and file shares that hold account data. The output is a deletion log listing each repository, the records removed or rendered unrecoverable, and any exceptions with an approved reason.
File outputs and record owner sign-off
The compliance lead assembles the scan reports, rescan evidence, deletion log and remediation records into one quarterly folder, with an index that maps each output to its requirement. The accountable owner for each area signs a dated record confirming the activities were completed and the exceptions were accepted. The cycle is closed when the folder and sign-off record exist, which is the evidence an assessor will sample first.
What a missed task does to your assessment
The PCI Security Standards Council does not enforce PCI DSS or impose penalties. The payment brands and your acquirer decide which entities must validate, when they must do so, and what happens when they do not. A missed daily log review, a skipped weekly change-detection comparison or a late quarterly scan does not trigger action from the Council itself. It becomes a matter for the brand or acquirer, and their programs differ. Read the Council's position on enforcement in PCI SSC FAQ 1004 and its guidance on consequences in PCI SSC FAQ 1015, then ask your acquirer directly what it would do.
From the assessor's side, a missed task is a gap in the evidence for that period. If the calendar requires a task every seven days and the records show only five weeks of comparisons out of eight, the assessor cannot confirm the control operated continuously, whatever the reason. The impact depends on the assessment type and the brand or acquirer. A gap may be recorded as a finding in a Report on Compliance, or it may stop a Self-Assessment Questionnaire from being signed as compliant. Ask the acquirer which of these applies to you, whether a gap must be reported before the assessment, and whether a re-performed task is treated differently from a missed one.
PCI SSC FAQ 1572 addresses compensating controls for missed periodic activities. Treat this as a remedy to confirm with your assessor before the assessment, not as a standing excuse for skipped work. Document the cause, the period affected, the interim control that covered the gap, and the date the normal task resumed, and keep the record with the evidence for that quarter. Before the assessment, confirm in writing with your acquirer or brand how a missed task will be treated, and agree with your assessor whether any compensating control is acceptable. A missed task that is caught and documented by your own team is far easier to explain than one discovered during testing.
Who runs each recurring task: your team, a provider or the assessor
Your organization owns its controls, and the recurring tasks that depend on daily judgment have to stay with people inside the business. Assessors look for named owners who review logs, act on change alerts and approve access, and they test whether those reviews really happened on schedule.
- Daily log review: Staff must review the logs from in-scope components, critical systems and security tools each day, and record what they checked and what they escalated.
- Change detection alerts: Someone accountable must triage file integrity alerts, decide whether each change was authorized, and keep the record of that decision.
- Access reviews: Business owners must confirm that each account and privilege still matches need, and management must acknowledge the results every six months.
- Policy and procedure upkeep: The security policy and its supporting procedures are written, approved and reviewed by your leadership, not by a vendor.
- Retention checks: Your data owners run the quarterly check that stored account data past its retention period has been deleted or made unrecoverable.
Confirm with each owner that they have a documented backup, that they know the escalation path, and that the evidence they produce is stored where an assessor can reach it.
An implementation partner such as DeployOpen can prepare the systems that make the calendar workable. The partner builds schedules, configures logging and file integrity tools, sets up scan and test runs, and organizes evidence folders. The partner does not sign off on whether your controls meet the standard.
- Schedules and reminders: Partners can build the recurring task calendar in your own tools so each daily, weekly, quarterly and six-monthly activity has a defined owner and due date.
- Log and FIM configuration: Partners can configure log collection and change detection in self-hosted platforms so the alerts and reports your team reviews are complete and retained.
- Scan and test set-up: Partners can prepare internal scan and penetration test runs, but qualified testers must perform and report them.
- Evidence folders: Partners can structure dated, labeled evidence so each recurring task produces a record an assessor can sample.
- Boundary: DeployOpen does not issue reports, attestations or certificates. Scope, deliverables and timelines are agreed in writing before work begins.
Check that the partner's written scope names each calendar task it touches and states that the final judgment and any validation remain with your team and the independent assessor.
Only an independent party issues the validation. A Qualified Security Assessor completes a Report on Compliance or supports an Attestation of Compliance, and an Approved Scanning Vendor performs external scans. The assessor samples evidence from the calendar and tests whether tasks ran as written.
- Sampling of recurring evidence: Assessors choose periods and events to check, so your records must cover the full assessment window, not only the most recent quarter.
- External ASV scans: An ASV performs external vulnerability scans, and the passing results feed the validation. Internal scans do not require an ASV, but they still need qualified, independent testers.
- Penetration and segmentation testing: Testers must be qualified and independent of the systems they test, and the results go into the assessor's report.
- Reliance on other reports: Assessors decide whether they can rely on a SOC 2 report for parts of the work. Read FAQ 1567 on relying on SOC 2 reports and confirm the position with your assessor before you plan around it.
- Independence: The assessor cannot design the controls it tests, so consulting and assessment work should come from different firms or be clearly separated.
Ask your assessor which calendar records they will sample, in what format, and whether any test they rely on needs to be repeated.
Why calendars slip and how to keep them on time
PCI DSS calendar tasks rarely fail because the work is hard. They fail because nobody owns them, nobody reads the output, or the schedule was never updated when the environment changed. The cards below name five common causes and the control that prevents each one, so an assessor can see a dated record for every recurring activity.
Name one owner per task
Every recurring activity needs a single named person, not a team, who is accountable for running it and proving it ran. Daily log review, weekly change detection, the quarterly retention check and the six-monthly account review each need their own row in a calendar with an owner, a backup and a due date. When an owner leaves, the row must be reassigned the same week. Ask whether each task has a name next to it before the assessor asks.
Route alerts into a ticket queue
Log and change-detection tools produce alerts that often go unread, and an unread alert does not satisfy a daily review. Send alerts from logging, file integrity monitoring and intrusion detection into a ticket queue that records who triaged each item, the decision taken and the closure date. Confirm that the queue survives staff turnover and that a missed day shows up as an open item rather than silence.
Re-baseline scans after scope changes
A quarterly scan schedule built for last year's environment can miss new hosts, new cloud accounts or a new payment page. Add a rule that any significant change to systems, networks or the cardholder data environment triggers a review of the scan targets, the segmentation test scope and the calendar itself. Record the date of each change, the person who approved the update and the new scan range. Ask your scanning provider how it handles newly discovered assets.
Include vendor accounts in access reviews
Six-monthly access reviews often cover employee accounts in the directory and skip the accounts used by integrators, managed service staff, support vendors and API service identities. Requirement 7.2.4 covers all user accounts and privileges, including third-party and vendor accounts, so the reviewed list must be built from every system that holds them. Management must also acknowledge the results and document what was removed. Check that the review population is exported from each system, not from the HR list alone.
Store evidence where assessors can reach it
Calendar tasks only count when the proof sits where an assessor can retrieve it. Keep one controlled evidence repository with a fixed folder structure by requirement and frequency, versioned records and a written retention rule that states how long each artifact is kept. Avoid evidence held in personal drives, chat threads or a tool that only one administrator can open. Confirm the retention period with your assessor before you set it, because the calendar and the evidence store must match.
PCI DSS calendar questions buyers ask before hiring help
How much effort does the PCI DSS recurring calendar take each quarter?
The effort depends mostly on scope, so no fixed figure applies. Quarterly work includes ASV external scans and internal vulnerability scans at least every three months, the retention check under 3.2.1, and rescans after high-risk and critical findings are fixed. Effort rises with the number of in-scope systems, the volume of log data reviewed under 10.4.1, the number of third parties with access, and how many scan findings need remediation. Ask any partner to break the quarter into named tasks, owners and hours, and to show which items recur and which are one-time setup.
Can our own team run the PCI DSS calendar without outside help?
Many organizations run the calendar internally, provided someone owns each recurring task and keeps dated evidence. The tasks that most often strain small teams are daily log review across all in-scope components, weekly change-detection comparisons, and the six-monthly account and firewall reviews. Outside help is commonly used to set up tooling, write procedures, or prepare evidence before an assessment. Assessors and Approved Scanning Vendors perform their own independent work, so a partner's preparation does not replace them. Confirm your internal capacity against the full task list before deciding.
Does one missed PCI DSS task automatically fail an assessment?
No, a single missed periodic activity does not automatically fail an assessment. The PCI SSC does not enforce compliance or impose penalties, and the payment brands and acquirers decide how a gap is handled. Assessors look at whether the requirement is met as a whole, and PCI SSC guidance describes compensating controls for missed periodic activities. Still, a missed task is a finding that needs documentation, root cause and correction. Ask your acquirer which consequences apply to you and ask your assessor how they treat a lapse before the assessment window.
Did requirements 11.6.1 and 7.2.4 become mandatory on 31 March 2025?
Yes, both became mandatory on 31 March 2025. Requirement 11.6.1 requires a change and payment page detection mechanism to run at least once every seven days, or at a frequency set by a targeted risk analysis. Requirement 7.2.4 requires review of all user accounts and privileges, including third-party and vendor accounts, at least every six months, with management acknowledging the results. Before that date both were future-dated requirements that could be marked not applicable. Confirm your current evidence covers the weekly and six-monthly cycles from that date.
Does the PCI DSS calendar change for service providers?
Yes, the main difference for service providers is segmentation testing. Segmentation tests run every 12 months for most entities, but service providers test segmentation every six months under requirement 11.4.6. Service providers also face the six-monthly review of network security control configurations under 1.2.7 and the six-monthly account review under 7.2.4, which apply to all entities. Shared hosting or managed services add responsibility matrix reviews and customer-facing evidence. Check the current SAQ D for Service Providers and your assessor's plan before fixing dates.
What should we ask an implementation partner for in a written scope?
Ask for a written scope that lists each recurring task by requirement and frequency, the owner for each task, and who performs it: your team, the partner, a scanning vendor, or the assessor. The scope should name the systems and log sources covered, the evidence produced for each task and where it is stored, and the handover of runbooks and dashboards. Ask which activities are one-time setup and which recur, what triggers an update after a significant change, and what is excluded. Confirm that the partner prepares evidence but does not issue reports, attestations or certifications, which only independent assessors can do.
Which calendar tasks are the most expensive to outsource?
Costs depend on how each task is delivered, and no typical figure applies. Quarterly external scans must come from an Approved Scanning Vendor, while internal scans may be run by qualified staff or a provider. Penetration tests and segmentation tests recur at least annually or every six months for service providers, and their cost depends on scope and environment complexity. Daily log review and weekly change detection are often the largest ongoing effort if they are not automated. Ask each provider to quote these as separate recurring line items so you can see which ones you can move in-house later.
How DeployOpen builds and evidences the PCI DSS calendar
DeployOpen helps organizations set up the systems that produce PCI DSS recurring evidence: daily log reviews, weekly change detection, quarterly scans and six-monthly account reviews. We build and document these routines inside your own infrastructure, then hand them to your team, while the organization keeps ownership of its controls and an independent QSA or ASV issues any validation.
How we scope
- We agree a written scope listing which recurring tasks, systems and log sources the calendar covers before work starts.
- Engagements are fixed-scope, with deliverables and timelines confirmed in writing before any build begins.
- Scope documents which frequency applies to each task, so your assessor can trace each activity to its requirement.
How we build
- We configure log collection, file integrity monitoring and scheduled review jobs in your cloud accounts or data centers.
- We test that alerts fire and that each recurring job runs at its defined frequency, recording the results.
- We set up ticketing and review workflows so every daily, weekly and quarterly task leaves a dated, attributable record.
How we hand over
- You receive a calendar listing each recurring task, its owner, its frequency and the evidence it produces.
- We document runbooks for each routine so your staff can perform and record the tasks without us.
- Handover includes a list of evidence locations and retention settings that your assessor can review directly.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover maintenance of scheduled jobs, alert tuning and updates to the calendar when your environment changes.
- Ask us to confirm in writing which calendar items remain your team's responsibility and which a retainer covers.
