Category: Cardholder Data

Account Data

Simply put

Account data is the payment card information involved in a transaction, made up of cardholder data and/or sensitive authentication data. Because it is a prime target for attackers, storing or handling it creates significant risk and must be protected under defined security controls.

Formal definition

In PCI DSS terminology, account data is the umbrella term for cardholder data and/or sensitive authentication data. Cardholder data includes the primary account number (PAN) and, when present, cardholder name, expiration date, and service code; some of this data may be stored under defined controls (for example, the PAN must be rendered unreadable per applicable requirements). Sensitive authentication data includes full track data, card verification codes/values (such as CAV2/CVC2/CVV2/CID), and PINs/PIN blocks, and must not be stored after authorization even if encrypted. Note that requirement numbering and wording differ across PCI DSS versions, so confirm specifics against the current published standard.

Why it matters

Account data is the core asset that most payment security controls are designed to protect. Because it consists of cardholder data and/or sensitive authentication data, it is a prime target for attackers, and any system that stores, processes, or transmits it creates a significant, business-critical exposure. Understanding what falls under account data is the starting point for defining PCI DSS scope: environments that touch this data are subject to the standard's controls, while accurately identifying and reducing where account data lives can shrink both scope and risk.

The distinction within account data matters enormously in practice. Cardholder data (the PAN and, when present, cardholder name, expiration date, and service code) may be stored under defined controls, such as rendering the PAN unreadable. Sensitive authentication data (full track data, card verification codes such as CAV2/CVC2/CVV2/CID, and PINs/PIN blocks) must not be stored after authorization, even when encrypted. Confusing these two categories is a common source of compliance failures, since a control that is acceptable for one may be prohibited for the other.

Because the term "account data" is used differently in other domains (for example, ERP account master data or user account information in consumer platforms), teams should be careful to use it in the specific PCI DSS sense when discussing payment security. Misapplying the term can lead to mis-scoping and to controls being applied to the wrong data. Note also that requirement numbering and wording differ across PCI DSS versions, so specifics should be confirmed against the current published standard rather than assumed.

Who it's relevant to

Compliance officers and QSAs

Correctly classifying account data is foundational to defining and validating PCI DSS scope. Distinguishing cardholder data (which may be stored under defined controls) from sensitive authentication data (which must not be stored after authorization) determines which controls apply and where compliance gaps arise. Specifics should be confirmed against the current published standard, since requirement numbering and wording differ across versions.

Security engineers and architects

Engineers who design systems that store, process, or transmit account data must apply protections according to the data subcategory, for example rendering the PAN unreadable while ensuring sensitive authentication data is not retained after authorization. Knowing which elements constitute account data helps identify where controls are required and where reducing data footprint can lower exposure.

Fraud analysts and merchant risk teams

Because account data is a prime target for attackers, teams monitoring for compromise and fraud need a clear understanding of which data elements are involved in transactions and the exposure their storage or handling creates. This informs both prevention and incident response, though the term should be used in its specific PCI DSS sense to avoid confusion with other 'account data' meanings.

Acquirers and payment processors

Entities in the payment chain handle account data at scale and must ensure their environments apply the correct controls to cardholder data versus sensitive authentication data. Clear classification supports accurate scoping, oversight of connected merchants, and adherence to the current published PCI DSS requirements.

Inside Account Data

Cardholder Data (CHD)

The subset of account data that includes the Primary Account Number (PAN), and, when present alongside the PAN, the cardholder name, expiration date, and service code. Under defined PCI DSS controls, elements of cardholder data may be stored, though the PAN must be rendered unreadable when stored per the applicable requirements of the current standard.

Primary Account Number (PAN)

The defining element of cardholder data. Its presence generally determines whether other associated data is treated as cardholder data. When stored, the PAN must be protected (for example through truncation, tokenization, hashing, or strong encryption) as defined by the current PCI DSS version; readers should confirm the exact requirement wording against the published standard.

Sensitive Authentication Data (SAD)

Security-related information used to authenticate cardholders or authorize transactions, comprising full track data (magnetic stripe or equivalent on a chip), card verification codes (CAV2/CVC2/CVV2/CID), and PINs and PIN blocks. SAD must not be retained after authorization completes, even if encrypted.

Full Track Data

The complete magnetic-stripe data (or its equivalent from a chip) read during a transaction. It is classified as sensitive authentication data and must not be stored after authorization.

Card Verification Codes (CAV2/CVC2/CVV2/CID)

The card-brand-specific verification values commonly used to help validate card-not-present transactions. These are sensitive authentication data and must not be stored after authorization, even when encrypted.

PINs and PIN Blocks

The personal identification number and its encrypted form used primarily in card-present and PIN-based transactions. These are sensitive authentication data and must not be stored after authorization. Note that PIN protection is also addressed by the separate PCI PIN standard.

Common questions

Answers to the questions practitioners most commonly ask about Account Data.

Is all account data the same, so I can store it as long as it is encrypted?

No. Account data is an umbrella term that includes both cardholder data and sensitive authentication data, and they are treated very differently. Cardholder data (such as the PAN, cardholder name, expiration date, and service code) may be stored under defined controls. Sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, and PINs/PIN blocks) must not be stored after authorization, even if it is encrypted. Encryption does not make sensitive authentication data eligible for post-authorization retention.

Does the CVV2/CVC2/CID count as cardholder data that I can keep for recurring billing?

No. The card verification value printed on the card (CAV2/CVC2/CVV2/CID) is sensitive authentication data, not cardholder data, and it must not be stored after authorization under any circumstances. Only elements classified as cardholder data, such as the PAN, may be retained for legitimate business needs under appropriate controls. Confirm the current classifications and requirements against the published PCI DSS standard, as wording can differ between versions.

Which elements of account data can we retain after authorization, and which must be purged?

Cardholder data elements (PAN, cardholder name, expiration date, service code) may be retained after authorization when there is a documented business justification and appropriate protections are applied. Sensitive authentication data (full track data, the card verification code/value, and PINs/PIN blocks) must be rendered unrecoverable after authorization and must not be stored. Verify your data-retention and disposal obligations against the current PCI DSS version, since requirement numbering and wording vary by version.

How should the PAN be protected when we do need to store it?

Where the PAN is stored, it must be rendered unreadable using an approved approach such as strong cryptography, truncation, tokenization, or one-way hashing, depending on the use case. These methods transform data differently and their effect on scope depends on implementation and validation, not the label alone. Where the PAN is displayed, masking limits how much is shown. Confirm the specific storage and display requirements against the current published standard.

How do we confirm that our systems are not inadvertently retaining sensitive authentication data?

Because sensitive authentication data must not be stored after authorization, review logs, transaction records, error and debug logs, memory dumps, database fields, and any temporary or backup files that could capture full track data, card verification values, or PIN blocks. Coordinate with your QSA or internal assessors to test for inadvertent capture, and validate that pre-authorization handling and secure deletion are effective. Align this review with the current PCI DSS requirements.

How does the way we handle account data affect PCI DSS scope?

Any system component that stores, processes, or transmits account data, or that can affect the security of that data, is in scope. Reducing what account data you retain, and transforming it through methods such as tokenization or truncation, may reduce scope, but the effect depends on how the control is implemented and validated rather than on the term used. Segmentation and data-flow analysis help define the boundary; confirm scoping guidance against the current published standard.

Common misconceptions

Account data and cardholder data are the same thing.

Account data is the broader category. It comprises cardholder data and sensitive authentication data. Cardholder data (such as the PAN, and associated name, expiration date, and service code) may be stored under defined controls, whereas sensitive authentication data must not be stored after authorization.

Sensitive authentication data can be retained after authorization as long as it is encrypted.

Encryption does not create an exception. Sensitive authentication data—including full track data, card verification codes, and PINs/PIN blocks—must not be stored after authorization completes, even in encrypted form.

Applying tokenization, truncation, masking, or hashing to a PAN automatically removes account data from PCI DSS scope.

These techniques transform or reduce data in different ways, and their effect on scope depends on the specific implementation and how it is validated, not on the label used. Scope reduction must be confirmed against the current standard rather than assumed.

Best practices

Classify each data element explicitly as cardholder data or sensitive authentication data so retention rules are applied correctly, and confirm the classification and any storage controls against the current published PCI DSS version rather than a remembered requirement number.

Ensure sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, and PINs/PIN blocks) is never persisted after authorization, and verify that logs, error dumps, and temporary files do not inadvertently retain it.

When the PAN must be stored, render it unreadable using an appropriate method (such as truncation, tokenization, hashing, or strong encryption) and validate that the chosen method meets the applicable requirements of the current standard.

Do not assume that applying tokenization, truncation, masking, or hashing removes systems from scope; validate the actual effect on scope based on the specific implementation.

Minimize the collection and retention of account data to only what is required for a defined business purpose, reducing the footprint of data subject to protection.

Keep the boundaries between PCI DSS and adjacent standards clear (for example PCI PIN for PIN handling), and route each control to the standard that actually governs it.