Many people approach PCI DSS compliance as a once-a-year activity. They get close to the day of reckoning, when their QSA comes on-site. Or they realize that it’s time to fill in the SAQ again. They fix a bunch of issues they became aware of over the year. They hope they’ve checked the boxes, and they’re done for another year.
Unfortunately for these folks, as we’ll see, PCI DSS is not designed to operate like this at all. PCI DSS, like all good information security programs, lowers the risk to what it’s protecting (Cardholder Data / CHD) through regular and routine review of many different controls. Some of these things need to be done annually, but those are the exception. Many others are supposed to be done semi-annually (every 6 months), quarterly, or even more frequently. Some, such as log event review, must be done daily.
Contents
Planning for PCI DSS Compliance
One of the early tasks in understanding the impact of PCI DSS compliance to your organization is establishing your PCI Calendar. This calendar:
- identifies all recurring tasks required by PCI DSS compliance, which your company can’t simply mark as ‘N/A’
- assigns ownership to each tasks such that there is accountability for it being completed
Note that the calendar doesn’t dictate how these tasks will be done. That’s a function of your procedure documentation, which in turn needs to align with the company’s approved policies and the PCI DSS itself. The specific procedure used can even change from time to time, as long as it’s done in accordance with the then-current procedure documents.
Because all calendar items are subject to audit, these procedures must all create some kind of “paper trail” that can be reviewed by a QSA. Otherwise, how can you demonstrate that you actually did the task? Auditors don’t generally like the response “well, our policy says that we only do anything if we find a problem”; they want you to record some evidence for them if everything was OK too.
Everything identified and placed on this calendar is a critical aspect of your PCI compliance. If any one item is found by a QSA to not have been done, that’s an automatic fail unless you are able to construct a compensating control.
PCI DSS Recurring Tasks
As noted previously, there are many different recurring tasks in the PCI DSS. Some of these need to be done on one of various schedules such as quarterly or daily; others should be done on a BAU (Business As Usual) basis.
So what does BAU mean for PCI DSS? BAU compliance tasks are typically those which are done as part of existing processes, rather than as scheduled review activities. As an example, when deploying a new server into an in-scope environment, a BAU task would be to update the network diagram and inventory accordingly.
Another type of BAU activity is one where the PCI DSS requires you to perform a task on an ongoing basis, but doesn’t specify the frequency. A good example of this is section 5.2, where you are required to ensure anti-virus systems are are kept current, and perform periodic scans. There is no definition for current, or frequency for those periodic scans. So these get categorized as BAU activities.
Some sample calendars, such as the one in the Verizon Payment Security Report, bundle BAU activities into the calendar. I’ve chosen to separate those out since they require significantly different handling. The things that BAU and scheduled calendar activities have in common are that they must be done as a core compliance task, and they must generate the all-important paper trail to demonstrate that they were done.
Service Providers
Items that apply to service providers only have been deliberately left out of these lists because they won’t apply to the majority of people reading this. If you’re in business as a PCI service provider, I really urge you to be working with a QSA from early on in your process. They’ll help you draw a line around what’s in scope vs. what is out of scope.
If you’d like to see which tasks are only for Service Providers, you can read the dedicated article on this topic.
Recurring Task Calendar
The following table contains a list of recurring tasks that you should be tracking in your PCI DSS activity calendar, along with the frequency. Some of these may be N/A for your environment, depending on your specific business and scoping. When doing your review, you should cross-reference these with the PCI DSS standard itself. This will both help you understand each specific requirement, and also find any gaps in this list.
Note that some of these tasks need to be done on a recurring basis, and also after any changes to the environment. As such, they should appear both in your PCI calendar, and also in routine procedure documents as BAU activities.
| PCI Requirement | Description of Task | Daily | Weekly | Quarterly | Biannually | Annually | After Changes |
|---|---|---|---|---|---|---|---|
| 1.1.7 | Perform router and firewall rule set reviews with documented evidence of results sets every six months | X | |||||
| 3.1 | Ensure that stored CHD does not exceed defined retention policies and validate secure deletion purge processes | X | |||||
| 6.4.6 | Upon completion of a significant change, implement all relevant PCI DSS requirements on all new or changes systems and networks, and update documentation | X | |||||
| 6.5 | Train developers at least annually in up-to-date, secure coding techniques, including how to avoid common coding vulnerabilities | X | |||||
| 6.6 | If not using a WAF, review public-facing web applications, at least annually, and after any changes | X | X | ||||
| 8.1.4 | Remove or disable inactive user accounts within 90 days | X | |||||
| 8.2.4 | Change user passwords and passphrases at least once every 90 days | X | |||||
| 9.5.1 | Store media backups in a secure location – preferably an off-site facility – such as an alternative or backup site, or a commercial store facility. Review the location’s security at least annually. | X | |||||
| 9.7.1 | Properly maintain inventory logs of all media, and conduct media inventories at least annually | X | |||||
| 10.6 | Review logs and security events for all system components to identify anomalies or suspicious activity | X | |||||
| 10.6.1 | Review logs and security events of all CDE components | X | |||||
| 10.8 | Detect and report on failures within critical security control systems | X | |||||
| 11.1 | Test for the presence of wireless access points (802.11), and detect and identify all authorized and unauthorized wireless access points on a quarterly basis | X | |||||
| 11.1.1 | Maintain inventory of authorized Wireless Access Points (WAPs) | X | |||||
| 11.2.1 | Perform quarterly internal vulnerability scans | X | |||||
| 11.2.2 | Perform quarterly external vulnerability scans | X | |||||
| 11.2.3 | Perform internal and external scans and rescan as needed, after any significant change | X | |||||
| 11.3 | Review and consider threats and vulnerabilities experienced in the last 12 months | X | |||||
| 11.3.1 | Perform external penetration testing at least annually an after any significant infrastructure or application upgrade or modification | X | |||||
| 11.3.2 | Conduct scans of the internal and external networks after any significant change | X | |||||
| 11.3.4 | If segmentation is used to isolate the CDE from other networks, perform penetration tests at least annually and after changes to segmentation controls and methods | X | X | ||||
| 11.5 | Perform critical file comparisons at least weekly | X | |||||
| 12.1.1 | Review the security policy at least annually and update the policy when the environment changes | X | |||||
| 12.2 | Perform a formal, documented analysis of risk, at least annually | X | |||||
| 12.4 | Ensure that the security policy and procedures clearly define information security responsibilities for all personnel | X | |||||
| 12.6.1 | Educate personnel upon hire and at least annually | X | |||||
| 12.6.2 | Require personnel to acknowledge at least annually that they have read and understood the security policy and procedures | X | |||||
| 12.8.4 | Maintain a program to monitor service providers’ PCI DSS compliance status at least annually | X | |||||
| 12.10.2 | Review and test the incident response plan, at least annually | X |
BAU / Business As Usual Tasks
As previously stated, BAU tasks are those that should be “baked in” to other routine procedures followed by your business.
The following table contains a list of BAU tasks that you need to ensure are incorporated into your business processes. Some of these may be N/A for your environment, depending on your specific business and scoping. When doing your review, you should cross-reference these with the PCI DSS standard itself. This will both help you understand each specific requirement, and also find any gaps in this list.
| PCI Requirement | Description of Task |
|---|---|
| 2 | Maintain updated configuration standards (supported versions of operating systems, devices, and applications). |
| 2.4 | Maintain an inventory of system components that are in scope for PCI DSS. |
| 3.6 | Retire or replace keys as necessary, in alignment with documented key management procedures. |
| 4 | Monitor transmission encryption protocol configurations and mechanisms. |
| 5.2 | Monitor antivirus configuration and performance. |
| 6.1 | Use reputable external security resources to identify new security vulnerabilities and assign a risk rating. |
| 6.2 | Ensure that all system components and software are protected from known vulnerabilities, by installing vendor-supplied patches, install critical security patches within a month of release. |
| 8.1.3 | Immediately revoke access for terminated users. |
| 12.3.9 | Activate remote-access technologies for vendors and business partners only when needed by vendors and business partners, with immediate deactivation after use |
| 12.10.3 | Designate specific personnel to be available on a 24/7 basis to respond to alerts. |
| 12.10.4 | Provide appropriate training to staff with security breach response responsibilities. |
Annual Scanning & Assessment
Many organizations who comply with PCI DSS are required to undergo some kind of annual assessment. It’s likely that you will also need to have any Internet-connected networks scanned by an ASV. The specific requirements for these depend on both:
- the number of transactions you process per year; and
- the card brands you accept
This is because the assessment and reporting rules are set by the card brands themselves.
Depending on organization type, you can determine your likely obligations by looking at the articles on Merchant Levels and Service Provider Levels.