How many of your merchants on campus have partnered with third-parties to outsource a portion of their payment processes? How many are sharing sensitive information with third-parties outside of your organization?
Before merchants enter into a partnership with a potential third-party vendor who handles cardholder data or may have an impact on the security of cardholder data, they should follow a formal approval process. New service providers should be reviewed by the PCI Team before they process a single payment and that review should include a thorough examination of the contract terms relevant to payment card handling.
The PCI DSS Requirement 12.8.x questions require that merchants maintain and implement policies and procedures to manage service providers if cardholder data is shared. Requirement 12.8.2 states merchants must “maintain a written agreement that includes an acknowledgment that the service providers are responsible for the security of cardholder data the service providers possess.” This means that, not only do you need to make sure you are collecting each service provider’s Attestation of Compliance (AOC) annually, you should also verify that the appropriate legal language is included in all payments-related contracts. As a merchant, you have agreed with your acquiring bank to pay fines and penalties for failure to comply with PCI. Similarly, the service provider will be fined by their bank should they fail to be PCI compliant. It is still, however, your responsibility to regularly check and hold the vendor responsible for their compliant status. Should the vendor suffer a breach, the negative impact would spill over to your organization so your contracts should clearly state that the service providers are required to pay any fines and penalties imposed on your organization due to their failure. Having the appropriate legal language in place is critical in order to reduce liability and limit your organization’s exposure to risk.
The PCI Team, in partnership with your organization’s Legal and Procurement departments, should carefully review and amend any agreements with third party service providers that have access to cardholder data. One of the questions our CampusGuard teams get asked the most is “What language needs to be included in the contract?” Contracts should contain language that asserts the service provider is currently PCI compliant, will maintain that compliance, and will protect all sensitive data while in their possession. The following sections should be included in all contracts:
Data Protection/Compliance:
The contract should clearly identify the service provider’s responsibility to implement safeguards to protect sensitive data and meet all compliance requirements, as well as provide appropriate documentation upon request.
- Ensuring the security and confidentiality of all non-public personal information and cardholder data in their possession
- Protecting against anticipated risks and threats
- Protecting against unauthorized access
- Proper disposal of confidential information and data
Example Language:
Vendor acknowledges and agrees that it is responsible for the security of all {INSTITUTION NAME}’s cardholder data in its possession. Vendor represents and warrants that for the life of the contract and/or while Vendor has involvement with {INSTITUTION NAME}’s cardholder data, the software and services used for processing transactions shall be compliant with current standards established by the Payment Card Industry Security Standards Council. Vendor shall, upon written request, furnish proof of compliance (an Attestation of Compliance or AOC) with the Payment Card Industry Data Security Standard (PCI DSS) within 10 business days of the
request.
Liability:
The service provider should acknowledge that, in the event of a data breach or compromise that is found to be the fault of the service provider, any and all costs related to the breach shall be their liability. The service provider should agree to assume responsibility, to indemnify and hold your organization/merchants harmless, and protect your employees from claims, damages, or other harm related to a breach. The service provider should also be responsible for informing all affected individuals in accordance with applicable requirements.
Example Language:
Vendor agrees to indemnify and hold {INSTITUTION NAME}, its officers, employees, and agents, harmless for, from, and against any and all claims, causes of action, suits, judgments, assessments, costs (including reasonable attorneys’ fees), and expenses arising out of, or relating to, any loss of {INSTITUTION NAME} payment card or identity information managed, retained, or maintained by Vendor, including but not limited to fraudulent or unapproved use of such payment card or identity information.
Some vendor contract language will limit their liability to a percentage of the contract value, and may have liability limiting clauses that remove vendor liability relating to damages, even if the vendor is negligent. Carefully review vendor contracts to determine whether data breaches are, or can be, excluded from the liability clause within the contract.
Termination:
Annually audit the PCI compliance status of all service providers and third-party vendors by requesting their updated AOC and related documentation. A lapse or failure in PCI compliance should allow for you to take appropriate action.
Example Language:
Notwithstanding anything to the contrary in the Agreement or the Addendum, in the event Vendor fails to maintain compliance with the PCI DSS or fails to maintain confidentiality or integrity of any cardholder data, {INSTITUTION NAME} reserves the right to suspend or terminate the Agreement immediately, without penalty, upon notice to the Vendor.
Breach Notification:
Contracts should require the service provider to immediately notify your organization of any security incidents related to cardholder data. This section may also spell out specific contacts (e.g. the CISO or a security distribution list) within the organization that should be notified and the procedures for notifying affected individuals.
Example Language:
Vendor will inform {KEY CONTACT} within 24 hours if it has knowledge of, or can reasonably expect that, a security breach of cardholder data has occurred. Vendor shall provide appropriate level of detail regarding the breach including, but not limited to, start and end dates, system(s) impacted, estimated number of users impacted, and remediation plans and timeline.
Where possible, you may even want to consider including any critical service providers in an annual tabletop exercise of your Incident Response Plan (IRP). This coordinated test will help to ensure that your breach response and notification procedures are in place and accurately being followed.
Data Retention:
The contract should also state how long data should be retained and how it should be deleted.
Example Language:
Vendor will destroy all media under its control containing copies of Customer Data not later than ____ days after the processing of such data, except where special circumstances warrant longer retention. In the event the data retention period cannot be achieved, Vendor will provide written notice no less than _____ days in advance of the retention expiration date. For purposes of this agreement, destruction means to render the relevant data unrecoverable by acceptable method according to the current PCI DSS.
Payment Applications:
Companies using third-party payment applications to process payment card transactions may include language that ensures compliance of that system.
Example Language:
Vendor warrants that the software meets PA-DSS (Payment Application Data Security Standard) requirements, and that {INSTITUTION NAME}, following vendor’s instructions detailed in the PA-DSS Implementation Guide, will be able to deploy and maintain the software according to Payment Card Industry Data Security Standard (PCI DSS). In the event any security vulnerabilities are identified within the software, Vendor will promptly notify {INSTITUTION NAME} and will provide instructions to mitigate risk of that vulnerability being exploited. Vendor will provide a patch release or security update within 30 days of a critical security vulnerability being discovered, and will provide support as necessary to properly deploy the patch or update.
Implementing and managing an effective third-party service provider program is a critical piece of your organization’s overall PCI compliance strategy. Ensure your organization has clearly defined procedures for reviewing and updating all payment-related contracts to confirm that they address liability and protect your organization from any unwanted exposures.
Some additional guidance from the Security Advisor Team below:
[Hobby]: What organizations qualify as a third party service provider under PCI, and which vendor contracts might need to be strengthened? The PCI SSC defines a service provider as:
“Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS, and other services as well as hosting providers and other entities. If an entity provides a service that involves only the provision of public network access—such as a telecommunications company providing just the communication link—the entity would not be considered a service provider for that service (although they may be considered a service provider for other services).”
So any third party organization that processes, stores, or transmits sensitive authentication data (SAD) or cardholder data (CHD) is a service provider. More simply, almost anyone you share card data with is a service provider. A key point to remember is that a provider needs to be PCI compliant if they CAN come into contact with sensitive data (SAD or CHD), not just if they DO. In the “As-A-Service” era, this could require many of your third party and “cloud” providers to be PCI compliant. An example is a managed firewall. If a third-party manages your PCI firewalls, that third-party probably does not directly access cardholder data, but they COULD, so they’re in your PCI scope.
Everyone involved in processing, storing, or transmitting sensitive card data has to be aware of their responsibilities. Unfortunately, ignorance is not an excuse, and a “don’t ask don’t tell” policy won’t work. Merchants, you need to make sure your service providers are aware that you require PCI compliance, and you also need to be aware of each provider’s PCI compliance status. Service Providers, you need be aware of your customers’ PCI compliance requirements and your own compliance status. Assuring compliance becomes much easier when merchants and service providers understand each other and work together.
