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.
We didn’t fail. We iterated
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:
- Testing
- User feedback
- Redesign
- Bug fixing
- Telemetry analysis
- Continuous improvement
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.
The rise of GRC engineering
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.
The future of trust
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.
Stop rewarding the best storytellers
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?
