Term

PCI DSS

The security standard for handling cardholder data.

The Payment Card Industry Data Security Standard sets out requirements for any organization that stores, processes, or transmits cardholder data. Version 4.0 introduced customized approaches and ongoing validation.

Cardholder data
Segmentation

Definition

PCI DSS, explained

PCI DSS is not a law. It is a contractual standard: merchants agree to it through their acquiring bank, and service providers through their contracts with merchants and payment brands. It is maintained by the PCI Security Standards Council, founded by American Express, Discover, JCB International, Mastercard, and Visa. The Council writes the standard; the individual card brands and acquirers decide who must validate compliance and how.

Scope starts with the cardholder data environment

Requirements apply to the cardholder data environment (CDE): the people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data, plus anything connected to or able to affect their security. Scope is the single biggest driver of PCI effort. Network segmentation that isolates the CDE, tokenization, and outsourcing payment pages to a validated provider can all shrink it dramatically. Segmentation used to reduce scope must be validated by penetration testing.

Six goals, twelve requirements

Goal, Requirement comparison
Goal	Requirement
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 to system components and cardholder data by business need to know
	8. Identify users and authenticate access to system components
	9. Restrict physical access to cardholder data
Regularly monitor and test networks	10. Log and monitor all access to system components and cardholder data
	11. Test security of systems and networks regularly
Maintain an information security policy	12. Support information security with organizational policies and programs

How compliance is validated

Method, Who completes it, Typical use comparison
Method	Who completes it	Typical use
Self-Assessment Questionnaire (SAQ)	The organization itself	Smaller merchants; several SAQ types exist depending on how cards are accepted
Report on Compliance (ROC)	A Qualified Security Assessor (QSA), or a qualified internal assessor where permitted	Higher-volume merchants and many service providers
Attestation of Compliance (AOC)	Signed by the organization, and by the QSA where one was used	Accompanies an SAQ or ROC as the summary shared with acquirers and customers

Which method applies depends on your merchant or service provider level, which the card brands and acquirers define mainly by annual transaction volume. Ask your acquirer rather than assuming. Quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) are also required in many cases.

Version 4 in brief

PCI DSS v4.0 was published in March 2022, and v3.2.1 was retired on 31 March 2024.
v4.0.1, a limited revision with clarifications and corrections, was published in June 2024, and v4.0 was retired at the end of 2024.
Requirements that v4.0 marked as future-dated became mandatory after 31 March 2025, including broader multi-factor authentication into the CDE and targeted risk analyses for flexible control frequencies.
The customized approach lets organizations meet a requirement's stated objective with their own controls, subject to documentation and assessor validation.

Many PCI requirements overlap with ISO 27001 and SOC 2, especially access, logging, and vulnerability management, so a shared control set avoids duplicate work; one control, four frameworks shows how. For requirement-level detail, go to the PCI DSS framework page, and see the ecommerce and fintech industry pages for sector context.

FAQ

Frequently asked questions

Is PCI DSS legally required?

PCI DSS is not a government law in most jurisdictions. It is enforced contractually through agreements with acquiring banks and card brands, which can impose fees, increase transaction costs, or withdraw card acceptance for non-compliance. A few jurisdictions reference it in legislation, so check local rules, but the main obligation is contractual.

Does using a payment processor make me PCI compliant?

No, but it can greatly reduce scope. If a validated third party handles card entry, for example through a hosted payment page, you may qualify for a shorter SAQ. You remain responsible for validating compliance for the parts you control, including the web page that redirects to or embeds the payment form.

What is the difference between cardholder data and sensitive authentication data?

Cardholder data includes the primary account number, and may include cardholder name, expiration date, and service code. Sensitive authentication data includes full track data, card verification codes, and PINs or PIN blocks. Sensitive authentication data must not be stored after authorization, even if encrypted, except in limited cases for card issuers.

How often must PCI DSS compliance be validated?

Validation is annual, through an SAQ or ROC and an accompanying Attestation of Compliance. Many individual requirements have their own frequencies within the year, such as quarterly external and internal vulnerability scans and periodic penetration testing, so compliance must be maintained continuously rather than prepared once a year.

Keep exploring

Ready to replace the spreadsheet chaos?

See Asurvo in action with a 20-minute walkthrough tailored to your stack and frameworks.

Request a demo Talk to sales