PCI DSS | What It Is and How to Comply | IT Governance UK

What is the PCI DSS?

The PCI DSS (Payment Card Industry Data Security Standard) is an information security standard designed to reduce payment card fraud by increasing security controls around cardholder data.

The Standard is a result of a collaboration between the major payment brands and is administered by the PCI SSC (Payment Card Industry Security Standards Council).

The latest iteration of the PCI DSS – version 4.0 – was released at the end of March 2022.

Read the full text of PCI DSS v4.0 on the PCI Security Standards Council website .

Merchants and service providers have a two-year transition period to update their security controls to conform to the new version of the Standard. Version 3.2.1 will be retired on 31 March 2024.

Read the full text of PCI DSS v3.2.1 on the PCI Security Standards Council website .

IT Governance is a PCI QSA (Qualified Security Assessor) company.

View our full range of PCI DSS consultancy services

Who has to comply with the PCI DSS?

All merchants and service providers that process, transmit or store cardholder data must comply with the PCI DSS.

Merchants accept debit or credit card payments for goods or services. Note that the PCI DSS applies to merchants even if they have subcontracted their payment card processing to a third party.

Service providers are directly involved in processing, storing or transmitting cardholder data on behalf of another entity.

Some organisations can be both a merchant and a service provider. For instance, an organisation that provides data processing services for other merchants will also be a merchant if it accepts card payments.

Speak to a PCI DSS expert

Our services can support you at each stage of your organisation’s PCI DSS compliance project. Call our team on +0330 800 7000, or request a call using the form below. Our experts are ready and waiting with practical advice.

Benefits of PCI DSS compliance

Payment security is essential for every organisation that stores, processes or transmits cardholder data.

According to UK Finance’s Fraud the Facts 2019 report , unauthorised financial fraud losses totalled £844.8 million in 2018, a year-on-year increase of 16%.

The Standard provides specific, actionable guidance on protecting payment card data. This guidance can be applied to organisations of any size or type that use any method of processing or storing data.

Penalties for non-compliance with the PCI DSS

The PCI DSS is a standard not a law, and is enforced through contracts between merchants, acquiring banks that process payment card transactions and the payment brands.

Each payment brand can fine acquiring banks for PCI DSS compliance violations. In turn, acquiring banks can withdraw the ability to accept card payments from non-compliant merchants.

Compliance obligations for merchants also increase significantly in the event of a breach.

Moreover, cardholder data breach or theft is also a breach of the EU GDPR (General Data Protection Regulation) . Data breaches risk heavy penalties under the Regulation : up to €20 million or 4% of annual global turnover – whichever is greater.

Learn more about GDPR compliance

The 12 PCI DSS requirements

The PCI DSS specifies 12 requirements that are organised into six control objectives.

PCI DSS requirements:

1. Install and maintain a firewall configuration to protect cardholder data.

Learn more about PCI DSS Requirement 1

Firewalls control data transmission between an organisation’s trusted internal networks and untrusted external networks and traffic between sensitive areas of the internal networks themselves. Systems must use firewalls to prevent unauthorised access. Where other system components provide a firewall's functionality, they must also be included in the scope and assessment of this requirement.

2. Do not use vendor-supplied defaults for system passwords and other security parameters.

Learn more about PCI DSS Requirement 2

The default settings of many commonly used systems are well known, easily exploitable and often used by criminal hackers to compromise them. Vendor-supplied default settings must. Therefore, vendor-supplied default settings must be changed, and unnecessary default accounts disabled or removed before any system is installed on a network. This applies to all default passwords, without exception. If firewalls are correctly implemented according to Requirement 1, they should also comply with Requirement 2.

The storage of cardholder data should be kept to a minimum, and appropriate data retention and disposal policies, procedures and processes should be implemented.

Certain data – such as the full contents of the chip or magnetic strip, the CVN (card verification number) or the PIN (personal identification number) – should never be stored. When data is stored, it should be stored securely.

Encryption, truncation, masking and hashing are critical components of cardholder data protection. Without access to the proper cryptographic keys, encrypted data will be unreadable and unusable by criminal hackers, even if they manage to circumvent other security controls.

Cryptographic keys should therefore be stored securely and access restricted to the fewest custodians necessary. Other data protection methods should also be considered.

4. Encrypt transmission of cardholder data across open, public networks.

Learn more about PCI DSS Requirement 4

Strong cryptography and security protocols (e.g. TLS, IPSec, SSH, etc.) should be used to safeguard sensitive cardholder data during transmission over open, public networks that malicious individuals could easily access.

Examples of open, public networks include the Internet, wireless technologies (e.g. Bluetooth), GPRS (general packet radio service) and satellite communications. Industry best practices must be followed to implement strong encryption for authentication and transmission.

Security policies and procedures for encrypting cardholder data transmission must be documented and made known to all affected parties.

5. Use and regularly update anti-virus software or programs.

Learn more about PCI DSS Requirement 5

Antivirus software capable of detecting, removing and protecting against all known malware types (e.g. viruses, worms and Trojans) must be used on all systems commonly affected by malware , to protect them from threats. For systems not commonly affected by malware, evolving malware threats should be periodically evaluated to determine if antivirus software is needed. Antivirus mechanisms must be maintained and kept actively running. They should only be disabled if formally authorised for a specific purpose.

6. Develop and maintain secure systems and applications.

Learn more about PCI DSS Requirement 6

Patches issued by software vendors fix many security vulnerabilities. Organisations should establish a process to identify security vulnerabilities and rank them according to their level of risk. Relevant security patches should be installed within a month of their release to protect against cardholder data compromise.

Whether developed internally or externally, all software applications should be developed securely in accordance with the PCI DSS. They should also be based on industry standards and/or best practices and incorporate information security throughout their development life cycle.

7. Restrict access to cardholder data by business need-to-know.

Learn more about PCI DSS Requirement 7

Exploiting authorised accounts and abusing user privileges is one of the easiest ways for criminal hackers to access a system. It is also one of the most difficult types of attack to detect.

Therefore, documented systems and processes should be put in place to limit access rights to critical data. Access control systems should deny all access by default. Access should be granted on a need-to-know basis and according to authorised personnel's clearly defined job responsibilities. ‘Need to know’ is defined in the PCI DSS as “when access rights are granted to only the least amount [sic] of data and privileges needed to perform a job”.

8. Assign a unique ID to each person with computer access.

Learn more about PCI DSS Requirement 8

The ability to identify individual users not only ensures that system access is limited to those with the proper authorisation, and it also establishes an audit trail that can be analysed following an incident.

Therefore, documented policies and procedures must be implemented to ensure proper user identification management for non-consumer users and administrators on all system components. All users must be assigned a unique ID, which must be managed according to specific guidelines.

Controlled user-authentication management (e.g. the use of passwords, smart cards or biometrics) should also be implemented and 2FA (two-factor authentication) must be used for remote network access.

9. Restrict physical access to cardholder data.

Learn more about PCI DSS Requirement 9

Electronic data breaches are not the only source of data loss; physical access to systems should also be limited and monitored using appropriate controls.

Procedures should be implemented to distinguish between on-site personnel and visitors. Physical access to sensitive areas (e.g. server rooms and data centres) should be restricted accordingly.

All media should be physically secured, and its storage, access and distribution controlled. Media should be destroyed in specific ways when no longer required.

Devices that capture payment card data via direct physical interaction with the card must be protected from tampering and substitution should be periodically inspected. An up-to-date list of these devices should be maintained.

10. Track and monitor all access to network resources and cardholder data.

Learn more about PCI DSS Requirement 10

The use of logging mechanisms is critical in preventing, detecting and minimising the impact of data compromise. If system usage is not logged, potential breaches cannot be identified.

Therefore, secure, controlled audit trails must be implemented that link all access to system components with individual users and log their actions. This includes:

Access to cardholder data

Actions taken by individuals with root or administrative privileges

Access to audit trails

Invalid logical access attempts

Use of and changes to identification and authentication mechanisms

The initialising, stopping or pausing of audit logs

The creation and deletion of system-level objects.

An audit trail history should be retained for at least a year, with a minimum of three months’ logs immediately available for analysis. Logs and security events should be regularly reviewed to identify anomalous or suspicious activity.

11. Regularly test security systems and processes.

Learn more about PCI DSS Requirement 11

New vulnerabilities are regularly found and exploited, so it is essential that system components, processes and custom software are regularly tested.

Documented processes must be implemented to detect and identify all unauthorised wireless access points every quarter. Internal and external network vulnerability scans must be performed by qualified personnel at least quarterly and after any significant network changes (e.g. new system component installations, changes in network topology, firewall rule modifications and product upgrades).

Intrusion detection/prevention techniques should be used to identify and/or prevent unauthorised network activity,. A change detection mechanism should be employed to perform weekly critical file comparisons, and alert personnel to unauthorised system modifications.

12. Maintain a policy that addresses information security for employees and contractors

Learn more about PCI DSS Requirement 12

To comply with the PCI DSS, organisations must establish, publish, maintain and disseminate a security policy, which must be reviewed annually and updated according to the changing risk environment. A risk assessment process must be implemented to identify threats and vulnerabilities, usage policies for critical technologies must be developed, security responsibilities for all personnel must be clearly defined, and a formal awareness programme must be implemented. Organisations must also implement an incident response plan so that they can respond immediately to any system breach.

How to become PCI DSS compliant

Merchants and service providers can show they meet PCI DSS requirements by doing an audit of their CDE (cardholder data environment) against the Standard's applicable requirements.

The types of audit are:

An RoC (Report on Compliance) completed by a PCI QSA organisation such as IT Governance or by an ISA (Internal Security Assessor).

An SAQ (self-assessment questionnaire) signed by an officer of the organisation. There are nine types of SAQ designed to meet different types of merchant and service provider's requirements. These are listed below.

An external vulnerability scan conducted by an ASV (Approved Scanning Vendor) .

The type of audit you must undergo, and your exact PCI compliance requirements will vary depending on your merchant or service provider level. This level is based on the number of card transactions processed per year.

Generally, the criteria applied will be based on those set by Visa and Mastercard, the predominant payment card brands.

PCI DSS: merchant validation criteria

RoC conducted by a QSA or ISA, or an SAQ (SAQ D) signed by a company officer (dependent on payment brand).

Quarterly scan by an ASV.

RoC conducted by a QSA or ISA, or an SAQ (SAQ D) signed by a company officer (dependent on payment brand).

Quarterly scan by an ASV.

Level-1 organisations

Level-1 organisations must have an external audit performed annually by a QSA and submit an RoC to their acquiring banks to prove their compliance.

The QSA will:

Validate the scope of the assessment;

Review all documentation and technical information provided;

Determine whether the Standard has been met;

Provide support and guidance during the compliance process;

Be onsite for the duration of the assessment as required;

Adhere to the PCI DSS assessment procedures;

Evaluate compensating controls; and

Produce the final RoC.

Free green paper: PCI DSS Audits – Preparing for success

Download this paper to better understand the PCI DSS audit process and learn about our step-by-step approach to preparing for audit success.

Download now

Learn more about PCI SAQs in our free paper

This paper provides an overview of the benefits of PCI DSS compliance, how to reduce your compliance scope, and how to choose the right SAQ under PCI DSS v4.0.

Download now

Assessing the security of your cardholder data

Many organisations use a three-step process to achieve PCI DSS compliance:

PCI DSS Gap Analysis – typically the first step for understanding an organisation’s compliance status. It compares the Standard’s requirements with the organisation’s current arrangements, identifies any compliance gaps and produces a prioritised plan to achieve full PCI DSS compliance.

PCI DSS Remediation – actioning the plan based on the gap analysis to reduce the project's scope where possible and close any remaining compliance gaps.

PCI DSS Audit – having finished implementing the action plan, an assessor will review your CDE and controls to ensure and record proof that you are PCI DSS-compliant.

Watch our free introductory webinar to the PCI DSS

For further information and a better understanding of the PCI DSS, why not listen to our free webinar? You will get expert advice from one of our QSAs, who will explain how the PCI DSS applies to your organisation.

The webinar covers:

What the PCI DSS is;

An introduction to the 12 requirements;

How to define your PCI DSS compliance level;

Your PCI validation requirements;

Why it is important to comply; and

The penalties for non-compliance.

Watch now

Discover our range of bestselling PCI DSS products and services

As a QSA company, IT Governance provides services to support you at each stage of your organisation’s PCI DSS compliance project.

We can help with reducing your CDE scope, conducting a gap analysis or risk assessment, and testing your systems and processes for security vulnerabilities.

View our range of bestselling products and services to find out how we can help you become PCI compliant today.

Free
resources

Resource hub Cyber security resources Data privacy resources ISO 27001 resources IT Governance blog Email preference centre Security Spotlight newsletter

Corporate
Information

COVID-19 About us Affiliate programme Become an IT Governance partner Careers - Join our team Clients Events Press releases

Delivery, returns
and payment

Adobe e-book FAQs Fulfilment FAQs Payment options Purchase store credit Returns Shipping View all FAQs

Customer
service

Contact us Leave a review Apply for a corporate account CyberComply portal GRC eLearning platform DocumentKits platform Cyber Essentials FAQs E-learning FAQs Training FAQs

Terms and
conditions

Acceptable use policy Cookie policy Customer Care Policy Environment and Sustainability Policy GRC International Group PLC End-User Software Agreement Terms for buying goods and services Terms and conditions of website use Promotion terms and conditions Privacy notice