What is Sensitive Authentication Data?

What Sensitive Authentication Data Is

Sensitive authentication data (SAD) is the subset of payment card information that is used to authenticate a transaction but must never be stored after authorisation. It includes three specific data elements: the full magnetic stripe data (or its chip equivalent), the card security code (CVV/CVC/CV2), and the PIN or PIN block.

While PCI DSS allows organisations to store certain cardholder data (like the card number and expiry date) under strict conditions, sensitive authentication data is treated differently. Once a transaction has been authorised, SAD must be securely deleted. No exceptions. No excuses. Even if you encrypt it, even if you think you might need it later. The rules are absolute.

The Three Types of SAD

Full Track Data

The magnetic stripe on the back of a payment card contains two or three tracks of data. This data includes the card number, expiry date, service code, and other information encoded by the card issuer. The chip on a modern card contains equivalent data. Full track data is used during card-present transactions to verify that the physical card is genuine.

If full track data is captured and stored, a criminal could create a counterfeit card with a working magnetic stripe. This is why PCI DSS prohibits its storage after authorisation under any circumstances.

Card Security Codes (CVV/CVC/CV2)

The three-digit code printed on the back of most cards (or four digits on the front of American Express cards) is designed specifically for card-not-present transactions. When a customer provides this code during a phone or online payment, it demonstrates they have physical access to the card -- or at least access to a side of it that cannot be read electronically.

Storing the security code after authorisation is one of the most common PCI DSS violations, and one of the most dangerous. If a merchant's database is breached and it contains card numbers alongside their security codes, the criminals have everything they need to make fraudulent purchases.

PIN and PIN Block

The Personal Identification Number (PIN) is the secret code the cardholder enters at a terminal to authorise a chip-and-PIN transaction. The PIN block is the encrypted form of the PIN as it travels through the payment network. Storing either the PIN or PIN block after authorisation is strictly prohibited because it would allow criminals to make fraudulent in-person transactions and ATM withdrawals.

Why SAD Must Never Be Stored

The reason PCI DSS treats SAD so strictly comes down to the damage that could be done if it were compromised. Regular cardholder data -- the card number, cardholder name, expiry date, and service code -- can be used for fraud, but there are limits. A card number without the security code is less useful for online fraud. A card number without track data cannot be used to create a counterfeit card.

SAD fills these gaps. If a criminal has the card number and the security code, they can shop online. If they have the track data, they can clone the card. If they have the PIN, they can empty the account at an ATM. This is why the payment card industry draws a hard line: once the transaction is authorised and the data has served its authentication purpose, it must be destroyed.

SAD vs Cardholder Data

It is important to understand the distinction between sensitive authentication data and cardholder data, because PCI DSS treats them differently.

• Cardholder data (PAN, cardholder name, expiry date, service code) may be stored if protected according to PCI DSS requirements -- encrypted, access-controlled, and with a documented business justification.
• Sensitive authentication data (full track data, security codes, PINs) must never be stored after authorisation, regardless of how it is protected. There is no business justification that makes it acceptable.

This distinction matters because many organisations do not realise they are storing SAD. Call recordings that capture customers reading out their CVV are storing a security code. Payment forms that save the CVV field to a database are storing a security code. Even log files that capture transaction requests in full may contain SAD without anyone intending it.

SAD and Telephone Payments

Telephone payments create particular risks around sensitive authentication data, especially the card security code. During a typical phone payment, the customer reads out their card number, expiry date, and CVV to an agent. If the call is recorded -- as most contact centre calls are -- the recording contains the CVV in the audio.

This means the organisation is storing sensitive authentication data, which is a direct violation of PCI DSS Requirement 3.2. And it is not just the recording itself -- the audio files sit on servers, get backed up, may be accessible to quality monitoring teams, and could be retained for months or years.

This is one of the most compelling reasons for businesses to adopt DTMF masking for telephone payments. When customers enter their card details on their phone keypad and the tones are masked before reaching the agent, no sensitive authentication data enters the call audio. There is nothing in the recording to violate the storage prohibition, and nothing for an attacker to extract.

Common Mistakes with SAD

Even organisations that know the rules sometimes make mistakes with sensitive authentication data. Here are the most common ones.

• Call recordings Recording calls where customers read out their CVV without any masking or redaction technology in place
• Application logs Payment applications that write transaction details, including security codes, to log files for debugging purposes
• Email and chat Customers sending card details including the CVV via email or live chat, which then sits in mailboxes and chat logs indefinitely
• Paper forms Order forms that include a field for the CVV, which are then filed, scanned, or stored without secure destruction procedures
• Backup systems Even if the primary system correctly purges SAD, backup copies may retain the data for weeks, months, or years

Practical Steps to Protect SAD

Protecting sensitive authentication data is fundamentally about preventing it from being captured and stored in the first place. Once it exists in your systems, you have a problem to fix. The most effective approach is to keep it out entirely.

• Use DTMF masking for telephone payments so that card security codes never enter the call audio or call recordings
• Ensure payment applications are configured not to log security codes or full track data
• Prohibit customers from sending card details by email or chat, and train staff to recognise and reject such communications
• If paper forms are used, eliminate the CVV field entirely -- it is only needed for the transaction itself and does not need to be written down
• Review backup and retention policies to ensure SAD is not being preserved in any form