SOC 2 certification has become shorthand for security. It isn't.
Max Clark breaks down what SOC 2 actually demonstrates — and the costly mistake most buyers make when building their controls: anchoring them to a specific vendor's tool. When you replace that tool, the control breaks. And you won't find out until your auditor does.
Max Clark (00:00)
2.0
does not mean that the company is secure. In many cases, SOC 2 could mean the company is no security at all,
and what does that mean for your SOC 2? It is a royal nightmare. It's a pain. Just be careful with...
what
The IT market is built for sellers, playbooks are for buyers. This is signed, I'm Max Clark from itbroker.com. Today's topic, be careful with your SOC 2 controls. No fluff and off the cuff, here we go.
Okay, so let's talk about SOC 2. SOC 2 is not a, I mean, it is turned into this thing that it just isn't. ⁓ As its core is a demonstration that you as a company,
have identified critical controls for your business and that you can pass an audit showing that you were actually maintaining and enforcing and tracking those controls. So there's some things, I'm gonna love this one because I'm gonna get so much hate and comments over this. Yes, there's so much going on with SOC 2 we're not gonna dig into. Go ahead, pile on the hate. anyways, the point is SOC 2.0
does not mean that the company is secure. In many cases, SOC 2 could mean the company is no security at all, just that they have controls that they adhere to, that they've designated, and that their auditors prove that they can conform with. Doing business with a company and saying, they're SOC 2 certified, therefore they're secure, that's craziness. That doesn't mean they're secure at all. Really, it does not. So we have a bigger issue with SOC 2 that we should probably talk about.
But what I want to talk about right now, or what I'm talking about right now is picking your SOC 2 controls. So at some point, you're going to go through with your initial SOC 2 readiness process, and maybe you're dealing with a consultant, an auditor, CPA, whatever, to help you define your controls. And you're going go through a bunch of different lists and spreadsheets and questions and lines and yada, yada, yada. The warning.
Do not build your controls around a tool's capabilities. So if you have an existing tool, you have SAT, you've got EDR, you've got multi-factor authentication, you've got, let's pick any acronym, SWG, CTNA, CSPM, DSPM, DLP, whatever your different tool is. There's a certain degree of,
You know, let's call it like portability or rip and replace or selection commodity, right? Like you could in theory replace one, you know, SSE with another SSE and it should still give you SSE capabilities, but how they implement those change CSPM what data it's giving you out of your cloud security posture management, right? What you're getting out of that tool changes from one vendor to the other vendor. So if I've seen this a lot of times now and it sucks and it's really painful because if you build a control,
that's dependent on a specific vendor tools capability and then you change that capability, you are gonna find out that that capability has been changed when you go back to do your SOC 2 annually and then you're gonna find out your control is no longer there and now you're gonna have an issue with your auditor because you've established a control that you have to maintain but now you can't maintain your control and what does that mean for your SOC 2? It is a royal nightmare. It's a pain. Just be careful with...
what you choose for your SOC 2 controls. Do not base them around a specific tool's capabilities. Because when you change a tool, you're going to have an issue. Anyways, that's the playbook. More is available at itbroker.com slash podcast. If you're in the middle of a real tech decision and want someone in your corner, book an intro call at itbroker.com and buy tech without regret. I'm Max Clark. See you on the next one.
.png)
