{"id":8592,"date":"2026-06-25T09:00:00","date_gmt":"2026-06-25T09:00:00","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=8592"},"modified":"2026-06-25T09:00:00","modified_gmt":"2026-06-25T09:00:00","slug":"grc-is-broken-fedramp-20x-might-fix-it","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=8592","title":{"rendered":"GRC is broken. FedRAMP 20x might fix it"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

We are auditing a curated version of history.<\/p>\n

I\u2019ve worked in security long enough now to know something most of us don\u2019t really say out loud. A lot of compliance is theatre. Not all of it, and not all auditors or frameworks, but enough of it that most experienced CISOs know exactly what I mean. If you understand how audits work, know how controls are interpreted and can manage scope and narrative well enough, you can often steer things where you need them to go.<\/p>\n

That\u2019s uncomfortable to admit, but it\u2019s true. The market now treats things like SOC 2 and ISO 27001 as direct statements about operational maturity and security posture when they really aren\u2019t. They are snapshots. Point-in-time reviews based on selected evidence and sampled testing. That doesn\u2019t make them useless. These frameworks were built for a completely different world where cloud infrastructure was less dynamic, APIs weren\u2019t everywhere and continuous telemetry at scale simply wasn\u2019t realistic. Sampling existed because there wasn\u2019t much of an alternative. That\u2019s before we even mention AI, where technology now changes on a monthly cadence against a regulatory backdrop that speaks in years.<\/p>\n

The issue is that the world moved on, but assurance largely didn\u2019t. The team behind\u00a0 FedRAMP 20x<\/a> are attempting to address exactly that problem, pushing assurance towards automation, machine-readable evidence and continuous validation rather than documentation-heavy compliance exercises. Most compliance programs still revolve around screenshots, exported evidence, manually curated narratives and carefully staged representations of reality. And that word, reality, is the important bit because in many cases, we are not auditing reality at all. We are auditing a curated version of history.<\/p>\n

That\u2019s why one of the most important things I\u2019ve heard said around FedRAMP 20x is this: Passing audits does not equal security<\/strong>.<\/p>\n

Exactly. A company can pass an audit while engineers bypass processes every Friday night to hit deadlines. Controls can drift quietly over time while nobody notices because the evidence only exists for a specific audit window. The audit passes because the story passes, and honestly, I think that\u2019s the bit the industry is becoming increasingly uncomfortable with. How many times a year is the production push made as a \u201chot fix\u201d?<\/p>\n

And honestly, I think that\u2019s why movements like GRC engineering are getting so much traction. Not because people suddenly wanted a trendy new title for compliance. But because there\u2019s growing frustration with how artificial parts of the industry have become.<\/p>\n

A few months ago, I gave a talk in Seattle comparing the rise of GRC engineering to the rise of grunge music. I\u2019m a huge Nirvana fan, so maybe the analogy was inevitable, but the more I thought about it, the more it made sense. Grunge didn\u2019t emerge because people desperately wanted something shiny and new. It emerged because people stopped believing the polished version was real. Hair metal had become overproduced and performative. Grunge felt rough around the edges, but it also felt honest.<\/p>\n

That\u2019s exactly where GRC feels like it is right now. Too much compliance has become about presenting the cleanest possible version of reality instead of exposing operational truth. Too many clean reports. Too many green ticks on trust centers. Too many perfect policies.<\/p>\n

The sat nav problem<\/h2>\n

Which brings me to one of the dumbest weekends of my life.<\/p>\n

Many years ago, my wife decided she wanted to go glamping in the Lake District for Valentine\u2019s Day.<\/p>\n

We drove north through classic, miserable British weather in a tiny little car completely unsuited for what was coming.<\/p>\n

As we got closer to the Lakes, the rain slowly turned into heavy snow.<\/p>\n

Then a full blizzard.<\/p>\n

The sat nav confidently directed us up a tiny snow-covered road that we physically could not drive up.<\/p>\n

We got stuck.<\/p>\n

Eventually, we got free.<\/p>\n

The sat nav recalculated and sent us up another equally impossible road.<\/p>\n

Same outcome.<\/p>\n

This happened multiple times until we eventually ended up buried in a snow drift somewhere in the middle of nowhere, waiting for a bloke in a 4\u00d74 to rescue us while trying not to laugh too hard at the idiots in the tiny car.<\/p>\n

After about seventeen hours of driving, we gave up and drove home.<\/p>\n

Completely failed Valentine\u2019s trip.<\/p>\n

But honestly, I think about that weekend a lot when I think about GRC because the sat nav had data. What it lacked was context. It didn\u2019t understand the environment, the conditions, the capability of the vehicle or even the actual outcome we were trying to achieve. We became obsessed with following the prescribed route instead of stepping back and asking whether the route itself still made sense. It reminds me of stories like tourists literally driving into the sea while blindly following GPS directions. The problem wasn\u2019t the absence of data. The problem was understanding the context around the data.\u00a0 Tourists drive into sea following GPS directions.<\/p>\n

A lot of compliance programs behave the same way. The objective quietly becomes \u201cpass the audit\u201d instead of \u201creduce meaningful risk\u201d, and once that happens, teams start optimising for the framework rather than the security outcome. That\u2019s the shift I think FedRAMP 20x and the broader GRC engineering movement are trying to force. Not just better automation or more integrations, but a fundamentally different way of thinking about trust.<\/p>\n

Compliance becomes an engineering problem<\/h2>\n

One of the central ideas behind FedRAMP 20x is that assurance increasingly needs to be treated as an engineering challenge rather than a documentation exercise.<\/p>\n

Historically, most compliance has been based on samples. Sampled pull requests, sampled access reviews and sampled infrastructure evidence. FedRAMP 20x pushes in a very different direction with machine-readable evidence, APIs, telemetry and complete datasets instead of manually curated snapshots. Many of these principles closely mirror those outlined in the GRC Engineering Manifesto<\/a>, which argues that modern assurance should be built on automation, telemetry and engineering disciplines rather than static evidence collection.<\/p>\n

One of the biggest mindset shifts for our engineering teams was realising FedRAMP wasn\u2019t really asking for selected evidence anymore. They wanted the underlying operational data itself. Not a screenshot proving something was configured correctly on one specific day, but the actual flow of telemetry that underpinned the control or assurance statement. That\u2019s a completely different way of thinking about compliance because the conversation moves away from \u201cprove this existed once\u201d and towards \u201cshow me the operational reality continuously.\u201d<\/p>\n

Instead of showing a screenshot proving a virtual machine was configured correctly on one day, you expose every VM in the environment alongside drift data over time.<\/p>\n

Instead of selecting a handful of GitHub pull requests, you expose the entire development workflow, including the messy bits where processes were bypassed.<\/p>\n

Instead of showing sampled JML evidence, you expose the full lifecycle history of identity management over years.<\/p>\n

Honestly, it should feel uncomfortable because that discomfort is probably a sign you\u2019re finally exposing operational truth instead of polishing it away. Trust shouldn\u2019t come from perfection. It should come from transparency.<\/p>\n

We thought we were ready<\/h2>\n

And honestly, that\u2019s exactly why our own FedRAMP 20x journey became so interesting.<\/p>\n

We originally planned to move towards moderate through a much longer runway. Then the programme timings changed, government shutdowns caused disruption, and suddenly we found ourselves with around six or seven weeks before audit activity started.<\/p>\n

We thought we had a solid plan.<\/p>\n

We didn\u2019t.<\/p>\n

Or at least not one that was mature enough yet.<\/p>\n

We had missed the low pilot earlier in the journey and entered the moderate phase without having already gone through that foundational learning process. We were also the only organization in our pilot group that hadn\u2019t already completed the low pathway first.<\/p>\n

That mattered.<\/p>\n

We didn\u2019t yet have the operational muscle memory.<\/p>\n

No established playbook.
No previous iteration.
No deeply embedded understanding of how this model actually behaved in practice.<\/p>\n

At the same time, we weren\u2019t trying to approach FedRAMP 20x like traditional compliance.<\/p>\n

We built direct API connectivity that allowed FedRAMP and auditors to pull complete machine-readable datasets in JSON format directly from the platform. Human-readable exports still existed where required, but the focus was on exposing operational truth rather than curating static evidence.<\/p>\n

That\u2019s also one of the core principles behind FedRAMP 20x itself. Controls increasingly need to be both machine-readable and human-readable. The baseline expectation is that a large percentage of controls should be automated with continuous evidence flowing behind them instead of static evidence being manually assembled before an audit.<\/p>\n

What that means in practice is that auditors no longer just review a point-in-time evidence pack. They gain ongoing visibility into operational datasets and can interrogate those environments in a much more dynamic way.<\/p>\n

That\u2019s a very different mindset from traditional compliance.<\/p>\n

And honestly, I think that difference is part of what made the journey so valuable.<\/p>\n

We didn\u2019t fail. We iterated<\/h2>\n

Because I don\u2019t actually think what happened next was failure.<\/p>\n

I think it was iteration.<\/p>\n

Modern engineering teams don\u2019t release perfect software on day one. They test, rebuild, refactor, improve and iterate continuously based on telemetry and feedback.<\/p>\n

Applications go through:<\/p>\n

Testing<\/p>\n

User feedback<\/p>\n

Redesign<\/p>\n

Bug fixing<\/p>\n

Telemetry analysis<\/p>\n

Continuous improvement<\/p>\n

Nobody expects version one to be perfect.<\/p>\n

Yet historically, GRC has behaved completely differently.<\/p>\n

Build the controls.
Collect the evidence.
Pass the audit.
Repeat next year.<\/p>\n

The audit becomes the finish line. Our finish line became a \u201cgood effort,\u201d \u201cwe think you\u2019re ready for a Low authorization, but not Moderate just yet.\u201d For a moment, it felt like failure. It hurt. It felt fundamentally different from any other assessment or audit as we genuinely didn\u2019t know what we\u2019d achieved. In fact, FedRAMP 20x feels fundamentally different and maybe that\u2019s the whole point.<\/p>\n

The process itself became feedback.<\/p>\n

Not: Can you tell a convincing enough story?<\/p>\n

But: What does your environment actually look like and how do you continuously improve it?<\/p>\n

That\u2019s a completely different mindset.<\/p>\n

One of the recurring themes throughout FedRAMP 20x is that assurance should improve through continuous iteration rather than annual point-in-time validation.<\/p>\n

Exactly.<\/p>\n

That\u2019s how engineering works.<\/p>\n

The Low authorization wasn\u2019t the end state. It was a checkpoint and a recalibration moment that helped us understand where the next iteration needed to go.<\/p>\n

And honestly, if you can speedrun moderate FedRAMP with perfectly polished dashboards and no uncomfortable truths exposed, then the framework probably isn\u2019t doing its job.<\/p>\n

That\u2019s one of the things I genuinely appreciate about FedRAMP 20x.<\/p>\n

It challenges your assumptions.<\/p>\n

It forces you to rethink approaches that have become normalized across large parts of the compliance industry.<\/p>\n

Historically, proving infrastructure security often meant screenshots or exported configs. Now we can expose every VM, every drift event and the full history of posture changes across the environment.<\/p>\n

That changes behavior massively because you can no longer optimize around the cleanest possible sample. You have to maintain the actual posture continuously.<\/p>\n

Historically, proving SDLC maturity meant selecting a handful of pull requests. Now we can expose the entire workflow, including every bypassed approval or manual push into production.<\/p>\n

Historically, proving identity governance meant sampled JML reviews. Now we can expose the operational history of the full identity lifecycle over years.<\/p>\n

And honestly, that was one of the areas that challenged some of our own assumptions the most.<\/p>\n

Traditional sampled evidence can make processes look consistently successful because you\u2019re only reviewing selected examples. But operational truth is different. You only need one joiner, mover or leaver process to fail in the wrong way for the risk to become real.<\/p>\n

That\u2019s exactly the kind of thing continuous operational visibility exposes much more quickly than traditional evidence collection.<\/p>\n

That\u2019s not just better evidence.<\/p>\n

It\u2019s a fundamentally different philosophy of assurance.<\/p>\n

The rise of GRC engineering<\/h2>\n

And this is where I think GRC engineering becomes genuinely important.<\/p>\n

Not because everybody suddenly needs to become a software engineer, but because the discipline itself is evolving from a documentation exercise into an operational engineering problem.<\/p>\n

Modern GRC teams are increasingly building telemetry pipelines, integrations, APIs, infrastructure visibility and continuous assurance layers. And honestly, some of those pipelines are much harder to build than people realize. Cloud infrastructure, CSPM tooling and application security platforms are relatively straightforward because the data is already fairly structured and accessible. The really difficult parts are the messy operational systems that organizations historically handled through process and human coordination.<\/p>\n

Things like policy management workflows, budget approvals, software bill of materials tracking and non-standard operational processes are far harder to standardize and expose consistently.<\/p>\n

That\u2019s another reason this shift matters so much. It forces organizations to operationalize areas that historically lived in spreadsheets, meetings or tribal knowledge.<\/p>\n

That\u2019s a very different skillset from managing spreadsheets and coordinating screenshots.<\/p>\n

More importantly, it changes the conversations.<\/p>\n

One of the things I enjoyed most throughout the FedRAMP 20x process was that discussions increasingly stopped being: How do we satisfy this control?<\/p>\n

And became: What risk are we actually trying to reduce here?<\/p>\n

That\u2019s such a healthier conversation for security teams to have. Because not every risk matters equally to every organization. Not every control meaningfully improves security posture. Not every framework requirement deserves the same operational investment.<\/p>\n

Traditional compliance often struggles with that nuance because it optimizes around consistency and uniformity.<\/p>\n

Modern engineering-led assurance feels different.<\/p>\n

It feels more contextual, more operational and honestly far more honest.<\/p>\n

And honestly, honesty is probably the biggest thing missing from large parts of compliance today.<\/p>\n

We\u2019ve built an industry where everyone feels pressure to look perfect.<\/p>\n

Perfect dashboards. Perfect controls. Perfect audit outcomes.<\/p>\n

But real engineering environments are never perfect.<\/p>\n

They have bugs, drift, exceptions, failures, temporary workarounds and weird edge cases.<\/p>\n

That doesn\u2019t automatically mean the environment is insecure. It means it\u2019s real.<\/p>\n

I actually think one of the biggest mindset shifts FedRAMP 20x and the broader GRC engineering movement are pushing is this: nonconformities should not automatically destroy trust. Handled correctly, they should build it.<\/p>\n

Because mature organizations are not the ones pretending problems don\u2019t exist. They\u2019re the ones capable of identifying issues quickly, exposing them honestly and improving continuously. That\u2019s engineering. And maybe that\u2019s where compliance finally starts becoming useful again.<\/p>\n

The future of trust<\/h2>\n

For organizations participating in the current pilots, many of these concepts are already being tested through automation-first assessments, machine-readable evidence and continuous visibility.\u00a0 FedRAMP 20x Phase 2<\/a>.<\/p>\n

Because right now, most compliance still works like we\u2019re printing MapQuest directions in 2004 and hoping nothing changes between point A and point B.<\/p>\n

The environment changes constantly. Cloud infrastructure drifts, engineers move quickly, businesses evolve and threat actors adapt far faster than annual audits ever could.<\/p>\n

Yet most assurance still relies on frozen snapshots and sampled evidence that were already out of date the second they were exported into a PDF.<\/p>\n

That\u2019s the bit I think FedRAMP 20x genuinely understands. This isn\u2019t just about modernising audits. It\u2019s about acknowledging that modern systems are living systems.<\/p>\n

They are transient, constantly changing and impossible to understand properly through static evidence alone.<\/p>\n

That\u2019s why the move towards APIs, telemetry and machine-readable evidence matters so much.<\/p>\n

Not because APIs are trendy.<\/p>\n

Because they allow us to expose operational truth continuously instead of periodically reconstructing it after the fact.<\/p>\n

And honestly, I think that changes the future of trust.<\/p>\n

In five years, I don\u2019t think organizations will primarily send customers PDFs and certifications.<\/p>\n

I think they\u2019ll expose assurance layers.<\/p>\n

APIs.
Telemetry.
Machine-readable evidence.<\/p>\n

Instead of saying: Here\u2019s our SOC 2.<\/p>\n

They\u2019ll say: Here\u2019s the operational data. Query it yourself.<\/p>\n

Auditors won\u2019t disappear, but I think their role changes significantly.<\/p>\n

Less time auditing screenshots and selected controls. More time validating whether the underlying evidence pipelines are complete, accurate and trustworthy.<\/p>\n

Modern audit becomes less about auditing controls and more about auditing data integrity.<\/p>\n

And honestly?<\/p>\n

That feels like a much healthier future than the one we\u2019ve built today.<\/p>\n

Because the future of trust probably isn\u2019t polished dashboards and carefully curated evidence. It\u2019s operational truth, and operational truth is messy. It contains drift, exceptions, bypasses, gaps and uncomfortable findings, but that\u2019s exactly why it\u2019s valuable.<\/p>\n

Stop rewarding the best storytellers<\/h2>\n

Maybe that\u2019s the biggest shift FedRAMP 20x is trying to create. Not better paperwork. Better visibility.<\/p>\n

For years, we\u2019ve rewarded organizations for telling the cleanest story. Maybe it\u2019s finally time we reward them for exposing the truth instead. That\u2019s the revolution FedRAMP 20x and GRC engineering are leading.<\/p>\n

This article is published as part of the Foundry Expert Contributor Network.<\/strong>
Want to join?<\/a><\/strong><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

We are auditing a curated version of history. I\u2019ve worked in security long enough now to know something most of us don\u2019t really say out loud. A lot of compliance is theatre. Not all of it, and not all auditors or frameworks, but enough of it that most experienced CISOs know exactly what I mean. […]<\/p>\n","protected":false},"author":0,"featured_media":8593,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-8592","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/8592"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=8592"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/8592\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/8593"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=8592"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=8592"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=8592"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}