What Is Considered Sensitive Data Within PCI SSF?

In the classic holiday film Home Alone, the McAllister family tries to plan for everything they need ahead of their big Christmas trip to Paris.

But the morning they leave, everything descends into chaos and confusion. The family accidentally leaves behind their young son Kevin, ruining the trip for everyone even as the kid gets up to some hijinks at home by himself.

Payment card security is decidedly not a trip to Paris. Still, it can be just as difficult to make sure you’re doing everything you need to before the big event that is your compliance assessment.

The McAllisters didn’t have everything when they got on the plane, but you do need to protect everything if you want to maintain a positive reputation and help your business thrive. What would help is an understanding exactly what is defined as the “sensitive data” that needs safeguarding.

With the emergence of the new PCI Secure Software Framework (SSF), that definition has been thrown into flux and so we want to provide some clarity. To help you make your transition to this new standard as smooth as possible, we will break down what the SSF actually means by the label “sensitive data.”

As qualified assessors for a variety of payment card standards, we have tackled both the SSF and its predecessor PA-DSS. We’re going to map how sensitive data has changed going from one to another. Knowing that, you won’t make like the McAllisters and accidentally leave something behind. Instead you’ll be better equipped for this assessment.

The Difference Between “Sensitive Data” Under PA-DSS and Under the PCI SSF

To put it simply, if you’re looking to switch from the current PA-DSS standard over to the new PCI SSF, you must start thinking about a fundamental change in defining your information that will be considered in-scope.

Under PA-DSS, data that needed to be considered essentially included elements of cardholder data as well as its restricted elements called “sensitive authentication data.” But under the PCI SSF, “sensitive data” now comprises any data used by the payment software that should be protected because of its possible impact on the security of the system or its users.

The key point here is that now, sensitive data is defined by the entity undergoing validation. That means that when you’re assessed against the SSF, PCI—as well as your assessor—will give you some latitude and responsibility to define what you consider to be data that should be protected.

How to Determine “Sensitive Data” Under PCI SSF?

That can seem like a lot of pressure on you now. But here are two tidbits to help you:

• If you previously went through PA-DSS validation and your software still works with cardholder data and sensitive authentication data, then this data should absolutely still be included within the scope of the PCI SSF engagement—after all, it’s still payment software.
• What if you have software that takes or stores ePHI or PII data as well as payment data? It’s time to consider that this data may need to be added to the scope of the assessment and protected under the same or similar controls as the payment data previously included under PA-DSS.

At this point, you’re probably wondering why this data is included within the assessment. Why did things need to shift at all, putting the onus on you?

Because if the PA-DSS was—whether intentionally or unintentionally—a “checkbox” model for payment security, the new PCI SSF is meant to be a true software security framework built around the concept of your buy-in.

The required buy-in includes a strong understanding of the data that your software is collecting and how that data is stored. Not only that, but if you’re looking to undergo validation under PCI SSF, you should write all that down.

How to Create Your Own Sensitive Data Inventory (and Why You Should)

Yes, to successfully meet these new requirements related to sensitive data, you should create a formal and documented data dictionary with a comprehensive sensitive data inventory based on a threat assessment.

When it comes to creating this inventory, here’s what you need to know:

• It is paramount that your inventory is correct and documented before you undergo your validation assessment. Not having it established and in place ahead of time is a major obstruction to the overall process that would delay things.
• Your inventory should be based on a mature threat analysis and risk assessment process. That means that the sensitive data you define should not be arbitrary; rather, consider the impact to be felt if the data were to become compromised. Your assessor will ask for formal documentation regarding how the risk assessment objectively coincides with the inventory.
• Without a sensitive data inventory, you would actually be out of compliance with Control Objective 1.1 and 1.2, which mandate that this data be identified correctly. In addition to the ancillary places within the standard where sensitive data is called out and the inventory used, there are also two high-level Control Objectives that specifically call out the need to define sensitive data—Control Objective 3: Sensitive Data Retention and Control Objective 6: Sensitive Data Protection.

Here’s a working example to further illustrate the importance of a sensitive data inventory:

• Control Objective 3.6 calls for your assessor to test and make sure that sensitive data is not disclosed through unintended channels.
• Without you having first defined said sensitive data, it would be impossible for your assessor to test this Control Objective since they simply wouldn’t know what data to target.
• Maybe certain elements of the personal identifiable information (PII) you keep are allowed to be disclosed whereas certain elements of electronic protected health information you maintain (ePHI) are not to be disclosed under any circumstances? Assessors would never know unless you define the parameters for all of it.

Making the Switch from PA-DSS to the PCI SSF

As much as these changes to the definition of sensitive data—as well the necessary process for defining it—may seem like an added burden, the added clarity is actually how the PCI SSF seeks to improve payment security.

If you’ve been thinking about making the switch to the PCI SSF from the more prescriptive nature of PA-DSS, you now understand the criticality of the changes concerning “sensitive data.”

Ensuring you’re in compliance with the new PCI SSF requirements will mean a fundamental shift in your security process, including the creation of your own data inventory.

Yes, this will require more effort than say, the McAllister family put in to make sure Kevin made the flight. But adopting this more customized and malleable approach to be based on your own threat and risk analysis will help you tailor and improve your security practices.

Defining your own sensitive data should be your top priority as you begin transitioning towards validation under the PCI SSF. Should you have any questions about a potential assessment, we’re happy to set up a conversation with you so as to help you understand how to apply these new requirements to your software.

But if you’re still not sure about making the jump, read our other content on the PCI SSF for further insight on this new standard:

• 5 Major Gaps to Avoid When Transitioning from PCI DSS to PCI SSF (and How to Avoid Them)
• The Benefits of the PCI SSF: Is It Right for You?