This topic came up this past week in a conversation. I had to go to the PCI DSS v3.2 and check to make sure what was being discussed was accurate. The discussion was around requirement 12.10.1 which says:
“Create the incident response plan to be implemented in the event of system breach. Ensure the plan addresses the following, at a minimum:
Roles, responsibilities, and communication and contact strategies in the event of a compromise including notification of the payment brands, at a minimum
Specific incident response procedures
Business recovery and continuity procedures
Data backup processes
Analysis of legal requirements for reporting compromises
Coverage and responses of all critical system components
Reference or inclusion of incident response procedures from the payment brands.”
The points of the discussion focused on the third and fourth bullets. Yes, that is right, they are calling out business recovery and continuity procedures and data backup processes. This caught me a bit flat footed at first.
For those of you that have been involved in or around PCI for a while are probably scratching your heads because the PCI DSS has never truly cared about business continuity unless it was a hot failover solution. The Council has even said so much at various Community Meetings over the years when business continuity and disaster recovery have come up as question topics.
So, what is the deal?
Well, the guidance provided for 12.10.1 sure does not give you a clue as it only says:
“The incident response plan should be thorough and contain all the key elements to allow your company to respond effectively in the event of a breach that could impact cardholder data.”
And the Report On Compliance (ROC) is still only asking for the name of the QSA that will attest to the incident response plan including these items.
Is the PCI DSS now interested in business continuity?
As I said earlier, the PCI DSS was to a degree interested in business continuity if it was always active as with a hot failover scenario and they have always been concerned about data backup processes as witnessed by requirements 9.5, 9.6, 9.7 and 9.8. The more we discussed these topics the more we believe that the PCI DSS is looking for organizations to ensure continuity of their PCI compliance when they invoke their business continuity plan.
The PCI DSS has only included business continuity (aka disaster recovery) in scope if cardholder data (CHD) is actively involved. This happens when organizations have hot recovery capabilities in their disaster recovery data center or are replicating data (that includes CHD) in real time to a disaster recovery site. Otherwise, the disaster recovery site is not in scope for the PCI assessment. As a result, most organizations push back on including their disaster recovery sites in their PCI assessments if they are cold or warm sites with no CHD involved.
However, here is the rub with that approach. Under the PCI DSS and the card brand agreements, the moment that any disaster recovery site becomes active because of a disaster, it is required to be PCI compliant. There is no grace period. None.
So, if a disaster recovery site has never been assessed for PCI compliance, how does an organization know it will be compliant? They do not. There could be significant PCI compliance issues not just with the site, but with the emergency business processes as well. That is why smart organizations periodically assess their disaster recovery sites and processes for PCI compliance so that there are few, if any, PCI compliance surprises when they activate them.
While the PCI DSS is not asking for an assessment of business continuity and data backup processes, the PCI DSS is providing a friendly reminder to organizations that business continuity can become a compliance problem and should be looked at before it creates an issue.