PCI DSS Business as Usual: How to Stay Compliant All Year

In PCI DSS, business as usual (BAU) means running your security controls as part of normal operations every day, rather than switching them on for the annual assessment. Under PCI DSS v4.0.1 it is no longer just advice. Requirements 1 to 11 each open with sub-requirements for documented policies, roles and responsibilities, many controls have fixed frequencies, and your assessor looks for evidence across the whole year, not just the week they are on site.

This guide covers maintaining PCI compliance in practice: what BAU means, a compliance calendar you can download and adapt, and the habits that stop controls drifting between assessments.

Key takeaways

• PCI DSS is assessed across the year, so evidence must be collected as you go.
• Many v4.0.1 controls have fixed frequencies; others depend on your targeted risk analyses.
• Change management is where compliance most often drifts.
• Named owners for each recurring task matter more than any tool.
• A mid-year health check finds problems while there is still time to fix them.

What does PCI DSS business as usual mean?

The standard itself includes guidance on implementing PCI DSS into business-as-usual processes. The idea is simple: security controls should be monitored, reviewed and corrected as part of normal work, so that compliance is a by-product of how you operate. Typical BAU practices include:

• Monitoring security controls, such as firewalls, anti-malware and logging, to confirm they are working
• Detecting and responding promptly to failures of those controls
• Reviewing changes to the environment before they are completed, to check the effect on scope and controls
• Reviewing changes to the organisation, such as a merger or a new outsourcing contract, for their effect on PCI DSS
• Periodically confirming that hardware and software are still supported and that required activities are happening

Why does PCI DSS compliance drift between assessments?

Compliance usually slips for ordinary reasons:

• The person who ran the quarterly scans leaves, and nobody picks it up.
• A new system is added to the network without anyone asking whether it is in scope.
• A “temporary” firewall rule becomes permanent.
• Policies are updated the month before the assessment and ignored the rest of the year.

The fix is not heroic effort before the audit. It is a clear list of recurring tasks, each with an owner, a frequency and a place to store the evidence.

Which v4.0.1 requirements make BAU mandatory?

Version 4.0 turned several BAU principles into testable requirements:

What should a PCI DSS compliance calendar include?

The table below lists common recurring activities. Check each against your own environment and SAQ or ROC, as not all apply to every organisation. If you are not sure which SAQ you fall under, our free PCI compliance check suggests the likely one.

Download the PCI DSS compliance calendar (Excel, free, no sign-up) to turn this table into a working plan. It spreads every activity across 12 months, with columns for month, task, requirement, owner and evidence, fills in due dates from your start date and lists the event-driven tasks, such as rescans after a significant change.

Some activities, such as reviewing application and system accounts (7.2.5.1) or inspecting card terminals for tampering (9.5.1.2.1), run at a frequency set by your own targeted risk analysis. Our PCI compliance checklist shows the evidence an assessor expects for each line.

How do you build PCI DSS into change management?

Most compliance drift starts with change. A new server, a cloud service, a payment integration or a firewall rule can all bring new systems into scope or weaken existing controls. Build PCI questions into your change process:

• Does this change store, process or transmit account data, or connect to systems that do?
• Does it alter network security controls or segmentation?
• Is it a significant change that requires rescanning, retesting or a scope review?
• Have system configuration standards been applied?

In agile or DevOps environments, these checks can sit in the pipeline or the definition of done. The aim is that nobody learns about a new in-scope system at the annual assessment.

How often do you need scans and penetration tests?

Scanning and testing are the backbone of ongoing assurance:

• Internal scans every quarter, authenticated where systems accept credentials (11.3.1.2). High-risk and critical vulnerabilities must be resolved and rescanned; lower-risk ones are managed according to your targeted risk analysis.
• External scans every quarter by a PCI SSC Approved Scanning Vendor, with passing results. Build in time for rescans, because a failed scan late in the quarter can leave you with a gap. We deliver ASV scans through our PCI SSC Approved Scanning Vendor partner.
• Penetration tests at least annually and after significant change, plus segmentation tests if you rely on segmentation. Scheduling PCI DSS penetration testing mid-cycle, rather than just before the assessment, leaves time to fix and retest.

Who should own PCI DSS tasks between assessments?

Ownership

Give every recurring task a named owner and a deputy. A simple responsibility matrix, mapped to the requirements, answers the assessor’s question “who does this?” and ensures cover when people are away or leave.

Training

Requirement 12.6 expects security awareness training on hire and at least every 12 months, including phishing and social engineering. Short, frequent sessions tend to work better than a single annual module. Our article on cyber security awareness training covers how to design a programme that sticks.

Service providers

Keep your list of third-party service providers current, check their Attestations of Compliance each year, and maintain the responsibility matrix showing which requirements they cover. When a provider’s AOC expires or changes scope, find out why.

What evidence should you keep between assessments?

Set up a central evidence library organised by requirement. For each recurring activity, store:

• The output (scan report, review record, meeting notes)
• The date it was performed and who did it
• Any actions arising, and evidence they were completed

Evidence gathered at the time is far more credible than evidence reconstructed later, and far less work.

Should you run a mid-year PCI DSS health check?

Yes. A light-touch review around six months after your last assessment is one of the most effective BAU habits. Check that each recurring activity has happened, scope still matches reality, and any changes in your business have been addressed. Our guide to common PCI DSS audit failures lists the areas that most often need attention.

Next steps

Year-round compliance is less about effort and more about rhythm. Sovereign Secure is a PCI SSC-approved QSA company. Our PCI DSS consultancy team runs mid-year health checks and retained support between assessments, so there are no surprises when your next PCI compliance audit arrives.