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: Will Your Compliance Software Vendor Protect Your Data?
Quick Take
Most companies overlook vendor vulnerabilities in compliance. On this episode, the CU Guys reveal hidden risks in vendor relationships, from breaches to vetting gaps.
Discover tactics for evaluating vendor security, asking the right questions, and spotting red flags. Protect your data by understanding the stakes—data breaches, penalties, and reputation damage.
This episode is essential for those managing compliance and security, offering actionable insights to safeguard your organization.
Read The Transcript
Todd Coshow:
Welcome in to another edition of Compliance Unfiltered. I’m Todd Coshow, alongside the Cheez Whiz to your compliance Philly cheesesteak, Mr. Adam Goslin. How the heck are you, sir?
Adam Goslin:
I am doing good. I actually had one of those in Philly. You know exactly what I’m talking about. I got some instruction on how to do it properly, the whole bit.
Todd Coshow:
There you go. Anything you want to pass along to the folks? Or is it like your signature, you got to do it your own way?
Adam Goslin:
No, when in Rome.
Todd Coshow:
No doubt.
Well, listen, as we look ahead, so much of what we’re talking about in the space today is around data. From a compliance vendor standpoint, my question, and our question today for the listeners is, will your compliance software vendor protect your data? Now, to be fair, Adam, this topic feels a little like discussing eating your own dog food, but let’s tee this one up for the folks.
Adam Goslin:
It is very much that.
When we got into this space, my background had been in IT security and compliance for quite some period of time before we even started TCT. It’s been enlightening, I guess it’d be a good way to put it, to see the variability out there in organizations that one would think has your best interests at heart, but certain people never cease to amaze me.
It is possible that your compliance vendor is going to have an issue. If you want to talk about a more recent event where a vendor had let organizations down, then just go chitchat with some of the educational institutions about the good old Canvas breach.
The reality is that organizations depend on vendors. As a consumer, it’s your core responsibility to make sure that your third-party service providers are doing all of the things and staying bare minimum compliant. But hopefully, you have a much better sense of their care and diligence surrounding security, especially in this space, being a compliance software vendor. You got to make sure.
As you’re thinking, “We should be able to trust the compliance software vendors,” at the end of the day, it’s where their bread and butter is, being in the security and compliance space. One would think, if anybody should, it should be them.
The cold hard truth is every compliance software vendor is different. Not every single one of them is doing their due diligence to the best of their capabilities. Some people that have landed into this space are people with bags of money that just wanted to make a software product so that they could go turn a profit. At the end of the day, it’s buyer beware.
Some organizations take it very seriously. Others don’t and do bare minimum checkbox-style compliance just to get a piece of paper that tells you that they’re secure.
It’s a challenging landscape to figure out as you’re going through the process. Who am I dealing with here? Is this somebody that’s worthy of that trust or not?
There are several telltale signs that you can pick up as you’re going through evaluation and after active engagement. The stuff we’re talking about today certainly isn’t exhaustive, but it’s going to give folks a good solid starting point for going through and having their eyes open as they’re going through the process.
Todd Coshow:
Indeed. What types of vetting needs to take place during the sales process?
Because that’s where you’re really going to get to ask your questions before the answers don’t really matter.
Adam Goslin:
During that initial evaluation phase, as a consumer, you should feel empowered to ask very pointed questions around security and compliance status and approach, and things along those lines.
There’s a given here. Most organizations are going to start with, “Is this going to work for me? Functionally, is it going to work for me?” As you’re going into that process, one of the things that I’d recommend to folks is: are they only talking about the functionality aspects, or are they coming out through that sales process with, “Hey, we really want to talk to you about our security stance and how we do it”?
It should be a good sign when the vendor’s raising the security topic before you’re dragging them kicking and screaming into it.
When the security topic comes about, that’s where you pay attention. Who’s giving the answers about security and compliance? If it’s high-level, fluffy, directional stuff from a sales dude or dudette, then that should raise some concerns. Or are they going to bring the head of security and compliance program into the conversations to answer questions with granular transparency?
I want to be realistic about it here. There’s a balance for a good organization that’s answering security and compliance-related questions. I don’t want to feel like I’m getting sales answers, if you will, but in the same sense, I also have no right to their detailed internal documentation. There’s a middle point there to be had, but certainly who’s giving the answers should be a good indicator of their care in that security and compliance arena.
Better yet, as you start to go down that path, any organization that’s doing things appropriately ought to be asking to have an NDA in place before they’re revealing internal, moderate-level detail around elements of their security program.
If they just start spewing sensitive details or handing over compliance reports, etc., without an NDA in place, that should raise an alarm as well. Any company that isn’t vigilantly protecting their own security-related information isn’t exactly going to prioritize the protection of your data.
So pay attention to that as well.
Another, I feel dumb for having to say this, but when you do get their compliance documentation, whether they produced an attestation of compliance of PCI or some public-facing report from another standard, such as SOC 2 or ISO 27001, don’t just “thanks” and file it. Look at it.
You need to actually take a look at the documentation you got because, man, I’ve seen some crazy stuff over the years helping organizations gather up vendor documentation.
Things like: does the documentation cover the specific services that you’re planning on consuming? If the offering is a location-based style offering, did the paperwork cover the location that you’re planning on working out of? Was the assessment or audit performed by a third party, or is it self-signed? Are they running their program as an annual compliance event, or are they gathering and validating evidence for their security compliance program all throughout their annual compliance cycle?
Check those reports. Do they have any noted exceptions during their last assessment? The exceptions will provide a glint into how well the program is run.
Most organizations are going to try very hard to not have any exceptions. When you’re seeing them in there, just the existence of them is one level of a sign. But if you do see exceptions, were they circumstantial in the grand scheme of things or fundamental? How transparent was the organization in terms of their response and the correction to any exceptions that are noted?
Whenever you’ve got a vendor relationship in place, there’s a strong trust mechanism as part of that relationship. So you want to get to the bottom of those questions and gain the reassurance that you need.
It may be surprising to find that a vendor specializing in compliance software isn’t adequately compliant themselves, but it can happen and more often than one would think when dealing with vendors.
When it comes to their internal documentation, if the vendor is just throwing documentation out there that should be kept internally, that should be another big red flag. If they’re handing over detailed vulnerability scanning reports or detailed pen testing reports—
Todd Coshow:
You’re saying that’s a bad idea?
Adam Goslin:
Yeah. Here’s the way I look at it for our organization. We have a responsibility to protect all of our clients. As a result, even part of the standards that you’re operating off of, there are tenets such as only sharing data and information with those that need to know, not divulging detailed internal architectural elements of your solution, such as internal IP addresses.
If I’ve got a vendor that’s just coughing this stuff up, or even detailed internal policy documentation, if they’re not going to protect their own organization and thereby their clients by distributing sensitive internal information, then what else do you really need to know?
You got to trust your gut as you’re going through this process. Again, all of this we’ve been talking about is just during the sales cycle, if you will.
Todd Coshow:
That kind of leads perfectly to the next question, which is, does the vetting stop after the initial courting period?
Adam Goslin:
No, absolutely not.
Todd Coshow:
Caught you trying to catch a sip of coffee over here. Good move, I thought.
Adam Goslin:
I was hoping you were going to slow roll that one, but whatever.
No, once you go through and you’ve made your choice, you sign a contract and you’re actively engaged with them, your radar should still be up with any vendor. The compliance vendor needs to get put into the annual vendor vetting process.
As you’re moving forward with that relationship, you need to continue to keep an eyeball open for warning signs that may have been missed as you’re going through the sales cycles. Looking out for indicators of internal stress, structural issues, etc., those are the types of things to keep your eyeballs open for.
Todd Coshow:
What are some of the areas of focus once things get underway? You’ve gone through all the vetting, you’ve gone through all the due diligence, and now you’ve started.
Adam Goslin:
First and foremost, let’s look at different arenas as I go through answering your question, but these are all things to keep your eyeballs open on.
Support and their operational philosophy. If you’re submitting support requests and it’s clear your feel is that the organization’s trying to do as much as they can with as little staff as humanly possible, then that should be a pretty strong indicator of their operational philosophy.
If they’re going to shortcut the support of their existing client base, what other corners are they cutting internally? If they’re all about profit, less about security, then you have information to make a more informed decision.
One of the red flags that I would be looking out for is you go and send a ticket in or something and you get some automated response from the ticketing system, but it’s days or weeks before you hear from a live human being that’s actually doing something with your issue. If they’re that overloaded, then that should be a warning sign.
Internal process issues: did you request something be done, but it wasn’t completed or it wasn’t done correctly? This is a strong indicator that the organization is lacking in terms of operational procedure, things like peer-to-peer reviews or a lack of quality assurance in terms of people doing the work.
All of those are things you can keep your eyeballs open for in terms of support and operational side.
The next side would be change control and functional releases. I know damn well as I start to get into this that some of the listeners are smiling to themselves because whenever an organization is announcing, “We’re going to do a functional release of the software,” is everybody like, “Oh, crap, not again”?
Todd Coshow:
Oh.
Adam Goslin:
If it’s a shit show every time that there’s a code release, this is a symptom that’s synonymous with, “Oh God, they did a code release. Now we’re going to be dealing with bugs and production problems and whatnot.”
That’s a serious lapse in change control maturity and security-related processes is how you can read that. The mature organization should have devs that are doing unit testing and integration testing, making sure everything plays together in the sandbox. There should be peer-to-peer code review, security reviews, etc., to review the new code and see what impacts it’s going to have on the existing security stance.
If they can’t get baseline requirements for change control correct, what confidence level are you going to have that they really have their eyeball finally attuned to their security stance?
A completely different arena, if you will, as a sign is just general instability turnover. If you’re seeing massive turnover and constant position changes, those are huge signs of internal stability issue. If the organization’s unstable internally, then do you think it’s going to be a greater or lesser chance that that’s going to have some type of a negative impact on security and compliance? I’d say dramatically higher at that point in the game.
Another area that can be an indicator is if the organization’s getting gobbled up by some larger behemoth, gets acquired. Typically, when that happens, there’s some type of halo period. The new owners are just observing. But just wait two, three months after, maybe a little longer, who knows. The parent company basically goes in and starts making modifications in an attempt to monetize the acquisition.
They’ve done the acquisition, and now they have two or more sets of HR, accounting, developers, security people, etc. It’s infrequent that you’ll see an acquisition go smoothly without something invariably going sideways.
The key indicator is whether the organization’s going to remain effective at securing the data. Watch closely, ask questions, pay attention. But you should be able to see that just through day by day, assigned personnel to your account, whether or not they’ve got other turnover happening within the organization.
It’s one of the main reasons that when I built TCT, I said, “We’re never going to get acquired.” I’ve seen too many things go sideways. I want to take care of the clients. It’s not been the goal to just sell it. I want the clients to be able to trust that we’re not going to be compromising on security or compliance. We’re not going to put profits first, things along those lines. We’re here to do a job, and by God, we’re going to do it.
Todd Coshow:
What’s the ultimate red flag on this, Adam?
Adam Goslin:
At the end of the day, if you’re seeing the vendor landing with their name in lights, etc., then that should be a huge red flag. We were just talking about acquisitions, things along those lines.
As part of that, I would suggest not only keeping an eyeball on the company proper, but if you think about it, any of the organizations for the parent company, any of the other organizations that roll up under the parent company, keep an eyeball on all that. Because if there’s problems with one piece of the overall organization where they’re not giving a crap about security, what do you think the chances are that there’s other areas of the organization where the same mentality has taken effect?
Keep your eyeball on the organization, its parent company, its sister companies, and just be informed of what the hell is going on with those because that’s probably your ultimate red flag.
If they ignored all of the warning signs, if they still managed to navigate their way toward an actual breach incident, etc., yeah, that should be a solid sign that Houston, we got a problem.
Todd Coshow:
Parting shots and thoughts for the folks this week, Adam.
Adam Goslin:
There’s a real reason why TCT is different from a lot of the other folks in the space. I didn’t develop TCT Portal with a mission just to go and kick back and put my feet in the sand on a beach. The driving force for the organization was, and continues to be, helping people in the space, period.
I saw the pain that I went through in my own compliance career. I didn’t want other people to have to go through that. I wanted to provide services to the security and compliance community that are both helpful and cost-effective.
You’re not going to see these warning signs here at TCT. We welcome detailed scrutiny from our prospective customers. After launching the portal in 2015, we’ve still got clients that started with us day one. We take those obligations to our clients seriously.
Anybody out there, if you’re experiencing problems, issues, you have concerns, whatever, give us a shout. Be happy to have a chit chat and see how TCT can be of service to you.
Todd Coshow:
And right there, that’s the good stuff.
