PCI DSS v4.0.1 defines 12 requirements grouped under six control objectives, and every organization that stores, processes, or transmits cardholder data has to satisfy them. Compliance means three things in practice: confirm what falls inside your cardholder data environment, build the controls the standard demands, and document continuous evidence rather than a one-time snapshot. Your next move is simple: nail down your CDE scope and figure out which validation route (SAQ or QSA-led ROC) applies to you.
TL;DR:
- Organizations must clearly define and continuously verify their cardholder data environment scope to reduce the number of systems requiring PCI controls.
- Recent updates emphasize mandatory multi-factor authentication for all CDE access, along with maintaining up-to-date script inventories and automated log reviews to close audit gaps.
- Validation routes depend on merchant level, with high-volume merchants needing QSAs and smaller merchants typically completing self-assessments, while quarterly scans and annual testing remain essential.
- Auditors demand comprehensive, year-round evidence such as asset inventories, scan reports, MFA logs, and incident response records to demonstrate ongoing compliance.
- Building a proactive, coordinated compliance program centered on scope management, continuous monitoring, and unified evidence collection reduces audit failures and simplifies assessments.
Table of Contents
- What are the 12 PCI DSS requirements?
- What changed with PCI DSS v4.0.1 in 2026?
- How do you define your cardholder data environment?
- Which validation route applies to your business?
- What evidence do auditors actually ask for?
- What causes most PCI audit failures?
- How do you build a year-round PCI compliance program?
- Nexus perspective: what actually reduces PCI friction
- Get help with PCI DSS readiness
- Sources
- FAQ
What are the 12 PCI DSS requirements?
The Payment Card Industry Data Security Standard organizes its 12 requirements into six control objectives. Each objective groups related controls, and understanding that grouping helps you see why an auditor asks for certain evidence together rather than requirement by requirement.
Build and Maintain a Secure Network and Systems
- Requirement 1 — Install and maintain network security controls (firewalls, routing rules, and segmentation between trusted and untrusted networks).
- Requirement 2 — Apply secure configurations to all system components; default passwords and unnecessary services get removed before anything touches production.
Protect Account Data
- Requirement 3 — Protect stored account data through encryption, truncation, masking, or tokenization, with strict limits on retention.
- Requirement 4 — Protect cardholder data with strong cryptography during transmission over open, public networks.
Maintain a Vulnerability Management Program
- Requirement 5 — Protect systems against malware with anti-malware mechanisms that are actively maintained, not installed once and forgotten.
- Requirement 6 — Develop and maintain secure systems and software, including patch management timelines and, critically in the current standard, a script inventory for payment pages.
Implement Strong Access Control Measures
- Requirement 7 — Restrict access to system components and cardholder data based on business need to know.
- Requirement 8 — Identify users and authenticate access, which now includes multi factor authentication for essentially all access into the cardholder data environment.
- Requirement 9 — Restrict physical access to cardholder data, covering server rooms, badge systems, and media disposal.
Regularly Monitor and Test Networks
- Requirement 10 — Log and monitor all access to system components and cardholder data, with automated review replacing manual log-checking in most environments now.
- Requirement 11 — Test security of systems and networks regularly, which is where ASV scans, internal vulnerability scans, and penetration testing live.
Maintain an Information Security Policy
- Requirement 12 — Support information security with organizational policies and programs, including third-party service provider (TPSP) management and a formal incident response plan.
If you're mapping responsibilities across a team, this structure is genuinely useful: Requirements 1, 2, and 9 typically sit with network and facilities staff; 3, 4, and 6 sit with application and database owners; 7, 8, and 10 belong to identity and security operations; and 5, 11, and 12 usually land with whoever owns the compliance program itself. Trying to assign PCI DSS ownership to one person on a mid-sized team is a common early mistake. It spreads too wide for any single role to cover convincingly.
What changed with PCI DSS v4.0.1 in 2026?
PCI DSS v4.0.1 formalized two structural changes that reshape how organizations demonstrate compliance: the Targeted Risk Analysis (TRA) and the Customized Approach. It also pushed a batch of previously "future-dated" controls into mandatory status on March 31, 2025.
The Targeted Risk Analysis requires you to document why you chose a particular frequency, method, or configuration for a given control, rather than assuming a fixed industry default applies to your environment. If you review firewall rules quarterly instead of monthly, the TRA is where you justify that decision with actual risk reasoning, not a guess.
The Customized Approach goes a step further. It lets organizations with mature security programs meet a requirement's intent through an alternative control, provided they can show, with structured evidence, that the alternative genuinely mitigates the risk the standard is targeting. That flexibility sounds appealing, but assessors expect a level of documentation that most smaller teams underestimate: detailed rationale, testing procedures unique to the custom control, and evidence the control actually operated as designed.
The controls that became mandatory in 2025 are the ones tripping up the most organizations right now:
- Universal multi factor authentication for all access into the CDE, not just remote or administrative access.
- Script inventory and integrity monitoring for payment pages (Requirement 6.4.3), addressing the wave of client-side skimming attacks.
- Automated log review (Requirement 10.4.1.1), replacing manual daily log checks with mechanisms that flag anomalies continuously.
- Targeted risk analyses for any control where the organization sets its own frequency or approach.
Statistic callout: Checklists built specifically around the 2026 SAQ process consistently flag these four controls as the leading source of new audit gaps, ahead of any of the older, more familiar requirements. If your remediation list only touches legacy items, you're solving yesterday's problem.
Prioritize remediation in this order: confirm your script inventory exists and is current, extend MFA to every CDE access path (including third-party vendor access), then automate log review before your next assessment window opens. Fixing these three areas first tends to close the biggest gaps assessors are actually looking for.
How do you define your cardholder data environment?
Your cardholder data environment (CDE) is the set of people, processes, and technology that store, process, or transmit cardholder data, plus any system component that connects to or supports that environment. Scope definition sounds like a paperwork exercise, but CDE scoping is genuinely the highest-leverage activity in the entire compliance program, because every system you can legitimately remove from scope is one fewer system that needs the full weight of PCI controls.
Here's the practical sequence for defining scope correctly:
- Inventory every system that touches payment data. List applications, databases, servers, and endpoints, including anything used for support, backup, or logging of that data.
- Map the data flow. Trace cardholder data from the point it enters your environment (a web form, a point-of-sale terminal, a call centre script) through every system it passes across until it's tokenized, encrypted, or deleted.
- Identify connected systems. Anything that can influence the security of the CDE, even without directly touching card data, such as a jump box used to administer payment servers, falls into scope too.
- Segment aggressively. Use firewalls, VLANs, or cloud security groups to isolate the CDE from the rest of your network, then verify the segmentation actually holds with testing rather than assuming the diagram matches reality.
- Document and revisit quarterly. Scope isn't a one-time exercise. New integrations, new vendors, and new cloud services can quietly pull previously out-of-scope systems back in.
The most common source of scope creep is a "temporary" integration that never gets decommissioned: a marketing platform that briefly touched a card number during a migration, a support tool with database read access, or a shared services VPC that was never properly walled off. In cloud environments specifically, security groups and software-defined networking often get treated as an afterthought rather than a primary segmentation control, and that's exactly where auditors start probing.
Pro Tip: Before your next assessment, run a simple exercise: ask every department head "does your system ever see, store, or touch a card number, even briefly?" You'll almost always find at least one forgotten integration that should have been descoped years ago.
Which validation route applies to your business?
Validation requirements depend on your merchant level, which card brands set based on annual transaction volume. Understanding PCI merchant levels is the first step to knowing exactly what paperwork, scanning, and assessor involvement you're on the hook for.
- Level 1 typically applies to merchants processing very high annual transaction volumes, or any merchant that's had a data breach. Level 1 requires an annual Report on Compliance (ROC) completed by a Qualified Security Assessor (QSA), plus quarterly ASV scans.
- Level 2 generally covers merchants processing 1 to 6 million transactions annually. Most card brands allow a Self-Assessment Questionnaire (SAQ) here, though some require a QSA-reviewed assessment depending on brand-specific rules.
- Level 3 and Level 4 cover smaller transaction volumes and almost always validate through an SAQ, self-completed or with light third-party support.
The SAQ itself isn't one form. It comes in several variants matched to how you handle cardholder data:
- SAQ A applies to merchants who fully outsource card data handling to a validated third party and never touch card data on their own systems.
- SAQ A-EP fits e-commerce merchants who outsource payment processing but whose website still influences the security of the payment transaction (an iframe or redirect setup, for instance).
- SAQ D is the broadest and most demanding, covering merchants who store, process, or transmit cardholder data directly and don't qualify for a narrower category.
- SAQ D-SP is the service provider version of SAQ D, used by third parties that handle cardholder data on behalf of merchants.
Regardless of level, quarterly ASV (Approved Scanning Vendor) scans are a distinct, contracted requirement for most validation paths. ASV scanning is a separate deliverable from your internal compliance program, not something a GRC tool or internal IT team can substitute for. Penetration testing requirements sit alongside this: Requirement 11 calls for annual penetration testing of the CDE and segmentation testing at least every six months if you're relying on network segmentation to reduce scope. A QSA becomes necessary the moment your merchant level, card brand agreement, or a prior breach requires a ROC rather than a self-completed SAQ.
What evidence do auditors actually ask for?
Auditors don't take your word for it. Every requirement maps to specific artifacts, and building your evidence library well before assessment season saves weeks of scrambling later.
Inventory and diagrams:
- A current CDE map showing every in-scope system and data flow
- A complete asset list, including cloud instances and containers
- A script inventory for every payment page, tracking source, purpose, and integrity checks
- A third-party service provider tracker listing every vendor with CDE access and their own compliance status
Operational evidence:
- Quarterly ASV scan reports showing passing results (or documented remediation for failures)
- Authenticated internal vulnerability scan results, run at minimum quarterly
- Annual penetration test reports, plus segmentation test results if you rely on network isolation
- Automated log-review outputs demonstrating continuous, not periodic, monitoring
- MFA logs proving multi-factor authentication is enforced across every CDE access path
- Access-review records showing periodic recertification of who has access to what
Policy artifacts:
- Documented risk assessments, including any Targeted Risk Analysis backing a customized control frequency
- Written information security policies covering acceptable use, data retention, and incident response
- Training records showing staff completed security awareness training within the required cycle
- Incident-response test records proving the plan was actually exercised, not just written and filed
Here's a practical order to build this evidence library if you're starting close to zero:
- Finalize your CDE map and asset inventory first. Nothing else means much without accurate scope.
- Pull your last four quarters of ASV scans and internal scan reports together in one place.
- Confirm MFA logs cover every access path, including third-party and remote vendor connections.
- Assemble policy documents and check they've been reviewed within the last 12 months.
- Schedule your penetration test and segmentation test if either is overdue.
Auditors increasingly want to see this evidence organized in a way that shows continuous operation, meaning logs and scans from throughout the year, not a single clean snapshot taken the week before the assessment.
What causes most PCI audit failures?
Testing and monitoring obligations under Requirement 11 come with specific cadences, and missing them is one of the fastest ways to fail an assessment. Quarterly ASV scans are external and contracted; internal authenticated scans, also quarterly at minimum, look inward at systems from a logged-in perspective and catch different classes of vulnerabilities than an ASV ever will. Annual penetration testing and, where segmentation is used to reduce scope, semi-annual segmentation testing round out the technical testing calendar.
Logging retention expectations are stricter under v4.0.1 than many teams realize. Requirement 10.4.1.1 pushes organizations toward automated daily log review rather than manual spot-checks, because manual review simply doesn't scale against the volume of log data most environments generate. A security analyst scanning logs by eye once a week is not what this requirement envisions anymore.
Statistic callout: Practical checklists built around 2026 assessments repeatedly point to the same handful of failure points: gaps in universal MFA coverage, incomplete or outdated script inventories, and continuous evidence that simply doesn't exist because logging or scan results weren't retained consistently through the year.
The highest-risk failure points to watch for heading into any 2026 audit:
- MFA gaps on legitimate but overlooked access paths, particularly third-party vendor connections and internal administrative jump boxes.
- Incomplete script inventories where new payment-page scripts were added without updating the tracked inventory or integrity checks.
- Missing continuous evidence, where a team can produce one good scan report but not four consecutive quarters of them.
- Segmentation that looks correct on paper but hasn't been validated with actual testing in the last six months.
How do you build a year-round PCI compliance program?
The organizations that pass assessments smoothly aren't the ones that scramble for two months beforehand. They're the ones running a rhythm all year that makes the assessment a formality rather than a fire drill.
Start with ownership. A workable RACI typically looks like this: IT or security leadership owns scope definition and network segmentation, application teams own patching and script inventory, identity and access management owns MFA and access reviews, and a compliance lead owns evidence collection, policy review, and vendor tracking. Without named owners for each piece, evidence collection quietly falls apart the moment someone goes on vacation.
Recurring cadence matters more than any single control:
- Monthly — Review access logs for anomalies, confirm MFA coverage on any newly provisioned systems, check patch status against your defined timelines.
- Quarterly — Run ASV scans and authenticated internal vulnerability scans, review third-party service provider compliance status, update the script inventory.
- Every six months — Run segmentation testing if you rely on network isolation to reduce scope, review and refresh access permissions across the CDE.
- Annually — Book your penetration test, complete your Targeted Risk Analysis review, refresh security awareness training, and test your incident response plan for real.
Prioritize in this order if you're building the program from scratch: fix scope first, because every control downstream gets cheaper and simpler once your CDE is smaller. Then push universal MFA and script inventory integrity across the board, since those are the two controls most 2025-era failures trace back to. Only after those are stable should you invest heavily in continuous monitoring automation. Building automated log review before your MFA coverage is solid is putting a nice roof on a house with no foundation.
Pro Tip: Put your scan and assessment dates on a shared calendar at the start of the fiscal year, not the month before your assessment window opens. ASV vendors and QSAs both book up, and scrambling to schedule a penetration test two weeks before your deadline rarely ends well.
Nexus perspective: what actually reduces PCI friction
Most PCI guidance treats each requirement as an isolated checkbox, and that's precisely why so many organizations struggle with the standard. Requirements 8, 10, and 11 aren't separate problems. MFA, logging, and scanning all depend on the same underlying visibility into your environment, and when monitoring tools are fragmented across five vendors, that evidence never lines up cleanly for an assessor.
The organizations that move through assessments fastest tend to consolidate detection, access control, and evidence collection into one operating picture rather than stitching together point solutions after the fact. Nexus approaches PCI readiness the same way we'd approach any regulated environment: map scope first, build the required controls against that scope, then keep evidence flowing continuously instead of reconstructing it under deadline pressure. That sequence, done consistently, is what actually separates a smooth ROC from a scramble.
— Nick - Sr. Executive
Get help with PCI DSS readiness
Getting PCI-ready without a plan usually means chasing MFA gaps, script inventory updates, and scan schedules separately across whatever tools your team already has. That work can be consolidated under one provider, so scope mapping, continuous monitoring, MFA enforcement, and evidence collection run through a single point of accountability instead of multiple disconnected vendors you have to coordinate yourself.
Our Compliance & Risk service is built around exactly the controls this article covers: CDE scope reduction, universal MFA rollout, EDR-backed threat detection, and automated log-review that produces the continuous evidence assessors expect. If your access-control gaps overlap with cyber insurance requirements, our breakdown of proving MFA, EDR, and backups shows how those two compliance tracks often reinforce each other.
Some of this you can absolutely run in-house, particularly initial scope mapping and policy documentation. Where teams usually benefit from managed support is the ongoing evidence automation and 24/7 monitoring that a compliance deadline can't wait for. A readiness assessment is the practical first step: it identifies your current gaps against v4.0.1's mandatory controls before you're staring down an assessment window. Visit our services page to start that conversation.
Sources
For the official standard itself, the Payment Card Industry Data Security Standard page is the canonical source for the 12 requirements and control objectives. The full PCI DSS v4.0.1 text and summary of changes covers the Targeted Risk Analysis, Customized Approach, and the March 2025 mandatory-control transition in detail. For a practical, checklist-driven walkthrough of the SAQ process, see the 2026 PCI DSS compliance checklist, and for a plain-language explainer on who needs to comply and how scope reduction works, Stripe's PCI DSS checklist for businesses is a solid companion reference.
- Payment Card Industry Data Security Standard
- PCI DSS v4.0.1 (text and summary)
- PCI DSS Compliance Checklist 2026: SAQ Steps in Order
- PCI DSS checklist for businesses | Stripe
FAQ
What are the 12 requirements for PCI DSS?
The 12 requirements cover secure network configuration, protecting stored and transmitted account data, vulnerability management, strong access control (including MFA), physical security, logging and monitoring, regular testing, and a formal information security policy. They're grouped under six control objectives defined in the official standard.
What are six major principles of PCI DSS?
The six control objectives are: build and maintain a secure network, protect account data, maintain a vulnerability management program, implement strong access control, regularly monitor and test networks, and maintain an information security policy. Each of the 12 numbered requirements falls under one of these six.
Is PCI DSS legally required?
PCI DSS isn't a government law in most jurisdictions, but it's contractually enforced by card brands and acquiring banks, which makes it effectively mandatory for any business that accepts card payments. Non-compliance can trigger fines, increased transaction fees, or loss of card acceptance privileges.
What is a PCI DSS compliance checklist?
A practical checklist walks through scope definition, the 12 requirements mapped to specific evidence, validation route selection (SAQ type or QSA-led ROC), and testing cadence for ASV scans and penetration tests. AccountNext-Nexus builds this kind of checklist into its readiness assessments, mapping each control to the evidence auditors expect before formal validation begins.
What's the difference between PCI Level 1 and Level 2?
Level 1 merchants, generally those processing over 6 million transactions annually or with a prior breach, require an annual Report on Compliance completed by a QSA. Level 2 merchants, typically in the 1 to 6 million transaction range, can usually validate through a Self-Assessment Questionnaire, though specific card brand rules vary.