We are auditing a curated version of history.
I’ve worked in security long enough now to know something most of us don’t 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.
That’s uncomfortable to admit, but it’s 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’t. They are snapshots. Point-in-time reviews based on selected evidence and sampled testing. That doesn’t make them useless. These frameworks were built for a completely different world where cloud infrastructure was less dynamic, APIs weren’t everywhere and continuous telemetry at scale simply wasn’t realistic. Sampling existed because there wasn’t much of an alternative. That’s before we even mention AI, where technology now changes on a monthly cadence against a regulatory backdrop that speaks in years.
The issue is that the world moved on, but assurance largely didn’t. The team behind FedRAMP 20x 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.
That’s why one of the most important things I’ve heard said around FedRAMP 20x is this: Passing audits does not equal security.
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’s the bit the industry is becoming increasingly uncomfortable with. How many times a year is the production push made as a “hot fix”?
And honestly, I think that’s why movements like GRC engineering are getting so much traction. Not because people suddenly wanted a trendy new title for compliance. But because there’s growing frustration with how artificial parts of the industry have become.
A few months ago, I gave a talk in Seattle comparing the rise of GRC engineering to the rise of grunge music. I’m a huge Nirvana fan, so maybe the analogy was inevitable, but the more I thought about it, the more it made sense. Grunge didn’t 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.
That’s 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.
Which brings me to one of the dumbest weekends of my life.
Many years ago, my wife decided she wanted to go glamping in the Lake District for Valentine’s Day.
We drove north through classic, miserable British weather in a tiny little car completely unsuited for what was coming.
As we got closer to the Lakes, the rain slowly turned into heavy snow.
Then a full blizzard.
The sat nav confidently directed us up a tiny snow-covered road that we physically could not drive up.
We got stuck.
Eventually, we got free.
The sat nav recalculated and sent us up another equally impossible road.
Same outcome.
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×4 to rescue us while trying not to laugh too hard at the idiots in the tiny car.
After about seventeen hours of driving, we gave up and drove home.
Completely failed Valentine’s trip.
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’t 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’t the absence of data. The problem was understanding the context around the data. Tourists drive into sea following GPS directions.
A lot of compliance programs behave the same way. The objective quietly becomes “pass the audit” instead of “reduce meaningful risk”, and once that happens, teams start optimising for the framework rather than the security outcome. That’s 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.
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.
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, which argues that modern assurance should be built on automation, telemetry and engineering disciplines rather than static evidence collection.
One of the biggest mindset shifts for our engineering teams was realising FedRAMP wasn’t 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’s a completely different way of thinking about compliance because the conversation moves away from “prove this existed once” and towards “show me the operational reality continuously.”
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.
Instead of selecting a handful of GitHub pull requests, you expose the entire development workflow, including the messy bits where processes were bypassed.
Instead of showing sampled JML evidence, you expose the full lifecycle history of identity management over years.
Honestly, it should feel uncomfortable because that discomfort is probably a sign you’re finally exposing operational truth instead of polishing it away. Trust shouldn’t come from perfection. It should come from transparency.
And honestly, that’s exactly why our own FedRAMP 20x journey became so interesting.
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.
We thought we had a solid plan.
We didn’t.
Or at least not one that was mature enough yet.
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’t already completed the low pathway first.
That mattered.
We didn’t yet have the operational muscle memory.
No established playbook.
No previous iteration.
No deeply embedded understanding of how this model actually behaved in practice.
At the same time, we weren’t trying to approach FedRAMP 20x like traditional compliance.
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.
That’s 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.
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.
That’s a very different mindset from traditional compliance.
And honestly, I think that difference is part of what made the journey so valuable.
Because I don’t actually think what happened next was failure.
I think it was iteration.
Modern engineering teams don’t release perfect software on day one. They test, rebuild, refactor, improve and iterate continuously based on telemetry and feedback.
Applications go through:
Nobody expects version one to be perfect.
Yet historically, GRC has behaved completely differently.
Build the controls.
Collect the evidence.
Pass the audit.
Repeat next year.
The audit becomes the finish line. Our finish line became a “good effort,” “we think you’re ready for a Low authorization, but not Moderate just yet.” For a moment, it felt like failure. It hurt. It felt fundamentally different from any other assessment or audit as we genuinely didn’t know what we’d achieved. In fact, FedRAMP 20x feels fundamentally different and maybe that’s the whole point.
The process itself became feedback.
Not: Can you tell a convincing enough story?
But: What does your environment actually look like and how do you continuously improve it?
That’s a completely different mindset.
One of the recurring themes throughout FedRAMP 20x is that assurance should improve through continuous iteration rather than annual point-in-time validation.
Exactly.
That’s how engineering works.
The Low authorization wasn’t the end state. It was a checkpoint and a recalibration moment that helped us understand where the next iteration needed to go.
And honestly, if you can speedrun moderate FedRAMP with perfectly polished dashboards and no uncomfortable truths exposed, then the framework probably isn’t doing its job.
That’s one of the things I genuinely appreciate about FedRAMP 20x.
It challenges your assumptions.
It forces you to rethink approaches that have become normalized across large parts of the compliance industry.
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.
That changes behavior massively because you can no longer optimize around the cleanest possible sample. You have to maintain the actual posture continuously.
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.
Historically, proving identity governance meant sampled JML reviews. Now we can expose the operational history of the full identity lifecycle over years.
And honestly, that was one of the areas that challenged some of our own assumptions the most.
Traditional sampled evidence can make processes look consistently successful because you’re 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.
That’s exactly the kind of thing continuous operational visibility exposes much more quickly than traditional evidence collection.
That’s not just better evidence.
It’s a fundamentally different philosophy of assurance.
And this is where I think GRC engineering becomes genuinely important.
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.
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.
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.
That’s another reason this shift matters so much. It forces organizations to operationalize areas that historically lived in spreadsheets, meetings or tribal knowledge.
That’s a very different skillset from managing spreadsheets and coordinating screenshots.
More importantly, it changes the conversations.
One of the things I enjoyed most throughout the FedRAMP 20x process was that discussions increasingly stopped being: How do we satisfy this control?
And became: What risk are we actually trying to reduce here?
That’s 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.
Traditional compliance often struggles with that nuance because it optimizes around consistency and uniformity.
Modern engineering-led assurance feels different.
It feels more contextual, more operational and honestly far more honest.
And honestly, honesty is probably the biggest thing missing from large parts of compliance today.
We’ve built an industry where everyone feels pressure to look perfect.
Perfect dashboards. Perfect controls. Perfect audit outcomes.
But real engineering environments are never perfect.
They have bugs, drift, exceptions, failures, temporary workarounds and weird edge cases.
That doesn’t automatically mean the environment is insecure. It means it’s real.
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.
Because mature organizations are not the ones pretending problems don’t exist. They’re the ones capable of identifying issues quickly, exposing them honestly and improving continuously. That’s engineering. And maybe that’s where compliance finally starts becoming useful again.
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. FedRAMP 20x Phase 2.
Because right now, most compliance still works like we’re printing MapQuest directions in 2004 and hoping nothing changes between point A and point B.
The environment changes constantly. Cloud infrastructure drifts, engineers move quickly, businesses evolve and threat actors adapt far faster than annual audits ever could.
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.
That’s the bit I think FedRAMP 20x genuinely understands. This isn’t just about modernising audits. It’s about acknowledging that modern systems are living systems.
They are transient, constantly changing and impossible to understand properly through static evidence alone.
That’s why the move towards APIs, telemetry and machine-readable evidence matters so much.
Not because APIs are trendy.
Because they allow us to expose operational truth continuously instead of periodically reconstructing it after the fact.
And honestly, I think that changes the future of trust.
In five years, I don’t think organizations will primarily send customers PDFs and certifications.
I think they’ll expose assurance layers.
APIs.
Telemetry.
Machine-readable evidence.
Instead of saying: Here’s our SOC 2.
They’ll say: Here’s the operational data. Query it yourself.
Auditors won’t disappear, but I think their role changes significantly.
Less time auditing screenshots and selected controls. More time validating whether the underlying evidence pipelines are complete, accurate and trustworthy.
Modern audit becomes less about auditing controls and more about auditing data integrity.
And honestly?
That feels like a much healthier future than the one we’ve built today.
Because the future of trust probably isn’t polished dashboards and carefully curated evidence. It’s operational truth, and operational truth is messy. It contains drift, exceptions, bypasses, gaps and uncomfortable findings, but that’s exactly why it’s valuable.
Maybe that’s the biggest shift FedRAMP 20x is trying to create. Not better paperwork. Better visibility.
For years, we’ve rewarded organizations for telling the cleanest story. Maybe it’s finally time we reward them for exposing the truth instead. That’s the revolution FedRAMP 20x and GRC engineering are leading.
This article is published as part of the Foundry Expert Contributor Network.
Want to join?
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。