What is Sensitive Authentication Data?

Learn about sensitive authentication data (SAD), like CVV and CVC, how it works, and why you likely can’t store it. Most everyone knows that merchants and other businesses that accept payment cards must take specific measures to protect the account data associated with a credit card, but did you know that some of its information is more valuable than others? This blog will cover the basics of Sensitive Authentication Data (SAD) and some popular questions regarding its use and storage. 

What is Sensitive Authentication Data (SAD)?

In its glossary, the Payment Card Industry Security Standards Council (PCI SSC) defines Sensitive Authentication Data (SAD) as: 

“Security-related information is used to authenticate cardholders and/or authorize payment card transactions.”

The Payment Card Industry Data Security Standard (PCI DSS v4.0) outlines the rules governing storing, transmitting, and processing credit card data. In its Requirement 3.3, the PCI DSS outlines SAD as follows:

• PIN or PIN blocks
• Card validation codes or values (CVC or CVV), or the 3-4 digit codes on the back of the card
• Full track data (from the magnetic stripe) 

It’s important to note that SAD continues to evolve and that new forms of authentication. Controls, like biometrics, used to authenticate a payment enjoy the same protections outlined in Requirements 3.3.

How is SAD used?

Unlike other pieces of cardholder data, which are used to determine where to route a transaction (e.g., Primary Account Number, or PAN), SAD is used to validate the account's ownership.

For example, when you're checking out online and want to pay with your credit or debit card, the processors, networks, and your bank will use your PAN to identify your account. The CVV, however, will be used to verify you have and/or own the card. This allows the bank and merchant a level of verification that it’s you making the purchase and not someone else using your card data (and thus potentially draining all of your funds).

Who can and cannot store SAD?

Keeping cardholder data and SAD separate plays a critical role in preventing several fraudulent activities. As such, PCI DSS states that organizations should only store sensitive authentication data for the time necessary to complete the transaction and then delete it as soon as possible. This can vary depending on the specific transaction and the organization's policies and procedures.

There is, however, one exception: issuers. These entities, which generate cards for their account holders, can store SAD, but they must have a documented business need and proven security protections to prevent abuse. You can learn about these in the PCI DSS v4.0 Requirement 3.3 (previously 3.2 in PCI DSS v3.2.1). So let’s take a closer look at both of those requirements:

• Business need: Requirement 3.3.3 defines a business need as ​​“necessary for the performance of the function being provided for the issuer.” When assessing your annual compliance, you’ll be expected to surface this as evidence and interview personnel to verify compliance.

• Security protections: SAD must be received in a secure environment like all cardholder data. When stored during authorization, SAD must be encrypted (and promptly deleted if you’re not an issuer). 

You should also note that Requirement 3.3 is not eligible for the customized approach introduced in PCI v4.

How to secure cardholder data?

As we mentioned, SAD is a subset of your credit card’s account data. While you’re likely unable to store SAD, you can keep the other components of cardholder data on file, like PAN, cardholder name, expiration date, and more. To do so, however, you need specialized controls to protect it from abuse. These controls are outlined as 300+ requirements within the PCI DSS and cost tens if not hundreds of thousands of dollars to build and support yourself. 

Fortunately, several service providers, like Basis Theory, can help you bypass the 6-9 month time to build and validate your own PCI-compliant environment. Interested? Check out our PCI Blueprint to learn how you can have your own Level 1 compliant cardholder data environment (CDE) for free and in less time than it takes to complete your morning stand-up.