I attended the FedRAMP Community Working Group around GRC Engineering this week, and there seemed to be a lot of pushback in the Q&A. Some folks thought that it was nothing but a vendor pitch. Others felt like it was being unfair to small (or large) CSPs. In my mind though, we need to shift the way we are thinking about all of this. FedRAMP 20x isn’t an overhaul of compliance. It is an extension of engineering best practices into compliance. In other words, compliance is now a function of Site Reliability Engineering. Let me explain.

The Misunderstanding

Most of the confusion around FedRAMP 20x comes from folks perceiving it solely as a compliance policy change. The pushback in the CWG would be reasonable if FedRAMP 20x was simply compliance reform. But it isn’t.

FedRAMP 20x is an engineering initiative disguised as compliance. The core move is the same one that SRE made against traditional operations a decade ago.

Understanding FedRAMP 20x as an extension of SRE gives practitioners an existing body of practice to draw from, and gives authorizing officials a clearer picture of what they should actually be asking for.

SRE in Brief

Site Reliability Engineering emerged from Google in 2003. SRE is what happens when you treat operations as a software engineering problem instead of just a staffing problem. Per the SRE Manifesto, eight core principles define the discipline:

1. SREs make sure their systems are reliable and not just available and resilient.
2. SREs guarantee all systems and applications are observable and under monitoring.
3. SREs manage systems, services, and infrastructure to learn how to automate toil.
4. SREs use data science and statistical methods to understand the observability of data.
5. SREs identify, measure, and reduce toil arising from operational and engineering work.
6. SREs implement test cases, execute software delivery tests, and stay ahead with capacity planning.
7. SREs employ chaos engineering to unveil systemic weaknesses in production.
8. SREs respond to meaningful incidents, implement complex changes, and conduct blameless postmortems.

This is the model FedRAMP 20x is now extending into compliance.

A Rose Is A Rose By Any Other Name (In This Case, GRC Engineering)

SRE has already influenced FedRAMP’s approach to continuous monitoring, at least for monthly deliverables. GRC Engineering is the next step in that propagation.

What changes is that controls stop being abstract narratives in word documents and start being measured engineering outcomes. CSPs participating in the FedRAMP 20x Phase 2 pilot are already demonstrating this. During the call, it was brought up that automated AT-2 validation, for example, works by querying identity provider and training platform APIs continuously to produce a live answer to “do the people who can access sensitive systems right now have the required training?” rather than a quarterly attestation about the past. None of this requires inventing new concepts. It just requires applying existing ones to a new domain.

The Open Source Stack

Whatever you call it — SRE for compliance, GRC engineering, compliance automation — it doesn’t have to rely on expensive vendors. The tooling is largely open source, and most of it already has SRE lineage. The core stack practitioners should know:

• Policy enforcement: Open Policy Agent (OPA) and Kyverno
• Observability: OpenTelemetry and Steampipe
• Machine-readable compliance: OSCAL
• Configuration baselines: SCuBA
• Supply chain integrity: SLSA, SBOMs, and Cosign
• Vulnerability intelligence: CVE, CVSS, KEV, VEX, and Vulnrichment

For those who want to read more, I’ve written articles on how to apply these technologies here, here, and here.

What This Means

For practitioners, FedRAMP 20x is a bridge that spans the engineering practices you already use for reliability and security into compliance. If your organization has mature observability, policy-as-code enforcement, and CI/CD security gates, you are closer to FedRAMP 20x readiness than an organization with a complete SSP and no automation.

GRC Engineering isn’t just a vendor pitch, and it isn’t inaccessible. The open source nature of this stack is precisely what levels the playing field. A small CSP with strong engineering practice and OPA, OpenTelemetry, and OSCAL is on equal footing with a large one running expensive commercial tooling. The advantage goes to solid engineering over big budgets.

More than that though, GRC engineering is just another name for the same thing that made cloud computing so successful in the first place. In fact, the thread goes all the way back to Claude Shannon and Norbert Wiener in the 1950s. But that’s for another blog post.