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, including nonprofit organizations. The Payment Card Industry Security Standards Council, organized in 2006 by leading payment brands, 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 a nonprofit fails to abide by the PCI DSS requirements, payment card brands may fine that nonprofit's acquiring bank for noncompliance. Often an acquiring bank will pass those fines on to the noncompliant nonprofit, and these may total thousands of dollars or more. Furthermore, the acquiring bank might terminate its relationship with the noncompliant nonprofit, ending its ability to process payment cards altogether. In sum, ensuring compliance with PCI DSS can be vital to a nonprofit's ability to conduct commerce and, thus, its financial health.

How Does PCI DSS Apply to Nonprofits?

If a nonprofit stores, processes, or transmits cardholder data or sensitive authentication data, it must be PCI DSS compliant, regardless of how many cards it processes or the manner in which it processes them. Stated more simply, PCI DSS applies to any nonprofit that accepts payment cards. Even if a nonprofit outsources its cardholder data environment or payment operations to an outside vendor, the nonprofit remains responsible for ensuring the outside vendor abides by PCI DSS requirements on its behalf. If the vendor fails to comply with PCI DSS, payment card companies may still hold the nonprofit responsible.

Validating Compliance

While all nonprofits 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 a nonprofit's annual transaction volume rises. All nonprofits will fall into one of four compliance validation levels, based on annual transaction volume. Most nonprofits fall into the lowest processing volume category (Level 4, with less than 20,000 transactions per year). 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 a nonprofit has more than one DBA, a payment card brand will aggregate the volume of transactions stored, processed, or transmitted by the nonprofit entity to determine the validation level. If data is not aggregated because each DBA is conducting business separately and, more important, such that the nonprofit 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 nonprofit and the payment card brand, and are generally available on the applicable payment card brand's website. Although many nonprofits fall into the lowest validation level, all nonprofits must ensure compliance with the requirements of their respective validation levels, especially as they grow.

Complying with PCI DSS v. 3.1

To ensure that nonprofits 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. Moreover, 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 off of SSL or early TLS.

The current PCI DSS lists 12 compliance requirements, which are organized into six groups of broad objectives. Generally, all entities, including nonprofits, required to follow PCI DSS must do the following to be considered PCI DSS compliant:

  1. Build and Maintain a Secure Network and Systems. PCI DSS requires nonprofits 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 a nonprofit'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 nonprofits from continuing to use any vendor-supplied default settings, passwords, or other security parameters after installation.
  2. Protect Cardholder Data. All PCI DSS requirements are designed, in part, to protect cardholder data. However, PCI DSS more specifically requires that a nonprofit protect stored cardholder data and encrypt its transmission of cardholder data when it crosses open, public networks. Nonprofits that accept payment cards may intentionally or unknowingly store cardholder data. PCI DSS requires these nonprofits to keep cardholder data storage to the minimum necessary that is required for legal, regulatory, or business requirements. Furthermore, when a nonprofit does store the data, PCI DSS contains a host of technical requirements that force the nonprofit to mask and protect personal information. Nonprofits that accept payment cards also transmit cardholder data to external, public networks. When this transmission occurs, PCI DSS requires nonprofits 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, nonprofits that transmit cardholder data should ensure that these protocols are phased out as quickly as possible.
  3. 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 nonprofits 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, nonprofits should deploy anti-virus software on all systems commonly affected by malicious software. Nonprofits need to ensure that their anti-virus protection runs actively and cannot be disabled by users without management authorization. Nonprofits can satisfy the second prong of PCI DSS's vulnerability management program requirement by undertaking several measures. Among other things, nonprofits must establish a process to identify their system vulnerabilities. Nonprofits also must ensure that all system components are protected by the latest vendor-supplied security patches.
  4. Implement Strong Access Control Measures. PCI DSS requires that nonprofits limit access to cardholder and sensitive data. In particular, nonprofits must restrict access to cardholder data on a need-to-know basis, 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 nonprofits should seek outside guidance in ensuring that their network and systems are secure.
  5. Regularly Monitor and Test Networks. To discourage breaches and identify individuals who cause data breaches, the PCI DSS requires nonprofits to track and monitor all access to network resources and cardholder data and regularly test security systems and processes.
  6. Maintain an Information Security Policy. By ensuring all employees are aware of their responsibilities to keep data secure, a nonprofit can take significant steps toward mitigating the risk of a cardholder data breach. Accordingly, the PCI DSS requires nonprofits to ensure that all employees are informed of and have access to the organization's information-security policies.

Given the threat of fines or termination of a nonprofit's ability to process payment cards for failing to comply with PCI DSS, nonprofits 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. Nonprofits may therefore want to consider engaging consultants and legal counsel with expertise in PCI DSS to ensure continued compliance.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.