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.
PCI Guru 
During COVID situation dont you think this req is very much necessary ? even work from home is BC plan
Agreed, but as I stated, until the BCP is invoked and CHD/SAD are flowing through the recovery sites, they are out of scope.
What about the situation where a company activates BC plan for a limited period of time. After all BC plans aren’t meant to be active indefinitely. And company decides not to make their disaster recovery location PCI compliant because it deemed that would be to expensive. How would that be treated and how would be possible to detect that certain merchant/service provider has felt out of compliance for that period?
While you are operating at the DR site, you are non-compliant and subject to fines and penalties which could offset the expense of being compliant.
You could try and get special dispensation from your bank or the card brands, but I will guarantee you they will come back with “you should have understood this fact when you invoke your BCP”.
Excellent post, thank you for the reminder to the community
Is it just me or does everyone else agree that only a fool wouldn’t include his hot site in his ROC? Even a fool would have to contemplate it during the scoping phase and consciously choose to exclude it.
Hot sites by definition would be included in any organization’s PCI assessment. It is warm and cold sites where I encounter push back from clients when they state there is no CHD at them.
The Continuity Plan could be in-scope if it involves the movement or handling of CHD.
If for example the plan calls out, “Bob will pull the CHD database backups, throw them in a box and drive them to the cold site.” There should be some consideration given to how Bob will handle the transfer because he has CHD on the media. Even if it is just to say, “Due to the sensitivity of CHD Bob will lock his car doors and not leave the backups unattended at any time.”
Agreed, but that falls under having CHD stored at the disaster recovery site similar to replicating it there SAN to SAN.