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 results from a collaboration between the major payment brands (American Express, Discover, JCB, Mastercard and Visa). It 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 are entities that 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 businesses directly involved in processing, storing or transmitting cardholder data on behalf of another entity.
Some organisations can be both merchants and service providers. 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 01474556685, or request a call using the form below. Our experts are ready and waiting with practical advice.
Contact us
Why is PCI compliance important?
Payment card data is a prime target in cyber attacks.
The 2019 Trustwave Global Security Report identified that threat actors targeted payment card data in most incidents, with CNP (card-not-present) data making up nearly 25% of events and card-track (magnetic stripe) data comprising 11%.
By obtaining the PAN and sensitive authentication data, an attacker can impersonate the cardholder, use the card and steal the cardholder’s identity.
If implemented correctly, the PCI DSS can help organisations reduce the risk of security breaches.
A key benefit of the Standard is the detailed action plan it provides – its requirements can be applied to organisations of any size or type that use any method of processing or storing payment card data.
Penalties for non-compliance with the PCI DSS
The PCI DSS is a standard, not a law, 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, the breach or theft of cardholder data 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.
Control objectives:
Build and maintain a secure network
PCI DSS requirements:
1. Install and maintain a firewall configuration to protect cardholder data.
Learn more about PCI DSS Requirement 1
Firewalls control the transmission of data 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 the functionality of a firewall, 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.
Therefore, vendor-supplied default settings 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.
3. Protect stored cardholder data.
Learn more about PCI DSS Requirement 3
Cardholder data storage 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 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 the transmission of cardholder data must be documented and made known to all affected parties.
Maintain a vulnerability management programme
5. Use and regularly update anti-virus software or programs.
Learn more about PCI DSS Requirement 5
Anti-virus software capable of detecting, removing and protecting against all known types of malware 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.
Anti-virus 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 following the PCI DSS.
They should also be based on industry standards or best practices and incorporate information security throughout their development life cycle.
Implement strong access control measures
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 ensures that system access is limited to those with the proper authorisation. 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, 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, and should be periodically inspected. An up-to-date list of these devices should be maintained.
Regularly monitor and test networks
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, and 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 system components, processes and custom software must be 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 changes in the network (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 prevent unauthorised network activity. A change detection mechanism should be employed to perform weekly critical file comparisons and alert personnel to unauthorised system modifications.
Maintain an information security policy
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
To demonstrate that your organisation is PCI DSS compliant, you must complete an audit of your CDE (cardholder data environment) – the system or part of your system that deals with cardholder data.
There are three types of audit:
The type of audit you must undergo and your exact PCI DSS compliance requirements will vary depending on your merchant or service provider level, 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
Level
|
Criteria
|
Annual validation criteria
|
1
|
Merchants that process more than 6 million transactions per year or those whose data has previously been compromised.
|
- RoC conducted by a QSA or ISA.
- Quarterly scan by an ASV.
|
2
|
Merchants that process 1 million to 6 million transactions per year.
|
- 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.
|
3
|
Merchants that process 20,000 to 1 million transactions per year.
|
- SAQ signed by a company officer.
- Quarterly scan by an ASV (dependent on SAQ completed).
|
4
|
Merchants that process fewer than 20,000 transactions per year.
|
- SAQ signed by a company officer.
- Quarterly scan by an ASV (dependent on SAQ completed).
|
PCI DSS: service provider validation criteria
Level
|
Criteria
|
Annual validation criteria
|
1
|
Service providers that process, transmit and/or store more than 300,000 transactions per year.
|
- RoC conducted by a QSA or ISA.
- Quarterly scan by an ASV.
|
2
|
Service providers that process, transmit and/or store fewer than 300,000 transactions per year.
|
- 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 – updated for PCI DSS v4.0 – to better understand the PCI DSS audit process and learn about our step-by-step approach to preparing for audit success.
Download now
List of PCI DSS SAQs
Level-2, -3 or -4 organisations can use an SAQ, comprising yes/no questions, to assess their level of cardholder data security. There are nine different questionnaires available.
SAQ
|
Description
|
A
|
Card-not-present merchants, all cardholder data functions fully outsourced.
|
A-EP
|
Partially outsourced e-commerce merchants using a third-party website for payment processing.
|
B
|
Merchants with only imprint machines or only standalone, dial-out terminals – no electronic cardholder data storage.
|
B-IP
|
Merchants with standalone, IP-connected PTS point-of-interaction (POI) terminals – no electronic cardholder data storage.
|
C-VT
|
Merchants with web-based virtual payment terminals – no electronic cardholder data storage.
|
C
|
Merchants with payment application systems connected to the Internet – no electronic cardholder data storage.
|
D for Merchants
|
All other SAQ-eligible merchants not included in the descriptions for SAQ types A to C above.
|
D for service providers
|
All service providers defined by a payment brand as eligible to complete an SAQ.
|
P2PE
|
Merchants using hardware payment terminals in a PCI SSC-listed P2PE solution only – no electronic cardholder data storage.
|
Learn more about PCI SAQs in our free paper
Download the paper now to learn about the benefits of PCI DSS compliance, how to minimise the compliance burden by reducing your 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 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.
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.
Whether you need to conduct a gap analysis, reduce the scope of your CDE, conduct a risk assessment or test the security of your systems and processes for vulnerabilities, we can help.
View our range of bestselling products and services to find out how we can help you.
Speak to an expert
For more information about the PCI DSS and what your organisation needs for compliance, please get in touch with one of our experts, who will be able to advise you further.