Privacy, Security, and SOC 2 Compliance

Megan: Hi, everyone. Welcome to our live panel discussion. We are just going to give it a minute or two and let everyone join and then we'll get started. If you're joining us, we are just waiting a couple of minutes, or a minute more, I guess, to let everybody finish joining. Just as this discussion goes on, just know that it is an active discussion and we would love your comments and your questions and you can put those down below in the chat or in the Q& A section. We'll make sure we get those addressed throughout the discussion. All right, I think we will get started here. My name is Megan. I am going to be turning myself off, but I will be monitoring the comments and questions that come in from you all. Again, if you missed what I said earlier, please feel free to add your comments and questions in the chat or in the Q& A section below and we'll make sure to address them throughout the discussion. I'm going to kick it off to our moderator, Jim Goldman, who is the co- founder and CEO of Trava, which is a company created to protect small and medium- sized businesses from the potential damage of cyber threats through risk assessment, security strategy, and cyber insurance. Jim is an ex- FBI agent or a...

Jim Goldman: Task force officer.

Megan: Task force, I always get that wrong, and has served both on the sales force at Salesforce and has been a Purdue University instructor. So he is poised for this position as moderator, so I will kick it off to you, Jim, to introduce the other people on our panel.

Jim Goldman: Thanks, Megan. It's a pleasure to be here. We frequently offer these webinars for people that are interested in learning more about the different cybersecurity assessments and certifications that are out there. We hope you'll find this helpful. We know that it can be a very overwhelming and confusing topic so, as the old saying goes, there are no bad questions, so please feel free to ask questions as we go along. It's my pleasure to introduce our panelists for today and I'd like each of them to take a few minutes to talk about themselves, a little bit about their background, and their frame of reference or point of view on today's topic. So first I'd like to introduce Marie Joseph, so Marie, share with everybody your title and your background and your perspective.

Marie Joseph: Yep, of course. So I'm Marie Joseph. I'm a security solutions engineer here at Trava. I've been here for about a year and a half. My background, I come from straight out of grad school, so I went to Indiana University and I was in their grad school program for Cyber Security Risk Management. It was a two- year program, I completed it in one year, and it was through three schools, so I got the perspective of business, law, and computing. So with Trava, I've been working a lot with the compliance and helping a lot of our customers get SOC 2 or ISO certified. So currently, I'm in several different engagements, helping them through that process and helping with the baseline cyber risk assessments as well.

Jim Goldman: Great. Thank you, Marie. And Scott Schlimmer.

Scott: Hi, everybody. I'm Scott. I'm a cyber risk specialist with Trava and my role mostly is, when a new customer joins, we do a baseline cyber risk assessment, a little different than a SOC two assessment, and broader of here's where you're strong, here's where you're weaker, and here's where to focus in the coming months, but there's often overlap between the general assessments and what you need for SOC 2. My background, after grad school at Michigan, went to the CIA. So I focused more on the physical security side of things before, and it's a good reminder that... physical security and things outside of the computers are a part of all of this. Been working in the cyber industry now for about... probably approaching 10 years now, geez, and working on compliance, different frameworks, and SOC 2 is an important one and happy to meet you all.

Jim Goldman: Great. Well, thanks, Marie and Scott. I think where we'd like to start is with some basic vocabulary because, God bless them, I don't think that AICPA could have made this more confusing. So I'm going to start with, what is the difference between SOC 1 and SOC 2? And then I think I'll turn it over to Marie and let her talk about a sub- category of those classifications, which is type one versus type two. All right? So at the highest level, if we start with what's called a SOC 1, SOC number one, that has to do with financial reporting, so controls over financial reporting. Some companies, are required to do that, should do that. Their customers asked to see their SOC 1 report, et cetera, but that's not what today's webinar is mostly about. However, if you've heard those terms and didn't understand the difference, I just wanted to point that out. So what we're talking about today is not a SOC 1, we're talking about a SOC 2, SOC number two, and that has to do with controls, and we'll go more into this later. Controls around security, confidentiality, availability, processing integrity, and privacy. And Marie, I know that for SOC 2, we further delineate that or further break that down into a SOC 2 type one and a SOC 2 type two. So why don't you start by talking about the differences between those two and what each is used for and, from a customer's perspective, what should their expectations be for each of those?

Marie Joseph: Of course. So with the type one and type two, those are two different reports. They're usually about the same when it comes to pricing, but those reports are going to tell you a little bit something different every time. So the type one, I like to view it as a screenshot in time. So it looks at your security controls and all your other controls, according to your policies, and it looks at it just in one instance. So it's like a frozen snapshot, seeing how everything stands, if things are implemented correctly, and if your policies actually have the controls that it says it does. And then the type two is usually there's an observation window to test those controls, so this is where it has a testing period. So typically, it ranges from three months to a year. You typically see a six month window, though, for most of those reports. So it tests those controls and make sure there are no incidents in that meantime and that everything actually works. Most people tend to want to see the type two when it comes down to it between the two, because they want to make sure that those security controls are actually in place and working properly.

Jim Goldman: But on that journey towards the SOC 2 type two, we know that sometimes we take that interim step for the SOC 2 type one, because it's almost like a better than nothing, right? We can at least send that report to our customers to show them that we're on our way, we're making progress, and sometimes that satisfies potential customers as well, because the SOC 2 type one, again, there's a little bit of confusion about it sometimes. It's sometimes described as it means all your controls are effectively designed, and while that's true, the external auditors don't just want to say that they're more or less theoretically effectively designed, they want to see that they're actually implemented effectively as well. Granted, you may not have six months of evidence or a year of evidence or whatever, but they do want to see that those controls are in fact effectively implemented. So I just want to make sure that before we move on, use that question and answer box and just make sure that there's no confusion on SOC 1 versus SOC 2, and then SOC 2 type one versus SOC 2 type two. Eventually, the goal is always to get to the SOC 2 type two, and then that gets repeated on an annual basis. There's a testing window, as Marie said, where your evidence is gathered. That's what the auditors want to see, and basically, you never want to have a gap. So whatever date your annual report for your SOC 2 type two is issued, you want to make sure that the next year's is issued in that same annual time window. You never want to have it more or less expire because then you're caught on your heels, you may have to ask for a bridge letter from your auditor saying," Yeah, we're working on it," that kind of thing, and, depending on the customers you deal with, they may get unhappy with you. So that's the overall logistics. So, Marie, maybe just based on your experience, let's start off with some general comments about, why are customers wanting to pursue this? What's their motivation? What are the benefits? Why are customers asking for it? That type of thing.

Marie Joseph: Yeah. So most of it comes down to, for the customers, their prospects. A lot of prospects are coming in, asking to see what type of certifications they have, if any, and they usually come in the form of a security questionnaire. A lot of customers start getting these as they start to interact with bigger businesses and they want to make sure that you're actually taking security seriously. So with those questionnaires, there comes a time where they ask to see certain policies, whether it be information security, your privacy, network security, all these different types, and it normally correlates to being SOC 2 certified in some type of way, the type one or the type two. Most people ask for type two, as we mentioned before, but the type one's a nice confirmation that you're actually doing what you're saying before you go into that observation period. The benefits of having it is normally you have a wider range of customers coming your way, wider range of prospects, and keeping customers, too. A lot of times, as other companies mature, they request that you become SOC 2 certified in order to keep their business.

Jim Goldman: Thanks, Marie. You brought up the old Reddit security questionnaire topic and, in your experience, does it make security questionnaires easier or go away? If you have one of these SOC 2 type two certifications, then you can just send them the management letter, which we'll talk about in a second?

Marie Joseph: Yes. A lot of the times, once you have that, normally all the questions go away. You can send them that report and then it eliminates almost all of the questions, if not all of them, and that's all you need to send off. Once you have that stamp of approval, you're pretty much good to go, in most cases.

Jim Goldman: Okay. So let's dig into that a little bit, because I know we've spoken to customers before where they say," I'm happy to do this certification, but I'm a little bit uncomfortable with sharing a detailed report that talks about all the security controls that we have in place, and I don't necessarily want my customers knowing all that information." So how does it work that we can assure our customers that we do have this SOC 2 type two certification without more or less oversharing about the nature of the controls that we have in place that we know the external auditors had to dig into in detail and look at the evidence of?

Marie Joseph: Yes, your external auditor will give you a letter, typically, and if they don't, you can request it from them. This letter will give you a summary saying that they observed your SOC 2 in all your security in a time window, whether it be the type one or type two, and they will say that you passed and that the controls are implemented properly. If there are any sort of discrepancies, it will say that, but normally, at least with us, you're in good hands, so there aren't any gaps and your results will be really good. You send that letter off to any anybody asking for it, so that letter just gives a good summary. It doesn't give any details about where there could have been issues or how it's implemented; it just gives the overall," They are certified by a third party certified auditor."

Jim Goldman: And that's pretty much accepted industry best practice now, so it's not, any of the folks on the webinar today, if they were to get SOC 2 certified, it's highly unlikely if you sent that management letter that you would get any pushback or get requested for additional information. So let's talk one more scope question, and then we'll maybe dig into the process a little bit. As I alluded to before, SOC 2 has about five different, I'll call them, flavors or bunches of controls that some are required and some are optional. So the required controls are sometimes referred to as the security controls. They are also sometimes referred to as the common criteria, or you might see an abbreviated CC, and those terms kind of get used interchangeably, so if you ever hear anybody talking about the SOC 2 common criteria, those are the security controls. And that is the basis, right? That is the part that's more or less mandatory. You can't get SOC 2 certified without putting in place those security controls. That's why they call them a common criteria; you have to start there, that's the foundation. Now, in addition, if you want to, you can also add additional controls in categories that are named availability, processing integrity, confidentiality, and privacy, but that's completely optional. Marie, keep me honest here: in our experience across our customer base, I only know of one customer that has sections of controls other than just the common criteria, other than just security.

Marie Joseph: Yeah. Most people just focus on the common control.

Jim Goldman: Yeah, exactly. So if anyone on the webinar today is being encouraged to do more than that, I wouldn't necessarily push back on it, but I would definitely dig into what the need is, et cetera. Maybe talk to us, we can help you with that. Okay. So with that said, maybe, Marie, talk about how an engagement would typically start. So new customer, and talk to them... Initially, it was determined that in a reasonable amount of time, they wanted to get SOC 2 type two certified. Let's lower the anxiety here and just talk about what this engagement usually looks like as we start.

Marie Joseph: Yep. So typically, most of our customers, they start this engagement just by doing our baseline cyber risk assessment. So with that, it gives us an overall how your security posture based on the inaudible survey. We evaluate that, and from there, we're able to tell where you stand with the policies and controls. So then that goes into the compliance engagement where we start off with evaluating if you have policies, and if not, we start by creating those. If you do have them, we evaluate to make sure you have all of them that fall under SOC 2. If there are any missing, we perform a gap analysis in that sense. So everything starts with the policies and then from there, you will know what controls you have to have implemented, so then we can evaluate where those gaps are with the actual technical controls and other operational type of controls. From there, we will work through that. Typically, it'll take a lot of task and action items and gathering the evidence from those controls. So most of the work will come from the policies and then making sure the policies are actually working like you say they are, so making sure you're not painting yourself in any corner and that you're doing everything you say, because the auditor will come and ask where everything is depending on those policies and that's where the big evidence pieces come in. Then, once you collect all the evidence, that's typically when I will do an internal audit for you. So the internal audit is a piece that typically has to be done for all auditors, and that will identify any gaps before you go into the actual audit with a third party auditor.

Jim Goldman: Great, great. We just had a question come in on the Q& A. When you talk about evidence, Marie, what does that typically look like? Is it screenshots? Is it logs? Is it all the above?

Marie Joseph: Yes. It's going to be all of the above. In some cases, it's honestly going to depend on the auditor. A lot of the things are going to be... Word documents, Excel spreadsheets of you logging certain information, logging assets, or just screenshots that certain meetings and meeting minutes have been held and making sure you actually are staying on top of everything. So it's just a wide variety.

Jim Goldman: It is a wide variety. The way I like to describe evidence is anything that you claim that you are going to do in your policy or your processes, you have to somehow be able to show that you actually did those things that you claimed. So Marie, you mentioned that the way we really start off is to get that baseline. You always want to start off with that initial assessment to understand where you are and identify the gaps, and Scott, that's really your bread and butter. That's what you spend most of your time at Trava doing for our customers. So maybe shed a little bit of light on what goes into completing one of those baseline cyber risk assessments. What's the nature of the different types of information that's gathered? How is that information gathered? How's the sausage made, if you will?

Scott: Yeah. So we start that off with a survey and we try to make the questions as simple as possible, so you just go through and say," Okay, we are doing this... We're not doing this, maybe, we are doing this at a semi- mature level, or we're doing this with a standard process, or we're doing this with a policy that guides and standardizes the process even more," and then we also run vulnerability scans and that gives us a little more insight into different strengths and weaknesses. From there, you can often find categories where really you should focus here in the beginning to get the most bang for your buck, the most advancement in security and reduction in risk for the least effort and investment.

Jim Goldman: Exactly right. Thanks, Scott. So just dig in there a little bit, what could a customer expect to see in this assessment? In other words, is it just," Here's where you are, best of luck, see you later," or how does that work?

Scott: Yeah, that is the next step, definitely. If you're weak in one area, the key thing is what should you do to get stronger? And part of that is we create a roadmap, and the roadmap has very specific steps of implement multifactor authentication for administrators, for people logging in from afar. We try to make it very tangible and," This is the way you do it. After you do that, prioritize. Here's priority two. After you do that," and to make that as clear of a roadmap as possible.

Jim Goldman: Yep, absolutely right. Absolutely right. So just pulling on the evidence thread a little bit, it sounds like with all these screenshots and files and archived notes and so forth, it could be a little bit difficult or overwhelming to keep that all well- organized and have it be just so when the auditors arrive, and so there's this category of technology now, I know that maybe some of the people on the call may or may not be aware of, called compliance platforms, distinct from the Trava platform that we alluded to that does the vulnerability scanning and risk management and so forth. So, Marie, I know you have a lot of experience with compliance platforms and helping our customers manage that, so maybe talk a little bit about compliance platforms these days and what you see.

Marie Joseph: Yes, of course. I've had different experiences where I've had engagements where they have compliance platforms and when they also are doing it manually, and with the compliance platform, I can honestly say it's a lot easier and productivity is a lot better. So in some cases you can find them ranging from different prices, but if you have one, it's going to change your game completely. A lot of our customers use them to store all their evidence, so every year, when it comes time for an audit, everything will be in one place and it helps you with making sure you're collecting evidence in a correct cadence. So when an auditor comes in, they'll ask for a piece of evidence from each month, and in some cases, those types of platforms can help automatically pull some of that evidence. Other ones will give you warnings or notifications that you need to manually put it in, but with those notifications, it's helpful to make sure you're staying on top of that and don't have to go back and dig up evidence when the audit comes, from five months ago. It's just making sure you're on top of it so when the audit comes, you're not overwhelmed. When it comes to a manual process, sometimes those are forgotten, those notifications, and you have to go hunting for all that evidence. Meanwhile, with a platform, it helps keep you on a cadence and keep you organized.

Jim Goldman: Very much so. It's one of those things that it's kind of like, why weren't we doing this years ago? I mean, compliance platforms are a relatively new category. When I did my first ISO certification in 2011, there wasn't such a thing, and so we used to say... we did compliance and certification by emails and spreadsheets. That's literally how we did it. I can tell you firsthand, it's a whole lot more difficult and it takes a lot more people's time because, without that compliance platform, as Marie alluded to, that you can more or less help organize your work throughout the year, what would happen is it would come to be audit time, the external auditors would come in, and it was like everybody in the company had to drop what they're doing and was scrambling together evidence at that last minute and meeting with auditors and explaining processes and so forth and so on, as opposed to just having this even level of effort throughout the year and putting everything in that compliance platform, you give the auditors access to the compliance platform, all the evidence is there, they look over all the evidence. They then have just a few questions for clarification, et cetera. A few meetings, the whole thing just goes so much better. It's fairly amazing, really. So Scott, maybe this one's for you. We have a question. So what are the control gaps that Trava commonly identifies that require the most remediation? I mean, you've done a bunch of these baseline cyber risk assessments now, and as we know, you create the risk register based on the control family. So maybe, what are the top three off the top of your head that you think you most commonly see on a risk register?

Scott: Oh, geez. People definitely are... companies are all over the place and we do tend to work with a lot of smaller and mid- sized companies. Some might not have much in place at all, so in that case, we're talking square one. So Marie talked about the policies, a lot of companies, and maybe some of you in the audience, don't have policies and are thinking," Oh no," but it's normal for a good chunk of companies, so that's okay. I'd say policies is a big one. I don't know if there are any... some of the foundational ones.

Jim Goldman: Continuous vulnerability management I know shows up quite often.

Scott: Yeah, that's a big one for sure. Some of the foundational ones are even just, do we know what inventory we have and what software we have?

Jim Goldman: Asset inventory. Absolutely.

Scott: inaudible we control those things and a lot of others build on those. Things like training can be hit or miss.

Jim Goldman: Yes.

Scott: Really, a lot of the gaps come up often and so I think the main takeaway would be, if you have gaps, it's just good to know what they are and address them because a lot of them are frequent.

Jim Goldman: Yep, and I think the other thing to clarify, I'm glad you brought up the asset inventory as kind of foundational, another misconception about becoming more secure, becoming SOC 2 certified, it's almost like the notion that there's a pill for every health problem someone could have. So if you take that to security, there's this mistaken notion that there's a magic security tool out there to solve every security problem and it's just a matter of buying a bunch of tools and you'll be fine, and unfortunately, it's not that simple. As I always like to say, a random collection of security tools does not a security program make. The way you make a good security program is doing this initial planning, understanding what you have in place, understanding your assets, understanding what you're trying to protect, understanding the physical infrastructure that you have. In other words, what's the nature of your network that leads to where your information, your data assets, that's really your crown jewels, where is that stored? What are the various layers of protection around that? Then you get into the technical controls, but before you get into the technology, I think it's important for people to understand that there are some very... I'll call them almost vanilla processes that need to be done, and it's like, do you understand the map of your assets? Do you understand the scope of your system? And that's really the first big deliverable on the path to SOC 2 certification. Marie, I know you help our customers a lot trying to put together that what's called the system description, so maybe talk about that journey for customers. How do they get that system description done and why is it so fundamental? Why is it like that first foundational building block towards the SOC 2 certification?

Marie Joseph: Yep. The system description definitely outlined what you exactly are going to be auditing, so it defines what... It gets you started on the asset inventory, almost. You have to define what softwares you're actually using and everything, too, so it gives that foundation of more of the scope in a way, and seeing where you have certain technologies already in place, what other third parties you're actually using to define that, and the system description can be kind of lengthy so it takes a lot of time to figure out what exactly your company is auditing against and where the security actually lies, and that's just the overall of it, I would say.

Jim Goldman: Yep, very good. We've just had a really good question come in that goes more or less back to the top in terms of the alphabet soup of all of the security certification standards that are out there, so I want to go back to it. It says, is the SOC 2 certification accepted globally, in your experience, particularly European customers sensitive with GDPR, and how does SOC 2 differ from GDPR? Great questions. So let's take them one at a time, and Scott and Marie, please chime in. So SOC 2 is a North American standard. The standard itself is defined by the AICPA, American Institute of Certified Public Accountants. In my experience, it is almost the default for customers in North America to ask about and look for. However, outside of North America, and in some cases inside North America, especially from larger customers, enterprise customers, they are far more interested in a different security certification, which is ISO 27001. ISO 27001: 2013, the 2013 version of it, is the default international standard for information security programs. Now, the second part of the question was saying, and what about GDPR? And I'm going to ask Scott to elaborate on this, because his expertise is very much in privacy. So at the very top, we need to distinguish between security and privacy, and although they're related, they're actually two different things. GDPR is a regulation mandated by the European Union Commission. It's not a standard, if you will; look at it as a law passed by the EU having to do with how personal data for European citizens must be handled, regardless of where your company might reside. So it doesn't matter that you're a US based company; if you handle personal data of European citizens, there are exemptions of course, but in general, you need to be GDPR compliant, and we can talk more about that in a second. But that's the main thing I want to talk about is the difference between security and privacy. GDPR is the big European one. In the United States, CCPA, which is the California Consumer Privacy Act, Protection Act, something like that, it is the most common one in the United States that our customers are being forced to comply with that we help them be compliant with. There's one coming out in Virginia, there's one in Utah, and now there's some legislation in the House that supposedly is going to pass... could take years. Supposedly, there'll be a US based GDPR compliant, so we don't have all different states having their own. So Scott, let me turn it back over to you and just talk about privacy and the difference between regulation and certification and that type of thing.

Scott: Yeah. So Jim mentioned that most of our SOC 2 customers, they have the option of doing these add- ons beyond the common core, and typically do not. And there is a privacy addition, and really, that will not cover you for California or for Europe. Privacy, it's a little bit of a bigger beast to tame, and a lot of what we're talking about here are security controls. A lot of privacy, it does include security controls, but it also includes internal processes to make sure you're not collecting too much of people's personal data, and then basically rules you have to follow that governments want you to follow to protect those people's rights. So you have to know, okay, if I have information on you specifically and you ask me," What do I have?" I have to have a process to be able to say," Here's what I have." And you can tell me," I don't want you to collect this information. Please stop," and you need to have processes for getting consent from people, deleting anything that they have that they don't want collected, rectifying it if it's wrong. So Jim mentioned it well- they overlap, but they are different. So I would not go with SOC 2 privacy for that and SOC 2 will not cover you for GDPR or CCPA. You'd want to go specifically into those. And that's the beauty of these compliance platforms that we've been talking about, where if you do one framework in this compliance platform, then you see, okay, we also have to do CCPA for California, anything that overlaps will be transferred, but then you'll have to do the additional things for privacy, but as we talked about, those are a little more procedural and a little less focused on security controls. The trick with these laws, where SOC 2 can activate business, you can maybe get a new customer because this larger company wants you to be SOC 2 compliant. Privacy is a little more... it can activate business also. It also has a punitive aspect where particularly GDPR has been very heavy- handed with the fines where if you're not doing something and you should be, and you're not a proper steward for people's personal data, we've been seeing fines in the hundreds of millions.

Jim Goldman: Up to 25% of annual revenue.

Scott: Yeah. The US is a little behind Europe in that regard, but it is coming, as Jim mentioned. California, Virginia, Colorado. It's patchwork, and it doesn't seem to matter... a lot of companies are hoping that there will be a federal law soon, a federal privacy law. It might make things a little simpler, but for now, it's if you do business at a certain level, have enough customers in 10 states that have privacy laws, then you have to comply with each of those states. So privacy and SOC 2, I would think of them distinctly,

Jim Goldman: I'll say about GDPR, there are different roles that are defined to clarify it again, and so they talk about the notion of a data controller versus a data processor. So if you're a company and you're interested in GDPR, you need to understand clearly what you are. Do you literally control that data? Are you the one collecting it and deciding what should be done with it from those individuals that you collect it from, or are you just following instructions? Are you a third party processor from the controller? What your responsibilities are under GDPR differ greatly depending on whether you're the data controller or the data processor, so that's important to remember as well. Okay. Let's move along. So Marie, maybe we'll send you this one. This kind of goes back to the system description question. How do you determine what systems are in scope for a SOC 2 at your company?

Marie Joseph: Typically, you want to do what's in scope with where most of your customer data is going to be lying. So that would be your in scope... if your software collects most of the data, that would be your in scope, and then if you have anything physical that stores data, that would be in scope, but it just depends. It also might depend on what your prospects are asking for, too. They can define what's going to be in scope in some cases, so you'd want to look in their eyes, if they're not asking, what are prospects going to ask for? That way, you just cover it all in one step.

Jim Goldman: Yeah. So let's say we're a software company, like a SaaS company. I'm assuming that the product that we're trying to get customers to buy subscriptions to would be in scope, but what you might call the backend business systems, are they going to care about our CRM system? Is that in scope? Our human resource platform, is that in scope?

Marie Joseph: Yeah. I would say typically, most people would consider that in scope, just because it has a lot of personal data in there. So if it's going to have any personal sort of information, like your HR is going to always have something, if it has any financial... They want to make sure that there are some sort of controls in place protecting everything, so that's why the security measure's so big and then... I would say those are included.

Jim Goldman: Yep. Very, very good. So we had another question come in. Again, we want to make this fairly non- commercial and not just about Trava and its platform, but there were some questions about our scans and they were asking, what's the nature of our scans? And they used acronyms like a DAS, which is a dynamic application scanning tool, and so, yeah, again, going back to the work that Scott does, when we do our baseline cyber risk assessment, we do our full array of scans, which includes an external scan looking for open ports and services, a certificate scan looking for the health of the certificates- whether they've been revoked, when they're due to renew, if they've expired, what level of encryption is being used on the certificates- we do what's called a breach scan which is looking for our evidence of past data breaches, compromised email addresses, that type of thing. We do a web application scan which is a dynamic application scan. That's looking for typical inaudible top 10 vulnerabilities, such as cross site scripting, SQL injection, that type of thing. We have a lot of SaaS companies, software companies as our customers, and we encourage them to run that web application scan before they do any release so they're not accidentally releasing new software with potential vulnerabilities in it. We do a cloud scan because so many of our customers are in the cloud now, on either AWS or GCP or Azure, and so the misconception is that those are highly secure cloud environments, which is true, but for the end user, they're only as secure as the level to which you securely configured them. So we've had a lot of customers get a lot of surprises about how badly configured their cloud environments are. They're publicly exposing data that they didn't realize they were publicly exposing, et cetera. So we do a cloud scan. We do a Microsoft 365 environment scan for those customers that have Microsoft 365, looking for OneDrive configuration errors or vulnerabilities in the exchange or active directory, that type of thing. We do an internal scan with a virtual appliance, so that can be used for discovery to discover potential rogue devices on networks. We do an agent scan where agents are downloaded onto your perimeter devices, be them laptops, et cetera, and then we look for vulnerabilities at the operating system level or application level, missing patches, et cetera. So it's a pretty comprehensive array of scans. Then, as Scott was alluding to, we also do that survey of control families, and we can do that against multiple different surveys. So we can do it against the NIST Cybersecurity Framework. We have a shorter, what we call our critical control survey, just to get an initial high- level assessment. We also do the CIS, Center for Internet Security Version 8 scan, that's the one we typically do for our baseline cyber risk assessment, and we recently introduced a SOC 2 survey for control maturity against the SOC 2 framework. We also introduced a CMMC framework. Now, CMMC is another certification that is required, or is in the process of being required, for Department of Defense tier three and tier four contractors. It's based on the NIST 800- 171 standards. So hopefully that answered that question. That was a good question, thank you. So maybe I'll ask each of our panelists here, and this might be the last question, we'll see if there's some more questions that come in. So the question is this: if SOC 2 is on your horizon, what should you be doing now so that you're not unpleasantly surprised?

Marie Joseph: I would just say start getting as prepared as possible. I know I talked through the steps earlier of what we do as a process, but documenting things tends to be the most time consuming. So as we said, policies, and I know Scott mentioned processes and procedures. So getting all of that documented is what auditors are going to want to see, so if you have processes, have those documented. If you don't have policies, get started there, and if you don't know where to start, our assessments are a good way to figure out what policies you should start with.

Scott: I was going to say, call Jim or call Gabe or Megan. Yeah. But no, seriously. I think just getting started getting started. Getting through each thing takes time, so get moving, get going, and that's really the key.

Jim Goldman: So what occurred to me as you were describing that, and I guess this question is for Marie, when's the right time to start talking to an external auditor? Because, as I think we pointed out, but we want to reiterate, the only way to get SOC 2 certified is to hire an external auditor and, to be clear, Trava is not an external auditor. We help companies get ready for their external audit, we'll do the internal audit for them if necessary, but Marie, in your opinion, when's the right time to engage... to start talking to, interview, et cetera, an external auditor?

Marie Joseph: Yeah. You can start immediately. Once it's on your mind, you might as well start reaching out to auditors if you don't have one in mind, because once you start engaging with one and interviewing them and deciding on one, that's when you can get started and they will help you through the process, too, of giving you a timeframe based on where you're standing right now. They'll have a better estimate maybe of when you should start engaging fully with them and have that observation window or when to start having meetings, but literally day one.

Jim Goldman: Yeah, I agree, and the other thing to understand about the role of the auditors is they are not allowed to tell you what to do. They can't more or less say," If you do this, you'll be fine, wink, wink," but they can set expectations, so that's a good thing. They can clarify what they expect to see, what the evidence needs to look like, the kinds of questions they'll be asking, so that makes a big difference. And so, yeah, I would say the sooner, the better in terms of en engaging auditors. We had one last question come in that we'll take, and then we'll see if any others come in here. It has to do kind of with the compliance platform, and so if a company uses one platform or have started the process and they want to transfer to a compliance platform of their choice, or if they've already developed some policies, let's say, and maybe they're in Word or Google Doc or something, do they have to start over from scratch or... you know what I mean? So if someone's already started along the process, should they be saying," Well, we can't really buy a compliance platform because it's too late, we've already started." I think that's the essence of the question.

Marie Joseph: Oh, yeah. It's never too late to start with the compliance platform, even if you have policies and controls already in place. Let's say you already have a lot of your policies created. You can choose to either use the templates that the platform has or keep your own policies in place. A lot of times, there's people that have already gone through SOC 2 audits and that means their policies were great and there's nothing wrong with them, so they can put those policies into that platform, or they can start from scratch and use those templates to make sure they're checking all the boxes that compliance platform sees fit for SOC 2. So that part doesn't matter, and then if you already have evidence of the controls in place, all you have to do is if you have it mapped out to the control numbers, put them in the correct spots within the platform. So it's a little time consuming, but once you have it in one space, it will save you a lot more time in the future.

Jim Goldman: Great. Thank you, Marie. We had one more great question. Come in right at the end here, and we will take this one and we'll see if any more come in. The question was, have you ever seen a SOC 2 attestation gone wrong, and what were some of the common pitfalls? In my experience, it wasn't a SOC 2 attestation, it was actually an ISO certification, but the lesson is still the same. What happened was the company brought in consultants to get them ISO certified, but the company never really adopted the ISO process internally. So when it came to re- certification time, because the processes hadn't been ingrained in the DNA of the company, they hadn't been maintained, all the controls that were supposed to be done quarterly, semi- annually, et cetera, hadn't been done. So as you would predict, it didn't go well. So the lesson there is, this is not some extraneous one- time thing that you can just hire consultants to do to jump through a hoop. It really does need to be a fundamental change in your culture that is of the highest priority from the senior- most management on down throughout the organization. So great question. So I think that's it. Thanks everybody for attending the panel discussion. If you're ready to take the next step on your security journey, you can book a personalized call with a Trava team member, I think Megan's posting the link there, and you can also read more about starting your SOC 2 security journey, Megan posted a link there as well. So I hope this was helpful. Stay safe, stay secure, stay private. Thank you.

Marie Joseph: Thank you, everyone.

Scott: Bye. Thanks.