skip to content

Under PCI DSS v4.0.1, what are the 12 principal requirements, and which account data do they protect?

level: juniorimportance: must knowfreq 60%

answer

  1. six headings, two requirements each
  2. PAN is the defining element
  3. cardholder data versus SAD
  4. SAD never kept after authorization

basics

~20 s

PCI DSS v4.0.1 has 12 principal requirements under six headings, from network security controls to policy. They protect account data: cardholder data (PAN, name, expiry, service code) and sensitive authentication data, which may not be stored after authorization.

solid answer

~40 s

PCI DSS v4.0.1 groups 12 principal requirements under six headings: build and maintain a secure network (1 network security controls, 2 secure configurations), protect account data (3 stored data, 4 transmission over open networks), vulnerability management (5 anti-malware, 6 secure systems and software), access control (7 need to know, 8 identification and authentication, 9 physical access), monitoring and testing (10 logging, 11 security testing) and policy (12 policies and programs). The object is **account data**: cardholder data - the `PAN`, which is the defining element, plus name, expiration date and service code - and sensitive authentication data - full track data, the card verification code and PINs or PIN blocks. Under Requirement 3.3.1, SAD is not stored after authorization, even if encrypted, except by issuers with a documented business need.

go deeper

for a junior

Recall the six headings and roughly which requirement sits where, and be able to split account data into cardholder data and sensitive authentication data.

for a middle

Explain why the PAN is the defining element and why SAD cannot be kept after authorization even when encrypted, citing Requirement 3.3.1.

for a senior

Show you know applicability goes beyond storage: an entity that only controls a payment page or stores SAD still inherits requirements, and brands and acquirers decide validation.

for a principal

Frame the 12 requirements as a data-minimisation argument: every element you stop storing or touching removes requirements, which is why product design decisions drive the compliance bill.

## What PCI DSS protects The **Payment Card Industry Data Security Standard (PCI DSS)** is maintained by the PCI Security Standards Council. The current version is **v4.0.1**, published in June 2024. It is a baseline of technical and operational requirements for protecting **account data**, and the standard splits account data into two sets that are *not* interchangeable: | Cardholder data (CHD) | Sensitive authentication data (SAD) | |---|---| | Primary account number (`PAN`) | Full track data (magnetic stripe or the chip equivalent) | | Cardholder name | Card verification code | | Expiration date | PINs and PIN blocks | | Service code | | - **The PAN is the defining factor.** Name, expiration date and service code must be protected as cardholder data when they are stored, processed or transmitted with the PAN or are otherwise present in the cardholder data environment (CDE). - **SAD is handled more harshly than CHD.** Requirement 3.3.1 says SAD is not stored after authorization, *even if encrypted*, and is rendered unrecoverable when authorization completes. Issuers and companies supporting issuing services with a legitimate, documented business need are the exception, handled under Requirement 3.3.3. - **What may survive authorization.** The guidance to Requirement 3.2.1 lists the only account data that may be stored after authorization: the PAN (rendered unreadable), expiration date, cardholder name and service code. ## The 12 requirements under six headings Table 1 of the standard lists the 12 principal requirements, grouped under six headings: | Heading | Requirements | |---|---| | Build and Maintain a Secure Network and Systems | 1 Install and maintain network security controls; 2 Apply secure configurations to all system components | | Protect Account Data | 3 Protect stored account data; 4 Protect cardholder data with strong cryptography during transmission over open, public networks | | Maintain a Vulnerability Management Program | 5 Protect all systems and networks from malicious software; 6 Develop and maintain secure systems and software | | Implement Strong Access Control Measures | 7 Restrict access by business need to know; 8 Identify users and authenticate access; 9 Restrict physical access to cardholder data | | Regularly Monitor and Test Networks | 10 Log and monitor all access; 11 Test security of systems and networks regularly | | Maintain an Information Security Policy | 12 Support information security with organizational policies and programs | Each principal requirement breaks into numbered sub-requirements such as **Requirement 3.5.1** (PAN rendered unreadable wherever it is stored) or **Requirement 11.3.2** (external vulnerability scans by an Approved Scanning Vendor at least once every three months). Each sub-requirement carries its defined-approach text, testing procedures, a *Customized Approach Objective* where one exists, applicability notes and guidance. ## Who has to comply, and who decides 1. **Applicability.** PCI DSS applies to entities that store, process or transmit CHD or SAD, *or* that could impact its security - merchants, processors, acquirers, issuers and other service providers. 2. **Enforcement.** The standard itself says that whether an entity must comply or validate is at the discretion of the organizations that manage compliance programs, such as the **payment brands and acquirers**. The Council writes the standard; it does not decide who must validate. 3. **Law wins.** Under the standard's *Limitations* section, if a requirement conflicts with country, state or local law, the law applies. 4. **Merchant levels are not in PCI DSS.** The volume-based merchant levels that decide how a merchant validates are set by the card brands and applied by acquirers, not defined in the standard. ## Common confusions interviewers probe - **Encrypting SAD does not make storing it acceptable** after authorization; Requirement 3.3.1 says "even if encrypted". - **Not storing PAN does not mean out of scope.** An entity whose web server controls the payment page, or who stores only SAD, still has applicable requirements. - **Requirement 12 is not just a policy binder.** It holds scope confirmation (12.5.2), targeted risk analyses (12.3.1), service-provider management (12.8) and the incident response plan (12.10.1). - **"PCI certified" is loose shorthand.** The standard speaks of assessing and validating compliance, documented in a Self-Assessment Questionnaire or Report on Compliance with an Attestation of Compliance.

  • Under PCI DSS v4.0.1, can a merchant keep the card verification code encrypted until a chargeback is resolved?
    No. Requirement 3.3.1.2 says the card verification code is not stored upon completion of authorization, and Requirement 3.3.1 applies even if the data is encrypted. Authorization completes when the merchant receives the approval or decline. Only issuers and issuing-service companies with a legitimate, documented business need are exempted from 3.3.1, under 3.3.3.
  • Under PCI DSS v4.0.1, does a cardholder name stored without any PAN count as cardholder data?
    Not for PCI DSS purposes on its own. The PAN is the defining factor: name, expiration date and service code must be protected as cardholder data when present with the PAN or otherwise in the CDE. Privacy law may still protect the name, and the standard notes such laws can apply separately.

saying these in an interview costs you the question

  • Encrypting the card verification code makes storing it after authorization acceptable.
  • PCI DSS only applies to companies that store card numbers.
  • The PCI Security Standards Council decides which merchants must validate compliance.
  • Merchant levels 1 to 4 are defined inside the PCI DSS standard.
  • Cardholder name alone, with no PAN anywhere, is cardholder data under PCI DSS.