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

What PCI DSS v4.0.1 actually says about SAD

The clearest rules are in PCI DSS v4.0.1 Requirement 3.3.1: "Sensitive authentication data is not retained after authorisation, even if encrypted." That's the whole rule. There's no carve-out for "we'll only keep it for 24 hours," no exception for "we encrypt it with a hardware module," and no allowance for "it's only in the call recording, not the database." Authorised, then gone — that's the test.

Requirements 3.3.2 and 3.3.3 add the operational detail. If SAD is captured before authorisation (because the card data arrives in a single payload), it must be rendered unrecoverable as soon as authorisation completes. Logs, debug output, troubleshooting files, application memory, message queues — every place the data might land has to be in scope of the deletion. Requirement 12.10.1 then puts the auditor's eye on incident response: if you find SAD where it shouldn't be, you treat it as an incident, not a tidy-up task.

One detail people miss is that SAD applies during the authorisation flow as well. If a payment gateway batches transactions and sits on the security code for 30 seconds while it routes them, that 30 seconds is fine — the data hasn't lived past authorisation. If your CRM grabs a copy of the same payload "in case of disputes," that copy is a hard violation the moment the authorisation response comes back.

SAD in card-not-present vs card-present flows

The SAD rules read the same on paper but bite differently depending on how a customer is paying.

Card-not-present (phone, web, MOTO) flows lean heavily on the CVV. The card number proves the card exists; the CVV proves the customer is holding it. That's why every online checkout asks for the three-digit code and every contact centre agent reads it back to enter it into a virtual terminal. The risk is huge — if the CVV ends up in a call recording, in a CRM note, in a chat transcript, or in a screen capture taken during agent training, you've stored SAD.

Card-present flows are dominated by chip and PIN. The risk shifts to the PIN block and the equivalent chip data being captured by skimmers or by a compromised terminal. PCI PTS (PIN Transaction Security) governs the terminals themselves; PCI DSS governs the merchant systems. Both have to hold for the chain to be intact.

SAD in call recordings is the silent compliance failure

Most UK contact centres record every call. Quality monitoring, regulatory obligations, training, dispute evidence — all good reasons. None of them justify recording the CVV.

The usual fix attempts go like this: "We'll pause the recording while the agent asks for the card." That sounds clean until it goes wrong. Agents forget. Software bugs leave the recording running. Pause-and-resume systems sometimes capture the few seconds either side of the pause, and "either side" is exactly where the security code gets spoken. A 2024 ICO investigation into a UK retailer found that "pause-and-resume" controls had failed on roughly 4% of calls over an 18-month period — tens of thousands of CVVs sitting in a recording archive.

The clean answer is to take the security code out of the audio channel entirely. DTMF masking does this by having the customer key the card details into their own phone keypad while the agent stays on the line. The keypad tones get intercepted before they reach the recording, so the recording captures a flat, equal tone instead of distinct digits. The agent never hears the CVV, the recording has nothing to extract, and the call recording system stops being a SAD repository.

SAD and PCI DSS scope reduction

Every system that touches SAD is in the cardholder data environment, full stop. That's the QSA's first question on any assessment: "Where can SAD appear?" If the answer is "agent workstations, call recording servers, CRM, ticketing system, email archive, helpdesk knowledge base," then every one of those is in scope for the full PCI DSS control set — segmentation, vulnerability scanning, access control, logging, training, the lot.

The fastest way to shrink that footprint is to make sure SAD never enters those systems. Not "enters and is then deleted" — never enters at all. That's the design principle behind DTMF masking, behind hosted payment pages for web checkout, and behind processor-managed terminals for in-person. Keep SAD outside the perimeter and the perimeter shrinks dramatically.

What "rendered unrecoverable" actually means

If SAD ever does land in your environment — usually during the authorisation flow itself — PCI DSS requires it to be "rendered unrecoverable" after authorisation. Three accepted methods:

• Cryptographic erasure: the encryption key is destroyed, so the encrypted SAD is mathematically unrecoverable.
• Secure deletion: the storage media is overwritten or the data is purged using NIST-aligned procedures, not just a file-system delete.
• Physical destruction: for paper or removable media containing SAD, the medium itself is shredded or incinerated.

Simply deleting a database row isn't enough. Many database engines keep the row in a transaction log, in a replica, in a backup, or in a recovery snapshot. Every one of those copies has to come off the system before the QSA will sign the requirement off as in-place.

SAD in development, test, and staging environments

One of the most common findings in PCI assessments is real card data — including SAD — sitting in non-production environments. A developer copies a production database to debug a bug. A test environment captures real customer traffic to validate a release. A QA tester pastes a real CVV into a Jira ticket because that was the failing test case.

PCI DSS Requirement 6.5.5 prohibits the use of production data, including SAD, in test environments. The fix is test data generators that emit realistic-looking but unconnected values — fake PANs that pass Luhn validation, fake security codes, fake names. Stripe's, Visa's and Mastercard's test card numbers exist precisely so developers never have a reason to copy a real one.

SAD vs cardholder data — what you can and cannot keep

Cardholder data (CHD) and Sensitive Authentication Data (SAD) get rolled together in conversation, but PCI DSS treats them differently. CHD covers the Primary Account Number (PAN), cardholder name, expiry date, and service code. You're allowed to store these post-authorisation as long as you apply the storage protection rules in Requirements 3.3 through 3.7 — encryption, key management, masking on display, restricted access, and the rest.

SAD is the strict category. Whatever the protection, whatever the justification, post-authorisation storage is banned. The line exists because compromising SAD plus CHD gives an attacker everything they need to commit fraud at scale. Compromising CHD alone is bad but more recoverable — the issuer can reissue the card, the fraud filters can be tuned, the customer can be notified. Compromising SAD on millions of cards is catastrophic in a way CHD alone isn't.

Practical signals that you're storing SAD without realising

The audit findings that surprise merchants tend to come from these places:

• Application logs at debug level capturing full HTTP request bodies that include the CVV field.
• Web server access logs recording POST data on payment endpoints during incident-investigation periods.
• CRM custom-field notes where agents have typed card details "just for this one customer."
• Helpdesk tickets with screenshots of payment forms attached — the screenshots include the visible CVV.
• Webhook payload archives where a payment processor briefly included the security code in a retry payload.
• Backup tapes from old systems before the SAD storage prohibition was operationalised — the tapes are still in the safe.

None of these are exotic. Every one is something a QSA has flagged in a real engagement in the last 18 months. The pattern is always the same — SAD landed somewhere nobody was looking for it, and nothing in the regular control checks was watching that place.