The Payment Card Industry Data Security Standard (PCI DSS) is a set of technical and operational security standards for entities that store, process, or transmit cardholder data. The Payment Card Industry Security Standards Council, organized in 2006 by payment brands including Discover, JCB, MasterCard, and Visa, manages and updates the PCI DSS requirements.
PCI DSS is not a law, and the Security Standards Council does not enforce PCI DSS requirements. Rather, each payment card brand has its own variation of compliance requirements and compliance enforcement mechanisms. When an entity fails to abide by the PCI DSS requirements, payment card brands may fine that entity's acquiring bank for noncompliance. Often, an acquiring bank will pass those fines on to the noncompliant entity, which may total thousands of dollars or more. Furthermore, the acquiring bank might terminate its relationship with the noncompliant entity, ending its ability to process payment cards altogether. In sum, ensuring compliance with PCI DSS can be vital to an organization's ability to conduct commerce and, thus, its financial health.
To whom does PCI DSS apply?
If an entity stores, processes, or transmits cardholder data or sensitive authentication data, it must be PCI DSS compliant. Stated more simply, PCI DSS applies to any entity that accepts payment cards. Even if an organization outsources its cardholder data environment or payment operations to an independent contractor, the entity remains responsible for ensuring the contractor abides by PCI DSS requirements on its behalf. If the third-party contractor fails to comply with PCI DSS, payment card companies may still hold the entity responsible.
Validating Compliance
Although all entities that accept payment cards must be PCI DSS compliant, payment card brands vary in the extent to which they validate compliance. Generally speaking, however, the rigor of a payment card brand's compliance assessment increases as an entity's annual transaction volume rises. All entities that accept payment cards fall into one of four compliance validation levels based on annual transaction volume. Annual transaction volume is calculated based upon the aggregate number of payment card transactions (inclusive of credit, debit, and prepaid) from a merchant "Doing Business As" (DBA) a particular business.
If an entity has more than one DBA, a payment card brand will aggregate the volume of transactions stored, processed, or transmitted by the corporate entity to determine the validation level. If data is not aggregated because each DBA is conducting business separately and, more importantly, such that the corporate entity does not store, process, or transmit cardholder data on behalf of multiple DBAs, the payment card brand will consider each DBA's individual transaction volume to determine the validation level. The validation requirements for each payment card brand can be found in the contract between the entity and the payment card brand and are also generally available on the applicable payment card brand's website.
Complying with PCI DSS v. 3.1
To ensure that entities which accept payment cards adequately protect cardholder data, the Security Standards Council regularly updates PCI DSS requirements. In April 2015, the Security Standards Council released Version 3.1 of the PCI DSS. The most important difference between Version 3.0 and Version 3.1 is with respect to the level of data encryption necessary to be considered PCI DSS compliant. Secure Sockets Layer (SSL) and early versions of the Transport Layer Security (TLS) protocol will no longer be considered compliant encryption levels after June 30, 2016, and, effective immediately, merchants are prohibited from implementing new technology that relies on SSL and early TLS. Further, Version 3.1 requires merchants to have a formal risk mitigation and migration plan for transitioning away from SSL or early TLS.
The current PCI DSS lists twelve compliance requirements, which are organized into six groups of broad objectives. Generally, entities required to follow PCI DSS must do the following to be considered PCI DSS compliant:
- Build and Maintain a Secure Network and Systems. PCI DSS requires entities to operate using a secure network and systems by installing and maintaining a firewall configuration to protect cardholder data and changing all vendor-supplied defaults for system passwords and other security passwords. Generally speaking, a firewall is a device that controls computer traffic between an entity's internal networks and untrusted, external networks. Effective firewalls examine this computer traffic and block transmissions that do not meet specified security criteria. Having an effective firewall in place is an essential first step in ensuring compliance with PCI DSS. When technology vendors sell software, they typically provide default system passwords and other security parameters. These default settings provide an accessible avenue for hackers to locate cardholder data. Accordingly, PCI DSS prohibits entities from continuing to use any vendor-supplied default settings, passwords, or other security parameters after installation.
- Protect Cardholder Data. All PCI DSS requirements are designed in part to protect cardholder data. However, PCI DSS more specifically requires that entities protect stored cardholder data and encrypt their transmission of cardholder data when it crosses open, public networks. Entities that accept payment cards may intentionally or unknowingly store cardholder data. PCI DSS requires these entities to keep cardholder data storage to the minimum necessary that is required for legal, regulatory, or business requirements. Furthermore, when an entity does store the data, PCI DSS contains a host of technical requirements that force the entity to mask and protect personal information. Entities that accept payment cards also transmit cardholder data to external, public networks. When this transmission occurs, PCI DSS requires entities to encrypt this data using "strong cryptography and security protocols." Importantly, as mentioned above, Version 3.1 of the PCI DSS mandates for the first time that Secure Sockets Layer (SSL) and early versions of the Transport Layer Security (TLS) protocol are not "strong cryptography" and cannot be used as security controls after June 30, 2016. To ensure PCI DSS compliance, entities that transmit cardholder data should ensure that these protocols are phased out as quickly as possible.
- Maintain a Vulnerability Management Program. A vital part of any risk mitigation program is the identification and mitigation of system vulnerabilities. Accordingly, PCI DSS requires that entities protect all systems against malware, regularly update anti-virus software or programs, and develop and maintain secure systems and applications. To comply with the first requirement, entities should deploy anti-virus software on all systems commonly affected by malicious software. Entities need to ensure that their anti-virus protection runs actively and cannot be disabled by users without management authorization. Entities can satisfy the second prong of PCI DSS's vulnerability management program requirement by undertaking several measures. Among other things, entities must establish a process to identify their system vulnerabilities. Entities also must ensure that all system components are protected by the latest vendor-supplied security patches.
- Implement Strong Access Control Measures. PCI DSS requires that entities limit access to cardholder and sensitive data. In particular, entities must restrict access to cardholder data by business need to know, identify and authenticate access to all system components, and restrict physical access to cardholder data. PCI DSS contains a host of more technical requirements under each prong, and entities should seek outside guidance in ensuring that their network and systems are secure.
- Regularly Monitor and Test Networks. To discourage breaches and identify individuals who cause data breaches, the PCI DSS requires entities to track and monitor all access to network resources and cardholder data and regularly test security systems and processes.
- Maintain an Information Security Policy. By ensuring all employees are aware of their responsibilities to keep data secure, an entity can take significant steps toward mitigating the risk of a cardholder data breach. Accordingly, the PCI DSS requires entities to ensure that all employees are informed of and have access to an organization's information security policies.
Given the threat of fines or termination of an entity's ability to process payment cards for failing to comply with PCI DSS, organizations should pay close attention to the requirements in the latest version of the PCI DSS. Understanding and complying with these requirements can sometimes be complex. Organizations may therefore want to engage consultants and legal counsel with expertise in PCI DSS to ensure continued compliance.