PCI Sensitive Authentication Data Requirements - What you should know?

Published on : 09 Jul 2022

PCI Sensitive Authentication Data Requirements – What you should know?

The PCI Council aims at minimizing the risk of cardholder data by securing sensitive cardholder data including Sensitive Authentication Data (SAD). For these reasons, PCI DSS Standards are strictly enforced in the payment card industry. According to the PCI DSS Security Standard Requirement, organizations dealing with sensitive card data are required to maintain maximum security and implement measures that ensure the confidentiality, privacy, and security of the cardholder data.

That said, there are specific requirements outlined for securing the Sensitive Authentication Data that stipulate organizations to not store magnetic stripe data, personal identification numbers (PINs), and card verification values (CVVs). Understanding this security requirement a bit in detail, we have shared information on the PCI requirements outlined in the PCI DSS 4.0 for Sensitive Authentication Data (SAD) in the article today. But before getting into the details let us understand the term Sensitive Authentication Data.

What is Sensitive Authentication Data (SAD)?

Sensitive Authentication Data (SAD) can be referred to as the information used to authorize card transactions, which includes

  • Magnetic Stripe Data
  • EMV chip data
  • Card validation codes or values, printed on the front or back of physical credit cards (3- or 4-digit number)-
    • CVV2
    • CVC2
    • CAV2
    • CID
  • Personal Identification Numbers (PIN)

These are highly sensitive card data that must be secured to prevent any potential cases of data breach incidents. While other card data such as Name, Primary Account Numbers (PAN), and other cardholder data are equally important and may be used for committing fraud. But the processing of a transaction requires SAD for authorization. For these reasons, the PCI Council emphasizes securing SAD data with the stringent PCI DSS requirements specifically outlined for protecting SAD data.

What does SAD mean as per PCI DSS?

From the PCI Council standpoint, SAD is cardholder data that is highly sensitive and requires maximum security. For these reasons, the PCI Council has enforced the PCI DSS Requirements for the security of SAD data, and merchants are expected to comply. As one of the most protected categories of data under the PCI DSS, SAD requirements are particularly stringent. The PCI Council emphasizes securing SAD data stored by Merchants and Service Providers.

The PCI Council in its latest version of PCI DSS 4.0 has outlined additional measures to ensure the security of the SAD data. While the earlier version of PCI DSS 3.2.1 had also outlined measures for SAD, the latest version is more specific and has further added additional requirements for securing the data. Meeting PCI compliance sensitive authentication data requirements is mandatory for merchants to protect and prevent the loss of valuable cardholder data which could also result in non-compliance with PCI DSS.

pci dss free consulting call

So, as per the payment standard, the merchant/service provider is not allowed to store the SAD information in their system. This further means that the SAD cannot even be stored in an encrypted format as well. The data is required to be deleted soon after the transaction.

However, in certain specific exceptions such as card issuing organizations that may store SAD are required to implement and maintain appropriate security measures and processes for the protection of the SAD data. Again the exception to allow storing of SAD data would be keeping in mind the minimized, and secure storage requirement and also having a legitimate business-need justification for this exception of storage. These requirements and standards were set to reduce the risk of theft or fraud in the process of card transactions.

What are the PCI DSS Sensitive Authentication Data Requirements?

Earlier in the previous version of PCI DSS 3.2.1, the requirement 3 Protect Stored Cardholder data at the time of storage. So, although the requirement in this version always included specific controls for protecting the full magnetic stripe data, the PIN/PIN Block and the Card Verification Code, the name of the requirement in the 3.2.1 versions of the PCI DSS simply just mentioned cardholder data and not explicitly include Sensitive Authentication Data which brought in inconsistency.

pci sensitive authenticity

However, in the PCI DSS 4.0 version, this was addressed with the requirement now being named Protect stored account data which explicitly defined the types of data that should be protected including the cardholder data and sensitive authentication data, as part of Protect Account Data. The latest version 4.0, has now provided long-overdue clarifications to the existing requirement and also added additional requirements as a part of improving the security measures.

pci sensitive account data

Additional Controls for Protecting Sensitive Authentication Data

PCI DSS 4.0 version included additional clarifications and controls for the protection of Sensitive Authentication Data stored before the completion of the authorization process. This includes

  • Inclusion of SAD data in the retention and secure deletion policy, to limit the storage of the data to the minimum necessary (req. 3.2.1),
  • Encryption of SAD data using strong cryptography, even if the PAN data is not present in the environment (req. 3.3.2 and 3.3.3).

These controls will be currently seen as good practice but will soon be effective as of March 31, 2025.

pci sensitive data

Explaining Requirement 3 concerning the protection of SAD in detail

Requirement 3.2- Storage of Account Data Kept to a Minimum

Requirement 3.2.1 talks about maintaining the account data storage to a minimum through the implementation of data retention and disposal policies, procedures, and processes that includes the SAD data stored before completion of authorization. The requirement includes

  • Limiting the data storage amount and retention time to that which is required for legal or regulatory, and/or business requirements.
  • Specific retention requirements that define the length of the retention period and include a documented business justification.
  • Defining a process for the secure deletion or rendering the data unrecoverable when no longer needed per the retention policy.
  • Define and establish a process for verifying, at least once every three months, that the data exceeding the defined retention period is securely deleted or rendered unrecoverable.


These measures are explicitly outlined for account data which includes the SAD data to ensure it is kept to a minimum, and only retained for the defined amount of time for maximum security of this highly sensitive data categorized under PCI DSS 4.0

Requirement 3.3 Sensitive Authentication Data (SAD) is not Stored After Authorization.

Requirement 3.3 talks about ensuring that SAD is not retained after authorization, even if it is in an encrypted form. All SAD data received should be rendered unrecoverable on completion of the authorization process. The requirement includes-

  • Sub requirement 3.3.1. – If SAD is received, the organization must examine documented policies, procedures, and system configurations to verify that the data is not retained after authorization.
  • Sub requirement 3.3.1. – If SAD is received, the organization must examine the documented procedures and ensure the secure data deletion processes. This is to verify the data is rendered unrecoverable on completion of the authorization process.

These measures are explicitly outlined for the SAD Account Data to prevent fraudulent transactions by malicious individuals. Hence the storage of SAD on completion of the authorization process is prohibited.

It is however important to note that the above requirement does not apply to issuers and companies that support issuing services (where SAD is needed for a legitimate issuing business need) and have a business justification to store the sensitive authentication data before authorization. But in that case, the organization is expected to follow and implement Requirement 3.3.2 of PCI DSS 4.0.

Sub Requirement 3.3.2- SAD that is stored electronically before completion of authorization should be encrypted using strong cryptography. Organizations must further, examine data stores, system configurations, and/or vendor documentation to verify that all SADs that is stored electronically before completion of authorization is encrypted.

Sub Requirement 3.3.3- Additional requirement for issuers and companies that support issuing services and store sensitive authentication data

Organizations must ensure –

  • Storage of SAD to be limited to that which is needed for a legitimate issuing business need and is secured.
  • Encrypted using strong cryptography
  • Consider encrypting SAD with a different cryptographic key than what is used to encrypt PAN. Note that this does not mean that PAN present in SAD (as part of track data) would need to be separately encrypted.

Final Thought

SAD in general is not permitted to be stored in systems. However, in case of an exception where the organization is permitted to store SAD before authorization, then they are expected to implement all the necessary and appropriate security measures to prevent non-compliance and the potential risk of a data breach. That said, it is also important to note and understand that whether or not your organization falls in the case of exception should be determined by payment brands, acquirers and the PCI qualified PCI QPA. So, in case of any doubts or queries regarding the PCI SAD requirements and the applicability of the requirements you can contact us at [email protected]. VISTA InfoSec is a qualified PCI QSA, who can guide you in your compliance journey.

4.8/5 - (5 votes)
Narendra Sahoo
Narendra Sahoo

Narendra Sahoo (PCI QPA, PCI QSA, PCI SSF ASSESSOR, CISSP, CISA, CRISC, 27001 LA) is the Founder and Director of VISTA InfoSec, a global Information Security Consulting firm, based in the US, Singapore & India. Mr. Sahoo holds more than 25 years of experience in the IT Industry, with expertise in Information Risk Consulting, Assessment, & Compliance services. VISTA InfoSec specializes in Information Security audit, consulting and certification services which include GDPR, HIPAA, CCPA, NESA, MAS-TRM, PCI DSS Compliance & Audit, PCI PIN, SOC2 Compliance & Audit, PDPA, PDPB to name a few. The company has for years (since 2004) worked with organizations across the globe to address the Regulatory and Information Security challenges in their industry. VISTA InfoSec has been instrumental in helping top multinational companies achieve compliance and secure their IT infrastructure.