a16z Podcast - a16z Podcast: What to Know about FedRAMP

Episode Date: August 28, 2019

with @ldhawke and @stevesi The government wants to get onto the cloud! But how do they assess the levels of risk in adopting specific cloud products, and which "cloud service providers" (aka "CSPs") to work with? That's where FedRAMP -- the Federal Risk and Authorization Management Program -- comes in. And enterprise SaaS companies need to pay attention, since it will be a requirement for selling to the U.S. government, which is one of the biggest buyers of tech. Not just that, but even state governments and private/public companies may seek FedRAMP certification because they either work with the federal government or are just seeking standards. How similar or different is FedRAMP to other types of certification, authorization, and compliance (such as ISO, SOC-2, GDPR, even HIPAA); and what does it mean for a startup to go through organizationally, culturally? Is it like a check-the-box policy thing, is it like getting a driver's license... or what? One thing's for sure: It's an opportunity for enterprise SaaS startups, and the government is trying to help companies through the process. What are the steps to certification? What are some acronyms and terms to be aware of? When and how should you bring a consultant, advisor, or third-party auditor into the process? How long does it take, really? And how does it affect your sales team? Most importantly, what is the best strategy for moving forward? (Hint: start with a customer). Lisa Hawke, VP of Security and Compliance at Everlaw, an a16z company, shares her expertise and their experience in navigating all this, as well as the resources below, in this episode of the a16z Podcast hosted by board partner Steven Sinofsky. (The two were also previously on another episode sharing everything startups need to know about GDPR.) For links mentioned in this episode and other resources, see: https://a16z.com/2019/08/28/fedramp-why-what-how-for-startups/

Hi, everyone. Welcome to the A6&Z podcast. I'm Sonal, and today's episode is all about a compliance topic, FedRamp, which is going to affect a lot of enterprise SaaS companies selling to government, and actually, even if not. So we share everything that startups need to know in this episode. Please note, you can find all the pointers, templates, and other links they mention in the show notes at A6NZ.com slash FedRamp. I highly recommend you check that out, too, to get all the resources after listening to this episode. Okay, so now on to the intros. This episode is hosted by A6NZ board partner Steven Sinovsky, who interviews Lisa Hawke, VP of Security and Compliance at A6NZ Company Everlaw. By the way, you can also catch both Lisa and Stephen on another interesting compliance topic that applies to many tech startups as well, GDPR, which we covered last year by going to A6NZ.com slash GDPR. But this episode is all about FedRamp, which stands for the Federal Risk and Authorization management program.

And here's what they cover. What risk means in selling to the government, depending on your product features, some of the most commonly used acronyms to be aware of, which they quickly lightning round in between, how similar or different FedRamp is to other types of certification, authorization, and compliance, such as ISO, SOC2, GDPR, even HIPAA. Most importantly, they break down the steps to FedRamp certification, including how and when to engage third-party auditors and advisors, how long it takes, and how it affects sales. They also share the best strategy for moving forward with a customer lined up first, but they begin by discussing why startups should consider FedRamp in the first place. Before everybody gets cynical about acronyms with the word Fed in them and security and the government and all this other stuff, this is some pretty interesting things that you can do for your company, and it opens up a world of opportunity in terms of selling to the United States government

and beyond, as we'll talk about. So first, welcome, Lisa. Thanks, Stephen. So if you're the CEO of a company, what are the core benefits of pursuing a FedRamp authorization? So if you're the CEO of a cloud company and you want to sell your product to federal agencies, FedRamp is probably going to be the only way in. There are some exceptions, very limited. For instance, if you want to do a private deployment in a facility for a single agency, but that's not what we're talking about today. We're talking about having a FedRamp authorization, which, for the record,

we are in process at Everla. We don't have our authorization yet. But it does open up a whole new market for you for all of the federal agencies. And as well, it provides some credibility, too, to the general market from a security standpoint outside of government. Yeah, that's something that we hear all the time is that like even if you want to sell to a company, a private or public company that isn't the government, they might look to see like, hey, did you get FedRamp certified? So we know now that FedRamps are requirement to like sell to the government. And most markets, especially in the U.S., the government is potentially a very big or the biggest potential customer for enterprise SaaS. No matter which agency you want to sell to, you know, from DOD to

ag or HHS or whatever, FedRamp is going to be required. And in many cases, like these connected or affiliated state organizations as well, something we learned in Everlaw is that if you want to sell to a state attorney general, they're going to want FedRamp authorization as well just because chances are they're going to be involved in litigation with the federal agencies. So, like, what is it that FedRamp actually, you know, quote, tests for in its process? So FedRamp stands for the Federal Risk and Authorization Management Program. So FedRamp, like the acronym says, it's all about risk. It's really a program that's designed to provide federal agencies with the information they need

to make their own informed risk-based decision about whether to adopt Cloud. and a specific product. I think there was a general recognition that in order for federal agencies to adopt cloud, they had to put it in place a way for companies to meet the federal standards and allow the federal agencies to do these risk assessments. Risk is a very amorphous concept.

How do they actually evaluate what risk? Well, for the security folks listening, hopefully this will be comforting in the sense that they didn't make up something new. They use the CIA framework, which is not the agency, no, confidentiality, integrity, and availability. So for companies that have been through, say, a SOC2 or maybe ISO, they'll have heard these terms. And in addition, they also look at baseline or impact levels, high, moderate, or low. The high, moderate, or low are actually pretty important because that puts people into buckets of sort of users of the product.

Yeah, exactly. So when you're going through a FedRamp authorization, you're going to have to look at your product and figure out, okay, based on the impact and the information that is going to be in that cloud product, what level are you high? So think law enforcement for high. Think DOD, federal criminal information, or are you moderate? Like normal the agriculture department or something like that, where it's sort of routine work. Yeah, exactly. And then for low or there's even another... Like a low or low or low.

A low or low. Yeah, it's called low impact SaaS. That's a mean name. We don't mean it to that your product is low impact. No, but they did create the low impact SaaS for products that only contain enough personal information to essentially set up an account. So they need your name, they need your email, there's going to be a password, but you're not holding really confidential or sensitive agency information.

So based on those impact level, that is going to determine which baseline, and the baseline is a set of controls. And they have, on the high end, the most controls, on the moderate, you know, around 300. The four levels of impact levels, it's super interesting. There's only seven authorizations for, like, high security stuff. And they're all mostly, they're just the cloud infrastructure providers. In fact, like, of the seven highs, I actually went and looked at it up. It was interesting.

Three of them are Microsoft, just for different parts of Microsoft. And then Oracle and some specialized ones. AWS. So, like, nobody has to worry about this extreme bar if you're mostly an app. They'll guide you to moderate or low. One cool thing about the Fedramt.com website is they have a marketplace for the folks out there kind of wondering, all right, what companies are doing the high, who's doing low, who's doing moderate, you can sort by that. And it's kind of interesting because, like you pointed out, the great majority are in the moderate category. And then there's a handful of highs and a handful of those. So given that they're not there to really bug Silicon Valley companies and make it

hard for the government to become a cloud provider, it's the opposite. The directive was specifically, we want to get the government on cloud. Like, it's too expensive to be on-prem. It's less secure. It's harder to do. It's less agile. So we want to get the government on cloud. If you're a government agency, what are some of the things that you observe right away when you see a FedRamp authorized products or show up? Like, what is it different about it? Well, I think if you've gone through FedRamp, you're going to show up looking a lot more organized. You're going to have that governance infrastructure in place because FedRamp is a mix of very technical things, but also governance related things. So if you've set up your security program in a way that addresses things like personnel security, policies and procedures for specific things like role-based access control, then you're going to show up as looking like you really have your act together compared to a company that, has these various security controls in place, but maybe hasn't gelled them into a program. I should have mentioned this earlier.

So all of these sets of controls for the high, moderate, and low baseline are separated into control families. So, for example, incident response is a family. But the more technical ones are things like configuration management, which deals with creating blueprints for the server types to meet functionality and hardening requirements, things that require implementing Center for Internet Security benchmarks. and we'll provide a link to the CIS benchmarks as well. Obviously, one of the things that ends up mattering the most to security

is just sort of access and identity and the role of authorization in general. Where does that fit in these families? So it spans several of them, but there is one control family called IA, which means identification and authorization, which deals with how you implement your system accounts, including credential management, version control, multi-factor authentication, which has to meet certain cryptographic standards.

And it's worth noting that in these control families, sometimes you as the cloud service provider are going to have the responsibility for the implementation, like something for authentication. But also sometimes the federal agency also has a responsibility in terms of how they implement their users and distribute out their usernames and so forth. So that is also something that's noted in the control family. So you don't go through this authorization process, and it's a recipe. There's like lots of decisions to make, lots of product design questions that are favorable to enterprise SaaS and have to sort of allow room to adapt to the variations across the government.

And most of the controls, a company can implement them in their commercial environment as well. We want all of our commercial customers to benefit from the same level of security as our future, federal customers. Because chances are whether you try to sell to a big tech company or a non-tech company that they've probably developed some list of things that look like these families, but might not be exactly the same. And ultimately, you're going to end up in the same boat trying to get all these done. I mean, the federal government and federal agencies are not the only ones that use the NIST framework for security and privacy. Many companies do it. A lot of security questionnaires are going to be based around NIST. So it's one of many acronyms. I think we're going to go

over today, right? Yeah. So I'm just going to go through a few of them and like make sure people know, because we'll say them and then we'll forget to expand them. And so NIST is one of my favorites because that goes so far back. That feels like 1950s NASA. And they're like in charge of weights and measures and stuff like that. But what do they do with this? NIST does a lot of cool stuff. But as it relates to what we're talking about today, NIST, the National Institute of Standards and Technology is the agency that defines government-wide standards for technology and security. And the one specific NIST document that we're talking about today is a special publication 853, which deals with security and privacy controls for federal information systems.

So FISMA. Yeah, so FISMA stands for Federal Information Security Management Act, and this is something that applies to federal government agencies and requires them to put in place a security framework to secure their information. So it doesn't apply to the private sector. So next was obviously a big government agency called OMB. Yeah, OMB is sort of like the COO for the federal government. They oversee budgeting and spending.

And then their sibling agency, GSA, is a general services administration. And the FedRamp office, so our friends in the FedRamp PMO, which means project management office, they sit under GSA. Awesome. And then finally, this whole thing is about the acronym they invented called CSPs. Yeah, CSP stands for a cloud service provider, and you'll also hear CSO, which stands for a cloud service offering. So FedRamp is all about cloud, which is why I think we're here today talking about it for the SaaS folks out there. Okay, so we have a bunch of acronyms out of the way. I got to tell you, as Lisa took me through the Everlaw certification, I have never seen so many acronyms exist in this process.

So your typical Series B enterprise startup, is FedRamp anything like what they've done before, in terms of running the sales process or a security process? Like, is it like SOX II? Is it like GDPR? I think it depends on what a company has done up until the point they decide, hey, let's do FedRAMP. So if you've been through a SOC2 type 2, which is the audit that tests your operational effectiveness,

then you're probably in a better position than if you'd only done a SOC2 type 1, which is just do I have a program in place. So I would say it really depends on what the company has done up until then. And what are some of the dimensions to really think about? Like, is it a size of the company thing? Is it the number of people you have dedicated security? Is it like how much data you store?

What are some of the variables that people should be aware of that might impact their time and effort and need and complexity of going through authorization? Yeah, that's a great question. The first thing is that if you have a motivated federal agency, that is going to be the biggest factor that either pushes you ahead or slows you down. So if you're in a place where a federal agency has already expressed interest in your product or you've already been in conversations and they're motivated to be your partner in the process and give you the confidence you need to make that financial commitment because it's going to take internal resources, which has a cost. Like one of the things that you mentioned was just how the lens of a FedRamp changed the Everlaw culture a little bit to be much more focused on sort of this continuous monitoring sort of mindset. How did that come about? From a continuous monitoring standpoint, we found that the FedRamp controls helped us gel around things like configuration management, making sure there are security checks and security impact analyses.

So putting in some of those processes, which on a continuous basis, now we're doing every release. In addition to the things that are just straight up required by continuous monitoring like bone scanning. I think there's a perception of FedRamp that it's a lot of policy, It's a lot of checking the box. And like any team that is staring down the face of a major security compliance and technical project, we were kind of thinking, oh, no, there are going to be so many controls in here that are just check the box. And like any compliance framework, there certainly is some box checking involved. It's a lot of governance, which is true.

There are a lot of control families that deal with a company's infrastructure like personnel security, is the PS control, AT is the awareness training control. But we found that on the whole, a lot of the controls really pushed us forward. And a lot of things we were already doing, there were some things that we needed to improve. But the process has really made our entire infrastructure more secure. No one at Everla had FedRamp experience before. I mean, we'd been through SOC2, and we'd actually undertook it at the same time as GDPR, which looking back is a little bit crazy.

You can't really get a choice in GDPR, though. That's true. So if you're a startup where the team has varying levels of experience and actually haven't gone through all of these things collectively, it sounds like what you're saying is just by virtue of having gone through the process, the whole organization sort of gets up-leveled and consistent based on just using this as a framework. You mentioned that it is also deeply technical. This is not just a list of, you know, do you have a security policy manual?

Do you have cipher locks on your door? There's stuff about the code and the process. What are some of the things that are technical that you had to sort of bring in engineering or product or devops and security ops to really think about? Yeah, I already mentioned a few of the other more governance related controls before. There's also IR, which is incident response, but some are very technical. And just anecdotally, in the system where Everlaw tracks sort of our features and what the things our engineers are working on, there were over 100 tickets in there. I don't know if tickets is the right word, but basically, you know, feature ideas, functionality that we were going to implement, that all required dev resources. And they ranged from simple things like adding a banner into the platform that says, you know, you're entering a federal environment, in our federal environment, to very complicated things.

I think one of the things is kind of interesting, too, is that this is not like a secret part of the government. Like all the CIOs across all the agencies sort of know this is going on. And so it sounds like it's become their common vocabulary, and security is for the government, the first order priority before functionality. So their sales team is just going to need to know all of these words just to interact with the customer. Yeah, I presented at our sales kickoff this year presentation on selling security to help them understand what does it mean to be FedRamp in process to make sure that they're not misrepresenting what our status is to the market, but also so that they can talk about it confidently and understand how it's different from our sales. sock to and so forth. So clearly there's a series of steps that have to happen. Like, what are these steps? So that flowchart is actually in the cloud service provider playbook, which will provide

a link to. And the first step is going to be establishing a partnership with a federal agency. I mean, like we were talking about before, it's just really critical that you have that agency support. And then once you have that agency support, then you're probably going to feel confident enough to start using your internal resources. So that's going to be putting together the package. And when I say the package, it means system security package or SSP, which is another acronym. So working on that documentation and then also working on any technical remediation you

might have to do. And so then eventually, like, someone who doesn't work for the agency or Forever Law is going to show up and sort of test you. That's right. The step before that authorization is a full security assessment by an independent auditing firm. And in FedRamp lingo, it's called a three-pow. It's a third-party assessing organization. And there's a small set of companies that can do this because they have to meet FedRAMP standards. And so you have to bring them in, just like any other independent auditor,

and they review all of... And this is like on-site. Yeah. Yeah, they came on-site for a week. But they review all of your implementations. I mean, you're screenshoting, you're working the command line in front of them to show them how you've implemented specific things. So, And do they, like, snoop around and everybody's like, who are these people in suits? And, like, do they have special badges? Like, how does this really work? I mean, they're very technical, and they're there to make sure that what you've represented in your security documentation is the actual thing you've implemented.

I mean, the federal agency is trusting them to help them form their risk-based decision, so they're serious about it. But they're great. They're nice. And they're basically consultants that come in on behalf of the OMB basically execute on this plan. I mean, they are working for the agency, not for you. You can engage an advisor. What does that entail? So there are other companies that can serve as the independent assessor or they can

serve as a consulting advisor. The key thing, though, is that if you engage a FedRAMP consulting advisor to help you put together your documentation, you can't use them as then the independent assessor, so you've got to swap. Basically, there are these specialists in doing security audits, and they're a list of them that OMB supports, and you can use them either to help you or to audit you. Yeah. And you just pick, and you might end up engaging too, but they're basically, it's a consulting

engagement. That's right. And you might be thinking, why would I want to engage a consultant? To help you with a consultant. Yeah, exactly. But the fact is, even with all of the program documentation that we had at Everlaw, you know, the whole suite of Infosec policies, we had great procedures around personnel security and training, but we still needed to engage a consulting advisor to help us put together the system

security package. It's, of course, a template that you can pull down from FedEx.gov, and since we're an AWS customer, and we inherit a lot of the cloud infrastructure controls from AWS, AWS will also provide you with that as well. But some things are just hard to navigate without the experience of knowing what the agency will accept. So a couple of examples are the consulting advisor can help you translate what the agency's actually looking for when it comes to an implementation. So if you have to do a deviation from a CIS benchmark. Ultimately, this process boils down to creating a lot of documentation. Like, they don't just have a phone call and take your word for it. So a lot of it sounds, I mean, like you said, like, oh, you inherit some of it from

AWS. So it sounds like sort of this large amount of paper that has a bunch of forms that are all filled in already. Well, our full SSP without the attachments with the implementations described is around 500 pages. But the template itself, even without those, is probably, I don't know, it's probably 30 pages or 40 pages just without all our info in it. It's a big lift to do that. So we found that a consulting advisor could, we could spend some time talking with them, chatting with them on the phone, explaining things, and then they would go write it up for us, and then we would QA it. So instead of us having to do that big lift, they did that for us, and then it was much more efficient that way. So, you know, obviously there's a bunch of sections

and chapters and different parts, which part of it was the part that really was, like, a ton of work where, like, the engineers needed to engage and you needed really detailed technical answers. Like, what was the scope of that and where in the process? So we went back and forth with our consulting advisor, so we would describe our technical implementations, and then they would take the first crack at writing them up, and then our director of infrastructure had to edit things out, because every once in a while, but also describing our entire system architecture and doing the architecture diagrams. Those are all things that our engineering team definitely had a hand in. Right. And it turns out it's one of those things

that like, well, we didn't really have a good architecture diagram of our system. And so now we have one and now we keep it up to date because we have to because of Conmon and all that. But sort of ended up being beneficial anyway. Okay, so you've got like this 500 page SSP thing sort of all bound up and ready to go. How do you know you're getting to the fifth? finishing line, and what does that start to look like? So once we had all of the documentation wrapped up, and, you know, you can't get too hung up on, you know, the final product because the whole thing is meant to be a living document because, you know, when we finished documenting it, then we knew we were going to

implement something else. So it's sort of, you know you're going to have to keep updating it. But the finish line comes when you're ready to actually hand that package over to the independent auditor and to say, all right, you know, here is all our stuff. We're putting it out there for you to review and schedule that on-site audit. And so then the auditors show up. They read a lot. They watch you doing the work. And then what happens?

Then they put together what's called a SAR, which means security assessment report. The SAR is the auditor's report on your overarching compliance with the baseline. And if they have findings, they'll rank them as high, medium or low, kind of like you see. Yeah, exactly. what their job is to describe to the agency what the risks are to using the system. So if they find things during the audit that they deem as a high risk, and it's all scoped out what those risk categories are, but they'll deliver that to the agency.

And again, to your point about risk, it's not like a pass-fail, because then the agency, who's the customer, looks and says, ooh, you have two highs, that might be too-too-many. Or are you planning on fixing this? if you're planning on it, there's like a whole give or take. After you do 18 months worth of work or nine months worth work, you don't fail and have to go back. And the customer is in control of evaluating the risk of like still buying you or not.

Yeah, and those findings would go onto what's called a Poam or plan of action and milestones. So once you have those findings, then you would describe what you're going to do to fix it, what's your timeline, what are your milestones, and so forth. And one of the benefits of having that consulting advisor looking at your package and helping you do that is, they'll tell you what a showstopper is. They'll say, hey, that implementation is not going to cut it. Don't do that. Let us help you. So sometimes people think about compliance. They think about it as sort of like getting your driver's license. Like you get annoyed, you go through a process, you take a test, and then poof, you have a driver's license basically for the rest of your life. But FedRamp isn't really like that. There's a lot about monitoring and keeping things. And so what did you learn going through the process that was different than other types of certification or authorization? I mean, the one thing I've learned is that FedRamp is not over. And I have to laugh. Okay, that's like an uplifting emotion. Like, yeah, please listen to our podcast for that. the thing that's never going to end. Well, it's just funny because we've been working on this.

And every time we hit a big milestone, we like to celebrate it with the wider team. And everybody's like, yay. And then they're like, oh, you're done with Fed right now, right? And we're like, no. So, you know, continuous monitoring is one thing we already mentioned where even once you obtain your authority to operate or your ATO and you have that authorization, you're still going to be working with the agency on a regular basis. So you have your ATO and you've got a bunch of conmon going on just to use that.

all the acronyms in one sentence. Yeah, and we'll link to the Conmon guide, which talks about what that looks like. But in a nutshell, you're doing monthly scanning, your ranking vulnerabilities, you're responding to those on a specified time basis, et cetera. So let's say that the company is ready to dive in. They have a product that they've been selling to commercial customers. The first cohorts believe it meets their needs for security and privacy and things like that, the product is selling, but now a agency is interested for whatever reason, the inbound

or you spoke at a conference or something. So first, how long do the salespeople have to wait until a deal is closed now? Well, be nice. Yeah, yeah. I mean, again, it depends on how motivated the agency is. So actually, that's a super important point. It's not just how motivated you are as the company. Like, if the agency really wants you, they can pull you through in a lot of ways. Yeah, because again, it's all about risk. And, you know, the agency is the decider of what kind of risk they're going to tolerate. And so if an agency is really motivated, then they can help push you along to becoming in-process. And in-process is a designation that requires explicit agency support. But if you're at that stage where you've got that interest,

you have to choose, okay, am I going to go, there are two ways to get authorized. There's the agency route, and then there's something called the Jab, which is the Joint Authorization Board, which is a little bit harder to do because you have to do a business. case. So I think for our purposes, it makes more sense to address the agency route, which is probably the situation you're talking about where somebody expresses interest. Right. So that's probably a good lesson for folks, which is that the best bet for going through this is, in a sense, to first line up a potential customer rather than just sort of say, oh, let's preemptively go and do FedRamp because it actually makes more work for yourself

if you don't have the first customer lined up. Yeah, that's right. And they do have that job process, which is for companies that might have, you know, a broad application, but it's a much different process. Okay, so there's a bunch of actual bureaucracy stuff about getting on the GSA list and filling out those forms. But then, like, is it a year, two years, five years? How long is this exactly?

Yeah, let's not keep the sales team hanging too long. So if you're counting from the time, you have your package already. It could be as little as a few months, maybe even six weeks, we've heard, for the agency to review that package and grant you the authorization. I think if you're counting from the day,

the team says, hey, let's do FedRamp, and you still have to put the package together, you're probably looking at at least nine months or a year, possibly. So it's actually not wildly out of bounds with what a procurement team might do or like any of the large tech companies that just do what they call a security audit or something might easily take that same length of time. It comes down to how many resources the company has to bring to bear on the project, because we took a little bit longer, but that's because we didn't stop people from doing their full-time jobs only to work on FredRamp. We didn't stop feature development for the product.

So you decided you're flipping the switch and you're going to go for it. Did you have a team of 10? Like how many people have to do all of this checkboxing and process documentation and Conmon stuff? So when we started, it was just myself on the security team. We had our engineers that were involved in sort of scoping and looking at how much work we thought it would be. And then over time, we brought on a DevOps person. We hired a couple of people onto my team. But again, none of us have been doing it full time. So it's been probably a core group of five people working on various elements of it. And then when we were doing the push to complete a lot of the technical and engineering work, we brought in other engineers. And this is an interesting

point because of the way you chose to do it, but you overlaid like SOC2 and GDPR and other privacy work sort of all at the same time, which sounds overwhelming. But it's all so closely related, was it more efficient to do it that way? Doing a lot of these broader things like GDPR and FedRamp, you know, there is overlap, so it certainly helps. I don't know that I would wish all those things on anyone, but certainly you're doing a lot of the same things. And, you know, for folks that do SOC2, you probably know the COSO standards were added, I think,

last year. Okay, so one last thing, which is you go through all of this. you're given the label, like, in process, authorized? Like, what is the specifics of that? Because that's something that salespeople often do get confused because of the FedRamp lingo, so to speak. The lingo can be slightly confusing. So in order to be listed in the Fedderamp marketplace on the website.

A marketplace, which is literally like these are the cloud things you can go buy as a federal agency. Yeah, exactly. So there's FedRamp Ready and FedRamp in process. And I think people swap those around a lot. So FedRAMP ready means that you've gone through sort of a high level evaluation. And if you get that ready stamp, it means that they think that you're capable to meet the FedRamp requirements. And it's just intended to help agencies look out there and say, oh, well, you know, there's

an independent assessment that these folks are ready and can probably do it. Whereas in process is a designation where you have to have the authorizing official at an agency tell the FedRAMP office that we are working with this cloud service provider on an authorization. You're not authorized yet, but you're affirmatively working on that authorization. And don't play fast and loose with those terms with your salespeople. Like don't make up what they mean and don't say what you aren't. Because they have branding guidelines and stuff. Yeah, the FedRamp Office has branding guidelines.

And for a good reason, they don't want companies out there saying that they have a FedEx authorization if they don't. they've worked hard on creating this process and creating this framework and they don't want companies misrepresenting. And so ultimately with security things, the reason nobody wants anything to happen like a breach or anything like that. But if you're operating in this environment where you've committed to a customer, in this case a federal agency, that you do all this stuff, and then something happens, does FedRamp have say in, like, are they part of like adjudicating the failure or do they have remediation duties? Or is they're not in involved in that? Like, where does the government come in in terms of a security issue?

Well, fortunately, I don't have direct experience with that. But the Conmon Guide on Continuous Monitoring does cover various types of escalations, like incidents. And so I think if a company had an authorization and they had some kind of security incident or breach occur, it would go through that escalation process in the Conmon. And certainly they contemplate revocation of your authorization. But it I imagine it would be a conversation with the folks at the agency, you know, talking about your plan for remediation. Did you catch it? Did you limit the damage? So I don't have sort of a black and white answer on what would happen there, but I know that they've put a framework in place

to address those kinds of things. All right. So in your role in Everlaw, you've gone through quite a few certifications. Like you've gone through GPR, you've gone through SOC2, you're working on Fed. Like, where does this fall in the spectrum of effort and time and come? complexity compared to. You've done some health care, even though HIPAA is not a certification. Yeah, we've done the privacy sock too, but we've also done an independent sort of HIPA compliance assessment as well. And FedRAMP has definitely been the most work because it involved, you know, from an architectural standpoint, you know, we're creating a federal environment and there's a lot of work that we've done to improve on the back end. But I'm trying to think because GDPR is also a ton

of work. It's actually a good time to mention, too. One of the things that I found particularly interesting as I dove into this with you is that at every step, the OMB has really worked to make this, like, attractive and easy. That sounds weird, but their goal is not to stop you from getting authorized. It's actually to find ways to get you authorized. And for what it's worth, the FedRamp.gov website is one of the best federal websites out there. They have a person who's the customer success manager, so they really are trying to make it

easier for cloud companies to go through this process, to understand. And, you know, Everlau, we met with those folks, and they helped us, they helped guide us. And so we found that to be really helpful. Yeah. So unlike what you normally think of in terms of regulation or certification, they don't come across as like, we're here to prevent you from getting this. It's not even like the DMV in that regard. They actually just want to help you. Yeah. I mean, their mandate is to help carry out the cloud first or, you know, the policy that the government has to push IT modernization and cloud adoption in the federal government. Well, this was super fun. So thanks so much. This has been Steven Sinovsky and Lisa Hawke. Thank you.

Thank you very much.