12 Key Requirements to Achieve PCI DSS Compliance

The Payment Card Industry Data Security Standard (PCI DSS) is a global security standard maintained by the Payment Card Industry Security Standards Council (PCI SSC) to protect payment card data. It applies to all organisations that store, process or transmit payment card data, including merchants, financial institutions and service providers.

The standard was first introduced in 2004 to address rising concerns about payment card data security. Since then, it has undergone multiple updates to keep pace with technological advancements and evolving threats. Revisions have refined existing measures and, in some cases, introduced new requirements to strengthen data protection.

• PCI DSS v1.0 (2004): The first version provided basic security requirements for cardholder data protection.
• PCI DSS v2.0 (2010): Introduced more detailed guidelines, clarifying specific requirements and strengthening the overall framework.
• PCI DSS v3.0 (2013): Focused on reducing vulnerabilities and aligning with new industry practices. This version also encouraged businesses to take a more proactive approach to security.
• PCI DSS v3.2.1 (2018): A minor revision that updated references to passed implementation dates and made other clarifications, without adding new requirements.
• PCI DSS v4.0 (2022): The latest major revision, which introduced a customised approach to meeting security objectives, allowing businesses more flexibility to tailor security measures to their specific environments. This version also expanded the scope of security measures and included stronger encryption and validation requirements.
• PCI DSS v4.0.1 (June 2024): A limited revision that clarified existing requirements without adding or removing requirements.

PCI DSS v3.2.1 retired on 31 March 2024 and v4.0 retired on 31 December 2024. PCI DSS v4.0.1 is the current version. All applicable future-dated requirements became mandatory on 31 March 2025 (PCI SSC, 2024).

UK Finance reported £423.5 million in remote purchase, or card-not-present, fraud losses in 2025, up 3% on 2024 (UK Finance, 2026).

Visa and Mastercard use four merchant validation levels, based mainly on annual transaction volumes. The examples below follow Mastercard’s categories, using combined Mastercard and Maestro transactions. Businesses should confirm their level and validation requirements with their acquiring bank:

• Level 1: For businesses processing over 6 million transactions annually or assigned to Level 1 by the card scheme. It requires an annual PCI DSS assessment resulting in a Report on Compliance (ROC). Assessor arrangements must meet the applicable scheme rules.
• Level 2: For businesses processing more than 1 million and up to 6 million transactions annually. Annual validation normally uses a self-assessment questionnaire (SAQ). Mastercard requires a PCI SSC-approved Qualified Security Assessor (QSA) or PCI SSC-certified Internal Security Assessor (ISA) for SAQ A, A-EP or D.
• Level 3: For businesses processing more than 20,000 and up to 1 million e-commerce transactions annually. Validation requirements are confirmed by the acquiring bank and may include an annual SAQ.
• Level 4: For all other merchants. Businesses must comply with applicable PCI DSS requirements; their acquiring bank confirms the validation requirements, which may include an annual SAQ.

Merchant levels primarily determine how compliance is validated. The applicable security requirements and SAQ depend on the payment environment. Small businesses are not automatically exempt, and outsourcing payment processing can reduce scope but does not remove all PCI DSS responsibilities.

Where Requirement 11.3.2 applies, external vulnerability scans by an Approved Scanning Vendor (ASV) must pass at least once every three months. This includes SAQ A merchants whose websites redirect customers to a payment provider or embed its payment form, even where payment processing is fully outsourced.

To achieve PCI DSS compliance, businesses must fulfil the applicable controls within 12 essential requirements designed to protect payment card data during every stage of the transaction process.

Establishing robust network security controls, such as firewalls, is the first line of defence against unauthorised access to cardholder data.

Think of these controls as barriers between trusted internal networks and untrusted external networks. They filter traffic based on pre-set security rules. To ensure effectiveness, regularly update and configure these controls so that only legitimate traffic is allowed.

Default settings and passwords provided by vendors are common knowledge and can be exploited by attackers.

Avoid this risk by changing all default passwords and applying secure configurations to your hardware and software. This includes disabling unnecessary services and features.

Use strong encryption methods to ensure that data remains unreadable if accessed without authorisation. Merchants must not retain sensitive authentication data, such as CVV/CVC values, full track data or PIN/PIN blocks, after authorisation, even if encrypted.

Additionally, mask primary account numbers (PANs) when displayed. Reveal only the last few digits to minimise exposure risks.

Transmitting cardholder data over open or public networks exposes it to interception.

Implement strong cryptographic protocols to encrypt the data during transmission. This ensures that even if data is intercepted, it cannot be read by unauthorised parties.

Regularly review and update your encryption methods to align with the latest industry standards.

Malware is a significant threat to systems handling cardholder data.

Protect your systems by deploying and updating anti-virus and anti-malware solutions. Regular scans and real-time protection can help you detect and mitigate malicious software before it causes any damage.

Processes and automated tools must also detect and protect personnel against phishing attacks (Requirement 5.4.1).

Regularly updating your systems and applications is vital to protect against known vulnerabilities.

Establish a process for the timely installation of security patches. Install patches for vulnerabilities ranked critical or high within one month of release. Also, prioritise secure coding practices when developing applications to minimise the risk of introducing vulnerabilities into your systems.

For in-scope public-facing web applications, use an automated solution to detect and prevent web attacks. Where payment-page script controls apply, authorise each script, check its integrity and maintain an inventory explaining why it is needed (Requirements 6.4.2 and 6.4.3).

Not everyone in your organisation needs access to cardholder data.

Limit access based on job roles. Follow the principle of least privilege and give employees access to the bare minimum data they need to perform their duties.

Assigning unique identification to each user ensures accountability and traceability.

Implement multi-factor authentication (MFA) for non-console access into the cardholder data environment (CDE), subject to the standard’s stated exceptions and permitted alternatives (Requirement 8.4.2).

Don’t overlook the importance of physical security. Restrict access to systems and devices that store or process cardholder data to prevent unauthorised individuals from gaining access. Implement access controls, monitor entry points and secure sensitive areas to safeguard cardholder information physically.

Keeping detailed logs of all access to system components and cardholder data is crucial for detecting and responding to security incidents.

Review logs for security events, systems handling card data, critical systems and systems performing security functions at least daily using automated tools. Investigate suspicious activity promptly (Requirements 10.4.1 and 10.4.1.1).

Regular testing of your security systems helps identify and address potential vulnerabilities.

Where applicable, conduct internal and external vulnerability scans at least every three months and after significant changes. Perform internal and external penetration testing at least annually and after significant infrastructure or application changes.

Where applicable, use a mechanism to detect unauthorised changes to payment pages as received by customers’ browsers (Requirement 11.6.1).

The January 2025 revision of SAQ A removed its direct assessment questions on payment-page scripts and tamper detection. The underlying requirements remain in PCI DSS.

SAQ A merchants using embedded payment forms must confirm their site is not susceptible to relevant script attacks. This can involve suitable controls or confirmation from their PCI DSS-compliant payment provider that its correctly implemented solution protects the page from script attacks.

A strong organisational policy is the backbone of any effective security programme.

Develop and maintain a comprehensive policy that serves as a framework for implementing and managing security measures.

Provide security awareness training on joining and at least every 12 months, including phishing and social engineering. Review the awareness programme at least annually and update it for relevant new threats.

While technical measures are essential, staff training is equally crucial for PCI DSS compliance. Employees must understand security best practices and their role in preventing data breaches and fraud.

Our online PCI DSS Training equips staff with the knowledge to identify risks and securely handle cardholder data, both in-person and remotely. The training course helps equip staff to maintain compliance and protect sensitive information.

Online awareness training cannot establish PCI DSS compliance by itself or replace the required technical controls and assessments.