The 12 PCI DSS Requirements Explained

The six goals behind the twelve requirements

The twelve requirements are not a random list; they are grouped under six overarching goals that tell a logical story. The goals are: build and maintain a secure network and systems; protect account data; maintain a vulnerability management program; implement strong access control measures; regularly monitor and test networks; and maintain an information security policy.

Reading the requirements through this lens makes them far easier to remember and apply. Each goal addresses a different dimension of security — the perimeter, the data, the software, the people, the visibility, and the governance — and the requirements beneath each goal are simply the concrete actions that achieve it. Keep the six goals in mind and the twelve requirements stop feeling like a checklist and start feeling like a coherent program.

Requirements 1 & 2: Build and maintain a secure network

The first goal concerns your network and systems. Requirement 1 calls for installing and maintaining network security controls — historically firewalls, now broadened to include any technology that controls traffic between networks — to protect the cardholder data environment from untrusted networks. The aim is to ensure that only necessary, justified traffic can reach systems handling card data.

Requirement 2 addresses secure configuration. It requires you to apply secure settings to all system components and, crucially, to change vendor-supplied defaults such as default passwords and accounts before deploying anything. Default configurations are widely known and frequently exploited, so hardening them is one of the simplest and most effective security steps a business can take.

Requirements 3 & 4: Protect account data

The second goal protects the data itself. Requirement 3 governs the protection of stored account data: cardholder data must be rendered unreadable wherever it is stored, through encryption, truncation, tokenization, or hashing, and sensitive authentication data must never be retained after authorization. This is where the rules about what you can and cannot store come into force.

Requirement 4 protects data in transit. Whenever cardholder data crosses open, public networks — the internet, wireless links, and similar — it must be protected with strong cryptography so it cannot be intercepted and read. Together these two requirements ensure that card data is unreadable both when it sits at rest and when it moves, closing the two main windows of exposure.

Requirements 5 & 6: Maintain a vulnerability management program

The third goal keeps your systems and software resistant to attack. Requirement 5 calls for protecting all systems and networks from malicious software, which means deploying and maintaining anti-malware defenses and keeping them current against evolving threats. Malware remains a primary vector for compromising payment environments, so this protection must be active and monitored.

Requirement 6 concerns secure systems and software. It requires you to develop and maintain secure applications, apply security patches promptly, and follow secure development practices that prevent common vulnerabilities. In the v4.0 era this also extends to managing the scripts loaded on payment pages to defend against e-skimming. The goal is to ensure the software handling card data does not itself become the weakness attackers exploit.

Requirements 7, 8 & 9: Implement strong access control

The fourth goal restricts who and what can reach cardholder data. Requirement 7 limits access by business need-to-know, ensuring people and systems can only reach the data and functions their role genuinely requires. Requirement 8 covers identification and authentication: every user must be uniquely identified and strongly authenticated, with multi-factor authentication now required for access into the cardholder data environment.

Requirement 9 addresses physical access, restricting who can physically reach systems, media, and facilities that hold cardholder data. Even in a cloud-centric world, physical controls matter for offices, devices, and any on-premises equipment. Together these three requirements ensure that access to card data is deliberately granted, individually accountable, and protected at both the logical and physical level.

Requirements 10 & 11: Regularly monitor and test networks

The fifth goal gives you visibility and assurance. Requirement 10 mandates logging and monitoring of all access to system components and cardholder data, so that activity can be reconstructed and anomalies detected. Comprehensive, reviewed logs are essential both for catching intrusions early and for investigating them afterward, and v4.0 pushes toward automated log review.

Requirement 11 requires regular testing of the security of systems and networks. This includes vulnerability scanning, penetration testing, and, for organizations using segmentation, testing that the segmentation actually holds. Testing turns assumptions into evidence: it confirms that the controls you believe are working really are, and surfaces weaknesses before attackers find them.

Requirement 12: Maintain an information security policy

The sixth goal is governance. Requirement 12 calls for maintaining an information security policy and program that supports the security of cardholder data and is understood by all relevant personnel. This is the connective tissue that holds the technical controls together: policies, risk assessments, security awareness training, incident response planning, and the assignment of clear responsibilities.

Although it is a single requirement, Requirement 12 is broad and easy to underestimate. Strong technical controls undermined by weak governance — no policies, untrained staff, no incident plan — will not produce durable security or a clean assessment. v4.0 reinforces this by expecting documented roles and responsibilities for each requirement, making accountability explicit.

How the requirements work together

The twelve requirements are designed to reinforce one another, forming layers of defense rather than isolated controls. A secure network keeps attackers out; protected data limits the damage if they get in; vulnerability management closes the holes they would exploit; access control ensures only the right people reach the data; monitoring and testing catch problems early; and governance ties it all together and keeps it running.

This layering is why partial compliance offers little protection. An environment with strong encryption but weak access control, or excellent monitoring but unpatched software, still has an open door. The requirements are a system, and their value comes from implementing them together so that the strength of each compensates for the moments when another is tested.

This is also why assessors look at the environment holistically rather than ticking boxes in isolation. They want to see that the requirements operate together as a living program, with controls that reinforce one another and gaps in one area covered by strength in others. An organization that understands the requirements as a connected system, rather than a list to satisfy individually, tends to produce both better security and cleaner assessments.

How ISpectra helps you meet all twelve

Implementing twelve requirements and their many sub-requirements is a substantial undertaking, and it is exactly what ISpectra Technologies guides businesses through on the path to pci dss certification. ISpectra runs a gap analysis against all twelve, prioritizes the work, helps implement the technical and governance controls, and prepares the evidence each requirement demands.

With free vulnerability assessment and penetration testing to satisfy the testing requirement and surface issues early, and a 10% discount when PCI DSS is pursued alongside SOC 2 or ISO 27001, ISpectra turns a daunting list of requirements into an organized, achievable program that leaves your cardholder data genuinely protected.