Considering SOC 2 Compliance? Here’s what you need to know.

Speaker 1: This meeting is being recorded.

Jim Goldman: Hey Ben.

Ben Phillips: Hey Jim.

Jim Goldman: It's weird in Zoom, I've got my normal background, but in the webinar, it's not there. Oh, well.

Megan : Hi everyone. We are just going to wait about a minute or so to let everyone join and then we will start the webinar. All right, Jim, do you want to kick us off?

Jim Goldman: Absolutely. Well, good afternoon everyone from wherever you are, may not be noon time. Good morning if that's the case. We're thrilled that you're here with us today. Today, we want to talk about something called SOC 2 from a number of perspectives. You probably see a lot about SOC 2 in LinkedIn or other places like that, but it seems as if it's always connected with someone trying to sell you something. And so what we thought might be helpful is to get a panel together and talk about SOC 2, really from a objective and more experiential standpoint and that's really the point for the panel today. Megan is our moderator. She'll talk to you about how to post your questions during the panel. We'll have some handouts for you afterwards, and basically we're thrilled you're here. Let's kick it off. So I think the first thing we'll do is we'll have everybody introduce themselves. As I said, I'm Jim Goldman. I'm CEO and co- founder of Trava Security. We're located here in Indianapolis, Indiana. We are risk and vulnerability assessment company, and we are also a cyber insurance company. We help a lot of our customers become SOC 2 compliant. Marie, I'll turn it over to you.

Marie Joseph: Yes, I'm Marie Joseph. I'm a security solutions engineer here at Trava. I work a lot with customers to get them to that compliance certification or just the readiness state for different types of certifications, whether it be SOC 2 or ISO, and I'm just here to help and I'm excited to talk about SOC 2 today.

Jim Goldman: Great. Ben.

Ben Phillips: Thank you everyone. Pleasure to be here. My name is Ben Phillips. I'm a director at Katz, Sapper& Miller or KSM CPAs and Advisors here in Indianapolis. I lead our IT audit and SOC audit team. Started my career in financial statement audit, naturally progressed SOC 2 in around 2012, when some of my clients were starting to get the SOC 2 wave. So I've been doing it since 2012. And outside of this, I'm a treasurer of the Central Indiana Information Systems Audit and Control Association, as well as Women In High Tech.

Jim Goldman: Well, thank you, Ben. Thank you, Marie. So Ben, let's just start off with kind of a high level introductory general kind of statement, opening question. Maybe just talk a little bit about what is SOC 2? I mean, it's sort of a funny acronym. So what is it? And maybe more importantly, why are your customers asking about it? What motivates a business to say," Gee, I really ought to look into getting SOC 2 compliant." And then what are the benefits?

Ben Phillips: Sure. Yeah. So first to start out with the acronym. So SOC is system and organizational controls. Specifically for SOC 2, at a high level what it is, it's an independent attestation assurance report over a service organization's internal controls relevant to either security, availability, privacy, confidentiality or processing integrity. A big difference between SOC 2, SOC 2 is just a reporting framework, way different than a security framework. So SOC 2 is just an independent representation of an independent CPA firm's audit of their internal controls as well as their description. Usually customers when they decide the right time to do a SOC 2 is when you're invested in it and you are willing to invest in the resources and the time to maintain your program. SOC 2 is, it's compliance, right? It's not the security that's built up to the compliance. It's a picture of what you did. So customers usually do it because mainly it's because one of their main customers is requiring it through a contract, or sometimes we see customers or clients doing it because they're in an industry where it's their competitors have it too and they want to showcase and level up to them. So hey, we have our security, we have our security controls in place as well and you can trust it because it's been verified by an independent auditor versus a self active station. Did I miss anything there, Jim?

Jim Goldman: No, that's good. I was just taking some notes. So just to reiterate, the motivation usually come due to a business motivation or competitive pressure, right? I thought you made a good point about talking about the difference between security and compliance and pointing out that this is a compliance attestation. You're compliant with the set of controls. But the other point that I really think is important to stress that you made is don't take this on if you're not committed for the long haul. This is not a one time thing. Right? It's like once you start, you are committed to maintain it over time. So maybe before we go much further, Ben, where you're coming at it from the auditing side, talk about what people could expect. Like every year you're going to have to do X, that kind of thing.

Ben Phillips: Yeah. Sure. And I'm going to maybe jump forward to just the attestation piece and kind of leave out this behind. Customers usually start with a SOC 2 type one attestation first. So there's SOC 1 type one and there's SOC 2 type one, SOC 2 type two. So every single year regardless, you're going to expect an engagement letter with your independent auditor. You're going to expect planning with your independent auditor to make sure they understand any changes to the system. You're going to have to furnish, provide your auditor with an updated description of the system, which is section three of the SOC report, which is more of a narrative describing the system. It has specific disclosure requirements that are described in an authoritative literature called DC 200. And the controls that are audited in your report really come from that description. So really planning, the auditor will work with you to schedule walkthroughs. If it's a type one versus a type two, generally a type one does not require populations or sampling of that sort. So a type one is really, and I know we'll get into this later, but the type one, the design of the controls as of a point in time. Type two, design and operating effectiveness of controls over a period of time. You can expect reporting after field work, follow up. If your auditor's not asking you any questions, you may be getting an easy audit, but over time that may come to burn you when one of your big customers that has the right to audit may ask you about this stuff. You're going to look kind of silly. I guess I'll pause there. I don't want to give it all away.

Jim Goldman: Well, no, no, that's good. We're going to dig in deeper as we go along. But again, an important theme here is that this is all about evidence. I think that's fair to say, right? Like it or not, no one's going to take your word for it that you're doing things a certain way. And so this is part of the long term understanding and commitment that not only are you doing these things, but you're carefully preserving evidence that you're doing these things. As you pointed out, whether it's for your third party auditors doing the audit, whether it's for your customers, internal audit, whatever, it's all about objective evidence. Okay. That's great. So if we understand a little bit about SOC 2, maybe let's bring it back to the organization and ask Marie to step in here. So Marie, in order to get there, in order to achieve kind of what Ben was talking about, where the auditors come in, what do you see as based on your experience, what do you see as kind of critical internal milestones that need to be accomplished prior to the SOC 2 examination and the auditors coming? In your experience in working with customers literally from day zero, what do some of those initial steps look like?

Marie Joseph: Yes. So the initial steps are typically defining your scope. So as Ben talked about earlier, finding those trust service criteria, figuring out which ones typically with customers that we've been dealing with, they just focus on the common control criteria. So the security aspect. Later they'll focus on privacy maybe, or depending on what their customers are asking for. But I think some of the main big milestones is documentation and specifically policies. A lot of customers come in with nothing written down or it's really it's ad hoc in certain ways and there's nothing specific. So getting all of that written and making sure it fits the SOC 2 framework is big and making sure you have all those controls in place. So the documentation and the technology I think are the big aspects and those are the big milestones. And as we talked about like the type one versus the type two, getting them in place is more of the type one. And then the type two's actually checks to make sure they work.

Jim Goldman: Yeah. That's very helpful. So I think we might summarize it as say what you do and do what you say, right? And where we start with a lot of companies, they may feel like they're doing the right things and they probably are, but they may not have it well documented. And so that's the say what you do part. And so Marie is absolutely right. A lot of the initial work is getting those policies and processes documented in a standardized format because I know from our own experience, different procedures develop over time, different people write them, they're stored in different places all over the place. And so it really is that first milestone is really getting your documentation organized and making sure it's accurate. You don't want to put anything in documentation that isn't truthful. Okay, great. And Ben, maybe we bring you back in here because Marie also mentioned the fact that there are different groups of criteria. There's the common criteria and you mentioned some of the other categories. So maybe talk a little bit about those other categories and maybe if you can, just based on your own experience, what percentage of the customers that you audit do more than security and are the other ones in some kind of popular order? I'm sure there's more emphasis now on privacy for example.

Ben Phillips: Right. Yeah. Yeah. So yeah, we had security, availability, processing, integrity, confidentiality and privacy. So security is really making sure the information and the systems are protected against unauthorized access, unauthorized disclosure of information and damage to the systems. Very commonly done by enterprise controls, CC one through five and then six through nine are more IT general controls ish, with some risk assessment approach tailored to CC nine. Availability really gets that, making sure the information and the systems are available for operation and use, to meet the entity's objective. So think about your SLAs regarding to system downtime and stuff like that. So make sure that you have suitable backups, making sure you've tested your business continuity plan, your disaster recovery plan, internet response, all that fun stuff. Processing integrity is really making sure the system processing is complete valid, accurate, timely, and authorized to meet your objectives. So very commonly there, we've seen it with specific things that you normally would think about it as a SOC one, like where the transaction can be pretty material to the end user and the end user needs to know that the system has controls to validate edit checks or certain stop gaps to identify any issues during the process. So that's what processing integrity carries. Confidentiality, information designated as confidential is protected to meet the entity's objectives. And then privacy is personal information is collected, retained, used, disclosed, and disposed to meet the entity's objectives. So those are the overall five. I would say obviously the most common is security. But if I was to pick the other, the top three that we see the most of would be security, availability and confidentiality. And then yeah, privacy is pretty specific based on processing healthcare information. I'm sorry. Yeah. Privacy healthcare information. And then processing integrity, we see it sometimes with organizations that maybe used to get a SOC 1 report that covers internal controls over financial reporting or certain aspects of transaction processing where their system is really doing that and the output is something that's impacting the customer's business in a significant manner. We've seen customers put in processing integrity just to give their clients that rationale of, hey, this is what we have in place to make sure that the system is processing and according to how it's intended. There may be edit checks. Again, there may be automated controls, manual checks, et cetera.

Jim Goldman: Yeah. Yeah. Very good. So on the privacy thing, I know we're here to talk about SOC 2 today, but I'd be interested in your opinion. In our experience, if a company is interested in having some kind of privacy compliance, it's far more likely that it's with EU standard known as GDPR or the California standard known as CCPA, California Consumer Privacy Act.

Ben Phillips: Yeah, yeah. No, 100%. I mean, they have to have a regulatory reason to do that and a big drive to do that. And honestly, the company says they need to have a SOC 2 over security in a year. As you said, generally, people, the companies, not generally, but sometimes companies just don't have anything documented. So security, I think that's something that you can scale. You can use best practices, but to add privacy off the bat, we wouldn't, unless you have like a privacy officer and you've done all the things, it's not something like you can just say," Yep. We can do that." No, there that big internal milestone.

Jim Goldman: Yes. Yes.

Ben Phillips: Totally different.

Jim Goldman: Yes. That's a very good point. Don't bite off more than you can chew, right?

Ben Phillips: Yeah. Yeah. 100%.

Jim Goldman: Yes. Yes. So we talked about these control families or control groups. And there is kind of a logical organization and of course the companies have work to do and that sometimes companies like Trava assist companies. Obviously Ben or other auditors come in when all that work has been done. And so along the way, excuse me, we have what are called control gaps. In other words, we want to do an initial assessment, get a current state of where they are and then we understand what the desired state is that's clearly in the SOC 2 standard, if you will. And so the matter at end is how do we close the gap between current state and desired state? Marie, would you like to comment on just your experience in working with companies from where they start to where they need to be? Are there more common or are there most common control families where we tend to see a need for work being done where we tend to see the gaps?

Marie Joseph: Yeah. I would say it kind of differs depending on the company and their maturity. A lot of the gaps, typically like I mentioned before, is documentation. And some of those documents include incident response plans and testing those plans and the disaster recovery. And most times they might have the plan, but they've never actually performed an exercise where they test it. And that's pretty big, especially when it comes to the type two and the monitoring phase. And those are typically some of the bigger gaps and a lot of the other ones, they don't typically have a quarterly security council meetings, which Trava helps with a lot. We set those up quarterly for our customers and make sure that documentation's all set up for when auditors like Ben come in and we can prove to them, oh, we have these minutes, they sign off on them. And they actually are taking their security seriously by looking at our risk registers and roadmaps.

Jim Goldman: Yeah. I totally agree with all of those. And for those companies that are in the software business, in other words it's a SaaS company, I think the other thing that we find is their software development life cycle is not again, it starts with documentation in their own minds. They may feel like they have a well- structured process and it's secure, but until it's documented, and it's one thing to document this is how we do it, but then you also have to monitor and say," And do we have checks in place and documentation and evidence to show that yes, every time we develop a new build or we release a new build to staging or to production, we do it the same way and here's the evidence." That type of thing. So yeah, I think we end up doing a lot of work with software development life cycle. Sometimes it's called secure software development life cycle as well. I think the other area that we often see a need for improvement is continuous vulnerability management. Many companies say," Oh, no. We do vulnerability management. We did a scan this year." Right. But it's like, okay, A, once a year is probably not enough. And B, just doing the scan is not enough. It's the vulnerability management. Management's the key there. What do you do with the results? Do you have evidence that you have an SLA, you have a threshold that you're supposed to fix a critical vulnerability and a high vulnerability and et cetera. And do you have evidence that you met those thresholds, that you mitigated those vulnerabilities according to your own internal processes? Yeah. Ben, do you have input on that? Like supposedly by the time you go in, the company is supposed to have all this worked out. But is there a control area, a control family where you are kind of more likely than not to say," Well, gee, you're not really where you need to be here."

Ben Phillips: Yeah. Yeah. And I would say this is something usually that we would, during the readiness phase when Trava's involved, we would be more lightly involved. Right. But just giving feedback. But I would say the areas of typical concern are usually companies haven't done a risk assessment depending on... Assuming a company's at like day zero, risk assessment, its required. That's a big thing. Vulnerability scans. That's a good, good call out there. That's huge. The fact that a vulnerability scan is like click the button, that's not really a control point. The control point is what comes after that. A vulnerability scan is conducted quarterly and high risk inaudible risk findings are identified, monitored or remediated and reviewed by the security council. That's the control. Logical security. We see commonly things again from a growth company, sometimes folks had access for convenience or just to get the job done. But when you're looking at the topic of least privilege and segregation of duties, same story with access reviews. We see commonly issues there with, hey, yep. We printed our IAM or we printed our user access listing. Okay, cool. But what did you do with it? What was the review? Hey, one big thing is a properly designed control, right? If the person that is responsible for reviewing the user access review is also responsible for provisioning access, then you have someone that's reviewing their own work. So in that case, a better design control would be, have an independent party also involved in the review and then documentation of that. Again, I totally agree with, as an auditor, we have the role of trusting but verifying, but also our documentation standards require if it's not documented, it didn't happen. And we have to have information in our audit file to support the testing conclusions that we're making. So documentation of those areas are extremely key.

Jim Goldman: Ben I'm so glad you mentioned access reviews because being on the other side of an audit and being audited in past lives, if there was one place where we would get burned, it would be on access reviews in that, especially in, you have a terminated employee or an employee leaves of their own accord and inevitably, you'd find one system where for whatever reason, their access wasn't removed. That's so easy to happen, especially with today's new IT where everything's SaaS based and there's a given user is logging in to pick a number 50 or 100 different systems and all that access has to be removed. And so it really does call for very tight procedures, as you said, well documented, but perhaps more importantly, very rigorously monitored that those procedures are being followed. So Marie, you mentioned early on that one of the first things we have to do is define the scope. So maybe elaborate a little bit more on that. When you first start working with the company, how do we help them determine what the scope of the SOC 2 is, and maybe talk about an example of what sometimes ends up out of scope. And so yeah, we'll start with you Marie and then we'll ask Ben that same question.

Marie Joseph: Perfect. So typically, that's one of the first things we ask a customer is what's going to be in scope. And that normally includes the trust service criterias we talked about earlier is figuring that out. What we normally do, as I said, is focus on the common criteria of security and finding out what is exactly what their customers are asking for. So it's really dependent on that. Typically, the actual person wanting the report, that client isn't, they don't typically want all of them. It just depends on what the prospects want, what their customers want. So that kind of determines what's in scope and then how your business is set up. So we work typically with SaaS companies, so software as a service, and they might have different controls and different criteria, depending on what data and information they're storing and that will determine what's in scope. Typically, we don't see too much that is necessarily out of scope I would say. Maybe if it is, it would be like physical controls because people are work from home now, but that's what I typically see.

Jim Goldman: Ben, how about in your experience? What do you see as in scope and out of scope?

Ben Phillips: Yeah. And I'll maybe hit it more from the... Marie, you covered the, what criteria and scope just extremely well. I'll probably hit more from just like the boundaries of the system. Right. We spoke more to going back to our logical access piece. Companies are using a lot of different software solutions. You'll have it where, I know you were in charge of GRC of an entire enterprise. And the enterprise is much different than the actual, like let's now laser focus into like what is SOC 2? So the boundaries of the system, if you're doing security, availability or processing and integrity, the boundaries of the system are going to be the systems used in the transaction processing life cycle. And if you're doing confidentiality or privacy, the system boundaries expands to the life cycle of those data sets. So what I typically do, even if a client, like I did this last week where a client's just doing security. But a logical way to think about what is the system boundary just for security is just think of it like availability as well. If this system went away, could we still do what we do? If yes or no, you can easily come to that conclusion. So that's kind of how we figure out what are the boundaries, what are the must haves? Because the SOC 2 allows the entity or the service organization to write their description and describe that. And that should then be vetted by the auditor. Yep, this makes sense. And then that makes the logical security access controls not be a surprise during the audit. It should not be because... The good thing about SOC 2 is it's not prescriptive. The bad thing about SOC 2 is also it's not prescriptive. So that's I guess my input on the boundaries of the system more from a system inaudible perspective.

Jim Goldman: Very good. So Ben, you alluded to this earlier, but maybe just expand on a little bit. It can get confusing with like, well, we got SOC 1, but we got SOC 2, but we got SOC 2 type one, then we get SOC 2 type two. So maybe just real slowly Walk through those.

Ben Phillips: Sure. And they should have done like a different acronym for the type, but it is what it is, policy. Type A, type B, I don't know. Right. Okay. So SOC 1 is really, so SAS 70 started, then SOC 1 was very common. The point of a SOC 1 is to benefit the external auditors of a company because the SOC 1 covers internal controls over financial reporting of a service organization. Very-

Jim Goldman: That's key. Financial reporting. Yeah.

Ben Phillips: Yeah. So think about payroll service providers, think about claims adjudicators, think about any other service that's as a result of what they're doing for you, they're giving you a number. And that number is going into your general ledger system. That's SOC 1. SOC 2 however, controls around security, availability, privacy, processing, integrity, confidentiality, more so security controls over a service that you're getting again, very vendor management specific. That's a big driver of it. Now, laser focusing out to type one versus type two, each report can be done as of a point in time or over a period of time. So generally, most companies do, a lot of companies do a type one first, and this is the design and implementation of the controls over a period of time. So a very common progression is to do a readiness assessment first. And let's say it's really at the decision of management of, hey, when does your customers, when have you promised your customers a report? Right. So it can take up to 12 months, depending on how long you make your type two to give your clients a type two report. Maybe you have a customer that you made a commitment in a contract to say, we have to give a SOC 2 by call it November of 2022. They will look... A type one is a totally normal way from a readiness first time to do type one. The benefit there is you get a deliverable. It doesn't have as much assurance as a type two, but it's a deliverable and it does describe your controls. It describes, and it takes all the reporting aspect. And it kind of gives you a nice, kind of a weigh into the water of what to expect before you go into the deep end of doing a type two. And then the type two, again, typically starts, the period typically starts the day after the type one is done. So when you start that type two, I mean, you really need to know and have a firm grasp of what are your control requirements? What are you doing? Because at that point in time, it's go time. And it's just important to see-

Jim Goldman: If I could interject right there. You have to be sure that all your evidence is being gathered, like everything's turned on. Yeah.

Ben Phillips: Yes. As well as monitoring. We see clients where they'll do an infrastructure change and they'll do something during the middle of the year and their control changed. Right? Well, if the auditor can't validate that that control was in place for a first part of the year, or if management's not evaluating as they're doing system changes that they have these other control requirements, hey, what are we doing? How is this mitigated? Just kind of proactively thinking about changes as in the lens of their... It's going to be presented in a compliance in a security attestation.

Jim Goldman: That ought to be documented in their change management procedure and change management policy, that those kinds of things get done.

Ben Phillips: Right. For sure.

Jim Goldman: So we actually have a related question in the chat and I want to encourage everybody to please place their questions in chat. So this came in from Cindy and she's saying," Is it possible to go straight to type two? If so, do you recommend that? Or should everyone really start with the type one?"

Ben Phillips: So do you want me to take that first, Jim?

Jim Goldman: Yeah, please.

Ben Phillips: Okay. Sure. Yeah. I mean, 100%, it's possible to go right into a type two. We see customers doing that, but more so they already had a pretty secure, a pretty, pretty mature security program. And this is literally just auditing what they've already been doing and there were not significant gaps, or control gaps. Honestly, I would recommend if you're doing a SOC 2 for the first time, be transparent with... Pull your critical customers that are expecting that from you to make sure that you can give them what they want. If they say," Hey, this is the first time, we're going to do a SOC 2 type one." This is very normal and you kind of lay out their plan and they're good with that, that's great. But if you have a commitment to say," No, we signed this agreement last year. Although it said SOC 2 in your contract, it meant SOC 2 type two." And if that's an important customer for you, you need to adapt to that. And I guess the one thing I would stay away from is if that's the case, make sure you give yourself enough time, because if you give your customer, like I think the minimum I've ever seen is a three month type two. We try and stay away from that because it doesn't give you that as an auditor, it doesn't give us much information to test. And your customers, if they know what they're looking at, they will see that. So if it is a... You have an expectation to do a type two, work backwards from that.

Jim Goldman: So I thought you made a very good point when you started to answer that question and it came down to this assurance as to the maturity of your program. Now that assurance can come internally because you've had a longstanding, mature security organization or can, that's really what the type one is. It's an assurance out of snapshot in time that things look good. Right. And so I think that's really the essence of the question. So let's dig into kind of the auditing process and without revealing any trade secrets, I mean, talk about this notion of sampling. And I know you're not going to literally for a given control, you're not going to look at six months of evidence for every control. So just give us some insight into how you do that without losing your mind.

Ben Phillips: Yeah. No joke. So obviously, you'll have a, like hypothetically let's say a company has finished their readiness and they have their control set, and let's say they have 55 controls total over security. Those controls are going to have different frequencies. Some may be quarterly, some may be annually, some may be monthly and some may be weekly and some may be ad hoc. Right. So ad hoc means when may happen. So quarterly, so for sampling perspective, most audit firms have, we take a statistical sampling approach, a representative sample of everything. So for quarterly, I'll pick two, for annually I'll pick one, for weekly I'll pick five to seven, it's all based on risk. But with ad hoc, the guidance that we have and most audit firms have is it changes with the number of occurrences of a control. So what we do, like let's first, a simpler one, let's think about a control, like new hired employees. Control example could be for all new hired employees, an access requisition ticket is completed and approved and verified to ensure that appropriate access was given for the in scope systems. Okay. If a company only hired nine people versus 38 people, the sample, the statistical sample would change based on that number. And so we'll get populations of that leading up. And this is generally only done for a type two. One big differentiator, what we look at at our team at least in a type one versus a type two is the guidance is somewhat gray as to what does the auditor need to look at to do a type one report. There's policies and procedures. There's show me, walk through controls. We take the approach of probably more conservative. We want to see an example piece of evidence for every single control to prove to us that it is designed and implemented.

Jim Goldman: It's actually been implemented. Yeah. That's key.

Ben Phillips: Yeah. Because for our perspective, we've seen clients come to us and knowing the type two starts right after. So type one is really our only shot to really help them make sure that their controls meet the bar. If you do this, I like to say like, if anything our team does and you give us and we document as part of the type one and then we do the next year as part of the type two and it doesn't quite meet the bar, I have something to show like, hey, no, this is what we talked about. I do not ever want to be having that discussion during a type two.

Jim Goldman: No, no, no, no.

Ben Phillips: It's kind of more of a client service perspective thing to us. We took the time during the type one to understand the design of your controls and make sure that you don't start the type two on assumptions.

Jim Goldman: Great. Great. So just to push a little bit more on that. So you do that initial sample, and it's not 100% great. What happens then? What do you do then?

Ben Phillips: Yeah, sure.

Jim Goldman: It's not 100% perfect.

Ben Phillips: Yeah. So hypothetically, yeah, so sampling... So type two, we're testing a sample of new hired employees, let's say six out of seven were fine. And there was one that was, it was not documented well. So that is a reportable exception in the report. There is a section from management to respond to that finding. Generally management will also do something to the tone of, although it wasn't documented, you can show screenshots of where they didn't get access or what have you to reduce the risk to a suitable level. And then we really, at the end of it evaluate all of the findings if there are more, as it relates to looking at the criteria that they relate to to develop the audit opinion. One thing we also try and do is we do walkthroughs, our control process walkthroughs during the audit period. And we'll do a piece of sampling in testing during the audit period, and then a piece of it afterwards. So in the event that anything comes up during the audit period, it's kind of nice because clients then can, they can act upon that. But if it's after the fact, it's after the fact. Right? So it gives them a chance to pivot. And maybe they do another more detailed access review over this risk. And then that's a more substantiated response that could reduce the impact of that exception. But obviously, yeah, if there's an exception that relates to kind of a one off thing, it's generally just a reported exception. But if it's a bigger issue, maybe a design issue, then we have a different discussion about report modification. And honestly, it's more and more common these days with, I mean, we're seeing it more, just the fight for talent. We see companies, they lose people, right? And when they develop these policies and procedures, the whole control framework didn't really pass along in a job description. So we're seeing more and more like, hey, we picked Q2 and Q4. Oh, Q2 access review didn't happen. But it happened in Q3 because we had turnover in that role. That's a thing we're seeing more and more.

Jim Goldman: That's interesting. Yeah. Yeah. So do you ever, so you got the one exception let's say. Do you ever then go and let's say you chose seven, like you said, and one out of the seven turned out to be an exception. Do you ever go back and then take a larger sample? Because maybe that one out of seven really was the only one out of the whole population which may have been 100. Right. So do you ever go back and take a larger sample?

Ben Phillips: We typically don't because the way our statistical sampling method works is we're expecting a larger population. So randomly selected, this should be an accurate representation of the sample. If we just do more, it would just be... So that's typically what we generally do, just because the way that the statistics with the confidence intervals work. So we typically do not do that. However, I have seen that done more so on the internal audit side where they're trying to, management wants to know okay, well, let's look at the rest of the period and maybe use that as just an internal governance perspective versus the purpose of providing a independent assurance report over controls over a period of time. So two different maybe directives there.

Jim Goldman: Yeah. Very good point. And actually, Eric, excuse me, Ben, that's an excellent segue because we want to talk a little bit about internal audit. And I know Marie, that's something that you do for customers in preparation, before the external auditors come in. So maybe talk a little bit about that from a process standpoint, and also from a deliverable standpoint, like what happens at the end of an internal audit? And then Ben maybe you pick that up and say, what do you look for as an output or an outcome from an internal audit? Go ahead, Marie.

Marie Joseph: Yes. So doing an internal audit, it kind of goes back to the topic we were talking about earlier with like in a gap assessment. So it can, you go through and you have gathering all this evidence for all the different control families and I go through to make sure that you have that evidence in place, that it's going to satisfy what the auditor is looking for. You don't want to give too much, too little, but this is what they're going to want, and this is what they're going to look for. So it's making sure the customer is ready themselves for the audit before the audit. So it's like having your own mini one, but it's where it's okay if there is a gap and making sure that you'll pass when your type one or type two comes along. And also making sure that you do have the technology in place for the actual control or the process itself. Because if it's not there not documented, then you're going to probably have a problem when the auditor comes in. And you really just want to make sure that you're prepared because one of the big things a lot of people struggle with is not having all their evidence ready to begin with. And it's a long process. It's not typically a one man type of job and making sure you actually have it all in one place is a big factor.

Jim Goldman: So I think you made a really key point there that it's not a one man job, that evidence comes from all corners of an organization. And so that's another thing to consider before you take on something like this is do you have senior management backing of it and is senior management willing to put the word out that this is a key corporate initiative? It's important. And when someone like Marie or anyone else in charge of internal audit for the company asks you for a piece of evidence, it's a top priority, because we've seen that struggle in the past before. So Ben, back to you know, what did you look for when you get evidence of an internal audit that you feel it's legitimate, it's been done effectively.

Ben Phillips: Yeah, yeah. Usually, I mean, and I'll take myself from the independent auditor's shoes of this. Marie is doing, very well said, the internal audit on behalf of management, working with management, making sure that they're prepared. From the external audit perspective, clients typically don't provide like all the gaps, because I want to say what the gap would be, what I'm hearing is that maybe they just haven't done that annual control yet. It's an annual control. I don't need to... That's more of like you assisting them and making sure that you're keeping them honest as it relates to their control requirements. So what I would be looking more for is the listing of controls that they talk through when they reviewed, making sure that those controls and the plan for those controls is consistent with the audit approach. But that's kind of more what we're looking for, at least from the external audit lens. If clients opened up the status of all their controls all the time, that may cause some more questions and they may not want to provide that to their independent auditor because we're auditing at the end of the period or for the period. A lot of this is more like helping them for the planning aspect to make sure that there's no surprises.

Jim Goldman: Right. So what I'm hearing you saying is you want an assurance that an effective internal audit has been conducted.

Ben Phillips: Yeah. I mean, yes, 100%. So yeah. I want assurance that clients are monitoring their internal controls.

Jim Goldman: Right. Right.

Ben Phillips: That's what I want. I don't want to talk to them like," Oh yeah, we haven't done that yet." Okay, let's not talk about that right now. And we try and do as much as we can to alleviate that. I send two months before, walkthroughs and resend the controls inaudible. Hey, this is what we'll talk about. These are the systems. Let's talk about any changes well before, so you have... So you can tie your shoes and pivot if need be.

Jim Goldman: Exactly. So we have another question that's come in and it's, we kind of brushed on it a little bit, but it's a great question. So once a SOC 2 type two certification is achieved, what activities are required between audits in that interim year. And this may be a hard question, hard follow up question, how many resources should be planned to ensure our company is ready for the next SOC 2?

Ben Phillips: You want me to take the first stab at that?

Jim Goldman: Take the first part.

Ben Phillips: Okay. I would say kind of like what we said with, let's say you've done a SOC 2 type two. So that means over a period of time, you've proved to your auditor that your controls are designed and they sampled your controls and they're operating. I feel that that would be a good representation of the number of resources needed.

Jim Goldman: Whatever inaudible. Yeah.

Ben Phillips: Because it's not like high trust where there's a phase two, or ISO where there's, you do a big audit one year and then there's like random types of controls. That's not how SOC 2 works. So expect the same type of audit every single year and that's a big differentiator.

Jim Goldman: Same level of effort. Yep.

Ben Phillips: Yeah. That's a big differentiator between SOC 2 and the other frameworks is that it's an annual examination of your control activities, all of the activities.

Jim Goldman: A word I sometimes use is perpetual. It's like a perpetual motion machine once you get it going.

Ben Phillips: Yeah. So I mean the activities required pretty simple. Look at your controls and make sure that those activities keep happening. Simply said. I guess maybe simply said, not simple but-

Jim Goldman: Yeah. And that you're monitoring those on an ongoing basis. That's right. We're starting to come up to the end of our time. We kind of have one more question and then I would open it up to both Marie and Ben, if you have any closing comments. And so if SOC 2 is on the horizon of anybody, what do you think they should be doing now so they don't get any unpleasant surprises? And obviously this is opinion, not fact, but this is based on your experience. Yeah.

Ben Phillips: Right. Yeah. I guess I would say yeah, from the legal, the opinions I'm saying are of Ben Phillips and not... Yeah. Right.

Jim Goldman: Exactly. Exactly.

Ben Phillips: Yeah. So I mean, I would say what you should be doing now. Risk assessment, you got to do a risk assessment. You got to understand what your risks are. You got to understand the services you're offering. Understand what legal, look at your contracts that you're giving your customers or the contracts that you're signing. Understand. One thing we didn't touch on Jim and Marie is that the SOC 2 is really based on your service commitments and system requirements that you make to your clients. So understanding what those are, what you're signing off on. So that's-

Jim Goldman: What have you promised? What have you promised to whom?

Ben Phillips: Exactly. And some of those larger enterprises may have a... You're getting the same level of contract that they're giving a fortune 12 company. Right. So really think about that. Based on that risk assessment and the controls that you've promised to do or agreed upon legally, develop a roadmap to achieving those. And then the one thing we didn't touch on is regardless of your roadmap, you got your controls, you got everything, get cyber insurance, make sure that you have that as a, it's a risk mitigation tactic. But still, I think just now more than ever, getting cybersecurity insurance is much harder than it was two years ago. So even having to go through that underwriting process may open up some good, oh, I didn't think about that. Or if anything bad happens, you want to make sure that you have an actionable claim and what can stop that is things that you said you were going to do, you're not doing.

Jim Goldman: That you never got around to doing. Yeah. Yeah. Right. Marie, how about you? What do you think are the things that people ought to be doing right now so they don't get any unpleasant surprises?

Marie Joseph: I think basically one of the big factors is just to be prepared and be prepared where you can, because one of the biggest surprises that normally comes up is when someone asks you to get SOC 2 type two or type one, and you're just not ready. You don't have any plan to even offer the prospect. And there's nothing worse than feeling rushed to do it because if you don't really have too much in place, then it is going to seem very chaotic and not knowing where to turn and how to gather that evidence or how to put in those controls in general. So just being ready and if there's not one in your future, I always think that having the preparedness and having a plan where you don't inaudible.

Jim Goldman: Have a plan. Yup. Yeah. You can always implement the plan at some point in the future. But the important thing is to have the plan. That's a very, very good point.

Ben Phillips: Jim, can I add one thing to that?

Jim Goldman: Absolutely.

Ben Phillips: I would say, even if like let's say you don't want to SOC 2. You don't need a SOC 2, at least in the next two years, but you have customers that are asking you about security all of the time, make sure you have a tailored response to that. The answer shouldn't be, no, the answer should be no, but we are doing this, this, this, this, this, this, and this. That is a much more polished response as to, and a confident response as to how are you safeguarding their data and what are you doing? And that can be done through the risk assessment, the vulnerability scan, all other things, the roadmap. I mean, SOC 2 is just the compliance of that. The independent audit, the compliance of it. The independent auditing of those controls. But in the meantime, make sure you have a good response because that's going to help you close more deals. It's going to help you during the process of having someone that can talk about your security when more and more customers are asking about it.

Jim Goldman: Absolutely. Absolutely. We just had a question come in and this really goes to you Ben. What can small company expect for a cost for a SOC 2 type one? And I'm assuming they're saying a SOC 2 type one audit.

Ben Phillips: Yeah. I mean, it really, it depends on the... I'm happy to talk about it offline, but it really happens to depend on the system boundaries, how many systems are-

Jim Goldman: inaudible right? Yeah.

Ben Phillips: And also the controls. The number of controls that are in place and if a proper readiness has been done, obviously before the type one. So there's a few factors, but again, most audit firms, we do fixed fees, but it's based on the expected level of effort to complete the audit.

Jim Goldman: Yeah. But I think the point that I hear you making is with a few kind of screening questions, you can give a pretty fair estimate. So it's not like we don't know, we'll send you a bill kind of-

Ben Phillips: Oh yeah. It's always pre agreed upon. So scoping questionnaire, if a readiness has been done, understanding the controls that are in place and we can evaluate that. Again, but it changes. So like we have a couple clients right now with like 50 some systems in scope. They're very large OnPrem, multi- cloud. We have some systems that are software as a service, smaller organization. Everything's on AWS.

Jim Goldman: One application. Yeah. Exactly.

Ben Phillips: Not overly difficult. So it really varies.

Jim Goldman: Yeah. Great. Great. I would just chime in on the last one. It's sort of reiterating what you said, Ben. I think the place to start, whether you know you're headed to SOC 2 or not is to have an annual risk assessment done. I think what I'd say is all risk assessments are not created equal. So make sure it's being done against a standardized framework, like the NIST cyber security framework or the Center for Internet Security, CIS version eight. If you're not looking at least 18 to 20 different control families, I would say your risk assessment isn't comprehensive enough. And then the other thing is a risk assessment isn't any good unless there's a risk register. And again, what you emphasize Ben, a risk mitigation roadmap. It's one thing to know what the issues are, it's another thing to know what are you going to do about those issues? So that's the roadmap part. Megan, just put some resources, some links to some resources in the chat. We are about at time. I'll give each of our panelists a chance to make any closing comments. Marie.

Marie Joseph: Don't think I have anything else. I think I gave everyone all the knowledge I have.

Jim Goldman: Okay. I thought you did a great job, Marie.

Marie Joseph: Thank you. You too.

Jim Goldman: You'd never know that this was Marie's first webinar. Ben.

Ben Phillips: I also do not have anything else to add this. This was fantastic. I appreciated the conversation. Great questions from the audience.

Jim Goldman: Yeah. Yeah. We appreciate the questions. We appreciate everyone joining us. Yes, there are resources in the chat. Thanks everybody for joining. We certainly appreciate your time. We hope you find it helpful. And if you do decide to pursue a SOC 2, by all means contact Trava or Ben at KSM. Thanks everybody.

Ben Phillips: Thanks. Have a good day.