The 12 PCI DSS Requirements Explained
Reviewed by Raymond Dantes, PCI QSA
PCI DSS organizes cardholder data protection into 12 specific requirements covering network isolation, encryption, access control, monitoring, and documentation. Each requirement addresses a proven attack vector used in payment card breaches. Understanding what each requirement covers and how they interconnect as a system prevents you from overspending on vendor solutions that solve the complicated version of compliance rather than the real one.
The 12 PCI DSS requirements are the actual framework you're going to be audited against. You need to understand what each one covers not because you need to memorize them, but so you know what you're actually responsible for implementing. That distinction matters because most merchants know PCI compliance is something they're required to do, but fewer understand the specific controls they're being asked to build. That knowledge gap is exactly where vendors and consultants make their money — by making the requirements sound more complicated than they actually are, and then selling you solutions to solve the complicated version instead of the real version.
Underneath all twelve requirements is a coherent system: isolate card data so that even if something goes wrong in one part of your environment, the attacker still can't get to it; control who can access the data and how; keep the data encrypted so stolen data is useless; monitor who's accessing it and what they're doing; and document everything so you can prove you're actually doing what you say you're doing. That's the philosophy. The twelve requirements are just different ways of implementing that philosophy.
Requirements 1 Through 4: Network Isolation and Encryption
Requirements 1 through 4 establish the perimeter defenses that prevent attackers from reaching cardholder data even when other parts of your network are compromised.
Requirement 1 is network segmentation — creating separate network boundaries between your cardholder data environment (the part of your network where card data lives) and everything else. The idea is that if an attacker compromises one part of your network, they shouldn't be able to just wander over to where the card data is. You build this with firewalls and access controls that explicitly define what traffic can move between network segments. This doesn't have to be elaborate. A small business might have a simple two-segment network: public-facing systems on one side, payment processing systems on the other, with a firewall controlling traffic between them. A larger business might have many more segments. But the principle is the same.
Requirement 2 is about eliminating default credentials. Every system in your cardholder data environment needs to have default passwords changed from whatever the vendor shipped it with, and default accounts that aren't needed should be disabled entirely. This sounds obvious until you discover how many systems still ship with default credentials and how many organizations never bother changing them. According to the Verizon 2024 Data Breach Investigations Report, use of stolen or default credentials remains one of the top initial access vectors in confirmed breaches. A system with default credentials is basically an unlocked door with a sign saying "please walk through."
Requirement 3 mandates encryption of stored card data. If someone manages to get a database export or a backup copy of your systems, the card data in that export should be unreadable without the encryption keys. This isn't optional. Unencrypted card data is one of the biggest liability vectors in a breach. Encryption here matters to both security and liability — if your data is encrypted and someone steals it, the breach is less catastrophic. If it's unencrypted, it's a disaster.
Requirement 4 requires encryption in transit — card data can't move unencrypted across networks or the internet. This means TLS/SSL for any transmission involving card data, whether it's moving between systems within your network or crossing the internet. If data moves unencrypted, anyone sniffing the network can read it. You're making that impossible.
These four requirements form the foundation. Get them right and you've solved the biggest attack vector against most organizations. Get them wrong and no other control in the world matters. Many organizations fail audits because they nail everything else but find that card data somewhere in their environment is either not encrypted at rest or not encrypted in transit. When an auditor finds that, it's a critical finding — it means your perimeter isn't actually protecting the asset.
Requirements 5 Through 7: Access Control and Authentication
Requirements 5, 6, and 7 eliminate the most common entry points attackers exploit by governing who can access cardholder data and how they authenticate.
Requirement 5 is multi-factor authentication (MFA) for anyone accessing the cardholder data environment. MFA means that a stolen password alone isn't enough to get in. You also need something else — a code from a phone, a hardware token, a biometric. The point is that compromising a single factor doesn't mean an attacker gets access. The Verizon DBIR consistently finds that stolen or compromised credentials are involved in a significant share of breaches, and MFA stops that attack vector cold. If you implement strong MFA for anyone accessing card data systems, you've eliminated a massive source of risk.
Requirement 6 is about keeping systems patched and hardened. This means installing security patches in a timely manner — PCI DSS 4.0 specifies that critical and high-security patches must be installed within one month of release. It also means hardening systems: removing unnecessary software, disabling unused services, configuring systems to be more resistant to attack. Most exploits target known vulnerabilities that patches would have fixed. If you keep systems current, you've eliminated the low-hanging fruit that attackers target first.
Requirement 7 is access control based on the principle of least privilege: people and systems only get the permissions they actually need to do their job. This sounds straightforward, but it's where most organizations fail. A person who handles customer service requests doesn't need access to view every customer's credit card data. They need access to see the requests and the last four digits of the card for transaction matching. That's it. Yet in many environments, access controls are so broad that a single compromised account gives an attacker visibility to the entire cardholder data environment.
Implementing least privilege requires understanding what people actually do and setting permissions accordingly. It's less technically complex than something like encryption, but it's administratively intensive because it requires ongoing management. When a new employee starts, someone has to set their permissions correctly. When they move to a different team, someone has to adjust permissions. When they leave, someone has to disable them. It's not difficult — it's just tedious and ongoing.
These three requirements together eliminate most of the entry points that attackers use. Strong authentication, current systems, and limited permissions mean attackers can't just walk through the front door. They'd have to find a sophisticated zero-day vulnerability or use some other advanced technique. At that point, you've already made yourself a harder target than most organizations, and attackers typically move on to easier prey.
Requirements 8 and 9: Accountability and Physical Security
Requirements 8 and 9 provide the detective controls that let you reconstruct what happened when something goes wrong — because despite your best prevention efforts, breaches happen.
Requirement 8 is identity and access management (IAM) — making sure you know who accessed what and when. This means logging account creation, modification, and deletion. It means logging login attempts, especially failures. It means having unique user IDs so you can trace actions back to a specific person. The point is that if something goes wrong — a data theft, an unauthorized change, a suspicious access pattern — you can investigate and understand what happened. Without this level of accountability, you have no way of knowing whether a breach happened or who was involved.
Requirement 9 is physical security — securing the actual buildings, server rooms, and hardware where card data lives. If someone can walk into your data center and plug a USB drive into a server to copy data, your encryption and access controls don't matter. Physical security means restricted access to facilities where systems are housed, surveillance systems, visitor logs, and procedures for handling sensitive materials. For a small business, this might mean a locked closet with servers and restricted key access. For a larger organization, it might mean a dedicated secure data center with badge access, cameras, and comprehensive logging of who enters and when.
The reason these two get grouped together is that they're both about detecting what actually happened rather than preventing the attack in the first place. Requirements 1 through 7 are preventive: they try to stop bad things from happening. Requirements 8 and 9 are detective: they help you figure out what bad thing happened and who did it. That's genuinely important because when breaches happen, logs and accountability information are what let you understand the scope of the breach and respond appropriately.
Logging everything and monitoring nothing is worse than not logging at all because you're creating the appearance of security while gaining zero visibility. Requirements 8 and 9 only matter if someone is actually reviewing logs and responding to anomalies. Effective monitoring means active review — someone with adequate training looking at logs with a specific purpose: identifying unauthorized or suspicious activity. That can be a security operations center (SOC) at a large company, a SIEM system (a centralized log analysis tool), or even a smaller organization with someone reviewing logs on a regular schedule. But someone has to be looking.
Requirements 10 Through 12: Maintenance and Documentation
Requirements 10 through 12 ensure your controls are continuously maintained and independently verifiable — not just implemented once and forgotten.
Requirement 10 is log retention and active monitoring. This means keeping logs for a sufficient period — typically at least one year, with at least three months readily accessible — and actually reviewing them to detect and respond to suspicious activity. This is the "proof of monitoring" requirement. You have logs. But are you reading them? When something suspicious shows up, do you investigate? This is the difference between having logs and actually having visibility.
Requirement 11 is vulnerability scanning and penetration testing. Vulnerability scanning is automated — you run a tool that probes your systems for known weaknesses, common misconfigurations, and unpatched software. PCI DSS 4.0 requires at least quarterly external scans by an Approved Scanning Vendor (ASV) and quarterly internal scans. Penetration testing is manual — a qualified person attempts to attack your systems to find security weaknesses that automated scanning might miss. The requirement is that you conduct annual penetration testing. Both of these create continuous verification that your controls actually work and that you haven't accidentally introduced new vulnerabilities through system changes or patches.
Requirement 12 is the policy and training layer. You need documented security policies that explain what your organization's requirements are around card data handling, access control, change management, incident response, and vendor management. You need employee awareness training so people understand the policies and their responsibility for following them. You need an incident response plan that explains what happens if a breach is detected — who needs to be notified, what the investigation process looks like, how you contain the damage. And you need to actually conduct incident response tabletops or simulations so people understand their roles before an actual emergency happens.
These sound administrative compared to the technical requirements, but they're not less important. Many organizations fail audits because they're missing documentation, even when they're actually implementing the controls correctly. An auditor can't verify a control that isn't documented. That's why Requirement 12 matters — it's not bureaucracy for its own sake. It's proof that you've thought through what you're doing and that you're doing it intentionally, not accidentally.
What These Twelve Requirements Actually Prevent
The PCI DSS structure addresses specific attack vectors with specific controls, and understanding which requirement prevents which attack helps you understand why you're doing this work.
Insider threats and excessive permissions are prevented by Requirements 7 and 8. If people can only access what they need and their access is logged, it's much harder for an insider to steal data or help an external attacker. Compromise of one system won't give an attacker free movement throughout your environment if network segmentation is in place under Requirement 1. Stolen credentials won't be enough to get in if MFA is implemented under Requirement 5. Unpatched systems won't provide an easy exploitation path if you're keeping systems current under Requirement 6. Attackers who do somehow get into your environment and steal data will find it useless if it's encrypted under Requirements 3 and 4. And when something goes wrong, you'll be able to investigate and understand what happened if you have logs and are monitoring them under Requirements 8, 9, and 10.
The twelve requirements aren't arbitrary. They're the collective wisdom of the payment card networks about what actually matters for securing card data. Every major breach in the history of card fraud has involved someone violating one or more of these requirements. Implement all twelve well, and you've made yourself a poor target for card data theft.
Which Requirements Apply Depends on Your Scope
Not every requirement applies in the same way to every organization — your cardholder data environment scope determines what you're actually responsible for.
This is critical: your scope determines what you're actually responsible for. If you use a hosted payment processor and never handle card data directly, many requirements don't apply. If your organization handles card data internally, all twelve apply. Understanding your scope prevents you from implementing irrelevant controls and wasting resources.
An e-commerce business using a hosted payment processor and never touching raw card numbers might only be responsible for ensuring their application connects securely to the processor (Requirement 4) and that they have an incident response plan (Requirement 12). Physical security (Requirement 9) doesn't apply because they don't have a data center with servers storing card data. A brick-and-mortar retailer using a payment terminal to process cards might have a minimal scope if the terminal handles all card data and never transmits it to their own systems. A healthcare practice that processes credit cards for patient payments but uses a payment processor that handles the data has minimal PCI scope.
The critical step is accurately defining your scope by understanding exactly what systems touch card data. Many organizations think they're handling more card data than they actually are, or conversely, discover they're handling card data in a system they didn't realize was PCI-scoped. That's why the scoping conversation with your auditor or acquiring bank is so important. Get scope right, and compliance becomes manageable. Get it wrong, and you're either doing unnecessary work or missing critical requirements.
You now understand the 12 requirements not as a bureaucratic checklist imposed by distant card networks, but as a coherent system that prevents the attack vectors actually used in card data breaches. You can read a PCI audit report and understand which requirements you failed and why, instead of nodding along while a consultant explains why you need their expensive solution to fix it. That clarity lets you make intelligent decisions about PCI controls — you understand that network segmentation and encryption are foundational, that access control and MFA matter significantly, that logging is useless without active monitoring, and that policies and documentation are as critical as technical controls. Most importantly, you understand which of these requirements actually apply to your specific environment, which prevents you from building unnecessary controls while ensuring you don't miss critical ones.
Frequently Asked Questions
Do all 12 PCI DSS requirements apply to every merchant?
No. Your scope depends on how your organization handles cardholder data. If you use a hosted payment processor and never touch raw card numbers, many requirements — particularly those around encryption at rest, physical security, and network segmentation — may not apply to your environment. Your acquiring bank or QSA can help you determine which requirements are relevant based on your specific architecture.
What is the difference between PCI DSS 3.2.1 and 4.0 regarding the 12 requirements?
PCI DSS 4.0, which became mandatory on March 31, 2024, restructured several requirements and added new sub-requirements around areas like targeted risk analysis, enhanced authentication, and anti-phishing controls. The 12 top-level requirement categories remain the same, but the specific controls within them have been updated and expanded. Organizations should validate their compliance against the current 4.0 standard.
Which PCI DSS requirements do organizations fail most often?
Requirements 6 (patching and system hardening), 10 (log monitoring), and 11 (vulnerability scanning and penetration testing) are among the most commonly cited areas of non-compliance in QSA assessments. These failures typically stem from operational gaps rather than technical inability — organizations implement the controls but fail to maintain them consistently or document their ongoing operation.
Can we use a single control to satisfy multiple PCI DSS requirements?
Yes. Many security controls address multiple requirements simultaneously. Network segmentation (Requirement 1) combined with strong encryption (Requirements 3 and 4) and access controls (Requirement 7) creates layered defense that satisfies several requirements at once. However, each requirement must be independently verifiable during an audit — you cannot claim compliance with one requirement solely because another overlapping control exists.
How does PCI DSS Requirement 12 relate to the technical requirements?
Requirement 12 is the documentation and policy layer that proves your technical controls are intentional and maintained. An auditor cannot verify a control that isn't documented, regardless of how well it functions. Organizations that implement strong technical controls but lack written policies, incident response plans, and training records frequently fail audits on Requirement 12 alone.
Fully Compliance provides educational content about IT compliance and cybersecurity. This article reflects general information about PCI DSS as of its publication date. Standards, costs, and requirements evolve — consult a qualified compliance professional for guidance specific to your organization.