For businesses, repeatedly answering the same question is a waste of valuable time and resources. You can expect this phenomenon to become increasingly common as you expand your PCI business with SMBs, because smaller merchants are more likely to have questions about becoming PCI compliant than your enterprise customers. At the same time, merchants are being told by experts like Marc Andreessen that outsourcing PCI compliance is, by far, the best way to get the job done: “From a technology standpoint, businesses either need to become first-class at security,…with first-class expertise and first-class funding, or they need to work with [cloud] vendors who are. … A lot of CIOs are becoming increasingly aware, especially at companies that haven’t mounted a first-class effort at talent and funding for security, that it is highly likely their cloud vendor is more secure than they are. And it’s highly likely that it has been that case for many years.”

But it’s not that easy for merchants to get the answers they need to make PCI outsourcing decisions. And the days when prospective customers were willing to sit through lengthy sales pitches are long gone. Most of today’s customers prefer to find answers for themselves rather than using the phone or email to talk to an actual person. So providers are wasting resources answering the same questions over and over. Merchants are trying to figure out how to find and evaluate PCI providers because they know outsourcing compliance is the right thing to do -- but, along the way, they’re discovering that they can’t get the answers they need without jumping through a bunch of hoops.

Save time and money with Responsibility Matrices

When it comes to PCI compliance, one of the easiest most effective ways to avoid having to answer the same questions day after day is with a clear and useful delineation of the division of responsibilities relevant to your PCI solutions - via Responsibility Matrices. That one step can reduce, or even eliminate, common questions like, “Is there anything I need to do to become compliant, or do you handle everything?” and “How do I let you know what I’ve done, and how do I find out what you’ve done?” Moreover, providing your Responsibility Matrices also makes you easier to do business with -- an important differentiator in the eyes of prospects and customers. So let’s talk about what Responsibility Matrices are -- and how publishing RMs benefits both you and your prospective customers.

What is a Responsibility Matrix (RM)?

A Responsibility Matrix is a chart that spells out each party’s responsibilities for fulfilling a certain PCI DSS requirement. The point is to eliminate any gray areas so that everybody knows who will do what, as well as when and how it will be done. Here’s an example of a blank Responsibility Matrix from the PCI DSS Council:

Photo source* When you provide multiple services, each service should have its own Responsibility Matrix (see Appendix B).

Each Responsibility Matrix should be accompanied by an AOC extra form for Service Providers – Section 2g clearly identifying the service being supplied.

** It’s important to remember that an RM isn’t just a customer service nicety. It’s a necessary part of fulfilling PCI DSS Requirements 12.8.1 through 12.8.5, which state that merchants must identify, list, evaluate, and monitor the PCI compliance of the providers (aka 3PSP or TPSP as seen in above graphic) they use. Specifically, a Responsibility Matrix addresses Requirement 12.8.5 (SAQ Question) “Is information maintained about which PCI DSS requirements are managed by each service provider, and which are managed by the entity?”

Note: It is important to understand that, while a document like an AOC (Attestation of Compliance) helps prove compliance with the PCI DSS, and can be considered a type of "Third Party Proof" (also known as 3PP), a Responsibility Matrix is simply a way to indicate who is responsible for which PCI DSS requirement and is not considered a type of Third Party Proof.

What are some RM best practices?

The PCI Council doesn’t specify how to format a Responsibility Matrix, but they do provide some examples (like the one above) that are useful. In general, a good Responsibility Matrix answers questions like these:

  • How does the service provider perform, manage, and maintain the required control?
  • How is the control implemented, and what are the supporting processes? (For example, a process for patch updates would include details of testing, scheduling, approvals, etc.)
  • How and when will the service provider provide ongoing assurance and/or evidence to the merchant that controls are met? (periodic reports, real-time notifications, results of testing, etc.)
  • Which activities are the merchant responsible for? (for example, assigning unique user IDs to merchant-employed sysadmin staff)

These answers are often included as notes in the individual boxes throughout a given Responsibility Matrix. Here’s an example of how this information can be formatted:

Bottom line, supplying Responsibility Matrices (along with AOCs) is one of the best things you can do to make it easy to get PCI done with your customers -- and even attract more customers for your PCI solutions. Additionally, keep in mind that a Responsibility Matrix is a living document, not a one-time task. If your support/customer success team gets repeated questions about the same thing, that’s a strong indication that there’s something missing. Scheduling periodic reviews of your Responsibility Matrices -- and soliciting input from your support team -- is a good practice that will save both time and money.

You may also like:

Why is it so damn hard to get an AOC from a PCI provider?