FedRAMP Public Notice-0013: Initial Outcome of the Rev5 Family of RFCs 0026 - 0039

We recently published about 17 RFCs on a Rev 5 baseline security controls. Um I think that was like RSC 26 through RFC 98, something crazy like that. >> Slight exaggeration, but sure. >> That felt like I mean uh 26 through 30 and and basically we did that by control family and originally that was just a streamlining of updating the controls to reflect options for the new uh balanced approved releases. Around the time that was published, we closed a couple previous RFCs. This is like a Marvel timeline, you got to unwind like like alternate universe over here. Um and then we published the notice that said we're going to change the way that Rev 5 was going to be handled and we were going to require mandatory balanced approved releases. And so we had this kind of like weird timeline moment where we had open RFCs out, but the reality was that uh we had already made some decisions that would affect that. So notice is going to be sharing our concept on how we're going to treat Rev 5 moving forward and like the major changes to that. It's going to follow up on the prior notice that said we're going to require balanced approved releases. We're going to require machine readable artifacts. We're going to require structured semi-structured text artifacts. Um but it changes the approach for individual controls and what we're doing and expecting with individual controls. Kind of trying to bring it a little bit more towards 20X. Tell us a bit more about that. >> Yeah, so in the the new Rev 5 baselines, we've taken away a lot of the FedRAMP uh defined parameters and specific guidance to let CSPs have more freedom in terms of how they feel they can best meet the security objectives that are described in those controls. So, that's a lot more similar to what we've done in 20X where our focus is more on tell us how you're secure, tell us how you're protecting federal data. That's the information that we want and then we'll make risk-based decisions based on that. >> Yeah, I think we've started finding that if a control stipulated that something had to be done annually, all cloud service providers were just saying, "I'm going to do it annually because that's what they were going to be held to." But, in reality, a lot of cloud service providers would do that much more frequently than the annually. And so, this gives the cloud service providers the ability to define what they think is reasonable for the federal >> Cuz one of those underlying things that is really interesting when you look at the history of FedRAMP, I mean, 15 years ago, 10 years ago, even 7, 8 years ago, there was a lot of just just we're going to build a GovCloud. Just tell us what you want this number to be so that it can pass and and we can create this minimum bar. And so, FedRAMP had built into the Rev 5 baselines on like so many of these controls, the organization is supposed to define a parameter. Like, how often will I do a thing, right? And FedRAMP set guidelines for those requirements everyone had to meet. And the theory there was that it was creating a minimum bar that everyone had to had to go over. And then, if you're over that bar, you're you're doing a good job. And that made sense in a world where we didn't have this established trust, we didn't know how this was going to work, and we knew people were going to build custom stuff for the government. It just kind of it was a logical beginning. The problem with that is it shifts the compliance first over security. And what happens is instead of becoming a minimum bar over time, that's become like a ceiling. And so, instead of people trying to do better than those things, they just are like, "Hey, we only need to do it once a year, we'll only do it once a year." >> Yeah. >> And in a modern era, like we don't this is no longer acceptable. Like most of these timelines are just like you should be doing things every minute. There are things that we say to do every 30 days that you should be doing continuously every second of every day. And like the technology has changed. The options for that has changed. So, do we decrease all those timelines? But that leads to a problem where one cloud service might not have a use case for a lower timeline. One cloud service might. Why are we forcing them both to be the same when they should be treated differently? Like there's a theory of 20X, right? >> One of one of the other big um themes for 20X is, right, that closer collaboration between engineering and GRC, right? And I've seen this happen where, you know, the security team is filling out the SSP and they're like, "Oh, great. This says that I have to do security scans weekly, so I don't have to go ask the engineering team how often we do security scans. I'll just put weekly here, right? And that's the end of it." And like this the engineering team is over there like, "Hey, we're scanning once a quarter. It's fine." So, you know, creating that forcing that uh dynamic, forcing that conversation between bless you. Forcing that conversation between the engineering team and the GRC team so that they are working closely together, they're collaborating, and figuring out what do we really do, what do we really want to do, what can we commit to. >> Yeah. It goes back to this like the the align shift from a system security plan. Like we nobody cares what your plan is. We don't care how often you plan to do it. We don't we don't care that you have organizationally defined that you plan to do something every 30 days. We want to know over the last period of time how often did you do it? When did you do it? What did it look like? That's what 20X is based on, right? It's is report out, not your plan, but the actual outcome of the decisions that you made. So, we're going to bring that to rev five a little bit, too. That's going to free up a lot of uh effort and and asked, but it's going to change the game cuz now you, just like with 20X, you're going to have to define your own goals. You're going to have to define your own parameters. So, the nutshell is outcome of uh notice on on the outcome of RFC 26 through 30 is going to primarily walk back a lot of requirements. It's going to pull things up, and it's get stand instead it's going to direct you to apply your own organizational goals and be very clear about what those are. And as we put out guidance in the consolidated rules for 2026 about how to uh format your semi-structured text or your, you know, very structured text, we're going to want to make sure that those parameters are well defined, so we can click quickly look at them. So can agencies. We've got some good stuff, and hopefully we can stop all this 30-days nonsense. Like do it more often. Do it more often.