Incident Response Plans

PCI Requirement 12.10 requires organizations to implement an incident response plan and be prepared to respond immediately to a system breach. Incident response plans are incredibly important to business continuity, and we believe that organizations should spend more time developing and testing their plan. The absolute worst thing that could happen in the event of an incident is no one knowing what to do next.

There are six basic steps to follow when creating an incident response plan:

1. Preparation – How are you currently preparing for a security incident? What are you doing to prevent an incident? How are you limiting the impact of an incident? Have you tested policies and procedures?
2. Detection and Identification – How would you identify an incident? How do you report an incident? How do you detect malicious activity? Do you have a specific team dedicated to incident response?
3. Containment – Has the appropriate personnel been notified? What evidence should be collected? Have you fully assessed the scope of the damage? How can you prevent further damage?
4. Remediation – Do you have backups in place? Has a complete forensic analysis been performed? Have you cleaned the system? Can you make changes to prevent a repeat incident? How can you test the changes?
5. Recovery – Have you securely restored the system? Do you have continuous monitoring to ensure problem is resolved? Have you replaced any lost files with backups?
6. Lessons Learned – What happened? What gaps can you now identify and remediate? Have you regained your consumers’ confidence? Have you reviewed policies and procedures to prevent future attacks?

PCI Requirement 12.10 requires organizations to implement an incident response plan so that confusion and lack of a unified response do not create further downtime for the business, unnecessary public media exposure, as well as new legal liabilities.

PCI Requirement 12.10 is rather short, sweet, and simple. It says that you need to implement an incident response plan and be prepared to respond immediately to a system breach. This is another one of those controls where organizations really ought to spend a lot more time in developing and correction. The last thing that you want to have happen in the event of a breach is standing around and wondering, “What do we do next?” This program needs to be tested and fully documented. There’s a lot of things that the PCI DSS calls out as it relates to the incident response program, but as part of this particular assessment, your assessors are going to be asking you for a copy of your incident response program and making sure that it contains the attributes that are called out within the rest of the requirement.

Service Provider Responsibilities

If you are a service provider, you must comply with PCI Requirement 12.9, which states, “Service providers acknowledge in writing to customers that they are responsible for the security of cardholder data the service provider possesses or otherwise stores, processes, or transmits on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.” PCI Requirement 12.9 functions in conjunction with PCI Requirement 12.8.2 to promote a consistent level of understanding between service providers and their customers about their applicable PCI compliance responsibilities.

The PCI DSS explains, “The service provider’s internal policies and procedures related to their customer engagement process and any templates used for written agreements should include a provision of an applicable PCI DSS acknowledgement to their customers. The method by which the service provider provides written acknowledgment should be agreed between the provider and their customers.”

PCI Requirement 12.9 is another one of those requirements for those organizations that are deemed as a service provider. What PCI Requirement 12.9 says is that if you are a service provider, you need to maintain some type of template or contractual language so that when your customers come to you and ask you for an agreement, you have something that says you are going to maintain all of the appropriate controls securely and that you can provide that to them.

What we found in the industry is that a lot of merchants and organizations who use service providers would go to their service providers and ask for this contract language and those service providers would not be able to provide that to them. If the organization that you work with is going to play within this PCI DSS space, it’s required that they provide you with that contractual language, or at least that language denotes that they’re going to be doing things in a compliant way.

Service Provider Compliance

PCI Requirement 12.8.4 requires that your organization maintain a program to monitor service providers’ PCI DSS compliance status at least annually. Your service providers don’t necessarily need to be compliant, but they need to perform the services that they’re providing to you in a compliant way. Implementing this monitoring program and knowing your service providers’ compliance status provides assurance about whether they comply with the same requirements that your organization is subject to.

PCI Requirement 12.8.5 further details vendor management practices and requires that your organization maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.

At least annually, you’re required to maintain a program where you’re monitoring your service providers’ compliance status. Understand that your service providers don’t necessarily need to be validated or compliant, but they need to be performing the services that they’re providing to you in a compliant way. This might be hard to understand, so I would recommend getting a hold of your assessor about this if you have any questions.

What we see in most cases is organizations that reach out to their service provider and ask them for a copy of their AOC. If your service provider can provide you with a copy of their AOC, you’re good for the next year. If they cannot provide you with an AOC, there might be a need for you to actually assess them or include them as part of your assessment that we perform on your behalf. In any event, your assessor is going to be looking for the evidence that you have to validate or to maintain this program around monitoring your service provider compliance.

Due Diligence with Vendor Relationships

PCI Requirement 12.8.3 asks organizations to ensure there is an established process for engaging service providers including proper due diligence prior to engagement. Due diligence is a key component of any compliance objective, but it’s especially important in PCI because the service provider will be handling cardholder data or could impact the security of cardholder data.

Due diligence efforts may include examining the service provider’s reporting practices, breach notification and incident response procedures, business continuity plan, details of how PCI DSS responsibilities are assigned between each party, how the provider validates their PCI DSS compliance and what evidence they will provide, etc. Compliance with PCI Requirement 12.8.3 ensures that any engagement or relationship with a service provider is thoroughly vetted internally.

You have to have a formalized program as part of managing your relationship with any vendors. PCI Requirement 12.8.3 calls out that you have due diligence that you do prior to engaging these entities.

What we look for, from an assessment perspective, is that you’re vetting these organizations and making sure that whatever services that they’re going to be providing for you, that it’s going to be provided in a compliant way. The PCI DSS does not necessarily call out what those requirements are, so from an assessment perspective, we don’t really get too in-depth, and we really don’t dig into what those particular things are that you’re doing as part of due diligence. However, we do look to make sure that you do have a due diligence program involved and that PCI DSS is typically pulled into those conversations.

Understanding Compliance Responsibilities

PCI Requirement 12.8.2 focuses on relationships with service providers and asks organizations to maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess or otherwise store, process or transmit on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment. Service providers could have a significant impact on your cardholder data, so compliance with this requirement is vital to securing it.

This acknowledgement provides evidence of the service provider’s commitment to maintaining proper security of cardholder data that it obtains from its clients. PCI Requirement 12.8.2 functions with Requirement 12.9 to promote a consistent level of understanding between parties about their compliance responsibilities. The PCI DSS doesn’t give us much instruction on the details of this acknowledgement, other than that the extent to which the service provider is responsible for the security of cardholder data will depend on the relationship and the service being provided. The guidance also states, “The exact wording of an acknowledgement will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party.”

When you establish a relationship with a new service provider that would interact with your cardholder data, you’re going to want to include a contract, or some type of language within a contract, where this third party agrees to maintain the security of the cardholder data or of those actions that they’re performing on your behalf such to the extent for those services and those things that they’re doing for you in a secure way.

Back in PCI Requirement 12.8.1, you’re asked to provide a list of service providers. What we do, from an assessment perspective, is we will typically sample that service provider list and ask for the contracts for those individuals. We will read those contracts looking for that specific language. There are situations where if that language does not exist, compensating controls can be developed. However, once again, it gets to be a pretty difficult conversation around how we’re going to meet these compliance objectives when you don’t have that language there.