When You Change Processors, What Happens To Your Data?

A 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.

Have you ever wondered what happens to all your old card transaction data after you change your processor or acquirer? Most retailers have made such a change, and many make it a practice to rebid their card-processing contract every few years. After you move on, though, your data frequently doesn't follow you. What are your responsibilities if this old data gets compromised?

Are you still responsible under PCI Requirement 12.8 for managing a service provider when you no longer have a relationship with that provider but it still has your data? Aside from PCI considerations, if a service provider--think tokenization vendor or loyalty program manager--simply goes out of business, how will you get your data back?

(Editor's Note: See related story about who is truly responsible under PCI for dealing with breached former processors.)

I am neither a lawyer nor do I work anymore for a card brand, so I can't say for sure that you would be held responsible for a third-party data breach in the above situations. But I do know that a large retailer makes a better headline than an obscure third-party provider. That fact alone should be reason enough for you to take a fresh look at your third-party service provider contracts.

Requirement 12.8 is probably my favorite in all of PCI. It states that if a merchant shares cardholder data with any third party, the merchant is responsible for having policies and procedures in place to manage that third-party relationship. Exactly what those policies and procedures should be is spelled out in four sub-sections.

One reason 12.8 is my favorite PCI requirement is that every merchant--from the largest Level 1 retailer that requires a 100-page Report on Compliance to the corner store that outsources its processing and validates its compliance with the two-page Self-Assessment Questionnaire "A"--has to confirm explicitly it is managing all its service provider relationships.

Another reason it is my favorite: 12.8 implicitly recognizes that cardholder data is toxic and that it continues to be toxic long after the original transaction. If you are going to entrust an outside organization with your cardholder data, PCI obligates you to take certain safeguards. These safeguards include securing the third party's agreement, in writing, that it will take responsibility for the cardholder data you entrust to the provider (12.8.2).

When you specify the contract details, then, it makes sense to ensure the terms carry on past the expiration of your current agreement and continue so long as the third party holds or has access to your data. Most CIOs will be familiar with such a continuing provision. Just about every non-disclosure agreement ever written includes one, whereby even after a particular project is over, neither party is free to disclose the other's confidential information. The same thinking applies here.

The parallel for CIOs is to use 12.8 to put that same continuing obligation in your service provider agreements. In the course of PCI assessments, I have seen several of these agreements. I don't recall too often, however, seeing an explicit recognition of the continuing value of the data beyond the initial term of the contract.Although you can outsource your processing, you cannot outsource your responsibility. By that I mean if a third party gets breached and loses your data, you are likely to be held responsible even if that data is a year old and you no longer work with that third party. You will get the headlines and likely the fines, too.

A related situation is when you want to access your data but can't. If you change processors and want to get back your old transaction data, does your original processor provide it or--better yet--send it along to your new processor? Or, what if your tokenization, encryption or key management vendor goes out of business? Can you get your original data back? Is there a provision in your contract for some form of data escrow where you can retrieve your original data either in case of business interruption or if you just want to change vendors?

At this point, we have to address the issue of whether the actions I'm describing would effectively put all the data back into your PCI scope. Particularly in the case of tokenized or encrypted data, which is generally considered to be in your PCI scope. The exception is if you, the merchant, have no ability to get back to the original clear text data. This exception should allow you the leeway to protect your organization.

The idea is that you do not have access to the clear text data unless and until you need to actually take it back, per the conditions spelled out in your contract. For example, in the case of tokenized or encrypted data, you cannot access that cardholder data unless, say, the vendor's business fails. Should you need to exercise this provision, though, at that point and only at that point, would the data come into your PCI scope.

I would hope service providers of all types would see the benefit in what I'm suggesting. In the case of a processor, it might be reluctant to ease your transition to a competitor. But obstructing the process only guarantees that processor will have no chance whatsoever of getting back your business the next time around. For a tokenization or encryption provider, offering some form of data escrow reduces the customer's risk and gives potential customers more confidence in the company. There may even be a business niche for such data escrow providers.

Alternatively, if you, the merchant, decide you don't want or need your old data, your contract can obligate the service provider to purge your data permanently on your orders. Just don't forget to do it if that's your plan.

Merchants and QSAs may disagree or have difficulties with individual pieces of PCI Requirement 12.8. But that requirement is in place to help merchants protect the data they share with third parties--even after the initial contract has expired. Remember that to take full advantage of this safeguard, you need to have a long-range view and think beyond the initial term of your present third-party agreements.

What do your third-party contracts look like? Do you have provisions that go beyond the initial term and obligate your providers to return or purge your data? It is your data, after all. If you're a service provider, what objections do you have to my suggestions? I'd like to hear your thoughts. Either leave a comment or E-mail me.