What is Sensitive Authentication Data?
Sensitive Authentication Data (SAD) is a category of payment card information that is used to authenticate transactions but must never be stored after authorisation. It includes the card security code (CVV/CVC), PIN or PIN block, and full magnetic stripe or chip data. PCI DSS strictly prohibits the retention of SAD after a transaction is authorised.
What Counts as Sensitive Authentication Data
PCI DSS defines three types of sensitive authentication data:
Card Security Code
The three or four digit code printed on the card (known as CVV, CVC, CV2, or CID depending on the card brand). This code is used to verify that the person making a card-not-present transaction has physical possession of the card. It must never be stored after authorisation, even in encrypted form.
PIN and PIN Block
The personal identification number entered by the cardholder at a point of sale terminal or ATM. The encrypted version of this data (the PIN block) is also classified as SAD. Storing PINs or PIN blocks after authorisation is strictly prohibited.
Full Track Data
The complete data stored on the magnetic stripe or chip of a payment card. This includes the primary account number (PAN), cardholder name, expiry date, and additional security values used for card authentication. Full track data must never be stored after authorisation.
Why SAD Must Never Be Stored
If sensitive authentication data is compromised, criminals can create counterfeit cards or make fraudulent transactions that are very difficult to detect. Unlike the card number alone, which can be tokenised or encrypted for legitimate business purposes, SAD has no valid reason to exist in any system after a transaction has been authorised.
This is why PCI DSS takes a hard line: there is no acceptable method of storing SAD post-authorisation. No level of encryption, access control, or security justifies keeping it. If an organisation is found to be storing SAD after authorisation, it is in direct violation of PCI DSS.
SAD vs Cardholder Data
PCI DSS distinguishes between sensitive authentication data and cardholder data. Cardholder data -- such as the PAN, cardholder name, and expiry date -- may be stored if properly protected with encryption and access controls. Sensitive authentication data may never be stored after authorisation, regardless of the protection applied.
Both categories fall under PCI DSS scope, but the rules for SAD are absolute: capture it for the transaction, then discard it immediately.
Paytia's platform is designed so that sensitive authentication data never enters your environment. When a customer keys in their card details during a phone payment, the data is captured and routed directly to the payment processor through Paytia's PCI DSS Level 1 certified infrastructure.
Your agents never hear, see, or have access to the card security code, and no SAD is stored anywhere in your systems. This eliminates the most serious category of PCI DSS risk from your contact centre entirely.
Frequently Asked Questions
Can I store the CVV code if I encrypt it?
No. PCI DSS prohibits the storage of sensitive authentication data after authorisation regardless of the protection method used. This includes encryption, hashing, or any other technique. The CVV code must be discarded as soon as the transaction is authorised.
What is the difference between sensitive authentication data and cardholder data?
Cardholder data (such as the card number, cardholder name, and expiry date) may be stored if properly protected with encryption and access controls. Sensitive authentication data (CVV codes, PINs, and full track data) must never be stored after authorisation under any circumstances. Both are covered by PCI DSS but SAD has stricter rules.
What happens if my business is found storing sensitive authentication data?
Storing SAD after authorisation is one of the most serious PCI DSS violations. It can result in significant fines from the card brands, mandatory forensic investigations, and potential termination of your ability to accept card payments. If a breach occurs as a result, the organisation may also face legal liability for fraud losses.
See how Paytia handles sensitive authentication data (sad)
Book a personalised demo and we'll show you how our platform works with your setup.
Request a Demo