The 12 PCI DSS Requirements Explained

The Structure Behind the Standard

PCI DSS is built on a straightforward principle: if your business handles card payment data, you need to protect it properly. To make that manageable, the PCI Security Standards Council organised the standard into six goals and twelve requirements. Each requirement addresses a specific area of security, and together they form a clear framework for keeping cardholder data safe.

The current version, PCI DSS v4.0.1, refines these requirements with an emphasis on continuous security rather than point-in-time compliance. But the core structure — six goals, twelve requirements — has remained consistent since the standard was first published in 2004. Understanding these requirements is essential for any business that needs to comply, and that is every business that handles card data.

Let us walk through each one in plain English.

Goal 1: Build and Maintain a Secure Network and Systems

Requirement 1: Install and Maintain Network Security Controls

This requirement is about controlling the traffic flowing in and out of your network. Traditionally, this meant installing firewalls — and firewalls are still important — but PCI DSS v4.0.1 broadened the language to "network security controls" to cover modern approaches like cloud-native security groups, zero-trust architectures, and software-defined networking.

In practice, this means you need to define which network traffic is allowed and which isn't, document your rules, and review them regularly. If your cardholder data environment (the systems that store, process, or transmit card data) is connected to other networks — including the internet — you need controls at every boundary. Think of it as building walls around the sensitive parts of your network, with carefully controlled doors.

Requirement 2: Apply Secure Configurations to All System Components

When you buy a new router, server, or piece of software, it comes with default settings — including default passwords like "admin" or "password123." Attackers know these defaults, and they exploit them constantly. Requirement 2 says: change them.

But it goes beyond passwords. You need to remove unnecessary services, disable insecure protocols, and configure systems according to industry-accepted hardening standards (such as those from CIS Benchmarks or NIST). Every system component in your cardholder data environment needs to be deliberately configured for security, not left with whatever settings it shipped with.

Goal 2: Protect Account Data

Requirement 3: Protect Stored Account Data

The best way to protect stored card data is to not store it in the first place. Requirement 3 starts from that premise: only store cardholder data if there's a genuine business justification, keep it for the minimum time necessary, and purge it when it's no longer needed.

When you do store card data, it must be rendered unreadable — typically through encryption, truncation, masking, or hashing. The full primary account number (PAN) should never be stored in plain text. And sensitive authentication data — the CVV/CVC code, PIN data, and full magnetic stripe data — must never be stored after authorisation, under any circumstances. This is one of the most common compliance failures, particularly with call recordings that capture spoken card details.

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks

Whenever card data travels across a network that could be intercepted — which includes the internet, wireless networks, and mobile networks — it must be encrypted using strong cryptography. In practice, this typically means using TLS 1.2 or higher for web-based transmissions and ensuring that other transmission channels (like email or messaging) never carry unencrypted card data.

This requirement also applies to internal networks if they're accessible to untrusted parties. The principle is simple: if someone could potentially intercept the data in transit, it needs to be encrypted.

Goal 3: Maintain a Vulnerability Management Programme

Requirement 5: Protect All Systems and Networks from Malicious Software

Malware is one of the most common attack vectors for stealing card data. Requirement 5 mandates anti-malware solutions on all systems commonly affected by malicious software. This includes servers, workstations, and laptops in the cardholder data environment.

Under PCI DSS v4.0.1, the requirement has been updated to address evolving threats. Anti-malware solutions must use active, up-to-date mechanisms — and you need periodic evaluations to determine whether systems not traditionally at risk (like certain Linux servers) need protection too. You also can't let users disable anti-malware unless there's a documented, time-limited, management-approved reason.

Requirement 6: Develop and Maintain Secure Systems and Software

This requirement covers two areas: keeping your systems patched and making sure any custom software you develop is built securely.

For patching, you need a process to identify and address security vulnerabilities promptly. Critical patches should be installed within a defined timeframe (PCI DSS v4.0.1 says within one month of release for critical vulnerabilities). For custom software — whether it's an e-commerce website, an internal application, or an API — you need to follow secure coding practices, conduct code reviews, and address common vulnerabilities like those in the OWASP Top 10.

Goal 4: Implement Strong Access Control Measures

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know

Not everyone in your organisation needs access to card data. Requirement 7 enforces the principle of least privilege: people should only have access to the systems and data they need to do their job. A marketing manager doesn't need access to the payment database. A customer service agent doesn't need admin rights to the payment gateway.

This means defining roles, assigning access rights based on those roles, and regularly reviewing who has access to what. When someone changes role or leaves the organisation, their access should be updated immediately.

Requirement 8: Identify Users and Authenticate Access to System Components

Every person who accesses systems in your cardholder data environment needs a unique user ID. No shared accounts, no generic logins. This ensures that every action can be traced back to a specific individual — critical for both security monitoring and incident investigation.

PCI DSS v4.0.1 significantly strengthened authentication requirements. Multi-factor authentication (MFA) is now required for all access to the cardholder data environment, not just remote access. Passwords must be at least 12 characters (up from 7 in the previous version) and incorporate complexity requirements. Service accounts and application passwords have their own set of controls too.

Requirement 9: Restrict Physical Access to Cardholder Data

Digital security is only half the picture. Requirement 9 addresses physical security — making sure that servers, paper records, workstations, and network equipment handling card data are in secure locations with appropriate access controls.

This includes visitor management (logging who enters secure areas), securing media containing card data (like backup tapes or paper forms), and properly destroying data when it's no longer needed. For many businesses — especially those with contact centres — this means thinking about who can physically see agent screens during payment calls.

Goal 5: Regularly Monitor and Test Networks

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data

When a breach occurs, logs are how you find out what happened, when, and how. Requirement 10 mandates detailed logging of all access to network resources and cardholder data. You need to record who accessed what, when, and from where — and review those logs regularly for anomalies.

PCI DSS v4.0.1 added requirements for automated log review mechanisms. Given the volume of logs modern systems generate, manual review alone isn't sufficient. You need tools that can detect and alert on suspicious patterns, failed access attempts, and other indicators of potential compromise.

Requirement 11: Test Security of Systems and Networks Regularly

Security controls aren't "set and forget." Requirement 11 requires regular testing to make sure your defences actually work. This includes quarterly vulnerability scans by an Approved Scanning Vendor (ASV), annual penetration testing, and wireless access point detection.

Think of it as a health check for your security. You wouldn't assume your locks work without testing them, and the same applies to firewalls, encryption, and access controls. PCI DSS v4.0.1 also introduced requirements for authenticated internal vulnerability scanning, giving you a more thorough view of your security posture.

Goal 6: Maintain an Information Security Policy

Requirement 12: Support Information Security with Organisational Policies and Programmes

The final requirement ties everything together with governance. You need a formal information security policy that's reviewed annually, understood by all staff, and backed by management commitment. This policy should address all aspects of PCI DSS and define responsibilities clearly.

Requirement 12 also covers security awareness training (all personnel must be trained at least annually), incident response planning (you need a documented plan for responding to security breaches), and risk assessment (you must formally assess risks to cardholder data at least annually and after significant changes).

For businesses that use third-party service providers — payment processors, hosting providers, telephone payment solutions — Requirement 12 also requires you to maintain a programme for monitoring those providers' PCI DSS compliance.

How to Approach the Requirements

Twelve requirements can feel overwhelming, but there's a practical approach that makes compliance far more manageable: reduce your scope first. The fewer systems and processes that touch card data, the fewer requirements apply in full force.

For example, if you use a hosted payment page for online transactions and a DTMF masking solution like Paytia for telephone payments, card data never enters your systems. This can reduce your compliance validation from the 326 questions of SAQ D to just 22 questions in SAQ A. We explain this strategy in detail in Guide 5: Descoping Your PCI Environment.

You'll also find that many of these requirements overlap with general good security practice. If you already have decent IT security — patching, access control, logging, employee training — you may be closer to compliance than you think.

Key Takeaways

• PCI DSS has 12 requirements organised under 6 security goals, covering everything from network security to organisational policy
• All 12 requirements apply to every business handling card data, though the specific controls depend on your SAQ type and compliance level
• PCI DSS v4.0.1 introduced significant updates including stronger authentication (12-character passwords, expanded MFA), automated log monitoring, and a focus on continuous compliance
• The most effective strategy is to reduce your scope so that fewer requirements apply in their full complexity — we cover this in Guide 5
• Many requirements align with good security practice you may already be following — compliance isn't about reinventing the wheel
• Never store sensitive authentication data (CVV, PIN, full track data) after authorisation — this is one of the most common and serious violations