The 12 Requirements of the PCI DSS
This page outlines the Payment Card Industry Data Security Standard’s 12 requirements and explains how to achieve and maintain compliance with each of them. The requirements apply to “all system components included in or connected to the cardholder data environment” – i.e. the “people, processes and technologies that store, process, or transmit cardholder data or sensitive authentication data”. Note that not all companies need to comply with all 12 requirements: compliance requirements depend on the type and volume of transactions your organisation undertakes, and will be dictated by your acquiring bank.
Compliance with the PCI DSS might seem onerous but it is not solely a matter of legal obligation – its requirements offer strong data security measures that will benefit your organisation. Indeed, the Verizon 2015 PCI Compliance Report found a strong correlation between non-compliance with the PCI DSS and the likelihood of suffering a data breach.
See our main PCI DSS information page for further guidance >>
Latest changes introduced by version 3.2
To review changes to the individual requirements introduced by PCI DSS version 3.2, please review the standard.
The 12 requirements of the PCI DSS are:
Build and maintain a secure network and systems
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Click here to expand.
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.
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Click here to expand.
The default settings of many commonly used systems are well known, easily exploitable and often used by 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, without exception. If firewalls are correctly implemented according to Requirement 1, they should also comply with Requirement 2.
Protect cardholder data
Requirement 3: Protect stored cardholder data
Click here to expand.
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 card verification number (CVN) or the personal identification number (PIN) – 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 hackers even if they manage to circumvent other security controls. Cryptographic keys should therefore be stored securely and access to them should be restricted to the fewest custodians necessary. Other data protection methods should also be considered.
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Click here to expand.
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 could easily be accessed by malicious individuals. Examples of open, public networks include the Internet, wireless technologies (e.g. Bluetooth), general packet radio service (GPRS) 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.
Version 3.1 has removed SSL as an example of a secure technology.
Maintain a vulnerability management program
Requirement 5: Protect all systems against malware and regularly update antivirus software or programs
Click here to expand.
Antivirus software capable of detecting, removing and protecting against all known types of malware (e.g. viruses, worms and Trojans) must be used on all systems commonly affected by malware in order to protect them from threats. For systems not commonly affected by malware, evolving malware threats should be periodically evaluated to determine whether antivirus software is needed. Antivirus mechanisms must be maintained and kept actively running and should only be disabled if formally authorised for a specific purpose.
Requirement 6: Develop and maintain secure systems and applications
Click here to expand.
Many security vulnerabilities are fixed by patches issued by the software vendors. Organisations should therefore establish a process to identify security vulnerabilities and rank them according to their level of risk, and should then install relevant security patches within a month of their release in order to protect against the compromise of cardholder data. All software applications, whether developed internally or externally, should be developed securely in accordance with the PCI DSS, based on industry standards and/or best practices, and should incorporate information security throughout their entire development lifecycle.
Implement strong access control measures
Requirement 7: Restrict access to cardholder data by business need to know
Click here to expand.
Exploiting authorised accounts and abusing user privileges is one of the easiest ways for hackers to gain access to a system. It is 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, based on the need to know and according to authorised personnels’ clearly defined job responsibilities. Access control systems should deny all access by default. ‘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”.
Requirement 8: Identify and authenticate access to system components
Click here to expand.
The ability to identify individual users not only ensures that system access is limited to those people with the proper authorisation, it also establishes an audit trail that can be analysed following any 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 used and, as three-quarters of all network intrusions exploit weak or stolen passwords, two-factor authentication must be used for remote network access.
Requirement 9: Restrict physical access to cardholder data
Click here to expand.
Electronic data breaches are not the only source of data loss; physical access to systems should also be limited and monitored by the use of appropriate controls. Procedures should be implemented to distinguish between on-site personnel and visitors, and physical access to sensitive areas (e.g. server rooms, data centres etc.) 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 to detect tampering or substitution. An up-to-date list of these devices should be maintained.
Regularly monitor and test networks
Requirement 10: Track and monitor all access to network resources and cardholder data
Click here to expand.
The use of logging mechanisms is critical in preventing, detecting and minimising the impact of data compromises. If system usage is not logged, then potential breaches cannot be identified. Secure, controlled audit trails must therefore be implemented that link all access to system components with individual users and log their actions (including 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). 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.
Requirement 11: Regularly test security systems and processes
Click here to expand.
New vulnerabilities are regularly found and exploited, so it is essential that system components, processes and custom software are regularly tested to ensure the continuing utility of security controls. Documented processes must be implemented to detect and identify all unauthorised wireless access points on a quarterly basis. 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 detect and/or prevent network intrusions, and a change detection mechanism should be employed to perform weekly critical file comparisons, and to alert personnel to unauthorised system modifications.
Note: Requirement 11.3 has been updated in the latest version of the PCI DSS. After 30 June 2015, internal and external penetration testing must be carried out at least annually as well as after any significant change in the network (e.g. operating system upgrade, the addition of a sub-network or a web server). Exploitable vulnerabilities found during penetration testing must be corrected and testing must then be repeated to confirm that the corrections are adequate. Until 30 June 2015 this is a best practice and, as such, is advised but not required.
Maintain an information security policy
Requirement 12: Maintain a policy that addresses information security for all personnel
Click here to expand.
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.
PCI DSS solutions
IT Governance sources, publishes and distributes the world’s best selection of PCI DSS resources, and provides a wide range of services to help you meet your PCI DSS obligations. Please download our free PCI DSS Compliance brochure or follow the links below for further information about specific products and services:
QSA-led consultancy services
Books
PCI DSS: A Pocket Guide, fifth edition, click here >>
Toolkit
PCI DSS documentation toolkit
Training courses
PCI DSS Foundation Training Course
PCI DSS Implementation Training Course
PCI DSS Self-Assessment Questionnaire (SAQ) Workshop
Staff awareness
PCI DSS Staff Awareness E-learning course
Penetration testing
PCI penetration testing
Call us on 00 800 48 484 484 or email us to discuss your specific PCI DSS requirements.