S3 E22: The Path to SOC 2 Compliance

Audio version

The Path to SOC 2 Compliance

Transcript

Jordan Eisner (00:15)

Welcome back to another episode of Compliance Pointers with a frequent show guest Carol Amick. Carol good to have you on again.

Carol Amick (00:24)

Thank you, it’s good to be here.

Jordan Eisner (00:26)

But this time we’re not talking HIPAA and we’re not talking HITRUST. We are we’re talking SOC 2. That’s right, because Carol is also a CPA. She’s a Jane of all trades.

No, you’ve been a CPA for a good while. We don’t have to how long, but you have quite a bit of experience. In CPA things, you have quite a bit of experience in cybersecurity, information security, and really how organizations take controls and implement them and pass audits against them from a governance standpoint, policies, procedures, and technical controls as well.

And, you know, a question I know I have a lot of times of SOC 2 is, okay, you can design your own scope to a degree. You can design your own controls. Well, what does that really mean for an organization that’s going through that for the first time? And how do you make that meaningful? How do you make that not too onerous? These are the things that I think are very valuable for companies. So we’re calling this podcast SOC 2 101 or SOC 2 Basics. But ultimately, Carol, as a CPA and as the leader of CompliancePoint’s SOC 2 audit business, I think you’re a great resource to talk about some of this in this video today. So let’s dive into those very things.

How do you create and craft a scope? How do you identify what the appropriate controls are for that scope? And then how do you demonstrate compliance? And so what are the things that organizations need to know? So let’s talk about first, or anything you want to say to that to sort of set the table, and then we can get into the SOC 2 criteria and how we apply that and develop a scope. But anything you would want to add to start.

Carol Amick (02:14)

So I think when you’re starting when you you starting a SOC to let’s say you are being asked by one of your clients to do that. A SOC 2 is basically for a service provider demonstrate the controls around the services you provide so you need to keep that in mind when you’re setting your scope. Does that mean you need to include things like AP probably not your accounts payable is probably not relevant.

So you want to start by defining your scope and your scope is the services you’re providing that your clients are relying on your security for. And that’s what you’re trying to define it down to so that you don’t start worrying about all these things that aren’t necessarily relevant to those services. You want it to be narrow focused on the services that you’re providing that your clients are depending on you for. So that’s the first thing to do.

Sometimes people just start in on the controls, but you really want to make sure you really know what environment you’re starting those controls with. Make sure you define that clearly and got it outlined. You’ll have to do that eventually formally for your SOC audit, but if you have it least bullet point outlined or detail outlined, you’ll be ahead of the game all the way around.

Jordan Eisner (03:29)

I like that. You know, SOC 2 does not have to apply to your entire business. It has to apply to the services you provide your clients. And how those are secure in nature. So anything that goes into those people, you know, physical locations, you know your database is your systems, your applications, anything that could be tied or has some sort of direct or maybe even indirect relationship with the services you’re providing your clients and how you’re securing them.

Carol Amick (04:02)

Yeah, for example, indirect, you want to have a kind of an incident response plan that in a way for your workforce and people to report potential security incidents to you. That’s not really related to the service directly, but it’s definitely related protecting any data or information you may have of your clients and shows them that you’re committed to stopping problems before they become big problems.

Jordan Eisner (04:26)

So I think that helps paint the picture of what scope needs to look like. Now let’s talk about the SOC 2 criteria. Ready? All right, I’m going to go off the top of my head here. Security, availability, confidentiality, processing integrity, and privacy. And I’m not looking at anything. So thank you. Thank you. I could memorize five things. That’s big for me. So all right.

Carol Amick (04:47)

Congratulations.

Jordan Eisner (04:54)

Talk about these. know that security has to be a part of it. And the most common combination of those five is security, availability, and confidentiality. But I’m a company, I’m looking at this. Okay, now I understand scope. Anywhere that my service is, or anything that goes into my services and providing clients directly or indirectly and how I secure that. Now I’ve got these criteria and they have controls or at least standards tied to them. How do I pick from these?

Carol Amick (05:23)

So the control, you said, there are the five categories you talked about are based on the AICPA’s Trust Service Criteria. So you get some guidance there. They tell you what these things are. And as you said, security is for our for everybody. It’s based on the COSO framework. For those of you go back to the days of Sarbanes-Oxley, basically what are you doing to protect your system? And then you said you’ve got the other four options that you can choose from availability, processing integrity, confidentiality, privacy.

You’re picking from those based on what services you provide your clients and kind of sometimes maybe even what your clients have asked for in a contract, depending on what you’re doing. So for example, if you are a cloud service provider, AWS, Azure, Google, all of those people have a SOC 2. And they always have availability in there because availability is the backbone of what we want from them, right? Security and availability. We want that thing to be running 24 seven all the time. So they always pick the availability.

Other places that are doing more maybe batch processing or something, availability might not be as big an issue. Processing integrity. If you are doing payment card type stuff, if you’re doing cash transactions, you’re, they want to have one and one comes in equals two and when they get it back, it’s still equals two. So you want that processing integrity. So you’re picking these based on what your risks are and what your services are and what your client picks.

And confidentiality is kind of are you protecting the PHI privacy is you know what are you doing with it and how are you sharing it kind of thing.

Jordan Eisner (06:59)

Your healthcare past came on there for a second. Carol, did you hear that? Did you catch yourself?

Carol Amick (07:03)

Yeah, protected health information is protected and just personal information. Yeah. Our confidentiality information, depending on what your clients are sharing with you, you could be getting a lot of their trade secrets or something and how you’re protecting those. So there’s things in there. That’s how you decide. And you’ve got to have to decide. A lot of times for a first one, we will tell people pick security and then add on as you go. You don’t have to do all five of these the first time out, but you have to do security. Sure.

The other thing I want to bring up is you can choose to bring in other frameworks and do a SOC audit against them. You could use the PCI framework in addition to security. You could use the HITRUST framework for going back to my healthcare background in addition to security. You could pull in some disk controls. So if there’s some things that you want that may not be physically addressed with those five areas, talk to your auditor and consultants and figure out what can we do to show that to our clients.

Jordan Eisner (08:02)

The way to say those, know, SOC 2 plus HIPAA, SOC 2 plus HITRUST, SOC 2 plus PCI. Yeah. So, so let me reframe here then. And I think there’s, there’s two types of organizations that have a SOC 2. There’s companies that do it because they have to. For contracts or, you know, to win business or to compete. And those organizations, not all of them, they’re going to really do the least amount they need. And so if the client says we need to do security and that’s all they care about, they’re just going to do security. It’s not always the case, but I’ve seen it quite a bit where organizations are going to do the least path of resistance, what they need from a SOC 2 standpoint to keep business or to gain business.

The other is organizations that maybe that’s the reason too, but they’re also just proactively, they’re really using SOC 2 as intended to, and that’s to put good controls in place to protect this.

It’s those organizations I’m more so talking about when I say, all right, how do I set the scope for SOC 2? Well, it’s the services I provide my clients, that’s the scope and anything that’s tied to that. Now, how do I decide what criteria? It’s more so based on the type of services I’m providing, just to your point. If I’m processing a lot of transactions, then processing integrity is probably important controls to take from as part of the standards that define SOC 2 and implement into my scope of my environment, because that’s going to be meaningful for people I’m sharing my SOC 2 with.

Carol Amick (09:39)

Yeah, and I think what you talk about the two different types you’re talking about. They’re not mutually exclusive. A lot of times companies will start a SOC 2 because they’re being driven down that road by their client. And especially we see this with startups and then they start to realize there’s a benefit here in terms of being able to demonstrate to their investors, to their any new clients, etc. that they really are committed to security.

Jordan Eisner (10:06)

Building to your point other compliance obligations they have such as PCI and HIPAA into their SOC 2. We need to have some sort of third-party attestation validation as to our compliance with HIPAA or our PCI compliance. Well, we can build that in SOC 2 and create some synergies internally as a business and do these audits one time.

Carol Amick (10:35)

Yeah, so there are some things I think, you know, I think a lot of people are doing this really to demonstrate their and also to be honest, some of them are hoping you have a third category is a lot of our clients complain a lot about the giant 200 page questionnaires they’re getting from there. And they’re hoping maybe if they can’t. They can hand that off and say here, read this and see if you’re happy.

Jordan Eisner (10:55)

Great question. Unfortunately, sometimes, right? It’s going to reduce it. Is it going to reduce it greatly? Probably not. Well, let’s keep moving then. What happens if an organization can’t demonstrate compliance with the controls that they’ve scoped and decided to decide and craft for their SOC 2?

Carol Amick (11:26)

We kind of skipped a step. We talked about the trust service criteria and everything. Once you’ve identified those criteria, you’ve got to identify your controls that you do to do those.

Jordan Eisner (11:35)

Yeah, so before we talk about what happens if you’re not compliant with those first design, OK, we decided scope, we’ve decided criteria. Now how do we design controls based on that? Good point, go ahead.

Carol Amick (11:48)

The criteria are fairly high-level. For example, I’m looking at one right now. It says the responsibilities of internal and external users and others whose roles affect the system are communicated to those parties. Okay, that’s a little high. That’s a little vague. You’re going to drill this down into the control that you do at your organization to make that. And hopefully it’s something you’re already doing. And that’s one of the things you want to have somebody work with you on to help you figure out

What are you already doing that we can leverage for this? So for example, in this case, your workforce members are advised of their roles and responsibility in terms of protecting the system, in terms of security. That’d be part of that. Your contracts that you have with clients say, guys, you have to do things too to protect the system. Yeah, I have in the past walked into locations and posted on a bulletin board is the login ID for some service provider.

Well, that’s not really protecting the data. if you’re the service provider, you want to protect yourself and say, look, it’s up to you to have good security too. We can’t protect you from yourself, so to speak. So you communicated to the external user, this is your role and responsibility in this. Your role is to protect your access into our system. Your role is whatever it is, depending on the system. So we would say, you have a contract or something that informs the clients of that.

So that would be the control. You would have like a contract with your client. That’s your control. It’s an existing control. It’s going to meet the standard. Your workforce members have been informed of their roles and responsibilities via training, via signing an acceptable use agreement, whatever it might be for your organization. And you can show that and demonstrate that. So that’s how you’re doing that. You’re going to take the trust service criteria and you’re going to drill that down to how do you at your organization demonstrate that? What are you doing? And so that’s the this step that you know can’t just take these trisarabaricotria out of the box and go with them because they’re not written that way they’re written in a theoretical level and you’ve got to get them down to a practical.

Jordan Eisner (13:53)

Got it? That was helpful. That was a helpful prerequisite to the question I originally asked. What happens if you can’t demonstrate compliance with those controls?

Carol Amick (14:03)

So once you start the audit, you really can’t remediate. So what you want to do before you do an audit is do a readiness assessment. So you can see where you are in terms of remediating those controls. What do you need to remediate? What do you not remediate? And working with somebody who has like a CPA firm or somebody who has experience, they can kind of tell you this is critical or not critical. You can get a clean audit report in a SOC too, a clean opinion from a CPA like me even if there are exceptions.

Now, if there are exceptions, the CPA firm will look at those exceptions and decide, are they critical? Are they not critical? If they’re critical, you might not get a clean opinion. If they’re not critical, you will probably get a clean opinion with those exceptions noted. And in the report, you will say, here’s what we’re going to do to clean up this exception for our next report. Your auditor will work with you on that.

I’m trying to think of something that, know, for example, I was just looking at one, this isn’t one we did, but I was just looking at one the other day and the control was every year, every workforce member gets an annual review where they talk about their compliance with policies and procedures of the company, protecting data, et cetera. In this case, the auditor attested like 25 employees. There were maybe three or four that didn’t get that four or five that didn’t get that review.

They called it as an exception. They did not make it critical. They still got a clean opinion, but they did have that exception and that was something for them to to deal with. So you want to do that. You want you know that’ll be in there. But the reason you want to do a readiness is you want to know before you start going down the audit road. If you’ve got a critical thing, for example, your firewall is wide open and anybody could get in. I’m going to look at you and go, sorry, you’re not going to get a clean opinion because that security breach is just too big. That’s just opening up a ransomware that’s opening up everything. You got to fix this. That will be a critical breach and you want to know that so you can remediate it before you start doing your audit. There’s not really time to remediate during the audit because the audit is a look back over a period of time as a general rule. There are some exceptions, but yeah.

Jordan Eisner (16:12)

That’s one clarification, right? What you’re talking about the SOC 2 type 2 and for our listeners there are two types. We’ve been primarily talking about type 2, which is how these controls are working in a time period. Three months, six months, nine months or a year. The best practice is a year. But sometimes reports are nine, six months. Sometimes they’re even three months, although that’s probably not looked on as positively.

Carol Amick (16:43)

It depends. mean, a lot of times what you will see is somebody doing it the first time will do a three-month look back and their partners know why they’re doing a three month look back and the first audit that’s fine. Now, a year from now you’re doing your second audit and you only want to do a three month look back. That’s going to raise some flags. But the first time I don’t think it raises huge flags.

Jordan Eisner (17:01)

So with a type one, which is just point in time, Carol’s not looking over a period of time, can you remediate during the auditor? Still probably not.

Carol Amick (17:08)

Still probably not, but well, actually, yes, probably you can do a little more radiation and all that. The top one is really only evaluating the design of the control, not as much the implementation. The effect of that. So the type one is saying, OK, you have, for example, you put vulnerability scanning in place. OK, you’ve got vulnerability scanning.

It’s not going to go in there and say you did it every quarter. It’s not going to go in there and make sure you have a plan to remediate. It’s not going to go back and test to make sure you’re remediated.

Jordan Eisner (17:40)

It’s like the, you know, if you’re relying on a type one, that’s a trust thing. If you’re relying on a type two, that’s trust and verify.

Carol Amick (17:48)

I mean, SOC Type, Type 2, Type 1 is generally a first step. And, you know, I will tell clients of ours when they look at it, okay, are you sure this is going to be received because it’s not having been on the other side of the table and having reviewed SOC audits to decide if the company I was working for and dealing with our internal controls could rely on your internal controls.

That would not impress me. I would not feel like I had what I needed to convince my external auditors that this partner was protecting me. And so, yeah, that’s where you kind of get into that. You may still then get more requests for more information, more evidence from your partner’s guests. They’re like, okay, well, it’s great that you plan to do vulnerability scanning. Show us your last results. Whereas if you have a type two, it’s okay, we do vulnerability scanning.

And you know, high risk things are in your control is high risk things are immediate within two weeks, 30 days, whatever you set up. And we look, we test and we go, okay, yeah, 80%, 90% we’re done.

Jordan Eisner (18:55)

What if you do a SOC 2 type 2, you get a clean report with exceptions, you answer to how you’re going to remediate those by the next audit, the next audit comes around, they have not been remediated, is it a clean report with exceptions again that are critical or does that mean, well, you didn’t fix this so we can’t issue a clean report anymore?

Carol Amick (19:20)

The auditor would have the CPA would look at it once again from the point of view of what’s the risk right now not necessarily going back and looking at it and saying well you know you didn’t fix this in two years if it’s still the same problem it still has the same risk level you’d still probably get a clean report I just saw not one of ours but I just saw a report this last week that had that that

Jordan Eisner (19:42)

Therein lies perhaps some of the negative rub on SOC 2.

Carol Amick (19:48)

And I think the thing to realize, if you are relying on your client, on your server spider SOC 2, you need to actually read the report. Look at it. Look at those.

Jordan Eisner (19:57)

Who’s got time to read Carol, attention spans are about 40 seconds.

Carol Amick (20:00)

Well, the exceptions are generally in a table. You can find those exceptions and you can get that dealt with. And I think that’s a real key to do is to go find those exceptions and see if they’re relevant to you. They may not be. You may not really care that they didn’t do annual reviews on their employees every year. You might not feel like that makes a big risk to you, but they could be. I mean, I used to, we had a client, we had a company that was our medical record provider that had exceptions every year. And that’s what I would do is read the exceptions and decide that we have to have a complementary control because they had a gap.

Jordan Eisner (20:38)

I think that that could be a good podcast. How to read a SOC tooth. Could we and effectively read a SOC 2.

Carol Amick (20:42)

How to Yeah, we can do that next. Yes, sir.

Jordan Eisner (20:50)

That’s your verbal agreement? You’re calling me sir now? Come on. All right, well, wrapping up. Does it have to be a CPA firm that does the SOC, too?

Carol Amick (21:07)

Not as steady CPA firm to do the readiness to help you design your controls, but the audits must be done by a CPA firm. Our CPA, yeah, they have to be.

Jordan Eisner (21:16)

That was a softball to end.

 Alright, well good deal. I think it’s been very helpful for organizations going through this for the first time. They’re trying to decide why SOC to what does it even mean? What do you mean you define your scope? What do you mean you bring your own controls? ⁓ This is it right? This breaks it down a little bit now. Of course there’s details in between and I would say to any of our listeners or viewers and they got questions on those details. We’d be more than happy to speak to him. Hopefully send him on their way or maybe even partner with him on how we can help them prepare for and get ready for SOC 2 audit, because we do provide those services in addition to Carol and her group who do the audits. And we can be reached and go to our website, compliancepoint.com. You can email us at connect at compliancepoint.com. Carol and I are both on LinkedIn. We’d be happy to field any questions and inquiries that way. Until next time, Carol, thank you. All right, be well, everybody.

Carol Amick (22:13)

Thank you.