Archive for June 23rd, 2016


Disaster Recovery And PCI

Boy!  When topics come up, they come up often and consistently.  Over the past couple of weeks the topic has been disaster recovery (DR) and its effect on PCI compliance.

The first thing that always seems to come up is in regards to where does the PCI DSS specify requirements for disaster recovery?  Most people are confused because they cannot find those requirements.  The reason people cannot find PCI requirements regarding disaster recovery is because there are none.  The PCI DSS does not concern itself with disaster recovery.  PCI does not concern itself with whether or not processes can be recovered, the PCI DSS only cares if sensitive authentication data (SAD) and cardholder data (CHD) are secured.

Which leads to the next question, “I have a hot/warm/cold DR site. Is it in-scope?”  Well, as in the immortal words of the Council, “that all depends.”

In all but the most very rare of cases, if your production data center is in-scope, your hot site is also in-scope for PCI compliance.  The reason is that there is already CHD stored in the hot site because it needs to take over immediately if the primary data center becomes inoperative.

Cold sites are never in-scope for PCI compliance.  By their very definition, a cold site has no equipment other than electrical power, telecommunications terminations, empty racks, HVAC and physical security.  As a result, there is no CHD or any other data storage/processing/transmission at a cold site.

Warm sites are always problematic.  In almost all of these cases, it falls to the QSA/ISA to determine if SAD is processed or transmitted or CHD is stored, processed or transmitted using the warm site.  And do not expect those data flow diagrams to necessarily point out that the warm site is in-scope.  In most cases, the people working on PCI compliance have forgotten how DR processes work or even exist.

This can be trickier than you might think.  The most common situation I encounter is where the people that set up the DR site/processes are no longer with the organization and the people left have no idea of what is stored/processed/transmitted at the warm site.  DR is one of those areas where IT people on their way out of the organization seem to end up.  And as soon as the DR plan is complete, out the door they go.

The next most common situation is data is being replicated SAN-to-SAN between data centers and there may even be servers there, but no production applications/processes are running.  That SAN-to-SAN data replication was likely overlooked because it is done by the SANs and therefore the application and network people likely will not know/remember it is even happening.  And it is always possible that SAD/CHD may or may not be at the warm site until it is used for production.  I have encountered that situation in a few rare cases.

I have also encountered situations were organizations load balanced their networks using their warm site and had SAD and CHD flowing through the warm site to transaction gateways/processors unbeknownst to others in the organization.

As a result, it can take a significant amount of effort to determine if a warm site is in-scope for PCI compliance.

But there is an even more disconcerting issue regarding DR that people do not think about until it is too late.  While the PCI DSS does not concern itself with DR, if production is moved to the DR site for any reason, that DR site immediately comes into PCI scope.  There is no grace period.  When you put production in the DR site, it immediately is in-scope.  So if there are PCI compliance issues at the DR site, they must be remediated as soon as possible because the organization is no longer PCI compliant until they are fixed.

And that is the rub.  DR sites typically are not assessed for PCI compliance because they are out of scope because there is no SAD/CHD there.  And people are vehement in their arguing about scope because assessing a DR site obviously adds to costs and time.  Yet if the DR site is ever invoked, the DR site is immediately in-scope.  This is why I tell my clients to assess their DR site(s) periodically for PCI compliance so they have as few surprises as possible should the DR site get used.  Particularly if there are changes to their DR site or they move to a new DR site.

So there you have it.  DR and PCI in a nutshell.


Welcome to the PCI Guru blog. The PCI Guru reserves the right to censor comments as they see fit. Sales people beware! This is not a place to push your goods and services.

June 2016