PCI Compliance Requirements: The Complete Guide to PCI DSS v4.0.1

If your business stores, processes, or transmits payment card data, PCI compliance requirements are not optional. They are a contractual obligation enforced by the card brands through your acquiring bank, and getting them wrong can mean six-figure fines, punitive per-transaction fees, or losing the ability to accept cards altogether. In our engagements at Atlant Security the same truth holds every time: merchants who treat PCI as an engineering scoping exercise finish fast and cheap, while those who treat it as a paperwork afterthought bleed money and time. This guide lays out the complete PCI DSS requirements under the current standard, PCI DSS v4.0.1, so you can plan an accurate path to compliance rather than a guess.

As a former Microsoft security consultant and CISSP, my aim here is the mental model that makes PCI tractable: understand what data you touch, shrink where it lives, then satisfy the controls that apply to what remains.

What PCI DSS is and who must meet PCI compliance requirements

The Payment Card Industry Data Security Standard (PCI DSS) is a global security standard published by the PCI Security Standards Council (PCI SSC), founded by the five major card brands: Visa, Mastercard, American Express, Discover, and JCB. PCI is not a law; it is a set of contractual requirements the card brands mandate and enforce through the chain of acquiring banks. When you sign a merchant agreement to accept cards, you agree to comply, and your acquiring bank is on the hook to the card brands for your compliance, which is why the bank ultimately fines you or terminates your account if you fall short.

Anyone who stores, processes, or transmits cardholder data must comply. That includes merchants of every size, from a one-person Shopify store to a global marketplace, and service providers such as payment gateways, hosting companies, and any third party that could affect the security of cardholder data. Even if you never touch a card number because a hosted payment page handles it, you are still in scope for a subset of requirements, because your website controls where the customer types that number.

Cardholder data, sensitive authentication data, and the CDE

Before any control makes sense, you have to know what PCI protects. The standard defines two categories of account data.

Cardholder data (CHD) is the Primary Account Number (PAN) plus, when stored with it, the cardholder name, expiration date, and service code. The PAN is the anchor: if you store it, you are squarely in scope for the strongest storage protections.

Sensitive authentication data (SAD) consists of full track data from the magnetic stripe or chip, the card verification value (CVV, CVC2, CID), and the PIN or PIN block. The rule here is absolute: you may never store SAD after authorization, even encrypted. This single rule catches more merchants than any other, because a verbose log file quietly captures the CVV during checkout.

The cardholder data environment (CDE) is the set of people, processes, and technology that store, process, or transmit CHD or SAD, plus any system component that connects to or could impact the security of that environment. Scope is everything in PCI, and the size and cost of your compliance effort is a direct function of how large your CDE is. A flat network where the payment application shares a subnet with the marketing site and office WiFi drags all of it into scope; a well-segmented environment that isolates card data keeps the CDE small and the assessment cheap.

The 12 core PCI compliance requirements, grouped into six goals

The heart of the standard is a set of twelve requirements organized under six control objectives. Under PCI DSS v4.0.1 each requirement expands into dozens of testable sub-requirements, and several that were future-dated when v4.0 launched are now in force, including expanded MFA and targeted risk analyses. Here is what each of the twelve PCI DSS requirements actually asks of you.

Goal 1: Build and maintain a secure network and systems

Requirement 1: Install and maintain network security controls. The modern rewording of the old firewall requirement. You need network security controls (firewalls, cloud security groups, and equivalent) between the internet and your CDE and between the CDE and less trusted networks, with documented rules, a justification for every allowed port and service, and a ruleset review every six months. Network and data-flow diagrams showing how cardholder data moves are mandatory and usually the first thing an assessor asks for.

Requirement 2: Apply secure configurations to all system components. Every server, firewall, container image, and application must be hardened. Vendor default passwords and default accounts have to be changed or disabled before a system goes live. You need documented configuration standards guided by hardening baselines such as the CIS Benchmarks, one function per server where practical, and unnecessary services disabled.

Goal 2: Protect account data

Requirement 3: Protect stored account data. If you must store the PAN, render it unreadable using strong cryptography, one-way hashing with per-account salts, truncation, or tokenization, and never store SAD after authorization. Encryption keys need documented management: strong generation, secure storage, split knowledge and dual control, and defined rotation. The best answer is almost always to not store the PAN at all.

Requirement 4: Protect cardholder data with strong cryptography during transmission over open, public networks. Any time CHD crosses the internet or a wireless network it must be encrypted with strong, current TLS, and weak protocols and cipher suites are prohibited. Under v4.0.1 you must also inventory trusted keys and certificates and confirm certificates are valid and not expired.

Goal 3: Maintain a vulnerability management program

Requirement 5: Protect all systems and networks from malicious software. Anti-malware protection on systems commonly affected by malware, kept current, actively running, and logging. v4.0.1 pushes you to address phishing and to periodically re-evaluate whether systems previously deemed not at risk still qualify.

Requirement 6: Develop and maintain secure systems and software. This dominates a fintech or SaaS assessment. Patch critical vulnerabilities within one month, follow secure coding practices, address common vulnerability classes such as injection and broken access control, and manage change control. v4.0.1 adds a control for payment page scripts: you must manage and monitor the scripts running in the browser on your payment pages and keep an inventory with written justification, a direct response to digital skimming (Magecart) attacks. A web application firewall or equivalent automated solution for public-facing web applications is also required.

Goal 4: Implement strong access control measures

Requirement 7: Restrict access to system components and cardholder data by business need to know. Access is denied by default and granted only to roles that genuinely need it, defined by job function, documented, and reviewed. Least privilege is the operating principle.

Requirement 8: Identify users and authenticate access to system components. Every user gets a unique ID, shared accounts are prohibited for administrative access, and passwords must meet strength rules (v4.0.1 sets a 12-character minimum where supported). The headline change now in force is multi-factor authentication: MFA is mandatory for all access into the CDE, not just remote administrative access, covering administrators, remote workers, and any personnel touching the environment. If you run single-factor logins into payment infrastructure, this is the requirement that bites first.

Requirement 9: Restrict physical access to cardholder data. Physical controls over facilities and media: badge access to data centers and server rooms, visitor logs, secure disposal of media containing CHD, and protection of point-of-interaction (POI) devices against tampering and substitution. Cloud-hosted merchants inherit much of this from their provider but still own device security in their own stores and offices.

Goal 5: Regularly monitor and test networks

Requirement 10: Log and monitor all access to system components and cardholder data. Comprehensive audit logging of who did what and when, time synchronization, tamper protection, and daily review of security events. v4.0.1 allows automated log review and requires that failures of critical security controls are detected and addressed promptly. Retain logs for at least twelve months, with three months immediately available.

Requirement 11: Regularly test security of systems and networks. You need quarterly internal vulnerability scans and quarterly external scans by an Approved Scanning Vendor (ASV), with rescans until a passing result, plus annual penetration testing at the network and application layers and segmentation testing to validate any isolation you rely on to keep systems out of scope. v4.0.1 adds a change-and-tamper detection mechanism on payment pages to alert on unauthorized modification of HTTP headers and page content. Wireless testing and intrusion detection round it out.

Goal 6: Maintain an information security policy

Requirement 12: Support information security with organizational policies and programs. A written information security policy reviewed at least annually; role-based security awareness training; a tested incident response plan; a formal risk approach (v4.0.1 replaces the annual generic risk assessment with targeted risk analyses); and a program to manage third-party service providers, including a maintained provider list, written agreements acknowledging their responsibility, and monitoring of their compliance.

For a structured read of where you stand against all twelve, a focused IT security audit turns this list into a prioritized gap report rather than a wall of text.

PCI merchant levels and what validation each needs

The card brands assign merchants to one of four levels based primarily on annual transaction volume, and the level determines how heavy your validation obligation is. Thresholds vary slightly by card brand, but Visa's model is the de facto industry reference.

Merchant level	Annual transaction volume (typical)	Validation required
Level 1	Over 6 million transactions per year, any merchant that suffered a breach, or one a card brand designates Level 1	Annual ROC via onsite assessment, quarterly ASV scans, and an AOC
Level 2	1 million to 6 million transactions per year	Annual SAQ, quarterly ASV scans, and an AOC (some brands require QSA sign-off)
Level 3	20,000 to 1 million e-commerce transactions per year	Annual SAQ, quarterly ASV scans, and an AOC
Level 4	Fewer than 20,000 e-commerce, or up to 1 million total transactions per year	Annual SAQ and quarterly ASV scans as required by the acquirer, plus an AOC

Service providers have their own two-tier model. A Level 1 service provider stores, processes, or transmits more than 300,000 transactions per year (or is otherwise designated) and must undergo an annual onsite assessment with a QSA-produced ROC. A Level 2 service provider handles fewer and may self-assess via SAQ D. If you are a SaaS or fintech platform selling to enterprises, expect to be treated as Level 1, because customers will demand your AOC before they sign, much as they demand a SOC 2 report.

PCI SAQ types and how to choose the right one

Most small and mid-sized merchants validate with a Self-Assessment Questionnaire. Choosing the correct PCI SAQ is consequential, because each maps to a specific way of accepting payments and covers a very different number of requirements. Pick the wrong one and you do far more work than necessary, or worse, attest to something untrue.

SAQ type	Who it is for
SAQ A	Card-not-present e-commerce or mail/telephone merchants who fully outsource all cardholder data functions to a PCI-compliant provider via a redirect or fully hosted iframe. Smallest control set.
SAQ A-EP	E-commerce merchants who partially outsource but whose website affects the transaction, for example a direct-post or JavaScript integration where your page controls the payment form. Much larger than SAQ A.
SAQ B	Merchants using only standalone dial-out imprint machines or dial-up terminals. No electronic storage.
SAQ B-IP	Merchants using only standalone, PTS-approved point-of-interaction terminals with an IP connection to the processor. No electronic storage.
SAQ C	Merchants with a payment application connected to the internet, but no electronic cardholder data storage.
SAQ C-VT	Merchants who key transactions one at a time into a web-based virtual terminal on an isolated computer. No storage.
SAQ P2PE	Merchants using a PCI-listed Point-to-Point Encryption (P2PE) solution with no access to clear-text cardholder data. Shortest questionnaire of all.
SAQ D	All other merchants who store cardholder data or do not fit a category above, and all SAQ-eligible service providers. The full questionnaire covering every applicable requirement.

The practical takeaway: SAQ A is the promised land for e-commerce, and the game is architecting your checkout so you legitimately qualify for it. The difference between SAQ A (roughly two dozen controls) and SAQ D (over 300) is enormous, so if your integration forces you into SAQ A-EP or D, moving to a fully hosted payment page or iframe can collapse your obligation dramatically.

Validation artifacts: SAQ, ROC, ASV scans, and AOC

• SAQ (Self-Assessment Questionnaire): the merchant's own attestation against the applicable subset of requirements, used where an onsite assessment is not required.
• ROC (Report on Compliance): a detailed, evidence-backed report produced after an onsite assessment, normally by a Qualified Security Assessor (QSA). Required for Level 1 merchants and Level 1 service providers.
• ASV scan: a quarterly external vulnerability scan of your internet-facing systems by an Approved Scanning Vendor from the PCI SSC's list. You must achieve a passing scan, remediating and rescanning as needed.
• AOC (Attestation of Compliance): the signed summary declaration of your compliance status (signed by a company officer, and by the QSA when involved). This is the document your acquiring bank and enterprise customers ask to see.

Scope reduction is your biggest cost lever

Everything expensive about PCI scales with the size of your cardholder data environment, so the smartest money is spent shrinking the CDE before you satisfy controls. A good scoping decision made early saves more than any amount of clever remediation later.

Four proven techniques compound.

Tokenization. Replace the stored PAN with a token that is worthless to an attacker and cannot be reversed without the token vault. If your systems only ever hold tokens for recurring billing and refunds while the real PAN lives in your provider's vault, your databases and applications drop out of the storage requirements of Requirement 3.

Hosted payment pages and iframes. When the customer types their card number into a page or iframe served entirely by your PSP, the card data never touches your servers. Done correctly, this qualifies an e-commerce merchant for SAQ A instead of SAQ A-EP or D. The nuance under v4.0.1 is that the new script-management and tamper-detection controls apply even to SAQ A merchants, because attackers learned to inject skimming scripts into the merchant page around the iframe.

Point-to-Point Encryption (P2PE). For card-present merchants, a PCI-listed P2PE solution encrypts card data inside the terminal at the moment of swipe, dip, or tap, so clear-text data never exists on your network. This unlocks the short SAQ P2PE.

Network segmentation. Isolate the systems that must handle card data into a tightly controlled enclave, separated by network security controls from the rest of your business. Segmentation does not reduce the controls that apply to the CDE, but it dramatically shrinks what counts as the CDE, and everything you carve out is something you no longer have to assess. If you rely on segmentation, Requirement 11 obligates you to prove it works with segmentation penetration testing at least annually, and every six months for service providers.

Penetration testing and segmentation testing under Requirement 11

Merchants routinely underestimate this work. PCI DSS requires a formal, methodology-driven penetration test at least annually and after any significant change, covering the CDE perimeter and critical systems from both outside and inside, at the network and application layers. This is not an ASV scan: the scan is automated and quarterly, while a penetration test is a manual, expert-led exercise that chains vulnerabilities the way a real attacker would.

If you use segmentation to reduce scope, you must additionally run a segmentation test that attempts to reach the CDE from out-of-scope networks to prove the isolation holds. When we run PCI penetration testing for clients, the segmentation test is frequently where we find the surprise: a forgotten management VLAN or a monitoring agent that quietly bridges the two networks. Better we find it than an attacker.

How long PCI compliance takes and what it costs

It depends entirely on your scope and starting maturity, but here are the ranges we see in practice.

For a typical SAQ-eligible merchant with a sound architecture, plan on roughly 90 days from kickoff to a signed AOC: gap assessment and scoping (two to four weeks), remediation to close gaps in policy, configuration, logging, MFA, and testing (four to eight weeks, the variable part), and validation to run scans, complete the SAQ, and sign the attestation (two to three weeks). A Level 1 merchant or service provider pursuing a QSA-led ROC should budget four to six months, given the deeper onsite assessment and evidence collection.

Cost breaks into consulting and remediation help, QSA or ASV fees, and internal engineering time. Rough industry ranges: ASV scanning runs from a few hundred to a couple of thousand dollars a year depending on external IP count; a SAQ-level readiness engagement lands in the low-to-mid five figures; a full QSA-led ROC for a Level 1 organization commonly runs from the mid five figures into six figures for complex environments; and a quality annual penetration test is usually a five-figure line item on its own. The biggest driver of every one of these numbers is your scope, which is exactly why scope reduction pays for itself.

Penalties for non-compliance

Because PCI is contractual rather than statutory, the penalties flow through your acquiring bank rather than a government regulator, and they are very real. The card brands can levy fines the acquirer passes to you, commonly from thousands to tens of thousands of dollars per month and escalating over time. Non-compliant merchants routinely see higher per-transaction fees, and in serious or repeated cases the acquirer can terminate your ability to accept cards entirely, which for most online businesses is an extinction-level event.

If non-compliance contributes to a breach, the costs multiply: forensic investigation by a PCI Forensic Investigator (PFI), card reissuance and fraud reimbursement assessments, a mandatory move to Level 1 validation, legal exposure, and reputational damage. In every breach investigation I have seen, the organization was non-compliant with at least one requirement that would have prevented or contained the incident, most often logging, patching, or access control. Compliance is no guarantee against a breach, but non-compliance reliably predicts a worse one.

Common gaps and a readiness checklist

The same gaps recur across our engagements, and closing them before formal validation saves weeks.

• Storing prohibited SAD: CVV or full track data captured in application logs, error dumps, or a "for troubleshooting" database column. Grep for it before an assessor does.
• Incomplete MFA: MFA on the VPN but not on the cloud console, database bastion, or SaaS admin panel that reaches into the CDE. v4.0.1 requires MFA for all CDE access.
• Unmanaged payment page scripts: no inventory or integrity monitoring of the third-party JavaScript on your checkout, now an explicit v4.0.1 requirement.
• Weak or missing segmentation testing: claiming reduced scope without the annual test to prove the boundary holds.
• Stale firewall rules and no data-flow diagram: rulesets never reviewed, no current diagram of where cardholder data goes, and critical patches lingering past the one-month window.
• Untracked service providers: no list of the third parties in your payment flow and no written acknowledgment of their PCI responsibilities.
• Policies that exist but are not lived: a security policy no one has read, no awareness training, and an incident response plan that has never been tested.

A practical readiness checklist: document your card data flows; determine your merchant level and correct SAQ; reduce scope through tokenization, a hosted page, P2PE, or segmentation; harden and patch every in-scope system; enforce unique IDs and MFA everywhere in the CDE; turn on comprehensive logging with daily review; schedule quarterly ASV scans and annual penetration and segmentation tests; write and socialize the required policies and training; inventory and contractually bind your service providers; then complete the SAQ or ROC and sign the AOC. If you want a partner to run this end to end, that is exactly what our PCI compliance consulting practice does.

PCI Compliance Requirements FAQ

Is PCI DSS a legal requirement?

No. PCI DSS is a contractual obligation, not a law. You agree to it when you sign a merchant agreement, and it is enforced by the card brands through your acquiring bank, which can fine you, raise your fees, or revoke your ability to process cards. Some jurisdictions reference PCI in regulation, and a breach can still trigger legal liability under data protection laws.

What is the difference between PCI DSS v4.0 and v4.0.1?

PCI DSS v4.0.1 is a limited revision of v4.0 that corrects and clarifies the standard without adding new requirements, and it is the current active version. Many controls that were "future-dated" best practices in v4.0 are now mandatory, including expanded MFA for all CDE access, the payment page script and tamper-detection controls, and the targeted risk analysis approach.

Do I need to comply if my payment processor handles all the card data?

Yes, but with a much smaller scope. Even if a hosted payment page means card numbers never touch your servers, your website still controls where the customer enters their card, so you remain responsible for a subset of requirements, typically validated through SAQ A, which under v4.0.1 now includes managing and monitoring the scripts on your payment page. Full outsourcing reduces your burden dramatically but never eliminates it entirely.

Is a penetration test really required for PCI?

Yes. Requirement 11 mandates a methodology-based penetration test at both the network and application layers at least annually and after significant changes. If you rely on segmentation to reduce scope, you must also run segmentation penetration testing to prove the isolation holds. This is separate from and in addition to the quarterly ASV vulnerability scans, which are automated rather than manual.

Can tokenization take my systems out of PCI scope?

Tokenization significantly reduces scope by having your systems store non-sensitive tokens instead of real card numbers, removing them from Requirement 3's storage rules. It rarely takes you completely out of scope, because the systems that transmit the card to be tokenized, and your payment pages, remain in scope. Combined with a hosted payment page and good segmentation, though, it is one of the most effective scope-reduction tools available.

What happens if I store the CVV or other sensitive authentication data?

You are in direct violation of Requirement 3, which prohibits storing sensitive authentication data (the CVV, full track data, or PIN) after authorization under any circumstances, even encrypted. This is one of the most common and serious findings, and it usually hides in application logs or debug output rather than a deliberate database field. Search for it before an assessor or attacker does.

Ready to get started? Atlant Security helps companies close security gaps and pass compliance fast, led personally by a former Microsoft security consultant with 200+ assessments across 14 countries. Book a free strategy call and get a fixed-price proposal within 24 hours.