The Payment Card Industry Data Security Standard (PCI DSS) is a set of security requirements designed to protect cardholder data wherever it is stored, processed, or transmitted. Developed and maintained by the PCI Security Standards Council — founded by American Express, Discover, JCB, Mastercard, and Visa — the standard applies to every organisation that handles payment card information, regardless of size or transaction volume.
PCI DSS is structured around 12 core requirements, grouped under six overarching goals. Together, these requirements establish a baseline for securing payment systems, from network architecture and data encryption through to access control, monitoring, and organisational policy. Version 4.0, released in March 2022, is now the only active version of the standard. The transition period from v3.2.1 concluded on 31 March 2024, and the future-dated requirements within v4.0 became mandatory on 31 March 2025. Organisations must now demonstrate compliance with every v4.0 requirement.
This guide walks through each of the 12 requirements in practical terms — what they demand, why they matter, and what organisations typically need to do to satisfy them.
Goal 1: Build and Maintain a Secure Network and Systems
The first goal addresses the foundational infrastructure that surrounds cardholder data. Network security is the outer perimeter of any payment environment, and weaknesses here undermine every other control.
Requirement 1: Install and Maintain Network Security Controls
Requirement 1 focuses on the controls that regulate traffic between trusted and untrusted networks. In earlier versions of the standard, this requirement referred specifically to firewalls and routers. Version 4.0 broadened the language to “network security controls” to account for modern architectures that include cloud-native firewalls, software-defined networking, micro-segmentation, zero-trust network access, and containerised environments.
Organisations must define and document all connections between the cardholder data environment (CDE) and other networks, including internal segments, partner connections, wireless networks, and the public internet. Every inbound and outbound traffic flow must be explicitly authorised, documented, and reviewed at least every six months to confirm that rules remain necessary and correctly scoped.
Network security controls must be placed at every boundary of the CDE. Inbound traffic from untrusted networks must be restricted to only what is necessary, and direct public access to systems that store cardholder data is prohibited. Where network segmentation is used to reduce PCI DSS scope — a common and recommended approach — the segmentation controls themselves must be tested to confirm they are effective at isolating the CDE.
Practical implementation: Maintain a current network diagram that shows all data flows into and out of the CDE. Automate firewall rule reviews where possible. If your environment uses cloud infrastructure, ensure that security groups, network ACLs, and virtual network configurations are governed by the same change-control processes as traditional firewalls.
Requirement 2: Apply Secure Configurations to All System Components
Requirement 2 addresses the risk posed by default configurations, factory passwords, and unnecessary services. Attackers routinely exploit systems left in their out-of-box state, and default credentials for common platforms are widely known and catalogued.
Organisations must change all vendor-supplied default passwords and remove or disable unnecessary default accounts before deploying any system component into the CDE. This applies to operating systems, databases, applications, network devices, point-of-sale terminals, and any other technology that touches cardholder data.
Beyond defaults, Requirement 2 mandates the development and application of configuration standards for all system components. These standards must address known security vulnerabilities, disable unnecessary services and protocols, and configure system security parameters to prevent misuse. Configuration standards should be based on industry-accepted hardening guides — such as those published by CIS Benchmarks, DISA STIGs, or vendor-specific security guides — and tailored to the organisation’s environment.
Only one primary function should be implemented per server to prevent functions that require different security levels from coexisting on the same system. Where virtualisation or containerisation is used, this principle still applies at the logical level.
Practical implementation: Build and maintain hardened base images (golden images) for every operating system and platform in the CDE. Use configuration management tools — Ansible, Chef, Puppet, or similar — to enforce standards consistently and detect drift. Scan for default credentials as part of deployment pipelines.
Goal 2: Protect Account Data
The second goal deals directly with the data that PCI DSS exists to protect: primary account numbers (PANs), cardholder names, expiration dates, service codes, and sensitive authentication data.
Requirement 3: Protect Stored Account Data
Requirement 3 is one of the most technically demanding areas of the standard. Its central principle is straightforward: if you do not need to store cardholder data, do not store it. If you must store it, protect it with strong cryptography and limit retention to the minimum duration required by business, legal, or regulatory need.
Sensitive authentication data — including full track data, card verification codes (CVV2/CVC2), and PINs or PIN blocks — must never be stored after authorisation, even in encrypted form. This prohibition is absolute and applies regardless of the encryption method used.
For stored PANs, the data must be rendered unreadable wherever it is stored. Acceptable methods include one-way cryptographic hashes (with a keyed input), truncation, index tokens (with the pads stored separately), and strong cryptography with associated key-management processes. When encryption is used, the key-management practices themselves become critical — keys must be generated, distributed, stored, rotated, and destroyed according to documented procedures, and access to cryptographic keys must be restricted to the fewest number of custodians necessary.
Version 4.0 introduced a requirement for organisations to perform a documented inventory of all locations where account data is stored, including previously unknown or legacy locations. Data discovery scans must be performed at least every twelve months to identify any unintended data retention.
Practical implementation: Conduct a thorough data discovery exercise to map every location where PANs exist — databases, log files, email archives, spreadsheets, backups, and test environments. Implement tokenisation at the point of capture to reduce the number of systems in scope. Define and enforce retention policies with automated deletion schedules.
Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks
Requirement 4 requires that cardholder data be encrypted whenever it traverses networks that are not fully under the organisation’s control. This includes the public internet, wireless networks, cellular technologies, satellite communications, and any network segment where interception is possible.
Strong cryptographic protocols must be used — currently TLS 1.2 or higher — and weak protocols, cipher suites, and configurations must be disabled. Organisations must maintain an inventory of trusted keys and certificates, ensuring that certificates are valid, not expired, and issued by trusted certificate authorities.
PAN must never be sent via end-user messaging technologies such as email, instant messaging, SMS, or chat unless it is rendered unreadable prior to transmission using strong cryptography.
Practical implementation: Enforce TLS 1.2 or 1.3 on all connections that carry cardholder data. Disable support for SSL, TLS 1.0, and TLS 1.1 entirely. Implement certificate monitoring to catch expirations before they cause outages or force fallback to insecure protocols. Use automated scanning to detect PANs in email and messaging systems.
Goal 3: Maintain a Vulnerability Management Programme
The third goal recognises that threats evolve continuously and that systems must be actively defended against malware and vulnerabilities.
Requirement 5: Protect All Systems and Networks from Malicious Software
Requirement 5 mandates the deployment of anti-malware mechanisms on all systems commonly affected by malicious software. This includes workstations, servers, and any system component in the CDE that is susceptible to malware infection.
Anti-malware solutions must be kept current with the latest signatures or behavioural detection capabilities, perform periodic scans and active real-time monitoring, generate audit logs, and be protected from being disabled or altered by users — unless specifically authorised by management on a case-by-case basis with a defined time limit.
Version 4.0 added a specific requirement to detect and protect against phishing attacks. Organisations must implement automated mechanisms — such as email filtering, anti-phishing tooling, link scanning, and domain-based authentication (DMARC, DKIM, SPF) — to identify and block phishing attempts before they reach users.
For systems that are not commonly affected by malware (such as certain mainframes or specialised embedded systems), organisations must perform a periodic evaluation — at least every twelve months — to confirm that the system remains not at risk and that anti-malware protection continues to be unnecessary.
Practical implementation: Deploy endpoint detection and response (EDR) solutions rather than relying solely on traditional signature-based antivirus. Implement email security gateways with phishing detection, URL rewriting, and attachment sandboxing. Document exceptions for systems not running anti-malware and review those exceptions annually.
Requirement 6: Develop and Maintain Secure Systems and Software
Requirement 6 covers two broad areas: keeping systems patched against known vulnerabilities and ensuring that custom software is developed securely from the outset.
All system components must be protected from known vulnerabilities by installing applicable security patches. Critical and high-severity patches — those scored 7.0 or above on the Common Vulnerability Scoring System (CVSS) or identified through the organisation’s own risk-ranking process — must be installed within one month of release. Organisations must maintain a process for identifying, ranking, and addressing vulnerabilities in all system components.
For custom and bespoke software — whether developed in-house or by a third party — Requirement 6 mandates a secure software development lifecycle (SSDLC). This includes training developers in secure coding practices at least once every twelve months, reviewing custom code prior to release using either manual code review or automated static and dynamic analysis tools, and addressing common software vulnerabilities such as injection flaws, broken authentication, cross-site scripting, insecure direct object references, and other risks catalogued in resources like the OWASP Top 10.
Public-facing web applications must be protected against known attacks, either through regular vulnerability assessments and patching or by deploying a web application firewall (WAF) in front of the application.
Practical implementation: Integrate vulnerability scanning into CI/CD pipelines. Maintain a patch-management programme with defined SLAs tied to CVSS severity. Require security-focused code reviews as a gate in the pull request process. Deploy a WAF for all public-facing web applications and review its ruleset regularly.
Goal 4: Implement Strong Access Control Measures
The fourth goal addresses who can access cardholder data and the systems that process it, and how their identity is verified.
Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know
Requirement 7 establishes the principle of least privilege. Access to cardholder data and the systems within the CDE must be limited to individuals whose job functions require that access. All other access must be denied by default.
Organisations must define access needs for each role, implement an access control system that restricts access based on those defined roles, and ensure that the access control system is set to “deny all” unless specifically allowed. Access control lists and permissions must be reviewed at least every six months to confirm they remain appropriate.
Practical implementation: Implement role-based access control (RBAC) with clearly documented role definitions. Automate access reviews using identity governance tools. Ensure that access provisioning follows a formal approval workflow and that role changes trigger immediate access adjustments.
Requirement 8: Identify Users and Authenticate Access to System Components
Requirement 8 requires that every individual with access to the CDE be assigned a unique identification, ensuring that actions on critical data and systems can be traced to a known user. Shared, group, or generic accounts are prohibited for administrative access, and their use is heavily restricted for all other access types.
Authentication must use at least one of the standard factors — something you know, something you have, or something you are. Version 4.0 significantly strengthened multi-factor authentication (MFA) requirements. MFA is now required for all access into the CDE — not just remote access, as was the case under v3.2.1. This applies to administrative access, console access, and any interactive login to systems within the CDE.
Password and passphrase requirements have also been updated. Passwords must be at least twelve characters in length (or eight characters if the system does not support twelve). They must contain both numeric and alphabetic characters. Passwords must be changed if there is any suspicion of compromise, and users must not be able to reuse any of the last four passwords.
Service accounts and application accounts used for automated access must also be managed — their credentials must be changed periodically, their permissions must follow least privilege, and interactive login must be disabled where feasible.
Practical implementation: Deploy an MFA solution that covers all CDE access paths — VPN, SSH, RDP, web consoles, and application logins. Integrate with a centralised identity provider (IdP) that enforces password policies. Implement privileged access management (PAM) for administrative and service accounts. Maintain an inventory of all service accounts with documented owners.
Requirement 9: Restrict Physical Access to Cardholder Data
Requirement 9 addresses the physical security of facilities that house systems containing cardholder data. Physical access controls must prevent unauthorised individuals from reaching systems, data stores, and network components within the CDE.
Entry to sensitive areas must be controlled using physical access mechanisms — badge readers, biometric scanners, locked doors, or monitored entry points. Visitors must be authorised before entry, given a visible badge or identification, logged on arrival and departure, and escorted at all times within areas where cardholder data is accessible.
Media containing cardholder data — including paper records, removable drives, and backup tapes — must be physically secured, classified, inventoried, and destroyed when no longer needed using methods that render the data unrecoverable (cross-cut shredding, degaussing, or secure destruction services).
Point-of-interaction (POI) devices, such as payment terminals, must be protected against tampering and substitution. Organisations must maintain an inventory of all POI devices, including make, model, serial number, and location, and must train personnel to detect evidence of tampering or replacement.
Practical implementation: Conduct physical security assessments of all facilities housing CDE components. Deploy CCTV at entry points and within sensitive areas, retaining footage for at least 90 days. Implement visitor management systems that integrate with physical access logs. Establish a media destruction policy with documented chain-of-custody procedures.
Goal 5: Regularly Monitor and Test Networks
The fifth goal requires organisations to maintain ongoing visibility into the security of their systems and to validate that controls are functioning as intended.
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data
Requirement 10 requires comprehensive logging of all user activity, administrative actions, and system events within the CDE. Logging mechanisms must record enough detail to support after-the-fact investigation of security incidents — including who performed the action, what they did, when they did it, and whether they succeeded or failed.
Audit logs must capture, at minimum: all individual user access to cardholder data, all actions taken by anyone with root or administrative privileges, access to all audit trails, invalid logical access attempts, use of identification and authentication mechanisms, initialisation, stopping, or pausing of audit logs, and creation and deletion of system-level objects.
Time synchronisation is a specific sub-requirement — all system clocks must be synchronised to an authoritative time source using NTP or a similar protocol to ensure that log entries from different systems can be correlated accurately.
Audit logs must be reviewed at least daily, either manually or using automated log monitoring tools, to identify anomalies or suspicious activity. Version 4.0 emphasised the use of automated mechanisms for log review and the detection of security events, recognising that the volume of log data in modern environments makes purely manual review impractical.
Logs must be protected against tampering and retained for at least twelve months, with at least the most recent three months immediately available for analysis.
Practical implementation: Deploy a centralised log management or SIEM platform that aggregates logs from all CDE components. Configure automated alerting for known indicators of compromise, privilege escalation, and policy violations. Implement write-once log storage or tamper-evident logging to protect audit trail integrity.
Requirement 11: Test Security of Systems and Networks Regularly
Requirement 11 mandates ongoing testing to confirm that security controls, processes, and configurations remain effective as the environment changes over time.
Wireless access points must be detected and identified quarterly, regardless of whether the organisation intentionally uses wireless technology within the CDE. Rogue wireless devices represent a common attack vector.
Internal vulnerability scans must be performed at least quarterly and after any significant change to the environment. Under v4.0, these scans must be authenticated — meaning the scanner logs into systems to evaluate configurations and patch levels, rather than relying solely on external network-based assessment. Vulnerabilities scored 4.0 or above on CVSS must be resolved and rescanned.
External vulnerability scans must be performed quarterly by an Approved Scanning Vendor (ASV), and the organisation must achieve a passing scan. Identified vulnerabilities must be resolved and the scan repeated until a passing result is obtained.
Penetration testing must be performed at least annually and after any significant infrastructure or application changes. Penetration tests must cover both network-layer and application-layer testing from both inside and outside the network. If network segmentation is used to reduce scope, the effectiveness of the segmentation must be validated through penetration testing at least every six months for service providers and annually for merchants.
Version 4.0 also introduced a requirement for change-detection mechanisms (such as file-integrity monitoring) on payment pages to alert on unauthorised modifications — a direct response to web-skimming attacks like Magecart.
Practical implementation: Engage a qualified penetration testing firm for annual assessments. Automate internal vulnerability scanning with authenticated agents. Deploy file-integrity monitoring on all payment-related web pages and critical system files. Contract with an ASV for quarterly external scans.
Goal 6: Maintain an Information Security Policy
The sixth goal addresses governance — the organisational policies, processes, and human factors that tie all technical controls together.
Requirement 12: Support Information Security with Organisational Policies and Programmes
Requirement 12 requires organisations to maintain a comprehensive information security policy that addresses all PCI DSS requirements and is reviewed at least annually and updated as the environment changes.
The policy must define information security responsibilities for all personnel. A specific individual or team must be formally assigned overall accountability for information security, and security responsibilities must be documented for all roles that interact with cardholder data or CDE systems.
Risk assessments must be performed at least annually and upon significant changes to the environment. The risk assessment process must identify critical assets, threats, and vulnerabilities, and result in a formal risk analysis that informs the organisation’s security posture.
Security awareness training must be provided to all personnel upon hire and at least annually thereafter. Training must cover the organisation’s information security policy, acceptable use of technologies, social engineering threats (including phishing), and each individual’s specific responsibilities for protecting cardholder data.
Organisations must also maintain an incident response plan that addresses roles, communication protocols, notification requirements (including those of relevant payment brands), containment and recovery procedures, and lessons learned from previous incidents. The incident response plan must be tested at least annually.
Service provider management is another significant component of Requirement 12. Organisations must maintain a list of all third-party service providers with whom cardholder data is shared or who could affect the security of the CDE. Written agreements must acknowledge the provider’s responsibility for the data, and the compliance status of each provider must be monitored at least annually.
Practical implementation: Appoint a Chief Information Security Officer (CISO) or equivalent with clear accountability. Conduct formal risk assessments using a recognised methodology (NIST, ISO 27005, FAIR). Run tabletop incident response exercises annually. Maintain a service provider register with documented agreements and compliance evidence.
PCI DSS v4.0: New and Future-Dated Requirements
PCI DSS v4.0 introduced 64 new requirements compared to v3.2.1. Of these, 13 took effect immediately upon the retirement of v3.2.1 on 31 March 2024, while the remaining 51 were classified as “future-dated” — giving organisations until 31 March 2025 to implement them. That deadline has now passed, and all v4.0 requirements are fully enforceable.
Key changes that organisations should have addressed include:
- Targeted risk analysis — Organisations may now use a targeted risk analysis to determine the frequency of certain periodic activities (such as log reviews, password changes, and rule-set reviews), rather than adhering to rigid time-based schedules. However, the analysis must be documented, justified, and reviewed annually.
- Customised approach — v4.0 introduced the “customised approach” as a formal alternative to the traditional “defined approach.” The customised approach allows organisations to meet the objective of a requirement using controls that differ from the stated testing procedures, provided the control’s effectiveness is validated through a rigorous, assessor-reviewed analysis. This replaces and formalises the concept of compensating controls for applicable requirements.
- Enhanced authentication — MFA is now required for all access into the CDE, not just remote access. Password length has increased to a minimum of twelve characters.
- Anti-phishing controls — Automated mechanisms to detect and protect personnel against phishing attacks are now mandatory.
- Payment page integrity — Mechanisms must detect and alert on unauthorised changes to HTTP headers and payment page content, defending against web-skimming attacks.
- Authenticated vulnerability scanning — Internal vulnerability scans must be performed with credentials to achieve deeper visibility.
- Encryption of sensitive authentication data (SAD) prior to authorisation — Where SAD is stored prior to completion of authorisation, it must be encrypted using strong cryptography.
- Service provider responsibility acknowledgement — Service providers must formally acknowledge, in writing, their responsibilities for protecting cardholder data.
Summary Table: All 12 PCI DSS Requirements
| Requirement | Title | Goal |
|---|---|---|
| 1 | Install and Maintain Network Security Controls | Build and Maintain a Secure Network and Systems |
| 2 | Apply Secure Configurations to All System Components | Build and Maintain a Secure Network and Systems |
| 3 | Protect Stored Account Data | Protect Account Data |
| 4 | Protect Cardholder Data with Strong Cryptography During Transmission | Protect Account Data |
| 5 | Protect All Systems and Networks from Malicious Software | Maintain a Vulnerability Management Programme |
| 6 | Develop and Maintain Secure Systems and Software | Maintain a Vulnerability Management Programme |
| 7 | Restrict Access to System Components and Cardholder Data by Business Need to Know | Implement Strong Access Control Measures |
| 8 | Identify Users and Authenticate Access to System Components | Implement Strong Access Control Measures |
| 9 | Restrict Physical Access to Cardholder Data | Implement Strong Access Control Measures |
| 10 | Log and Monitor All Access to System Components and Cardholder Data | Regularly Monitor and Test Networks |
| 11 | Test Security of Systems and Networks Regularly | Regularly Monitor and Test Networks |
| 12 | Support Information Security with Organisational Policies and Programmes | Maintain an Information Security Policy |
Achieving and maintaining PCI DSS compliance is not a one-time exercise. The standard is designed to establish an ongoing security programme — one that evolves as threats, technologies, and business operations change. Organisations that treat the 12 requirements as a living framework rather than an annual checkbox exercise will find themselves better protected against payment card fraud and better positioned to demonstrate that protection to customers, partners, and acquirers.