PCI DSS compliance requires new vendor management strategy

In the first part of this tip, Andrew Baer discussed the provisions of PCI DSS Requirement 12.8 and what it means for vendor management. In the second part of the tip, below, Baer explores the ways organizations can mitigate the risks posed by third-party vendors.

PCI DSS Requirement 12.8 and its supporting guidance do not provide specifics about what must be in the "established process" for vendor due diligence, i.e., the individual items or queries in a vendor due diligence request. Rather, the emphasis is on timing. PCI DSS compliance requires verification that an "established process" kicks in before the contract is signed.

More on risk management Architect preventative compliance controls for best risk management Effective techniques for continuity risk management, measurement

The "Navigating PCI DSS" document that was issued by the Payment Card Industry Security Standards Council to provide interpretive guidance for PCI DSS Version 1.2 states only that the process must "ensure that any engagement of a service provider is thoroughly vetted by an organization, which should include a risk analysis prior to establishing a formal relationship with the service provider." Clearly, however, due diligence is important, since its emphasis in PCI Version 1.2 represents a major departure from Requirement 12.8 of PCI DSS Version 1.1, which focused solely on binding vendors to contractual compliance obligations. Common business sense also supports this approach. It is far better to uncover a vulnerability in a preliminary screening of a vendor than to have to rely on contractual language, even if it is well drafted, in the event of an actual data breach.

Based on my experience in the banking world, where pre-contract due diligence was already a regulatory compliance mandate, I would recommend the following, assuming that an organization has the necessary internal IT and information security expertise and resources:

• Review the vendor's written information security program and ask follow-up questions, as appropriate. These could include questions about firewalls, intrusion detection systems, physical and logical access controls, the monitoring system, the incident response plan, whether personnel are fingerprinted and given a criminal background check, frequency of network vulnerability scanning and penetration testing, etc.
• Submit an IT questionnaire to be completed by the vendor with specific information about its network architecture.
• Inquire about any prior data breaches the vendor has experienced.
• If available, review a SAS 70 prepared by the vendor's independent auditors that covers its data environment.
• Validate the vendor's PCI DSS compliance (and Payment Application Data Security Standard compliance, if the vendor is providing a payment application).

If the vendor will access or store significant amounts of cardholder data, ideally there should also be an on-site visit to the vendor's data center for the purpose of confirming that the controls and security measures represented by the vendor are in place. While not required by PCI DSS, for critical vendors the organization should also review audited financial statements and a business continuity plan. Based on the foregoing information, the organization should conduct the risk analysis required by the PCI DSS guidance and, if the risk is deemed acceptable, initiate contract negotiations.

Of course, many SMBs do not have the internal expertise and resources to undertake such a thorough due diligence investigation. The safest option in this case would be to hire an information security consultant to assess the vendor. However, this will likely cost thousands of dollars.

What is the absolute minimum needed to comply with Requirement 12.8?

While there is no clear answer, PCI DSS Requirement 12.8 would be meaningless if organizations didn't request information about a vendor's information security program, network architecture and PCI DSS compliance status. Without this information, it would be impossible to conduct an informed risk analysis, as specified in the supporting guidance.

"Reputational due diligence" can also be used to mitigate risk and compensate for a lack of more granular (and costly) IT due diligence. Reputational due diligence includes checking references, running Internet searches to uncover reports of prior security incidents and dealing with vendors that are recognized industry leaders in information security and PCI DSS compliance.

For a bare-bones "established [due diligence] process," then, an organization should create and document procedures for obtaining this information prior to contracting. For each vendor with whom cardholder data is shared, an organization should maintain a file containing copies of whatever information is acquired from and about the vendor, or at least a summary of this information. Organizations should also retain an official memo or signoff sheet that confirms senior management go-ahead, based on the results of the risk analysis.

With respect to ongoing monitoring post-contract, Requirement 12.8 requires only monitoring of PCI DSS compliance status, which should be revalidated at least annually. To the extent that time and resources permit, however, the organization should also consider repeating some of the initial due diligence steps. These include reviewing updates to the vendor's information security program and SAS 70 on an annual basis. If the vendor experiences a significant change, then appropriate follow-up due diligence should be completed as soon as possible after the change or incident occurs. Such events include an acquisition by another company, a major change in network architecture, relocation of its data center, or if the vendor experiences a data breach incident.

Contracting tips

PCI DSS requires written contracts with service providers that include an explicit acknowledgment of the service provider's responsibility for the security of cardholder data shared with it. This is a minimal requirement, although some smaller businesses (and, in my experience, even some business clients at larger ones) view written contracts as annoying administrative obstacles, desired only by risk-adverse lawyers who think they are paid by the word.

Moreover, as I described earlier, to comply with state-law requirements concerning contracts and manage legal and operational risk, I would recommend going beyond Requirement 12.8 whenever possible. That means ensuring robust data security protections in any contract where cardholder or other nonpublic personal information is shared with a vendor. I outline the most important protections below. These protections need not add pages of verbiage to a contract. While the legalese will inevitably be negotiated, in the age of PCI DSS compliance vendors are used to dealing with such requests and often have standardized responses to them.

In addition to requiring the vendor to acknowledge its responsibility for the security of cardholder data, the contract should require the vendor to implement and maintain reasonable security measures. These security measures should be appropriate to the nature of the information, protect the information from unauthorized access, use or disclosure. The vendor must warrant that it has validated PCI DSS compliance and will continue to do so on an ongoing basis. An organization should also reserve the right to audit and monitor these security measures and PCI DSS compliance periodically with the vendor's cooperation. This is particularly important when a vendor has possession of a significant amount of cardholder data, permitting annual onsite visits to its data center.

Organizations should not panic over Requirement 12.8. It merely formalizes what is already good business practice. ,

This point is critical. If the contract doesn't specifically contain audit and monitoring rights and the vendor is uncooperative, the organization may not be able to meet its compliance obligation under PCI DSS Requirement 12.8 and applicable state regulations. Some vendors may balk at this requirement and complain that it risks disruption to their business or may compromise other clients' data in a shared hosting environment. Such arguments should be treated skeptically.

As in the banking world, vendors that build a business around outsourced transaction services and data storage should expect and be equipped to deal with due diligence, audit and monitoring requests. Compliance is an essential part of the product they are marketing. Furthermore, with respect to shared hosting environments, Requirement 2.4 and Appendix A of PCI DSS prescribe specific logical separation requirements for such settings in order to minimize the risk that one customer's access and use of its data will impinge upon another customer's data access or security.

Last but not least, the contract should require immediate notification by the vendor when it becomes aware of unauthorized access, use or disclosure of cardholder data, along with its reasonable cooperation in investigating and remediating any such incident. This is important because data breach notification statutes make the data owner or licensor responsible for notifying affected individuals. Without the vendor's active cooperation, an organization will not be able to determine what happened, what types of data was compromised and who was or might have been affected by the breach.

Although not required by PCI DSS or statute, organizations should also consult with their technology counsel about including legal protections to shift the financial losses of a data breach, such as requiring the vendor to hold the organization harmless from the out-of-pocket costs of investigation, customer notification and remediation resulting from a breach, as well as from any statutory or regulatory penalties and third-party claims.

Organizations should not panic over Requirement 12.8. Although its focus on process may be alien to SMBs used to cutting quick deals with vendors based on lowest available pricing, compliance does not require massive internal or external resources. Requirement 12.8 merely formalizes what is already good business practice: Educate yourself about who will have your data, make an informed decision about whether or not that entity deserves your confidence (both prior to contracting and as the relationship progresses), and make sure your contract requires it to step up when it comes to data security.

Andrew M. Baer is an attorney and founder of Baer Business Law LLC, a Philadelphia firm focused on providing clients with cost-efficient business counseling and transactional assistance, particularly in the areas of technology and intellectual property law. Baer can be contacted at [email protected] or @BaerBizLaw on Twitter.