PCI DSS Compliance: The 12 Requirements, SAQs and Scope Explained

PCI DSS compliance is required of every business that accepts, processes, stores or transmits payment card data, and of service providers that can affect its security. It is not a government law in most countries. It is an industry standard that the card brands enforce through contracts: your acquiring bank or payment provider requires it, and the brands can fine the acquirer, which passes costs on.

For developers and product teams, the most important PCI DSS decision is architectural: how much of your system touches card data. A checkout that sends card numbers to your own server brings your servers, network, staff and processes into scope for hundreds of requirements. A checkout that uses a payment provider's hosted page or hosted fields can reduce your obligations to a short self-assessment, although it does not remove them. This guide explains the 12 requirements of PCI DSS v4.0.1, scope and segmentation, the validation options, the changes that took effect in March 2025, and the mistakes that bring card data back into scope.

What is PCI DSS?

The Payment Card Industry Data Security Standard is a set of technical and operational requirements for protecting account data. It is published by the PCI Security Standards Council (PCI SSC). Account data has two parts:

• Cardholder data: the primary account number (PAN), plus cardholder name, expiry date and service code when stored with the PAN.
• Sensitive authentication data: full track data from the magnetic stripe or chip, card verification codes (CVV2, CVC2 and similar) and PINs or PIN blocks. Sensitive authentication data must not be stored after authorisation, even if encrypted (requirement 3.3).

The cardholder data environment (CDE) is the people, processes and technology that store, process or transmit account data, plus system components connected to it or that can affect its security. Everything in the CDE is in scope.

History and why PCI DSS was introduced

In the early 2000s, card brands ran separate security programmes for merchants, such as Visa's Cardholder Information Security Program and Mastercard's Site Data Protection program. Merchants faced different, overlapping rules. The brands aligned them into PCI DSS version 1.0 in 2004 and in 2006 founded the PCI Security Standards Council to manage the standard and its assessor programmes.

The standard has been revised regularly. Version 4.0 was published in March 2022 and introduced a customised approach to meeting requirements, targeted risk analyses and new requirements that were future-dated. Version 4.0.1, published in June 2024, corrected errors and clarified wording without adding or removing requirements. Version 3.2.1 was retired on 31 March 2024 and v4.0 on 31 December 2024, so v4.0.1 is the version assessed today. The future-dated requirements became effective on 31 March 2025.

The reason for the standard is plain: stolen card data is easy to monetise, and the brands, banks and merchants share the fraud losses. A common baseline reduces breaches across the ecosystem.

Who needs PCI DSS compliance?

• Merchants: any business that accepts card payments, online or in person, regardless of size or volume.
• Service providers: businesses that are not a payment brand but are directly involved in processing, storing or transmitting account data on behalf of another entity, or that can affect its security. Payment gateways, hosting providers of a CDE, managed security providers and some SaaS platforms fall here.
• Software vendors and agencies building checkouts and payment integrations, whose design decisions determine their clients' scope. Vendors of payment software sold to others should also look at the PCI Secure Software Standard.

Levels. The card brands, not the PCI SSC, define merchant and service provider levels, usually by annual transaction volume, and decide how each level validates compliance. The largest merchants and service providers generally need an onsite assessment by a Qualified Security Assessor; smaller ones usually complete a self-assessment questionnaire. Your acquirer tells you which applies.

Geography. PCI DSS applies worldwide wherever the participating brands' cards are used. Some jurisdictions also reference it in law, and some regulators have their own payment data rules on top, such as the RBI's payment data storage directive in India.

The 12 requirements

PCI DSS v4.0.1 groups 12 principal requirements under six goals.

Goal	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 programme	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 organisational policies and programmes.

The requirements in detail

Requirements 1 and 2: network security and secure configuration

Network security controls (firewalls, cloud security groups and similar) must restrict traffic into and out of the CDE to what is necessary, with documented rules reviewed at least every six months. Systems must be configured to hardening standards, vendor default accounts disabled or changed, and only necessary services enabled.

Requirement 3: protect stored account data

Keep storage to a minimum with a retention policy, never store sensitive authentication data after authorisation, mask the PAN when displayed (showing at most the BIN and last four digits to those without a business need), and render the PAN unreadable wherever it is stored, using strong cryptography, truncation, tokenisation or one-way hashes with keys. Cryptographic keys need documented management. The easiest way to meet requirement 3 is not to store PANs at all: use your payment provider's tokens.

Requirement 4: encrypt transmission

Use strong cryptography (current TLS with trusted certificates) whenever the PAN crosses open, public networks, and keep an inventory of trusted keys and certificates.

Requirement 5: malware protection

Deploy anti-malware on systems at risk, keep it current, and protect against phishing. Systems considered not at risk must be evaluated periodically.

Requirement 6: secure systems and software

This is the developers' requirement. Software developed in-house or for you must be built securely, with training for developers at least annually, code review before release, and protection against common attacks such as injection, broken authentication and cross-site scripting (the OWASP Top 10 is the usual reference). Vulnerabilities must be identified and ranked, critical and high patches applied within defined timelines, and public-facing web applications protected by an automated technical solution such as a web application firewall (6.4.2). Requirement 6.4.3 requires an inventory of all scripts on payment pages, a method to confirm each is authorised, and assurance of their integrity. Change control and separation of production and pre-production apply (6.5).

Requirements 7 and 8: access control and authentication

Access is granted by least privilege and need to know, and reviewed. Every user gets a unique ID; shared accounts are restricted. Multi-factor authentication is required for all access into the CDE (8.4.2) and for all remote network access. Passwords for user accounts must be at least 12 characters (or 8 where a system cannot support 12), and system and application accounts are managed and their passwords protected (8.6).

Requirement 9: physical security

Control physical access to facilities and media with cardholder data, protect point-of-interaction devices from tampering and substitution, and destroy media securely. For cloud-hosted environments, much of this is inherited from the provider and evidenced by its attestation.

Requirement 10: logging and monitoring

Log user access to cardholder data, administrative actions, access to audit logs, failed logins and changes to identification mechanisms. Review logs (automated mechanisms are expected, 10.4.1.1), synchronise time, protect logs from tampering and retain them for at least 12 months, with the most recent three months immediately available.

Requirement 11: testing

Detect unauthorised wireless access points, run internal vulnerability scans and external scans by a PCI SSC Approved Scanning Vendor at least quarterly (11.3), perform internal and external penetration tests at least annually and after significant changes, including segmentation tests (11.4), use intrusion detection, and deploy a change and tamper detection mechanism for payment pages that alerts on unauthorised changes to HTTP headers and page contents (11.6.1).

Requirement 12: policy and programme

Maintain an information security policy, perform targeted risk analyses where requirements allow flexibility in frequency (12.3.1), run security awareness training, manage third-party service providers with written agreements and a responsibility matrix (12.8, 12.9), have an incident response plan, and confirm PCI DSS scope at least once every 12 months (12.5.2), or every six months for service providers.

Scope reduction: the decision that matters most

The way your checkout collects card data decides your scope.

Integration	Where card data goes	Typical validation for an e-commerce merchant
Full redirect to the provider's hosted payment page	Only the provider's systems	SAQ A, if all eligibility criteria are met
Provider's iframe or hosted fields embedded in your page	Only the provider's systems, but your page loads the frame	SAQ A in many cases, subject to the eligibility criteria
JavaScript on your page that sends card data directly to the provider (direct post)	Provider's systems, but your page controls the form	SAQ A-EP
Card data posted to your server, then forwarded	Your servers and network	SAQ D or a full assessment

Even with a hosted page, the page that sends the customer to it can be attacked: a malicious script that swaps the redirect or overlays a fake form steals cards without touching the provider. That is why the payment page script controls exist. In January 2025 the PCI SSC revised SAQ A for v4.0.1: requirements 6.4.3, 11.6.1 and 12.3.1 were removed from SAQ A, and a new eligibility criterion asks the merchant to confirm that its site is not susceptible to attacks from scripts that could affect its e-commerce systems. The requirements themselves remain in PCI DSS and apply in full to service providers and to merchants using other SAQs or a Report on Compliance.

Network segmentation, tokenisation and point-to-point encryption (a PCI SSC validated P2PE solution for card-present payments) are the other main scope reducers.

How to achieve PCI DSS compliance step by step

1. Find all account data. Map every channel (web, app, phone, in-store) and every system and person that touches card data. Search databases, logs and tickets for stored PANs.
2. Reduce scope: move to hosted payment pages or fields, tokenise stored cards with the provider, remove PANs from logs and support tools, and segment what remains.
3. Confirm your level and validation method with your acquirer or the brands.
4. Choose the right SAQ or engage a QSA for a Report on Compliance.
5. Gap assessment against the applicable requirements.
6. Remediate: secure configuration, MFA, logging, patching, script controls on payment pages, secure development, policies.
7. Engage an Approved Scanning Vendor for quarterly external scans if your SAQ requires them, and run penetration tests where required.
8. Manage service providers: collect their Attestations of Compliance and document who is responsible for which requirement.
9. Complete the SAQ or assessment and the Attestation of Compliance, signed by an executive, and submit as your acquirer directs.
10. Maintain: scans, reviews, training and scope confirmation run all year, not just before validation.

Documentation and policies required

• Information security policy and acceptable use policies (12.1, 12.2).
• Cardholder data flow diagrams and network diagrams (1.2.3, 1.2.4).
• Inventory of system components in scope (12.5.1) and the annual scope confirmation (12.5.2).
• Data retention and disposal policy (3.2.1).
• Configuration standards (2.2).
• Key management procedures where you store encrypted PANs (3.6, 3.7).
• Secure development procedures and code review records (6.2).
• Payment page script inventory with justification (6.4.3), where applicable.
• Access control policy and access reviews (7.2).
• Targeted risk analyses for requirements that allow flexible frequency (12.3.1).
• Service provider list, written agreements and responsibility matrix (12.8).
• Incident response plan (12.10).
• Scan reports, penetration test reports, training records and the SAQ or ROC with the Attestation of Compliance.

Assessment and validation

• Report on Compliance (ROC): a detailed assessment by a Qualified Security Assessor (QSA), or by an Internal Security Assessor for some organisations, with an Attestation of Compliance (AOC).
• Self-Assessment Questionnaire (SAQ): for eligible merchants and some service providers, completed by the organisation itself. There are several SAQs (A, A-EP, B, B-IP, C, C-VT, P2PE, SPoC, D for merchants and D for service providers), each with eligibility criteria.
• ASV scans: quarterly external vulnerability scans by an Approved Scanning Vendor, where required.

PCI DSS is validated annually. There is no "PCI certification" issued by the Council; what you can show customers is your AOC.

The customised approach

Since v4.0, organisations can meet most requirements either with the defined approach (the requirement as written) or with a customised approach, in which they design controls to meet the stated objective and the assessor validates them with a targeted risk analysis and more evidence. It is meant for mature organisations with strong risk management; most small merchants use the defined approach.

Timeline and cost considerations

Validation is annual, and ASV scans are quarterly where required. How long it takes to get compliant depends almost entirely on scope. A merchant using a hosted payment page can often complete SAQ A quickly once its site and policies are in order. A company that stores PANs and runs its own payment processing faces a long programme of segmentation, encryption, logging and testing before a QSA assessment.

Cost factors: QSA fees for a ROC, ASV scanning, penetration testing, web application firewall and payment page monitoring tools, logging and SIEM, key management or HSMs where PANs are stored, network segmentation, and internal engineering time. Re-architecting to reduce scope often costs less over a few years than maintaining a large CDE.

Benefits and consequences of non-compliance

Compliance keeps you able to accept cards on normal terms, reduces the chance of a card breach, and is often required by enterprise customers of payment-adjacent SaaS. The controls also strengthen general security.

Consequences of non-compliance are contractual and financial. Card brands can impose penalties on acquirers, which pass them to merchants under their agreements; acquirers can raise fees, require a forensic investigation by a PCI Forensic Investigator after a suspected breach, hold the merchant liable for fraud losses and card replacement costs, or terminate the merchant's ability to accept cards. Breaches also trigger notification duties under privacy and breach laws, regulatory action and litigation. For example, after its 2013 payment card breach, Target agreed in 2017 to an 18.5 million dollar settlement with 47 US states and the District of Columbia, in addition to settlements with card brands and banks.

Common mistakes and challenges for IT companies

• Card numbers in logs. Request logging, error trackers and debug output capture PANs from forms or API payloads. Mask or exclude payment fields everywhere.
• Assuming a hosted page means no PCI. You still validate (usually SAQ A) and must protect the page that sends customers to the provider.
• Unmanaged third-party scripts on checkout pages. Analytics, chat and A/B testing scripts on payment pages are the usual route for skimming attacks.
• Customer support taking card numbers by email, chat or recorded phone calls, which brings those systems into scope.
• Flat networks. Without segmentation, every system connected to the CDE is in scope.
• Storing CVV "temporarily". Sensitive authentication data must never be stored after authorisation.
• No responsibility matrix with providers. Requirement 12.8 and 12.9 need clear documentation of who does what.

Best practices, tools and technologies

• Use hosted payment pages or hosted fields and the provider's tokens for saved cards and recurring billing.
• Serve payment pages with a strict Content Security Policy and Subresource Integrity, and monitor them for script and header changes.
• Keep the payment flow on a minimal page with as few third-party scripts as possible.
• Enforce MFA and SSO for administrators, and isolate any CDE in a separate cloud account or VPC.
• Automate dependency and container scanning and patch on defined timelines.
• Centralise logs with tamper protection and 12-month retention.
• Train developers on secure coding annually, as requirement 6.2.2 expects, and test against the OWASP ASVS.

Our e-commerce and payment integration work starts with keeping card data off your servers.

How PCI DSS relates to other frameworks

Framework	Relationship
ISO/IEC 27001	Broader management system. Helpful, but does not satisfy PCI DSS validation.
SOC 2	Customers may ask for both; neither replaces the other.
PCI Secure Software Standard	For vendors of payment software sold to others; complements PCI DSS for the merchant.
OWASP Top 10 and ASVS	Common references for requirement 6 secure coding and testing.
GDPR, DPDP Act, GLBA	Legal duties on personal and financial data, including breach notification, that apply alongside PCI DSS.
RBI payment data storage	Indian requirement for payment system data to be stored in India, separate from PCI DSS.

Real-world implementation examples

Large card breaches have repeatedly come through the same routes PCI DSS targets: compromised third-party credentials, unsegmented networks, malware on point-of-sale systems, and malicious scripts injected into checkout pages. The rise of script-based skimming on e-commerce sites is the reason requirements 6.4.3 and 11.6.1 were added in v4.0.

An illustrative pattern for a SaaS product with subscriptions: the original build posted card details to the application server, which called the gateway. Moving to the gateway's hosted fields and storing only gateway tokens took the application servers out of the cardholder data flow, removed PANs from logs and backups, and changed the validation from SAQ D to SAQ A, with a short list of remaining controls focused on the checkout page.

Next steps

1. Map where card data flows today, including logs and support channels.
2. Decide whether to move to hosted payment pages or fields and tokens.
3. Ask your acquirer which level and validation method applies.
4. Close gaps for your SAQ or ROC, and set up scans and testing.
5. Collect AOCs from your service providers.

Need the checkout rebuilt? Get a quote.

Frequently asked questions

Is PCI DSS a law?

Not in most countries. It is an industry standard enforced through contracts with acquiring banks and the card brands. A few jurisdictions reference it in legislation.

What is the current version of PCI DSS?

PCI DSS v4.0.1, published in June 2024. Version 4.0 was retired at the end of 2024, and the requirements that were future-dated became effective on 31 March 2025.

Who needs to be PCI DSS compliant?

Every merchant that accepts payment cards and every service provider that stores, processes or transmits cardholder data or can affect its security, regardless of size.

If we use Stripe, Razorpay or PayPal, are we exempt?

No, but your scope can be very small. With a hosted payment page or hosted fields, many merchants validate with SAQ A. You remain responsible for the security of the pages that lead to the payment form.

Is there a PCI certification?

The PCI SSC does not certify merchants. Compliance is validated annually through a ROC or SAQ, and you receive an Attestation of Compliance that you can share.

What is the difference between a QSA and an ASV?

A Qualified Security Assessor performs PCI DSS assessments. An Approved Scanning Vendor performs the quarterly external vulnerability scans. Both are qualified and listed by the PCI SSC.

Can we store card numbers?

Only if there is a business need, and then the PAN must be unreadable wherever it is stored, with key management and access controls. Most businesses use provider tokens instead. CVV codes and full track data must never be stored after authorisation.

What changed in PCI DSS v4?

Among other things: MFA for all access into the CDE, 12-character passwords, payment page script controls, automated log review, targeted risk analyses, the customised approach, and stronger requirements for service providers.

Do PCI rules apply to card data in logs?

Yes. Any system that stores a PAN, including logs, backups and support tickets, is in scope and must meet requirement 3. The usual fix is to stop it being logged.

How often must we validate?

Annually, with quarterly ASV scans where your SAQ or ROC requires them, and scope confirmation at least every 12 months (every six months for service providers).

What happens after a card data breach?

Your acquirer may require a forensic investigation by a PCI Forensic Investigator, and you may face brand penalties passed on by the acquirer, fraud liability, card replacement costs, legal notification duties and litigation.

Does PCI DSS apply to UPI or bank transfers?

PCI DSS covers payment card data of the participating brands. Other payment methods have their own rules; in India, for example, the RBI's directions apply to payment system data.