From Audits To Assurance: How 'Self-Healing' Compliance-As-Code Is Redefining Federal Security

For over a decade, federal cloud security ran on point‑in‑time documentation packages that were often obsolete before the approval signature dried. But in a world where software ships daily and threats evolve faster, static reviews no longer reflect the systems they are meant to govern. To address this, the federal government has launched an overhaul of its cloud authorization framework centered on real‑time validation. Technology executives are now navigating the shift from document‑centric reviews to controls embedded directly in engineering workflows. This continuous compliance imperative is redefining what proof of security actually requires.

Sandeep Shilawat is Partner, Hybrid Cloud CTO Lead & AI/Automation Leader at IBM, where he leads the AI and Automation Practice for U.S. Federal clients. With over 25 years of experience driving large-scale digital transformations, he has built and delivered secure hybrid cloud solutions at FedRAMP High and DoD IL5 levels, including $200M+ in federal deals at IBM. A Forbes contributor on federal technology strategy, he believes compliance will never keep pace with modern threats until it is treated as an engineering discipline, rather than a documentation exercise.

"Compliance can't be a point-in-time exercise in a world where the threat landscape changes every day. It has to operate in real time in the age of AI," said Shilawat. The problem, he believes, runs deeper than process: compliance has long been treated as an obligation to fulfill rather than a system designed to protect. The fix, in his view, is treating governance as a native part of the engineering workflow so proof generates automatically rather than after the fact.

That shift starts with understanding how the current model broke down. FedRAMP was established nearly two decades ago to create a common security baseline for cloud service providers using NIST standards. Since then, software delivery practices have matured, while many compliance processes remain document‑heavy and periodic. That disconnect reinforces a view of compliance as a separate chore rather than a core component of how systems operate.

• Unpacking the baggage: Shilawat traced the problem to assumptions baked into the GRC industry from the start. "Every time we think compliance is some sort of baggage that we are carrying, we need to fill out the paperwork and finish it without keeping the purpose in mind. And then we design the compliance in the entire GRC industry based on some manual processes," he said.

• The paper-pushing paradox: That default has had measurable consequences. "Compliance should have all been programmatic, and humans should never have been loaded with this workload. This has become pretty much a job creation exchange. Very little or no return because violations have been occurring," he added. What Shilawat calls the compliance tax, engineering time and budget consumed by documentation that does not improve security outcomes, is the direct cost of treating governance as a back-loaded exercise. Slow‑moving federal processes can stall agile startups, leaving many SaaS applications waiting in accreditation queues and delaying faster access to secure services. Shilawat pointed to Wall Street as a comparison point where firms absorbed heavy regulation while continuing to innovate.

As attackers automate and AI accelerates the threat cycle, compliance frameworks still built around human review cycles and annual assessments struggle to keep pace. The rise of a new class of insider threats makes manual defense look fragile by comparison.

• Bots don't do paperwork: "Numerous attacks are being done using automated systems. Those systems are driven by AI. Are those systems compliant?" asked Shilawat. "I sure hope they are compliant first. Do we know that for a fact? No. Are they changing fast enough? Yes. Is the compliance happening at the same speed they're changing? Absolutely not." The question is no longer whether automated threats outpace manual defenses: compliance has already fallen behind.

Rather than writing narrative PDFs and spreadsheets after the fact, teams are experimenting with approaches where System Security Plans (SSPs), Security Assessment Reports (SARs), and POA&Ms generate automatically from the same pipelines that build, test, and deploy code. Shilawat drew an analogy from his early career as a Java developer: just as Javadocs made documentation a natural byproduct of writing code, compliance evidence can be a byproduct of building systems.

• From cables to code: "Earlier infrastructure used to be all manual processes: pulling cables, fixing gears. Then it became infrastructure as code, IaC. Compliance as code should also be as common as infrastructure as code. And when you do compliance as code, all the relevant artifacts that are needed by compliance, regardless of policies and standards, would be generated," he noted. The blueprint relies on a foundational machine‑readable language to automate evidence collection natively. As teams harden images, apply STIGs, and configure logging, the same actions can generate machine‑readable evidence in formats such as OSCAL. He added that in the federal space today, only a small subset of niche vendors can consistently produce OSCAL‑native artifacts. That scarcity has a direct infrastructure implication: the CIOs who build on OSCAL-native foundations today are the ones who will be able to deploy AI agents for compliance enforcement tomorrow. Those who don't are foreclosing that option now.

As agencies move from basic cloud hosting toward what Shilawat called the "neo cloud" era, blending hybrid, multi‑cloud, and AI‑driven infrastructures, the case for automated compliance built on public sector security mindsets grows stronger. By shifting compliance left, teams can turn what has been a back‑loaded documentation exercise into a front‑loaded engineering standard.

• Coding the culture: Recent FedRAMP workforce adjustments and modernization efforts are accelerating this shift. As the program office moves toward standard-setting and away from individual package review, agencies and vendors can no longer rely on a centralized body to carry the compliance load. They have to build it in themselves. "If you make compliance as code, you are incentivizing engineers to embed it in the code itself so the back-loaded compliance will become front-loaded," said Shilawat. "It will not be seen as some sort of headache that everybody will have to deal with at the end of the project. It will be something you'll be doing for a living." For CIOs, that means compliance strategy belongs in the same conversation as infrastructure architecture, not delegated to a governance team after engineering decisions are already made.

• Jurassic GRC: Operational realities are also reshaping the vendor ecosystem. Providers still anchored to manual documentation are finding their offerings misaligned with what agencies now require. The nimble firms that moved early on OSCAL-driven compliance‑as‑code have become acquisition targets, snapped up by larger players who couldn't build the capability fast enough. That consolidation is driving M&A as the market reorganizes around automation. "We have some dinosaurs in the GRC industry. It's like a phoenix. They rise out of the ashes again and again and try to rejuvenate themselves," said Shilawat. "So the big companies now are kind of trying to buy their way into this particular ecosystem." For CIOs evaluating compliance vendors today, the question is no longer whether a provider is FedRAMP-authorized, it is whether they can produce machine-readable evidence natively, without manual intervention.

Instead of treating compliance as a late‑stage review, some forward-leaning agencies are experimenting with ways to embed policies directly into infrastructure‑as‑code templates, CI/CD pipelines, and AIOps platforms. For Shilawat, the end state is self-healing, fully automated machine-readable compliance: systems that monitor not just for uptime but for drift, generating evidence continuously without human intervention. He expects AI agents to play a growing role in this environment, not only in monitoring performance but also in enforcing policy and generating evidence. He described the federal vendor market as moving toward "FedRAMP Darwinism," where vendors that do not adapt to continuous, automated compliance may find themselves at a disadvantage. The same pressure applies to agencies. Those that continue to treat compliance as a periodic documentation exercise will find themselves structurally unable to keep pace as FedRAMP enforcement tightens and automated threats accelerate.

"The outcome for those companies will be extinction because the market is moving at the speed it is, and it's not going to stop for anybody," said Shilawat. "So the government will catch up on innovation and the regulatory bodies will try to enforce. So that forcing function will lead to automated compliance, and those who don't adopt will perish."

The views and opinions expressed are those of Sandeep Shilawat and do not represent the official policy or position of any organization.