A compliance checklist for the 12 requirements of the PCI DSS

Any organisation that stores, processes or transmits payment card data must comply with the PCI DSS (Payment Card Industry Data Security Standard). 

The Standard contains 12 requirements, which we’ll run through in this blog along with an overview of the steps you should complete to meet each one.


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

Firewalls control the transmission of data between an organisation’s trusted internal networks and untrusted external networks, as well as traffic between sensitive areas of the internal networks themselves. 

Requirement 1 of the PCI DSS requires systems to 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

The default settings of many commonly used systems are well known, easily exploitable and often used by criminal hackers to compromise those systems. 

Vendor-supplied default settings must, therefore, be changed, and unnecessary default accounts disabled or removed before any system is installed on a network. 

This applies to all default passwords. If firewalls are correctly implemented according to Requirement 1, they should also comply with Requirement


3. Protect stored cardholder data

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 CVV (card verification value) or the PIN– should never be stored. 

You must have adequate safeguards in place when data storage is necessary. Encryption, truncation, masking and hashing are critical components of cardholder data protection. 

Without access to the proper cryptographic keys, criminal hackers will be unable to read or access encrypted data, even if they manage to circumvent other security controls. 

Cryptographic keys should therefore be stored securely, and access restricted to as few people as possible. Other data protection methods should also be considered. 


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

Strong cryptography and security protocols should be used to protect sensitive cardholder data during transmission over open, public networks that could easily be accessed by malicious individuals. 

Examples of such 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 relevant parties.


5. Protect all systems against malware and regularly update antivirus software or programs

Antivirus software capable of detecting, removing and protecting against all known types of malware must be used on all commonly affected systems. 

For less vulnerable systems, evolving malware threats should be periodically evaluated to determine if antivirus software is needed. 

Antivirus mechanisms must be maintained, kept active and only be disabled if formally authorised for a specific purpose. 


6.Develop and maintain secure systems and applications

Many security vulnerabilities are fixed by patches issued by software vendors. 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. 

All software applications, whether they’re developed internally or externally, 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 entire development lifecycle. 


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

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

Documented systems and processes should therefore be put in place to limit access rights to critical data. Access control systems should deny all access by default, and authorisation should be granted according to the clearly defined job responsibilities.


8. Identify and authenticate access to system components

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

Documented policies and procedures must therefore 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

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, and 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 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

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. Secure, controlled audit trails must therefore 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

New vulnerabilities are constantly found and exploited, so its 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 at least quarterly. 

Internal and external network vulnerability scans must be performed by qualified personnel at least quarterly and after any significant change 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/or prevent unauthorised network activity, and a change detection mechanism should be employed to perform weekly critical file comparisons, and to alert personnel to unauthorised system modifications.


12. Maintain a policy that addresses information security for all personnel

To comply with the PCI DSS, organisations must establish, publish, maintain and disseminate a security policy, which must be reviewed at least 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. 


Watch our free introductory webinar on the PCI DSS

Find out more about these requirements and how you can meet them by registering for our upcoming webinar: PCI DSS – Challenge or Opportunity? 

This presentation gives an overview of the main challenges organisations face when implementing the PCI DSS’s requirements and offers recommendations to help you overcome them. 

It also introduces a set of controls for keeping cardholder data secure and explains how technologies, processes and procedures can help you protect your systems. 

The webinar is available on demand and can be downloaded here

Download now >>



Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.