Reece Hirsch
Credit card data is a primary target for identity thieves because it is easily exploited in fraudulent transactions and it is often all-too-accessible. In the absence of a U.S. law that imposes a general obligation on businesses to safeguard credit card information and other sensitive customer data, the credit card associations took matters into their own hands by adopting the Payment Card Industry (PCI) Data Security Standard (DSS) in 2005. In recent months, support for the PCI Data Security Standard appears to be gaining momentum with the issuance of an updated version of the standard.
On September 7, 2006, the five major credit card companies announced the formation of a new organization to improve and implement the PCI standard, marking the first time that the five major brands (American Express, Discover Financial Services, JCB, MasterCard Worldwide and Visa International) have agreed to a single, shared framework. The new group, known as the Payment Card International Security Standards Council, took its first action by issuing PCI 1.1., an updated version of PCI DSS.
Visa implemented PCI's predecessor standard, the Cardholder Information Security Program (CISP), in 2001. MasterCard and Visa introduced the PCI Data Security Standard (PCI DSS) in 2004, and it took effect June 30, 2005.
The PCI Data Security Standard has prompted relatively little action by merchants. Visa recently estimated that only 22 percent of the largest merchants (those that handle more than 6 million credit card transactions per year) are PCI-compliant today. But it expected that number to climb dramatically by the end of 2006. Visa also has estimated that 72 percent of the largest merchants have conducted an initial PCI audit, identified their deficiencies and have a remediation plan in place to achieve full compliance.
Merchants ignoring the growing adoption of the PCI DSS do so at their peril because the penalties for noncompliance are severe. Noncompliant merchants and payment processors can face as much as $500,000 in fines per incident if cardholder data is compromised. Visa has reported that it imposed $4.6 million in fines against banks in 2006, up from $3.4 million in 2005. Even more devastating than fines, credit card companies also may revoke the right of a merchant to process credit card transactions, a virtual death sentence for many businesses.
Carrots and Sticks
On December 12, 2006, Visa announced a new program, known as the "Visa PCI Compliance Acceleration Program," which seeks to create financial incentives to encourage PCI compliance. Under the program, Visa has committed $20 million to offer financial incentives to banks that process credit card transactions if they can demonstrate that the merchants they deal with are PCI-compliant. A Visa spokesperson has stated that the new program is intended to supplement the "stick" of noncompliance penalties with a "carrot" in the form of financial incentives.
It appears that credit card associations may no longer be the only parties seeking to compel compliance by merchants with PCI DSS standards. In January 2007, the director of the Massachusetts Office of Consumer Affairs and Business Regulation announced plans to call on merchants to begin disclosing the extent to which they comply with the PCI DSS. In February 2007, a class action claim filed in Massachusetts federal district court charged that TJX, Inc. failed to adhere to PCI standards.
PCI's Three-Tiered Approach
The PCI DSS applies to three tiers of entities: the merchant, the acquiring bank and the credit card associations that are members of the PCI Security Standards Council. Merchants are the first tier because they are on the "front lines" of credit card transactions. A merchant, either through a physical store or a Web site, accepts credit card payments from the consumer. The PCI Data Security Standard assumes that merchants are in the best position to safeguard credit card information because they are the point of contact with the consumer. As a result, merchants bear the brunt of the standard's compliance obligations.
The second level is the "acquiring bank" or "acquirer." A merchant that processes credit card transactions must have a relationship with an acquiring bank that processes the transaction. The merchant contacts the acquirer to confirm that the consumer has sufficient funds in the consumer's account and authorizes payment.
The credit card associations occupy the third tier. The associations develop PCI standards and impose them upon the acquiring banks, which are responsible for implementation of, and compliance with, those standards. The associations do not have a direct relationship to the merchants, and rely upon the acquiring banks to enforce the PCI requirements with respect to merchants.
Encryption and Compensating Controls
One PCI standard creating headaches for merchants is the requirement of database encryption. A covered entity must render cardholder data unreadable anywhere it is stored by using strong cryptography, such as Triple Data Encryption Standard 128-bit encryption, or other specified methods. It appears that even many large processors of credit card transactions have not yet achieved full PCI compliance due to the time and cost associated with implementing database encryption projects.
The PCI Security Standards Council's September 2006 update of the standards made this requirement more flexible, providing that if for some reason a company is unable to encrypt cardholder data, "compensating controls" may be employed. The update provides that compensating controls may be considered for most PCI DSS requirements when an entity cannot meet a technical specification of a requirement, but has sufficiently mitigated the associated risk through other controls.
The PCI Security Standards Council has issued a PCI DSS Glossary, which specifies that compensating controls must: (1) Meet the intent and rigor of the original stated PCI DSS requirement; (2) Repel a compromise attempt with similar force; (3) Be "above and beyond" other PCI DSS requirements; and (4) Be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement.
Clearly, this new flexibility is by no means an easy out for merchants seeking to bypass PCI's encryption standard or other standards posing implementation difficulties. Merchants that fail to encrypt cardholder data must be prepared to perform a PCI security audit to demonstrate the presence of "compensating controls" and "mitigating circumstances." It also is becoming apparent that different auditors have different interpretations of what "compensating controls" and "mitigating circumstances" are adequate. Differing interpretations of these critical terms could lead to significant variation in implementation of PCI DSS and "forum shopping" for security auditors who are perceived to have adopted a more lenient (and less costly) reading of the standards.
Penalties for Noncompliance
Although the credit card associations have not been very active thus far in enforcing the PCI Data Standard, the potential consequences of noncompliance are severe. Acquiring banks are responsible for monitoring PCI compliance and reporting noncompliant merchants. An acquiring bank may report a merchant violating PCI to the Terminated Merchant File or MATCH list, which is available to other acquirers. A merchant placed on the MATCH list will have great difficulty in processing credit card transactions, and there is no clear process for a merchant to appeal the determination.
The most substantial penalties may be applied if the credit card association determines that a security breach occurred and, at the time of the breach, the merchant was not PCI-compliant. In such a case, the merchant will be responsible for a full-scale investigation of the breach. After the investigation, the merchant must obtain a PCI compliance certification in order to continue processing credit card transactions. The merchant also may be responsible for any and all charges posted to credit card numbers obtained through the breach. As if those consequences were not dire enough, the acquiring bank may fine the merchant $500,000 per incident.
Because so many merchants are currently not in full compliance with PCI, it is important to understand to what extent partial compliance may insulate a merchant from liability. If a merchant is subject to a security breach and is not fully PCI-compliant, do the more substantial penalties described above automatically apply? What if the breach occurs with respect to an aspect of the merchant's systems that is currently PCI compliant? These murky issues will hopefully be clarified as the standards are enforced by the associations through the acquiring banks.
Enforcement is another muddled area of the PCI DDS. The creation of the PCI Security Standards Council creates a broader platform for PCI because all five major credit card brands are now responsible for maintaining the standard, not just MasterCard and Visa. However, each member credit card that is a member of the PCI Security Standards Council remains individually responsible for enforcing the PCI standard through acquiring banks. Unless the Council issues PCI enforcement guidance, it is unlikely that PCI enforcement will be uniform or predictable.
Compliance Steps
The PCI DSS program divides merchants into four levels, based on the volume of credit card transactions they process annually. Most merchants will fall into merchant levels 2 (between 1 and 6 million transactions), 3 (fewer than 1 million transactions) or 4 (fewer than 20,000 online transactions). Merchants in levels 2, 3 and 4 are permitted to "self-certify" their compliance with the PCI Data Standard, rather than obtaining a PCI audit from an independent vendor. It is relatively easy for a merchant to self-certify and take a lax approach to PCI compliance - but that places the merchant in a very dangerous position if it experiences a security breach involving credit card transactions.
Therefore, merchants should be proactive and adopt a diligent approach to PCI compliance, as part of an enterprise-wide approach to privacy and security. Merchants should not shy away from the more complex aspects of PCI compliance, such as database encryption, establishing a security-oriented hiring policy for staff and contractors, and assigning each person a unique ID for accessing data. In addition, covered entities should amend their contracts with vendors that access cardholder data to include certain PCI-specific provision, such as the right to audit to validate compliance with the PCI standard.
While the PCI Data Standard will undoubtedly continue to evolve, any changes are likely to only facilitate wider adoption of the standard. In short, the PCI Data Standard is rapidly becoming an inescapable fact of life for all merchants that process credit card transactions.
Reece Hirsch is a partner in the San Francisco office of Sonnenschein Nath & Rosenthal LLP specializing in privacy and data security issues. He can be reached at +415.882.5040 or
rhirsch@sonnenschein.com.
A version of this article appeared previously in BNA's Privacy & Security Law Report.
SIDEBAR: The Digital Dozen
The PCI Data Security Standard contains 12 basic security requirements, also known as the "digital dozen." The Standard requires covered entities to:
- Install and maintain a firewall configuration to protect data;
- Not use vendor-supplied defaults for system passwords and other security parameters;
- Protect stored cardholder data;
- Encrypt transmission of cardholder data and sensitive information across public networks;
- Use and regularly update anti-virus software;
- Develop and maintain secure systems and applications;
- Restrict access to data by business need-to-know;
- Track and monitor all access to network resources and cardholder data;
- Regularly test security systems and processes; and
- Maintain a policy that addresses information security.
Unlike many statutes and regulations that address data security, the PCI DSS includes specific metrics and specifications for each of the 12 requirements. Nevertheless, PCI's digital dozen generally reflect basic security principles consistent with best practices.
Comments
If you want to comment on this post, you need to login.