Glossary · Compliance · 4 min read

Sensitive Authentication Data (SAD)

Sensitive authentication data includes card security codes, full track data, and PINs used to authenticate a payment. PCI DSS prohibits storing it after authorization, even in encrypted form.

Also called: SAD

What sensitive authentication data is

Sensitive authentication data, or SAD, is payment-card information an issuer uses to authenticate the card and cardholder. PCI DSS identifies three types: full magnetic-stripe data or its chip equivalent, card verification codes such as CVV or CVC, and PINs or PIN blocks. These details are different from the primary account number and other cardholder data.

The issuer checks these details during authorization. For example, an issuer validates the card verification code entered for an online purchase, or the PIN entered at a terminal. The code printed on the card is SAD even when your business never sees the full card number.

If your business retains a card security code after authorization, encryption does not make that storage compliant.

When SAD is used

SAD helps the issuer assess whether the card and its cardholder are being used in the transaction. Full track data comes from a card’s magnetic stripe or equivalent chip data. A card verification code is supplied for some card-not-present payments, while a PIN or PIN block is used for PIN transactions.

A 3-D Secure authentication value is not SAD under PCI DSS. That distinction matters when you review what your checkout, payment system, or customer-service tools collect: the card verification code remains SAD, but the 3-D Secure value does not.

The storage rule and your risk

You must not store SAD after authorization, even if you encrypt it and even if your system does not store a card number. This is a firm PCI DSS rule. A saved CVV in a customer profile, order record, email, call recording, or support log is still stored SAD.

PCI DSS also requires a policy covering SAD retained before authorization is complete. That policy requirement became mandatory for assessments on March 31, 2025. Retain only what you need before authorization, then securely delete it. Stored codes combined with other stolen customer information can help criminals connect a card to its owner and make fraud harder for issuers to detect.

What it means for your costs

SAD does not create a separate per-transaction processing fee. The financial exposure comes from compliance and security failures: processors commonly bill a monthly PCI non-compliance fee when you have not validated compliance, and a data incident can lead to additional investigation and response costs.

Outsourcing payment handling does not remove your responsibility for your own PCI DSS compliance. Eligible merchants using SAQ A outsource account-data processing and do not electronically store, process, or transmit account data on their systems or premises. Keeping card details out of email, recordings, and business software reduces the amount of sensitive data your systems handle.

What you can actually change

  1. Remove saved codes. Search customer profiles, order records, email, call recordings, and support logs for CVV, CVC, CID, PIN, or track data. Delete stored SAD after authorization, including encrypted copies.
  2. Keep codes out. Use payment workflows that send card details directly to your payment provider instead of routing them through email or internal notes. Do not request a card verification code for stored-credential or recurring transactions.
  3. Review your controls. Confirm your PCI DSS process covers any SAD held before authorization completes and securely deletes it afterward. If you outsource payment handling, document which systems still touch account data.

Frequently asked questions

Is CVV considered sensitive authentication data?

Yes. A card verification code, such as CVV, CVC, or CID, is SAD under PCI DSS. You must not store it after authorization, even if it is encrypted or stored without the card number.

Can I store a customer’s CVV for recurring payments?

No. You cannot retain a card verification code after authorization for a recurring payment. For stored-credential transactions, including recurring transactions, the merchant does not need to provide the code again.

Are 3-D Secure authentication values SAD?

No. PCI DSS does not classify 3-D Secure authentication values as SAD. Full track data, card verification codes, and PINs or PIN blocks are SAD, and the post-authorization storage prohibition applies to them.

Does using a payment provider make my business PCI compliant?

No. Outsourcing payment processing does not remove your responsibility for your own PCI DSS compliance. Eligible SAQ A merchants outsource account-data processing and do not electronically store, process, or transmit account data on their systems or premises.

Readytostartsaving?

Tell us about your volume and we'll estimate what you could save. Free, with no obligation. If you save nothing, we charge nothing.

Customer type
Current processor
How do you take payments?
Net effective rate0.00%