There is no established playbook.
No previous iterations.
There is no deep understanding of how this model actually behaves in practice.
At the same time, we were not trying to approach FedRAMP 20x as traditional compliance.
We’ve built a direct API connection that allows FedRAMP and auditors to pull complete machine-readable data sets in JSON format directly from the platform. Human-readable exports were still present where necessary, but the focus was on uncovering operational truth rather than processing hard evidence.
That is one of the main principles behind FedRAMP 20x itself. Controls need to be both machine readable and human readable. The basic expectation is that a large percentage of controls should be automated with consistent evidence flowing behind them rather than consistent evidence being compiled manually before being audited.
What this means in practice is that auditors are no longer just reviewing a package of time evidence. They get continuous visibility into operational data sets and can query those fields in a very flexible way.
That is a very different concept from traditional obedience.
And honestly, I think that difference is part of what made the trip so rewarding.
We did not fail. We repeated
Because I don’t think what followed was a failure.
I think it was a repeat.
Modern engineering teams don’t release perfect software on day one. They evaluate, rebuild, re-engineer, improve and iterate continuously based on telemetry and feedback.
Applications go through:
- Testing
- User feedback
- Reorganize
- Fixing bugs
- Telemetry analysis
- Continuous improvement
No one expects the first version to be perfect.
But historically, the GRC has behaved quite differently.
Build controls.
Gather evidence.
Pass the survey.
Repeat next year.
Auditing becomes the bottom line. Our finish line was “good effort,” “we think it’s ready for a Low endorsement, but not a Medium yet.” For a moment, it seemed like a failure. It was painful. It felt very different from any other test or research as we didn’t really know what we had achieved. In fact, FedRAMP 20x feels fundamentally different and maybe that’s the whole point.
The process itself was the answer.
Not: Can you tell a good enough story?
But: What is your environment really like and how do you continuously improve it?
That’s a completely different concept.
One of the themes that emerges throughout FedRAMP 20x is that assurance should evolve through continuous iterations rather than guaranteeing a yearly point in time.
Of course.
That’s how engineering works.
Low Approval was not the final condition. It was a testing ground and a time for refactoring that helped us understand where the next iteration should go.
And honestly, if you can speed up the average FedRAMP with well-polished dashboards and no uncomfortable truths exposed, then the framework probably isn’t doing its job.
That’s one of the things I really appreciate about FedRAMP 20x.
It challenges your thinking.
It forces you to rethink the practices that have become standard across all parts of the compliance industry.
Historically, proving infrastructure security often meant screenshots or posted settings. Now we can expose every VM, every drift event and the full history of position changes in the entire environment.
That changes the behavior a lot because you can no longer prepare a very pure sample. You must maintain the original posture continuously.
Historically, proving SDLC maturity meant selecting a handful of pull requests. We can now expose all workflows, including all overrides or manual pushes to production.
Historically, proving ownership has meant reviewing the sample JML. We can now reveal the performance history of the full ownership life cycle over the years.
And honestly, that was one of the areas that challenged some of our thinking the most.
Traditional sample evidence can make processes look consistently successful because it reviews only selected examples. But the practical reality is different. You only need one joint, transformer or leaving process to fail improperly for the risk to be real.
That’s exactly the kind of thing that ongoing performance visibility reveals much faster than traditional evidence gathering.
That’s just not the best evidence.
It is a very different philosophy of certainty.
The rise of GRC engineering
And this is where I think GRC engineering becomes very important.
Not because everyone suddenly needs to be a software engineer, but because the discipline itself is moving from the use of documentation to the problem of functional engineering.
Modern GRC teams are increasingly building telemetry pipelines, integrations, APIs, infrastructure visibility and continuous assurance layers. And honestly, some of those pipelines are more difficult to build than people realize. Cloud infrastructure, CSPM tool and application security platforms are straightforward because the data is already structured and accessible. The really hard parts of messy applications are organizations that were historically handled through process and human interaction.
Things like policy management workflows, budget approvals, tracking software and non-standard operating procedures are very difficult to set up and consistently disclose.
This is another reason why this change is so important. It forces organizations to use the spaces that used to reside in spreadsheets, meetings or national information.
That’s a very different skill set than managing spreadsheets and linking screenshots.
More importantly, it changes the conversation.
One of the things I’ve enjoyed most throughout the FedRAMP 20x process is that the conversations have stopped being: How do we satisfy this control?
And he was: What risk are we actually trying to reduce here?
That’s a healthy conversation for security teams to have. Because not every risk is equally important to every organization. Not all controls logically improve the security posture. Not all framework requirements are suitable for the same investment.
Traditional compliance tends to struggle with that nuance because it promotes consistency and uniformity.
Modern engineer-led assurance feels different.
It feels more concrete, more practical and more realistically reliable.
And honestly, honesty is probably the biggest thing missing from most compliance departments today.
We have created an industry where everyone feels pressure to look perfect.
Complete dashboards. Complete controls. Complete the results of the study.
But real engineering environments are never perfect.
They have bugs, drifts, exceptions, failures, temporary workarounds and rare cases.
That does not automatically mean an unsafe environment. It means it’s true.
In fact I think one of the biggest changes FedRAMP 20x and the wider GRC engineering movement is pushing is this: disagreement should not destroy trust. If they are handled properly, they should build up.
Because mature organizations don’t pretend problems don’t exist. They are the ones who can identify problems quickly, disclose them honestly and improve them continuously. That’s engineering. And maybe that’s where compliance finally starts to come in handy again.
The future of trust
In organizations participating in current pilots, many of these concepts are already being tested through automated-first tests, machine-readable proofs and continuous visualization. FedRAMP 20x Phase 2.
Because right now, most compliance still works like we print out MapQuest directions in 2004 and hope nothing changes between point A and point B.
The environment is constantly changing. Cloud infrastructure is moving, developers are moving fast, businesses are evolving and threat actors are adapting faster than an annual audit.
Yet much of the certainty still relies on frozen images and sample proofs that are out of date the second they are sent to PDF.
That’s the bit I think FedRAMP 20x genuinely understands. This is not just about keeping the audits up to date. It is about acknowledging that modern systems are living systems.
They are ephemeral, constantly changing and impossible to fully understand with consistent evidence alone.
This is why the move to APIs, telemetry and machine-readable proofs is so important.
Not because APIs are trendy.
Because they allow us to reveal the working 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 be sending customers PDFs and certificates.
I think they will expose the layers of authentication.
APIs.
Telemetry.
Machine-readable proof.
Instead of: Here is our SOC 2.
They will say: Here is the performance data. Ask yourself.
Auditors are not going to disappear, but I think their role is changing a lot.
A little time to explore screenshots and selected controls. More time to ensure that the evidence base pipelines are complete, accurate and reliable.
Modern auditing is becoming less about auditing controls and more about auditing data integrity.
And honestly?
That sounds like a much healthier future than the one we’re building today.
Because the future of trust is probably not polished dashboards and carefully curated testimonials. It’s practical truth, and practical truth is messy. It contains drifts, exceptions, bypasses, loopholes and uncomfortable findings, but that’s why it’s important.
Stop rewarding the best narrators
Perhaps that is the biggest change FedRAMP 20x is trying to make. They are not better papers. Better visibility.
For years, we have rewarded organizations for telling a clean story. Maybe it’s time we rewarded them for revealing the truth instead. That’s FedRAMP 20x transformation and best-in-class GRC engineering.
This article was published as part of the Foundry Expert Contributor Network.
Want to join?
