According to the payment card industry’s (PCI) Data Security Standards (DSS), organizations must minimize the breach risks to cardholder data (CHD), including sensitive authentication data. Specifically for PCI compliance, sensitive authentication data requirements generally stipulate that organizations may not store magnetic stripe data, personal identification numbers (PINs), and card verification values (CVVs).
PCI Compliance Sensitive Authentication Data (SAD)
Securing the collection processing, storage, and transmission of CHD allows organizations—termed “merchants” by the DSS—to focus on running critical business operations while minimizing risk. As one of the most protected categories under the PCI DSS, sensitive authentication data (SAD) requirements are particularly strict.
Per PCI DSS stipulations, the strict PCI compliance sensitive authentication data requirements prohibit SAD storage beyond transaction authorization. However, specific exceptions, such as card issuing organizations, may store SAD if the proper security measures and processes for protection have been implemented:
- Minimized, secure storage
- Legitimate business-need justification
Meeting PCI compliance sensitive authentication data requirements will help protect your organization from threats—preventing the loss of valuable customer data and preventing noncompliance.
What is Sensitive Authentication Data (SAD)?
Concerning compliance with the PCI DSS, sensitive authentication data (SAD) refers to the information used to authorize card transactions, such as:
- Magnetic stripe data
- EMV chip data
- Card validation codes or values, printed on the front or back of physical credit cards as a 3- or 4-digit number:
- CVV2
- CVC2
- CAV2
- CID
- Personal identification numbers (PIN)
While names, primary account numbers (PAN), and other cardholder data may be used to commit fraud, successful transaction processing generally requires SAD for authorization. As a result, some of the strictest PCI DSS requirements stipulate the necessary SAD security measures.
Request a Free Consultation
What are the PCI DSS Sensitive Authentication Data Requirements?
The most critical of the PCI compliance sensitive authentication data requirements is PCI DSS Requirement 3.2. This stipulates that organizations processing card payments cannot store SAD, even when encrypted. Organizations must completely erase sensitive authentication data—ensuring irrecoverability—once transaction authorization is complete.
However, PCI DSS SAD requirements do allow storage for organizations issuing payment cards or those companies supporting issuing services under business-critical justifications. These organizations must meet certain criteria:
- SAD is stored strictly for documented, legitimate business purposes, as stipulated in a data retention policy
-
- Per guidance in the full PCI DSS v3.2.1, business justification legitimacy is determined as stored SAD being “necessary for the performance of the function being provided for the issuer.”
- SAD storage is secure, “in accordance with all PCI DSS specific payment brand requirements,” which include:
- SAD retention must be limited to the required minimum for legal, regulatory, or business purposes.
- SAD deletion processes must be established for secure, unrecoverable elimination when storage is no longer necessary.
- Quarterly processes must be defined and executed to identify and destroy unnecessarily stored SAD.
SAD PCI DSS Sub-Requirements and Testing Procedures
Included within the full text of PCI DSS Requirements are sub-requirements and Testing Procedures used to evaluate compliance. For Requirement 3.2 and, in particular, SAD, PCI DSS specifications are:
- Requirement 3.2 – SAD may not be stored regardless of encryption following transaction authorization. Any SAD received must be rendered unrecoverable.
- Testing Procedure 3.2.a – For organizations permitted to store SAD, examine documented policies and conduct interviews with relevant personnel to confirm the legitimate business reason.
- Testing Procedure 3.2.b – For organizations permitted to store SAD, evaluate SAD storage environments and security configurations to confirm security.
- Testing Procedure 3.2.c – For organizations not permitted to store SAD, examine policies, procedures, and configurations to confirm that no sensitive authentication data is retained.
- Testing Procedure 3.2.d – For organizations not permitted to store SAD, examine policies and procedures to confirm that any received sensitive authentication data is deleted beyond recovery.
- Requirement 3.2.1 – Storage of any sensitive authentication track data following transaction authorization is not permitted. Storage of non-SAD track data (e.g., primary account numbers) must be minimized to necessary, business-justified reasons only.
- Requirement 3.2.2 – Storage of card verification codes (e.g., CVV2, CVC2) following transaction authorization is not permitted.
- Requirement 3.2.3 – Storage of any PINs or encrypted PIN blocks following transaction authorization is not permitted.
Note that the Testing Procedures for Requirements 3.2.1, 3.2.2, and 3.2.3 provide the same assessment guidance with regard to their respective data types: Ensure that track data, particularly SAD, is not stored from data sources, including:
- Incoming transactions
- Logs (e.g., transaction, history, debugging, error)
- History and trace files
- Database schemes and contents
What Cardholder Data Can You Store?
Since PCI DSS SAD requirements prohibit any storage by most organizations, what cardholder data storage is permitted?
If sufficient protections have been implemented and retention amount and duration are minimized, the PCI DSS allows merchants to store:
- Primary account numbers (PAN), which must also adhere to:
- Requirement 3.3 – PAN must be securely masked (i.e., displaying no more than the first six and last four digits), except for viewing by authorized personnel in legitimate business-need cases.
- Requirement 3.4 – PAN should be stored in an unreadable format, whether storage utilizes backup media, logs, or wireless networks.
- Name of cardholder
- Service code
- Expiration date
PAN—Storing in an Unreadable Format
Unreadable PAN storage can be achieved via the following PCI DSS-approved methods:
- One-way hashing of entire PANs, using tested cryptographic measures
- Truncation of PAN segments to limit potentially compromising exposures of full PANs
- Index tokenization and use of securely stored pads or random keys to encrypt PANs
- Robust protocols ensuring secure management of cryptographic keys
Note that the storage of truncated and hashed versions of PAN in the same CHD environment can potentially compromise CHD integrity. Therefore, organizations must implement security controls to minimize risk.
If your organization needs to locate all instances of stored PAN or other personally identifiable information (PII), a PII/PAN scan will help determine and reduce PCI DSS compliance scope.
Encrypting CHD
SAD storage is rarely permitted—even when encrypted. However, encryption practices can be used to secure allowable CHD categories, of which the most critical measures include:
- Implementing the proper use of both key-encrypting keys and data-encrypting keys. Specifically, service providers are required to document any cryptographic architecture used to encrypt CHD, including:
- Detailed measures such as algorithms, protocols, and keys, including expiry dates and key strength
- Details about the usage of each cryptographic key
- Inventory of the hardware security modules (HSMs) and secure cryptographic devices (SCDs) used to manage cryptographic keys
- Restricting cryptographic key access to only authorized individuals
- Storing all cryptographic keys, both secret and private, in various forms, including:
- Key-encrypting keys that are just as robust as data-encrypting keys
- Secure devices (e.g., HSMs)
- Industry-accepted standards, processes, and tools, such as (at least) two full-length key components
- Minimizing the locations in which cryptographic keys are stored
- Complete documentation of cryptographic key management processes, the most critical of which include:
- Generating unique keys that match industry standards
- Securing key distribution and storage to prevent unauthorized access
- Routinely changing expired keys at defined intervals, per vendor or key owner recommendations and guidelines such as NIST Special Publication 800-57
- Replacing or retiring vulnerable keys (e.g., following employee departures)
- Restricting unauthorized key substitution
- Ensuring that the custodians holding access to keys have a proper understanding of their roles and responsibilities in key management
Implementing and enforcing strict encryption management will help meet PCI DSS requirements, providing compliant CHD integrity.
Assess PCI Compliance for Sensitive Authentication Data
Generally speaking, no organization aside from those performing card issuing functions may store SAD in any form.
As a cybersecurity expert and PCI Security Standards Council-approved third-party assessor, RSI Security can help your organization ensure that PCI compliance sensitive authentication data requirements are met. RSI Security can also perform required assessments for compliance reporting as a Qualified Security Assessor (QSA) and Approved Scanning Vendor (ASV).
To learn more, contact RSI Security today.
Download Our PCI DSS Checklist
Assess where your organization currently stands with being PCI DSS compliant by completing this checklist. Upon filling out this brief form you will receive the checklist via email.