Compliance Unfiltered is TCT’s tell-it-like-it is podcast, dedicated to making compliance suck less. It’s a fresh, raw, uncut alternative for anyone who needs honest, reliable, compliance expertise with a sprinkling of personality.
Show Notes: The Struggle that is Getting Service Provider Responsibility Matrices
Quick Take
On this episode of Compliance Unfiltered, The CU Guys take on a topic suggested to us by one of our listeners!
The Struggle is real when attempting to get service provider responsibility matrices, is a challenge many in the assessment world face.
Have a listen and see if you relate! As a reminder, if YOU have a topic you think we should cover, please let us know. Send an email to [email protected] and we will add your topic to the list for a future episode.
Read The Transcript
So let’s face it, managing compliance sucks. It’s complicated. It’s so hard to keep organized and it requires a ton of expertise in order to survive the entire process.Welcome to Compliance Unfiltered, a podcast dedicated to making compliance suck less. Now here’s your host, Todd Coshow with Adam Goslin.
Well, welcome in to another edition of Compliance Unfiltered. I’m Todd Coshow alongside the prize at the bottom of your Compliance Cracker Jack box, Mr. Adam Goslin. How the heck are you, sir?
I’m doing good today, Todd. How about yourself?
I can’t complain, I can’t complain at all. This is a very special edition of Compliance Unfiltered as it’s coming to you by request.So today we’re gonna talk about how the struggle is real when attempting to get service provider responsibility matrices. I’m just a friendly reminder to our listeners as this one has. If you have a good topic for us to cover here on Compliance Unfiltered, feel free to drop us a note. Compliance Unfiltered at totalcompliancetracking.com and we’ll be able to add that into the mix. We look forward to hearing from you. So Adam, we received an inquiry on this suggested topic from our friend Paul at Confide. Give the listeners a little history about the responsibility matrix as it relates to PCI.
Well, you know, the prior versions prior to 4, you know, so 3, 2, 1 and before, you know, there was a requirement in there for having a responsibility matrix for the organization itself. And primarily, it centered around the service provider, you know, the company and then any of their service providers that they had that would assist with provisioning of services. And it was really more of a document to assist the organization with making sure that they kind of thought everything through. They were on a common page, both internally and with their assessor for, you know, who was responsible for what, you know, for this particular organization’s engagement.And up through 3, 2, 1, the requirement from the customer’s perspective was simply there was a, you know, some type of like a one-liner statement that would have to go into the agreements that they had with their customers as a service provider that the service provider would, you know, basically take care of, you know, any implications to their security or impacts to their cardholder data environment, things along those lines. So, you know, that was kind of the way it was all the way through and up to 3, 2, 1. But the Matrix had a, you know, kind of a driver. It was for the company itself and they just needed this, you know, kind of statement about how they would handle, you know, any material impacts or card data.
Sure, that makes sense. Now, despite the bare minimum requirements, historically, how were seasoned compliance professionals handling customer responsibility inquiries?
Well, different organizations over time were taking different approaches, generating different forms of documentation to help their customers out to varying degrees. I mean, honestly, some of them weren’t doing a hell of a lot.Some of them would generate some type of documentation that would help their clients out or lay the groundwork for their clients as they were going through their engagements, etcetera. Because as an organization serving customers in a compliant space, you’re used to getting a plethora of different inquiries. So in some of them, we’re literally putting together a kind of a responsibility matrix between the provider and their client. But honestly, I saw relatively few doing that, even though it was astronomically helpful to the organizations that needed to consume the services of that service provider. It was kind of a wild, wild west to be a good way to put it.
wild wild west indeed now. What has changed in the PCI landscape since 3,2,1?
Well, in PCI v4, they made a modification. And instead of just having that one-liner statement that said you needed to have this agreement with your clients as a service provider, they extended those responsibilities, great, finally, to basically say that the third-party service provider needed to support their clients’ inquiries for information to meet a couple of different requirements by providing a couple of different things. Certainly, the service provider’s compliance status information is one. And finally, they threw in there, hey, by the way, we’re going to need you to go put together a responsibility matrix delineating the differences between the third party service provider and the responsibilities of their customer and detailing out any shared responsibilities type of thing.So it’s written up at a high level. But really, the advent of 4 is really where that started to come into play, is under PCI v4. So you see a lot of organizations, I don’t know, I’ll call it, they’ve been used to doing what they’ve been doing and kind of getting away with it. I think the gear shifting is, in many cases, a little more grinding than in others, shall we say.
Fair enough. Now, I know TCT has been around this space for some period of time. What kinds of things does TCT do for its customers to support their inquiry?
Well, quite some time ago, and this is really on the backs of having worked in the space and helping various organizations, a lot of which were service providers, etcetera. So one of the things that TCT kind of did out of that process is quite literally having a tracking mechanism for all client inquiries and the mechanism by which you do the tracking, whatever. Some people are using ticketing systems, some people are using tracking sheets, whatever. The bottom line is that having almost the capability to produce a logbook of customer-related compliance security and compliance inquiries and logging, who asked what, at what date, who are the people that are asking, things along those lines. So TCT has kind of developed its own tracking mechanism to be able to keep that detail. We already had it in place before they had the PCI v4 modifications, but it was actually astoundingly helpful to already have that going because we were able to leverage that as part of the evidence for our own kind of compliance push, etcetera.One of the things that TCT did is we also generated detailed security-related documentation that we could generate so that it could be client-facing. We found that there were a number of organizations not quite as familiar with the PCI landscape, and so to assist and help them, we generated kind of a companion explanation document that would go out with our AOC, giving the recipient just kind of the roadmap for what is it that they’re reading, what they’re reading means, things along those lines. So one of the comments that I’ve given to organizations, the AOCs that you’ll go and you’ll see, in some cases you’ll see that the service provider literally is trying to skirt every X in requirements known to man, where TCT does the polar opposite. I want everything included that we can possibly include. We use a scope of sensitive data for our environment and then apply the rules, rigor, of the controls that would be associated with card data across all of the sensitive data. And so that associative document to the AOC, that really helps when you’ve got the organizations out there that are primarily used to gathering up SOC reports or ISO reports or so.So that one kind of really helps with the comprehension. And then I was talking a minute ago about generating these kinds of detailed security documentation responses. Well, whatever, we get standard inquiries around, tell us about your security testing or tell us about your business continuity and disaster recovery capabilities. So what we’ll do, and I like it because what we’ll do is that when we get in a new inquiry that I can see coming from somebody else, what we’ll do is we’ll go generate a new document that covers that topic. That way, next time, sure enough, I’m going to get the inquiry from another organization. Then we can go ahead and just use that documentation and be able to use it. So basically, what we’ll do is if we have to generate some form of new response material, then we’ll simultaneously go back and update our tracking mechanism with another column for that particular artifact.
That way, we know which clients got what last time, that type of thing. That’s also super helpful when you’ve got clients coming back around again.It’s funny, a lot of them will say, hey, what you gave us the last time was great, send it again. I’m supposed to remember when I did the last go-around. So it makes it nice because now I can go back, I can take a look at what was produced the last go-around. We can always keep the materials up to date, etcetera. So it’s super, super helpful and it makes the process streamline from the client perspective as well.
Absolutely. Now, what are some mistakes that organizations have been making when it comes to their customer security and compliance related inquiries?
Well, one of the biggest things that I’ve seen over the years is I’ll call it inconsistency of responses, more often than not. What I mean by that is, I’ll explain it in a second, what I mean by that is that let’s pretend for the sake of this discussion that the organization just says, you know what, we’re going to have support handle our security and compliance inquiries. Well, I don’t know, maybe there’s 25 different people on the support team. Some of them have been there for a week. Some of them have been there for eight years, you know, that type of thing. So you’ve got resources which their specialty isn’t doing, you know, doing security and compliance stuff. Meanwhile, they’re answering security and compliance questions. And so, gee, go figure, if I were to call the same company out with the same inquiry that went to three different people, then very likely I’m going to get three different responses back, you know, from that organization. So, you know, gaining consistency in those responses.Number one, you know, though, I’m going to call it centralizing the response realm for security and compliance inquiries. So that’s cool that supports handling your day by day support, that’s their job, they kick butt at that, great. But if you’ve got something related to security and compliance, go hand it to the security team, you know, type of thing. It’s not one person or, you know, maybe it’s two or three people, whatever. But some subset of the entirety of the group is the one that handles the security and compliance requests. And, you know, harkening back to what I was detailing out earlier, you know, the notion of having standardized documentation to be able to leverage when responding to the client inquiries, that just takes the variability I may get even across three security people. I now have eliminated that realm of, you know, variability through the use of standardized written documentation, etcetera, you know, that type of thing. You know, the other mistake that I’ve seen organizations making, even when they were, you know, kind of ahead of the curve, right, generating some form of either documentation or a responsibility matrix-like artifact for use in the conversation with their customers. You know, the one thing that I saw out there is a lot of organizations would tend to, I don’t know, make a set of documentation for their main offering. But they were forgetting that, well, you know, we really have, let’s say, four different service offerings. Well, each of those service offerings carries different responsibilities when it comes to security and compliance. So, in all reality, what you need is a set of documentation for each of your associative service offerings, you know, because that way you can get down into the nitty-gritty based on offering, be very clear about who needs to do what, etcetera. It all is astronomically helpful, you know, in terms of being able to apply a level of clarity to the, you know, to the client, you know, and really to keep them on the same page as you related to who has which responsibilities.
Some customers will request a copy of the rock or the FAQ. What are your thoughts there?
Well, I’m not a gigantic fan. The detailed rock and self-assessment questionnaires, those could, it depends on who wrote it up, what types of information they did or didn’t include when they wrote it up. The sack, less so, the rock almost assuredly, you know, would have, you know, kind of sensitive details contained within it. I’m not a fan of handing that document out.If the organization has its act together when it comes to being able to provision the kind of detailed responses that, you know, that they ought to be able to produce for their clients to help them and their compliance out, I think, I say keep the, you know, keep the rock and the sack to yourself. There’s definitely that middle ground to be had. You know, the bottom line is that when you’re oversharing with information, that makes me so frightened, honestly frightened, right? I’ve actually done experiments over the years, gone to an organization and said, hey, give me a copy and give me your internal copy pen-test, you know, type of thing. If they cough that, oh, that is a gigantic red flag. Just a gigantic red flag. If they’re willing to hand their f-ing penetration test over to somebody, what else are they sharing? You know, there’s a ton of sensitive information and detail in a, you know, in a full blown report on compliance, certainly in a pen test report, you know, etcetera, every single time one of these service providers is oversharing, they’re basically putting their entire customer base at risk because of the fact that they’re, that they’re sharing sensitive details that they shouldn’t be.So I would say instead, get your act together on your capability to respond to your, to your client’s inquiries on a security and compliance form.
That makes sense. Now, what can be done if the service provider isn’t providing a responsibility matrix when asked?
Well, a couple of different things. You know, sometimes I’m just like I’m on the blower with Bob over at the service provider and he’s not coughing it or whatever. You know, my first step would be to make an official request, AKA put a ticket in, send in an email to their support, make sure that it gets documented, get a ticket number, you know, etcetera, that way. And don’t include it with eight other requests. Make a singular standalone. Please provide me with your AOC and your responsibility matrix that details the difference between your responsibilities as my provider, my responsibilities as your customer and anywhere where we have shared responsibilities. So, yeah, I would go ahead and make that official request.I would make it singular. Once you’ve made the request, if it’s either falling on deaf ears, not coming about, etcetera, I’d escalate to leadership at that service provider. Give their leadership an opportunity to go get things addressed. If that, for whatever reason, also falls on deaf ears, then I would request, if they go through a third-party assessment, I would request the company to go ahead and get a meeting together with their assessor, if they’ve got one. So if they do and you’ve received their security compliance documentation, make the request of the company to speak with their assessor. I would also not shy away from making a request directly to their assessor because that will often gleam some manner of action because the company doesn’t wanna be perceived as, if you think about it, right? If the company is not responding to these inquiries, they’re basically already violating PCI requirements as a result of not responding to those organizations. So escalating to their assessor should get you some movement. Another possibility, if you’re going through this much hassle, switch service providers. I’m not a gigantic fan of trying to yell into the wind. And so, if you’re not getting, if you’re not getting, okay, it’s called a service provider for a reason. They’re supposed to be providing service. And if they aren’t, then yeah, maybe you need to go find one that will.So that’d be another option. Certainly as a kind of a last resort is making an inquiry. So let’s say I’ve got to go up against PCI. One thing that can be helpful is to go to them if they do other standards, SOC 2, ISO, anything else, and request any other compliance standard that they’ve got, because those reports may contain information which will be helpful for you. Unfortunately, to have to do the heavy lifting of interpreting, you know, where is the divisional line, the split of responsibilities between your organization and that of your service provider, honestly though, it ought not to be that challenging, but I do that as a last resort because that basically means now you got to go in and do a lot of heavy lifting that quite frankly, if the provider is PCI compliant, they’re already obligated to provision you with a response despite the fact you’re not doing it.
Hm. Parting shots and thoughts for the folks this week, Adam. It’s been an interesting one.
Well, it’s a responsibility of your service provider, not only to provision service, but also to be able to be clear about the responsibilities of those involved. They need to be able to clearly articulate what things as a service provider are they taking care of without anything needed from you.So, which ones, which ones for you as the customer are exclusively your responsibility? And especially on those ones where they call them shared, you know, I think there’s an inference there in PCI that if it’s a shared responsibility, then you would thereby go ahead and produce some detail around what aspects of it are shared. Is it mostly me, mostly you? You know, where does that boundary line fall? I would recommend the service providers of the world. Don’t leave it, you know, up to a guessing game. Don’t just put an X beside shared, but add some additional written detail, you know, what things is it the responsibility of the service provider? What elements are going to fall to the customer? But that way we can clearly call out where those boundary lines fall.You know, if you think about it differently, having that as a service provider, having that documentation in place actually helps the service provider to protect themselves, to have clarity with their client, with their customer. Everybody’s happier and, you know, and life moves on. But I can tell you that for those service providers out there that haven’t seen the site, that haven’t been, you know, haven’t generated a good quality responsibility matrix between their provisioned services and the responsibilities of their clients, get on the stick because there’s a lot of people that are going to be starting to ask more and more questions. And keep in mind, if you are ostensibly PCI compliant, then you literally under, I think it’s 1292, have a responsibility, yeah, 1292. You have a responsibility to support your clients as part of your own PCI compliance. So take that responsibility seriously because it could come back to bite you.
No doubt about it. And that right there, that’s the good stuff. Well, that’s all the time we have for this episode of Compliance Unfiltered. I’m Todd Coshow and I’m Adam Goslin, hope we helped to get you fired up to make your compliance suck less.
