Category: Cardholder Data

Primary Account Number (PAN)

Also known as: PAN, card number, payment card number, account number

Simply put

A Primary Account Number (PAN) is the string of digits printed or embossed on a credit, debit, or prepaid card that identifies the card and links transactions to a specific account. It is typically 16 digits but can range from 12 to 19 digits. The PAN is used by payment processors to route and verify a transaction during payment processing.

Formal definition

The PAN is the payment card identifier found on credit, debit, and prepaid cards, generally 12 to 19 digits in length (commonly 16), used to identify the issuing account and route transactions through the payment networks. Under PCI DSS, the PAN is the defining element of cardholder data; its presence determines whether an environment is in scope for cardholder data protection controls. The PAN is distinct from sensitive authentication data (such as full track data, CAV2/CVC2/CVV2/CID, and PIN/PIN blocks): the PAN may be stored under defined controls such as rendering it unreadable through methods like truncation, masking, tokenization, hashing, or strong cryptography, whereas sensitive authentication data must not be retained after authorization. The specific protection and rendering requirements, along with their requirement numbering and wording, differ between PCI DSS versions and should be confirmed against the current published standard.

Why it matters

The PAN is the central data element that determines PCI DSS scope. Under PCI DSS, the presence of the PAN is what defines an environment as containing cardholder data and therefore subject to protection controls. Any system that stores, processes, or transmits the PAN generally falls within the cardholder data environment, which is why accurately identifying where PANs flow is one of the first steps in scoping an assessment. Misunderstanding where the PAN resides can lead to gaps in protection or to over-scoped environments that are costly to maintain.

Because the PAN is the identifier that links transactions to a specific account, it is a high-value target for attackers and a focal point for controls such as truncation, masking, tokenization, hashing, and strong cryptography. It is important to distinguish the PAN from sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, and PIN or PIN blocks: the PAN may be stored under defined controls when rendered unreadable, whereas sensitive authentication data must not be retained after authorization even if encrypted. Confusing these categories is a common source of compliance and security failures.

The specific requirements governing how the PAN must be rendered unreadable, protected in transit, and restricted in display differ between PCI DSS versions, including their requirement numbering and wording. Teams should confirm the applicable obligations against the current published standard rather than relying on a fixed requirement number, since both the controls and the accepted methods evolve over time.

Who it's relevant to

Security engineers

Engineers designing systems that handle payment data need to identify every location where the PAN is stored, processed, or transmitted, since its presence drives the cardholder data environment. They implement controls such as truncation, masking, tokenization, or strong cryptography to render the PAN unreadable, and must apply the method appropriate to each use case rather than assuming any label alone satisfies the requirement.

Compliance officers

Compliance teams rely on accurate PAN identification to define PCI DSS scope and validate that protection and rendering controls meet the current published standard. They should confirm requirement numbering and wording against the applicable PCI DSS version and ensure that the PAN is distinguished from sensitive authentication data, which must not be retained after authorization.

Payment processors and acquirers

Processors and acquirers use the PAN to route and verify transactions through the payment networks to the correct issuing account. They must maintain controls around PAN handling in authorization and settlement flows while ensuring that sensitive authentication data is not stored after authorization.

Merchant risk and fraud teams

Risk and fraud analysts encounter the PAN as the key that links transactions to a specific account. Understanding how PANs are protected, masked, or tokenized in their environment helps them assess exposure and coordinate with security and compliance functions, while recognizing that PAN protection controls address data confidentiality rather than eliminating fraud on their own.

Inside PAN

PAN structure

The Primary Account Number is the payment card number that identifies the issuer and the cardholder account. It is classified as cardholder data under PCI DSS, distinct from sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, and PINs/PIN blocks.

Issuer Identification Number (IIN/BIN)

The leading digits of the PAN identify the issuing institution and card brand. This portion is commonly retained in truncated or masked forms depending on business need and applicable card brand and network rules.

Account identifier and check digit

The PAN includes digits identifying the individual account, typically ending with a check digit. When displayed, masking rules govern which portions may be shown.

Relationship to other cardholder data

The PAN is the defining element of cardholder data; when the PAN is stored, processed, or transmitted, associated cardholder data (such as cardholder name, expiration date, and service code) must also be protected under defined PCI DSS controls.

Protection transformations

The PAN can be rendered unreadable through methods such as tokenization, encryption, truncation, hashing, or masking. These transformations differ in how they reduce or transform the data, and their effect on PCI DSS scope depends on implementation and validation, not on the label alone.

Common questions

Answers to the questions practitioners most commonly ask about PAN.

Is the PAN the same thing as sensitive authentication data?

No. The PAN is cardholder data, not sensitive authentication data. Sensitive authentication data includes full track data, the card verification code or value (CAV2/CVC2/CVV2/CID), and PINs or PIN blocks, and it must not be stored after authorization even if encrypted. The PAN, by contrast, may be stored after authorization when protected under defined controls. It is worth noting that when the PAN is stored, any associated cardholder name, expiration date, or service code is also considered cardholder data and must be protected accordingly.

If we encrypt the PAN, does that remove our systems from PCI DSS scope?

Not automatically. Encryption transforms the PAN into ciphertext, but encrypted PAN is generally still treated as cardholder data, and systems that can decrypt it or that hold the keys typically remain in scope. Whether encryption, tokenization, truncation, masking, or hashing reduces scope depends on the specific implementation and how it is validated, not on the label applied to the technique. Confirm scope decisions against the current published PCI DSS standard and, where relevant, guidance for the specific technology used.

How should the PAN be rendered when it must be displayed to staff or customers?

PCI DSS restricts how much of the PAN may be shown when it is displayed, so that most users see only a limited portion rather than the full number. Masking is a display control and is distinct from truncation, which permanently removes digits from stored data. The specific number of digits that may be shown, and the conditions for displaying more, are defined in the standard; confirm the exact requirement wording and any masking allowances against the current published version, since numbering and detail differ between versions.

What is the difference between truncating and hashing a PAN for storage?

Truncation permanently removes a segment of the PAN so the removed digits cannot be recovered, whereas hashing applies a one-way function to produce a fixed-length value. These transform the data differently and are not interchangeable. Where both a truncated and a hashed version of the same PAN could be present, care is needed because the combination may allow the original PAN to be reconstructed or correlated. Whether either approach reduces PCI DSS scope depends on the implementation and its validation, so verify the applicable controls against the current standard.

Do tokens that replace the PAN fall under the same storage rules as the PAN itself?

Tokenization substitutes the PAN with a surrogate value, which is a different operation from encryption. Whether a token is in or out of PCI DSS scope depends on how it is generated, whether it can be mapped back to the PAN, and how that mapping is protected and validated. A token is not automatically out of scope simply because it is called a token. Assess the token solution's design and validation against current PCI DSS guidance rather than assuming the label determines the treatment.

When identifying where PAN lives in our environment, what locations are commonly overlooked?

PAN can appear in more places than the primary databases, including application logs, error and debug output, transaction files, backups, message queues, temporary files, and support or ticketing systems. Building an accurate data flow and inventory of where the PAN is transmitted, processed, and stored is foundational to defining PCI DSS scope. Locations that hold PAN, or that can access systems holding it, are generally in scope; confirm scoping determinations against the current published standard.

Common misconceptions

The PAN and sensitive authentication data can be treated the same way, so an encrypted PAN and an encrypted CVV2 have the same storage rules.

The PAN is cardholder data that may be stored under defined controls, while sensitive authentication data such as CAV2/CVC2/CVV2/CID, full track data, and PINs/PIN blocks must not be stored after authorization, even when encrypted.

Masking or truncating the PAN for display is the same as tokenizing or encrypting it, and any of these labels automatically removes systems from PCI DSS scope.

Truncation, masking, tokenization, encryption, and hashing transform data differently and serve different purposes. Their impact on PCI DSS scope depends on the specific implementation and how it is validated, not on the label applied.

Because the PAN is only a number, hashing or masking it always renders it fully unrecoverable and out of scope.

Whether a rendered PAN is considered unreadable and how it affects scope depends on the method and its implementation. Confirm the applicable requirements against the current published PCI DSS standard, since requirement numbering and wording differ between versions.

Best practices

Classify the PAN explicitly as cardholder data and ensure it is never handled alongside stored sensitive authentication data after authorization, even in encrypted form.

Minimize where the PAN is stored, processed, or transmitted to reduce PCI DSS scope, and validate any tokenization, encryption, truncation, masking, or hashing against the specific method used rather than relying on the label.

Apply masking so that only the portions of the PAN permitted by applicable card brand and network rules are displayed, and restrict full PAN access to those with a documented business need.

Render the stored PAN unreadable using an approved method appropriate to your implementation, and confirm the applicable controls against the current published PCI DSS standard rather than assuming a fixed requirement number.

Protect associated cardholder data (such as cardholder name, expiration date, and service code) with defined controls wherever the PAN is present.

Document data flows for the PAN and periodically review them, since transformations and their validation determine scope and may change as systems evolve.