John Kudomal: Hey, everybody. My name's John Kodumal and I'm the CTO and co-founder of LaunchDarkly. Thanks for joining this morning. I know it's very early, and as a reward for getting up this early you get to hear a talk on compliance, which is probably one of the most exciting things that you could imagine getting up for. And so the reason I'm talking about compliance is my company, LaunchDarkly, actually just went through a SOC 2 Type 1 audit. And coming into that process, compliance wasn't something that was necessarily on my radar as something that you would even consider doing as a startup. And some of the things that I learned through the process I thought were very valuable. And more particularly, I thought it was very interesting that we actually got a lot of positive benefit from going through the compliance audit at the stage that we were at. When I first came in, I didn't think it was something that startups did. I didn't think it was possible and it seemed like a waste of time and effort, and I gotta say, it was exactly the opposite of that when we actually went through the process.
John Kudomal: So I thought I'd share a little bit about my experience, and give you an opportunity to learn a little bit about a topic that's probably not on your radar as an entrepreneur or a startup founder. So as a disclaimer, I'm coming at this from the perspective of an entrepreneur, and specifically an engineer. I am not an expert on compliance. I am not a compliance auditor. I am not a lawyer. I am not many things. So I'll be approaching this from that perspective. I'm mostly focusing on the impact that a compliance audit might have on your business, how it might impact your teams, and specifically, a bit on how it'll impact your engineering teams. I am an engineer at heart, so I do have a bias towards focusing on engineering problems. So one of the running themes through this talk is that compliance ought to do something that's gonna impact your entire organization, not just your engineering team. So if I tend to focus a little bit on the engineering work, just remember there are things that your entire company is going to have to do.
John Kudomal: So again, because I'm not an expert, if you hear something that is at odds with what your compliance auditor is saying or what your compliance officer is saying, listen to them and not me. I'm trying not to lie, but who knows, maybe I am lying about a couple things. So as I alluded to a couple slides ago, compliance is something that I had had a negative experience with at other companies. I had been at larger companies in previous work before starting LaunchDarkly, where we'd gone through compliance audits. And from an engineer's perspective, it just felt like a whole lot of red tape and bureaucracy that was getting in our way and leading to a bunch of slowdowns and extra steps in our processes. One of the challenges was, there was an enormous amount of disconnect between communicating the rationale for going through a compliance audit to the implementers. So getting individual contributors to understand why you were going through a compliance audit, and why the steps that were being put in place were being put in place was an enormous challenge.
John Kudomal: One of the pleasant things that I discovered after going through the process as a small startup was that you had, first of all, an enormous amount of flexibility in how you implemented those processes. And so you can actually go through a compliance audit process as a startup and not handcuff your team. So you can gain the change management required, the audit logging, all of the other tools in place. You can have those in place and not deal with the slowdown that you might otherwise expect. And furthermore, by doing this as a small startup, you can communicate the value to everyone in your team more efficiently. And you can get buy-in from your entire organization, which leads to people kind of really understanding why you're doing this and really buying into the processes and tooling that you're putting into place.
John Kudomal: That said, going through a compliance audit process has costs. It costs time. It'll cost money, you're gonna have to hire somebody to help you out. And it basically will cost you a number of resources that are some of the most valuable things that you have as a startup, so it might not seem like a reasonable thing to do as a startup. And in fact, I think there's only one compelling reason to go through a compliance audit as a startup, and that's if your customers and business demand it. So absent that reason, it's not something that I would recommend you go through. However, as a comma to that, learning about the compliance audit process... Sorry, my slides are advancing automatically, sorry. Learning about the compliance audit process and some of the things that you need to have in place, can be a north star for your startup. So you can learn about some of the things that you've been missing out on, some of the things that you don't have in place as a startup just by learning about what compliance is.
John Kudomal: So again, the main reason to go through a compliance audit is if you're being pushed upmarket. So if you're starting to engage with enterprise sales, you're starting to go through procurement teams to close deals, you're starting to go through security reviews, then a compliance audit might make sense for you. And that has to be the driving factor that pushes you towards doing it as a startup.
John Kudomal: Now, one of the things that I learned through this process is that even if you're going upmarket and engaging with enterprise customers, they may not be articulating those requirements as a specific need for you to go through a specific compliance standard. So what we saw at LaunchDarkly was that we were getting these massive security review documents from individual customers. This was coming in the form of 200 to 250 question Excel spreadsheets that were all very differently phrased. And we would spent an enormous amount of effort parsing through the questions, trying to understand what evidence those companies were asking from us. And for the most part, people weren't asking us if we were SOC 2 compliant, they were asking us, "Hey, can you fill out this security review?" It was enormously time-consuming and resource-intensive for us to engage with these customers.
John Kudomal: One of the things we discovered is after going through the SOC 2 compliance Process, our processes for these security reviews became much more turnkey. So if you're spending tons of effort filling out these security reviews, even if you're not hearing the words, SOC 2 compliance, it could benefit you to go through a compliance audit, because you can go from these ad hoc questionnaires to you handing out a report to your prospective customers under NDA, saying, "Here's how we run things, here's how our service runs, do you have any questions or are there any gaps that you'd like us to cover?" And this cut down our level of effort on these security reviews by a factor of 10 or more.
Tasia, Head of Marketing at Nylas: So another thing that I've found going through the compliance process was that there were actually really positive benefits as a startup to implementing these processes. It ended up being a catalyst for a lot of the process maturity that we put in place as we scaled from an eight person company to a 25 person company. So, we were already pretty good at some of the engineering practices but we got even better. In particular, change management was something that we got far more mature on, and I think we're amazingly mature for a 25 person organization at this point. So we went from having some gaps in things like our audit logging, our learning and monitoring systems to having an extreme amount of confidence that when something was happening in production, we could track that change to the deployment or the changing configuration that caused that to occur.
John Kudomal: So the DevOps side of things became much more mature for us as we went through the SOC 2 audit process. And again, compliance is something that impacts your entire organization, and on the side of people management, we actually got much more mature. So, when we started the SOC 2 audit process, we actually didn't even have proper on boarding and off boarding processes.
John Kudomal: New employees would show up and we'd kind of, on a demand-driven basis, say like, "I think you might need access to that system, let me get you what you need." And we went from that to the current state of things which is when a new employee comes in, they sit down and everything is set up for them. Their laptop is set up, they're on boarded to all of the accounts that they need. The dual of that is that we got off boarding set up. So, now when an employee leaves, we can lock them out of all of the critical systems that we need to very quickly and efficiently. Those are obviously things that you wanna have in place, the SOC 2 compliance audit just kind of kick started us to make sure that we got those in place as a startup earlier rather than later.
John Kudomal: One of the most surprising things we found, is that we saw a positive culture benefit from going through the SOC 2 compliance audit. And I know that culture and culture improvements can kind of seem like a nebulous thing, so I have a concrete, specific thing that happened for us. One of the things that we were asked to do in the compliance audit process was provide a handbook. We didn't have a handbook, an employee handbook, so I wrote one. And I took that process very seriously and it really forced me to articulate who I wanted to work with and how I wanted our teams to operate, how I wanted us to work together and when I wrote that down and shared it with everyone in the company, there was an enormously positive reaction.
John Kudomal: It really helped just set the groundwork for our company culture and it really was spurred on by the SOC 2 audit process. So, there are some hidden benefits, there are some reasons why you might consider going through a SOC 2 audit process that can just really be positive impacts for your company.
John Kudomal: A final reason that you should possibly consider going through a compliance audit earlier rather than later is the amount of effort required as a small startup is massively smaller than what it would be if you did this later on. Your processes now, as a smaller startup, are pretty much greenfield. So if you can bake compliance requirements into those processes earlier, it is much cheaper than retooling your existing processes to handle compliance requirements. So at a large company, like one extreme end of the spectrum, if you're a public company or a company on an IPO warpath, the amount of effort required to retool your processes, it's gonna be incredibly expensive. It's probably going to take many years of effort versus, as a startup, we went through the process in several months of a lot of hands off time, so we weren't like retooling the entire company for several months.
John Kudomal: So, those are the reasons why I think you might consider going through a compliance audit as an early stage startup. I think it's worth spending a little bit of time talking about the landscape because it's actually incredibly confusing and there's a lot out there. So we're gonna focus on something called a SOC 2 compliance audit. The reason we're talking about that is because, in a sense, the SOC 2 audit is one of the most, sort of, general purpose audits that you can go through. If you're engaging with enterprise customers and you're going through these security reviews, probably what they're looking for is covered by the SOC 2 audit.
John Kudomal: A lot of the other compliance standards are much more specific, maybe niche, and they depend on the specific customer verticals that you're going after. For example, if you're dealing with a European customer base, EU privacy shield and GDPR are probably relevant to you. If you're going after government contracts, then FISMA and FedRAMP are gonna be interesting to you. If you're going after healthcare, then HIPAA compliance is probably going to be important to you.
John Kudomal: Something to note is that the SOC 2 compliance audit has a tremendous amount of overlap with these other audits. So if you know that you're gonna need to do HIPAA compliance down the line, it's actually cheaper for you to go through SOC 2 and do HIPAA at the same time because 90% of the evidence that you gather for SOC 2 will cover you for HIPAA.
John Kudomal: But even within the world of just SOC compliance, things are a little bit confusing. I needed some reason to throw up a Dr Seuss picture so here we go. So there are actually three kinds of SOC audits, there's a SOC 1 audit, a SOC 2 audit, and a SOC 3 audit. SOC 1 audit relates to financial controls, so we're not gonna talk about that. The SOC 3 audit is like a public marketing focused report that you can share with customers outside of an NDA, that it doesn't describe the specifics of your controls that you've implemented. We're also not gonna talk about that, it's a much more expensive audit and something that you would do after going through the SOC 2 process. So we're gonna focus on SOC 2, but even within SOC 2 compliance, there are a lot of different dimensions along which you can get a SOC 2 audit.
John Kudomal:: First is that, in SOC 2... So SOC stands for Service Organization Controls and it's basically an assertion to your customers that you're following some of the best practices as they relate to specific trust principles. So I'll talk about the trust principles in the next couple of slides, but as an example, one of the trust principles is security. If you go through a SOC 2 compliance audit, you're basically providing some information to your customers about how you adhere to best practices as they relate to security. So you can pick which trust principles you go after. The first dimension for your SOC audit is which trust principles are you going to address? The second is that there are actually two types of SOC 2 audits. There is a SOC 2 type 1 audit, which is a point in time validation. Think of it as an auditor coming out and insuring that the processes that you've designed adhere to those trust principles. So they're collecting a single data point.
John Kudomal: When they come out and see you at that point in time it looks like your systems are designed right. The Type 2 audit is far more comprehensive and it is an audit of samples over a time period. The auditor is essentially guaranteeing or attempting to validate that you are actually operating, running your business and service according to those principles. So instead of a single data point they're going to be collecting a set of data points over a time period. That's the reason it is much more comprehensive and much more time-consuming. It's typically something like a six month period that you'll be audited over. Excuse me.
John Kudomal: A little bit more on those trust principles. As I mentioned, there are five. The security which relates to how you protect your systems against unauthorized access. There's availability which relates to how you keep your systems up and reliable. Integrity, data processing integrity which relates to the correctness of how you process data and information. And confidentiality and privacy which are related. They're both related to the life cycle and management of data. Confidentiality specifically relates to non-personal information, things like corporate information, transaction information. And privacy which relates specifically to processing and appropriate handling of PII, Personally Identifying Information.
John Kudomal: So it actually turns out that with the security principle, there was a tremendous amount of overlap between that and the other four principles. So they kinda re-factored SOC 2 into a set of common criteria as well as the four trust principles that you see here. So basically, now instead of going after security separately, you go after the common criteria. You provide evidence for those and then you get security kinda for free and then you can choose from availability, integrity, confidentiality and privacy after that.
John Kudomal: So one of the things that I had no idea about going into this was what the actual process of a SOC 2 audit looked like. I did a lot of googling around and it turns out that most of what you'll find comes from compliance auditing companies and consultants, and so they're not very clear about specifically what it is you have to do. So I thought I would spend a slide kind of distilling that. It actually is a very simple process. Basically, to go through a SOC 2 compliance audit you'll engage with an auditor, you'll find an auditor and then they'll give you one of those awesome spreadsheets of 150 or 200 things that you need to provide. And you'll look through that list and you'll see, "Okay, there are maybe about half of them or three quarters of them are things that I'm already doing already." And you'll need to provide evidence, documentation, and explain that you do those things. Most of that is actually just like screenshots of systems. Like a screen shot of your GitHub account indicating that you use GitHub for change control to source code.
John Kudomal: And then there's gonna be a set of things that you're not actually doing and you're gonna need time to actually build those processes. For example, you might not have a system in place for network intrusion detection. So you'll need time to actually pull that together. You'll schedule your auditor to come out for fieldwork. So once you've actually built those processes, you'll set a date for an auditor to come out and actually review your fieldwork, review your evidence and in that fieldwork phase they will actually meet with your leadership and your officers and go through all of the screenshots that you've provided them and make sure that they understand how your processes work and that's basically it. Once you've done that, they'll write up a SOC 2 report for you and then once you have a customer under NDA you can share that report with them. So it's a fairly straightforward process.
John Kudomal: After going through the process myself, I thought I'd share a couple tips that kinda helped us succeed in this and I think could be very helpful, especially if you're a smaller startup thinking about going through one of these processes. The first is that you should pick the right auditor. You have a choice of very many auditors, if you google SOC 2 compliance, you will get bombarded with advertisements of different auditors that you could choose from. The first thing to note is that you should treat this as a... You should understand what the right relationship between you and the auditor should be. You should not treat them as an adversary. That's not really the intent. You should seek to have a collaborative relationship with them. You should be pretty open and forthright about the processes that you're putting in place. And the reason for that is that the auditor is really on your side. They're helping you articulate to your customers how you follow these best practices. If you're just hiding information from them, you're doing yourself and them a disservice.
John Kudomal: The second thing around picking the right auditor is find someone that can work with startups. There are auditors that will work with pre-IPO companies, even public companies are on SOC 2 compliance audits. They're probably not the ones you wanna pick. The reason for that is because the processes you put in place as a startup are going to be very different from the processes you put in place as a 200 or a 2,000 person organization. That's not gonna mean that they're less valid or that they implement the controls less well, they're just going to be different. And you need someone that has worked with startups before that can understand how to best implement those controls and processes at a company your size.
John Kudomal: Finally, find an auditor that understands SaaS businesses. I'm assuming that almost everyone in this audience is... Has a SaaS business of some kind, so if you're working with an auditor that doesn't know what the Cloud is, that's gonna introduce a lot of friction into your processes. It may sound funny, but a lot of the evidence and controls that you have to put in place critically depend on the nature of which Cloud providers you're using, whether or not you're using third-party SaaS providers. It's totally possible to go through the process and use them, obviously, but you need to find somebody that understands what that means as it relates to providing evidence.
John Kudomal: So, another tip is to... If you're deciding to go down this path, if you think you are gonna go down a SOC compliance path, try to get as much of the work in in advance. Understand what you're probably going to need to have, and try to bite that off over a period of time before you engage with an auditor. So, this is a non-exhaustive list of some of the things that we either had in place already or put in place as a part of the SOC 2 audit process. So, from our engineering team, we knew that we were gonna do this, we knew we were gonna engage with an auditor and go through SOC compliance, and so we had done things like engage with a third party company to do penetration testing of our service. We codified our process around coder views and made sure that every change we had was code-reviewed. We implemented Patch Management policies, disaster recovery plans, backup policies, static analysis tools. So, you're gonna wanna do these things. If you try to bite them all off at one time, it will be a very daunting task.
John Kudomal: And again, this is something that is gonna impact your entire organization, not just engineering, so on the operation side of things, we implemented SLAs for our customers, MSAs to hand out to our customers, incident response plans. We built an org chart and kept it up to date. We did background checks on new employee hires, and we put in better account management processes. So you're gonna wanna do this stuff in advance because when the auditor comes in, they're gonna ask you, "Hey, are you doing background checks on prospective hires?" And if you haven't hired anyone in the past couple of months it's pretty hard to collect that evidence.
John Kudomal: So, the last... Sorry. The last tip I have is around planning the actual audit project. And the tip that I have is that you basically need to do a Gantt chart, unfortunately, to actually get through the project management process. You're gonna need to figure out the rate-limiting steps, like the things that are gonna take time to put in place, and front-load those. And then the second tip is you wanna schedule fieldwork at a point in time when you know that you're hitting 90% of the evidence, so when you engage with your auditor, they're gonna say, "We wanna do fieldwork on this date." Look at that date, do your project planning and figure out if it's feasible. If it's not, then your auditor is gonna come on site and you're gonna be scrambling to bake in processes that you can't possibly bake into place at that kind of timing.
John Kudomal: This is actually the burn down chart from our actual implementation of our SOC 2 compliance. And this is, I think, over a four-month period. This is coming from our issue tracker. So we took that massive Excel spreadsheet from our auditor and dumped it into Clubhouse, and just ran the project as a Kanban board. And you can see we implemented processes like overtime, and then we spread out the evidence gathering, so as it related to picking out screenshots and showing some of our internal documentation tools, we spread that out over a significant amount of time. The vertical line that you can barely see on the end there, that's actually our fieldwork due dates. That was when we told the auditor you can come out and review our evidence, and we aimed for about 80%, hitting about 80% of the evidence by the time they came out. We just about hit that. The auditor had scheduled seven to 10 days on site to work with us. We actually got them in and out in three days because we'd done so much planning in advance, so spread out the evidence. This isn't high school. You don't wanna cram the night before the exam and just have the auditor show up and have you grabbing screenshots of all of your systems the night before. It's not gonna work out that way.
John Kudomal: So the last thing that I wanna say is remember when you're going through this process, the end goal is to make your company better. And I would say that that's probably on multiple fronts, but the two most important ones are; first, this needs to be a process that opens doors for your sales team. So again, back to the primary motivation for doing this. If you're going upmarket, you're starting to sell to enterprise companies, and you need this to open doors for you, that's one way that this will make your company better.
John Kudomal: The second point that I wanted to make on this is, you have a choice here to kind of treat it as theater and a bunch of checkboxes that you're just trying to fulfill, or you can try to embrace it and make it a set of changes that improve your company's processes. If you do the latter, it's something that will last and stick with your company. If you do the former, you're just gonna be putting up a bunch of roadblocks in front of your team, that they're not gonna buy into. So when we went through this process, we got buy-in from everyone throughout the organization at all hands. Multiple times we were explaining why we were doing this process. We were explaining what the outcome was. "It's gonna open our doors, we need this for sales," and we were explaining why we were implementing certain processes like, "Hey, I know that antivirus software is terrible and you don't want it running on your laptop." But guess what? This matters to some companies. We're picking the right AV vendor that's not gonna introduce a ton of overhead and not gonna chew through your CPU.
John Kudomal: And when you have this in place, our customers will trust that nothing malicious is gonna happen to their data as they use our service, because we're protecting ourselves. So treat it with that level of respect and treat it with that level of honesty. Again, if you're just going through this to check some boxes I wouldn't recommend doing it at all. It's just not gonna be something that's gonna make you better at the end of the day. So, that's all I had. I hope this was helpful. I hope if you decide to go through a compliance audit process, this is valuable information for you. And just to reiterate, if you're not going through a compliance audit process, it might be valuable to learn a little bit more about SOC 2 and what it's asking you to do. Again, as kind of like a north star to understand where your processes could be more mature, and where you can improve things. Thanks very much.