The compliance function is undergoing the same transformation that operations went through fifteen years ago. Just as DevOps and SRE forced infrastructure work to move from ticket queues into code, compliance is moving from binders into pipelines. The difference is that the operations community had nearly a decade to build the playbooks. The compliance community has months.
If you lead a GRC organization at any scale, the timeline already landed on your desk. FedRAMP 20x targets full transition by 2027. OSCAL becomes mandatory under RFC-0024 for every FedRAMP submission, with the initial deadline arriving September 2026 and the final cutover in 2027. This overhaul fundamentally changes how organizations operate and demonstrate compliance. Screenshots, pdf exports, spreadsheets will be replaced by machine readable artifacts that are automatically generated as a byproduct of services operating.
Yet most GRC leaders I speak to, including those who manage 7+ figure compliance budgets, still see compliance as a document factory. They translate framework requirements into spreadsheets. They prepare for audits. They cannot, in any meaningful sense, prove their security posture continuously, and they cannot scale without adding heads in proportion to scope.
The reference model below is drawn from my experience building and scaling Compliance programs at Microsoft, Tableau, DocuSign, UiPath, and Autodesk. These views and opinions are my own and do not reflect the views or beliefs of my former or current employers.
What "Compliance as Code" Actually Means
The phrase gets thrown around to describe four very different things, and the conflation is part of why most implementations fail.
At the surface, compliance as code means writing your control specifications in machine-readable formats: OSCAL for FedRAMP, OpenSCAP for hardening baselines, custom YAML for internal frameworks. This is necessary but it is also the least interesting layer. All you've done is convert documentation from one format to another.
One layer deeper, compliance as code means policy as code: expressing controls as executable rules. OPA with Rego policies enforcing access controls. HashiCorp Sentinel gating Terraform deployments. Cedar evaluating runtime authorization. This is where shift.left compliance lives. A developer attempts to deploy an unencrypted S3 bucket; the pipeline fails the commit before the bucket exists.
One layer deeper still, compliance as code means continuous evidence: the platform itself emits proof of its own compliance posture, structured for both human dashboards and machine consumption. Your monitoring stack does not just feed the SOC; it produces audit-ready telemetry mapped directly to control families.
The deepest interpretation, and the one most organizations skip, is operational: compliance as code is a change in who owns what. Evidence is no longer produced by a compliance team interviewing engineers. Evidence is produced by infrastructure, and the compliance team's job shifts from production to specification, validation and judgement.
The first two layers give you automated documentation. Build all four and you have transformed the function.
Why the Industry Isn't Ready
Put bluntly: the gap between the regulatory direction and the operational maturity of most GRC organizations is wider than the public narrative admits. You'll see a lot of LinkedIn posts from compliance leaders praising automation and AI as an efficiency multiplier but in many cases, they're just automating documentation and file organization.
Three failure modes show up repeatedly in my peer conversations:
First is the talent shape. The average GRC org is 99 percent analysts whose primary skill is reading frameworks and assembling evidence. Compliance as code requires people who write policy code, build OSCAL pipelines, integrate with CI/CD, and treat compliance as a service.
Second is the tooling stack. Most legacy GRC platforms were designed before OSCAL existed and before policy as code matured. They are workflow tools wrapped around document storage. They do not natively consume infrastructure telemetry, they do not produce machine-readable assessment results, and they cannot be integrated into a CI/CD pipeline as a first-class citizen.
Third is the organizational physics. I've personally led compliance teams under Legal, Program Management, Product Management, and Security. For a long time organizations didn't know where to put it and some still don't. Compliance as Code requires the team to operate as a platform service. This requires engineering alignment. This creates political friction.
The Reference Model
This is the compliance architecture I've built throughout recent years. It's tested against real constraints, not theory, but it's also grounded in what I've done and observed, not in exhaustive coverage of every region or vertical. I'm presenting it because most frameworks I've seen either obscure the hard problems or ignore them entirely. Adapt accordingly.
The Three Layer Compliance Stack
Layer 1: Your control library, expressed in OSCAL. NIST 800-53 catalogs and FedRAMP profiles already exist in OSCAL. ISO 27001 mappings are emerging. Your internal additions live in the same format, version-controlled in Git, reviewed via pull request, and merged with the same rigor as production code. Documentation generation is a build artifact, not a deliverable.
Layer 2: The evidence pipeline. Every control specified in Layer 1 has at least one defined data source, and the data flows continuously rather than being collected on a quarterly cadence. CloudTrail and Config produce configuration evidence. Okta and IAM produce identity evidence. Scanners produce vulnerability evidence. Pipelines produce change-management evidence. The data normalizes through the OCSF schema where possible, which gives you a single language across sources.
Layer 3: Enforcement and validation. Policy engines evaluate the evidence against the Layer 1 specifications in real time. CI/CD gates block deployments that would violate controls. Auto-remediation closes drift where the action is safe and reversible. The outputs of all three feed back into Layer 1 as OSCAL assessment results, which is what the 3PAO ultimately validates.
The interesting property of this architecture is that the loop closes. Specifications generate enforcement, enforcement produces evidence, evidence validates specifications. This is the C2P (compliance-to-policy) pattern, and it is what FedRAMP 20x is implicitly endorsing through KSI-based monitoring.
The Closed Loop
The 3PAO's role changes materially. Under the legacy model, they review documents and screenshots produced by humans. In this model, they validate the integrity of the automated pipeline that produces the evidence. That shift was foreshadowed in the Confluent pilot proposal that the FedRAMP PMO publicly praised in Phase 2 of the 20x program for "doubling down on engineering over compliance." The signal is there.
The Operating Model: Federated CoE
The biggest organizational mistake I've watched leaders make is collapsing compliance into SRE. The instinct is understandable; SRE already runs the platform, already understands continuous validation, and opposes bolt-on processes. The structural problem is that SRE's incentives, knowledge domains, and stakeholder surfaces are not aligned with compliance outcomes. SRE optimizes for reliability. Compliance optimizes for control coverage. Those are correlated but not the same, and the divergence is exactly where regulatory exposure lives.
The model that works at scale is federated:
The Compliance Engineering CoE owns the platform and standards. Compliance engineers translate framework requirements into engineering specifications. Embedded compliance engineers sit inside product and infrastructure domains; they own local control implementation and evidence generation, but they consume platform services rather than building parallel ones.
In a traditional GRC org of 100 people roughly 90% are analysts doing toil and 10% are people doing risk-informed work. The target in this model is closer to 30 people total: 5 compliance architects, 25 compliance engineers, and a thin but strong leadership layer. The headcount reduction is not an HR exercise. It is an architecture exercise. You reduce headcount by moving work from humans to platforms, and the people who remain are engineers and senior framework specialists who can handle risk informed judgement.
The SRE Translation
The conceptual framework that ties this together comes from SRE, which solved the same class of problem in a different domain ten years ago.
| SRE concept | Compliance translation |
|---|---|
| SLI / Service Level Indicator | CLI / Compliance Level Indicator. MFA coverage rate, key rotation lag, drift detection latency, evidence freshness |
| SLO / Service Level Objective | CLO / Compliance Level Objective. The target threshold for each CLI, measured continuously |
| Error budget | Compliance risk budget. Quantified, time-boxed tolerance for control gaps before changes freeze |
| Toil | Manual evidence collection, repetitive audit prep, screenshot harvesting. Target under 30 percent of team time |
| Blameless postmortem | Compliance incident review. Drift surfaced early is good engineering, not failure |
| Embedded SREs | Embedded compliance engineers in product domains |
The most useful concept here is the compliance risk budget. Traditional compliance treats every deviation as a binary "finding" that goes onto a POA&M and waits for a quarterly review. That model is incompatible with continuous deployment. The risk-budget model says: a 4-hour MFA gap on a service account is a measurable deviation with a known blast radius, not a finding. You allocate a budget for these deviations per control family, you track burn rate, and when the budget is exhausted you freeze changes the same way SRE freezes deploys when the error budget is spent.
This is also the language that makes compliance posture legible to executives and boards, who are far more comfortable with quantified risk envelopes than with binary pass/fail audits.
A Three Horizon Implementation Plan
The model is the easy part. Sequencing matters more than architecture, because most failed transformations fail fast.
Horizon 1, months 0 to 6: automate the toil. Don't start with a grand architecture. Start by mapping every manual workflow in the existing GRC organization and sorting them into three buckets: automate, eliminate, keep. The automatable bucket is almost always larger than the team expects, frequently 50 to 60 percent of evidence labor. Connect the existing GRC tools to source systems via API where available. Eliminate spreadsheets where you can. The cultural and political signal of fast wins in this phase buys you the runway for Horizons 2 and 3.
Horizon 2, months 6 to 18: policy as code. Move from automated evidence collection to automated enforcement. Express the high-volume controls (access management, encryption, vulnerability remediation, change management) as executable policies. Embed them in the CI/CD pipeline. Build the OSCAL pipeline for FedRAMP submissions. This is the phase where the function starts looking like an engineering team rather than a compliance team. It is also the phase where talent issues come to a head, and the leader's job is to make the compliance-architect / compliance-engineer split structurally explicit.
Horizon 3, months 18 to 36: compliance as platform capability. Compliance is no longer a team function; it is a property of the platform. Hyperscale environments emit evidence continuously. The 3PAO validates the pipeline, not the output. Audit prep is "run the pipeline" rather than a multi-week assembly project. Findings live in the same tracking system as production bugs, prioritized by the same SLAs. The function distills into its true core: senior people who own the policy layer, manage risk, establish governance and own regulator relationships.
What "Done" Looks Like
A few markers tell you whether the transformation has actually landed.
Evidence packages generate themselves on demand. Continuous authorization is in place for the frameworks that allow it (FedRAMP 20x, ISO 27001 surveillance, SOC 2 Type 2). Compliance posture is visible on the same dashboards engineering and SRE already use, and it is queryable via API. The 3PAO relationship has shifted from document review to pipeline validation. The compliance team is smaller, technical, and respected by the engineering organizations it serves. The board sees compliance posture as a continuous risk function, not a quarterly status update.
Most importantly, compliance no longer scales linearly with growth. A new product, a new region, or a new framework adds policy work, not headcount.
The Honest Caveats
I want to flag the things this model does not solve, because the AI-generated thought-leadership versions of this argument always skip them.
OSCAL tooling exists, but production-grade implementation at hyperscale is not plug-and-play. The community is still maturing. Expect to invest in tooling that does not yet have a Gartner Magic Quadrant.
Policy as Code authoring is a real engineering discipline. Upskilling current staff takes time.
Continuous monitoring infrastructure is a cost center until it pays off, which is usually month 18 to 24. Be clear about the burn-to-payoff rate ahead of time. If you don't know what it is, then be honest. Board members will demand impact quickly if expectations are not set from the jump.
Auditor and 3PAO maturity is uneven. Some understand the new model; many do not. Part of your job is co-developing the validation methodology with the assessor community, and that is slower than any of us would like.
Aside from FR20x, there isn't a big push in this direction. Expect resistance until the mandate becomes clear and the investment feels justified. It's your job to prepare the business for what's inevitably coming. Build the boat *before* the flood.
Closing
The frame that crystallizes this for me is this: compliance is becoming an engineering problem, and the GRC leaders who do not internalize that within the next 18 months will become liabilities to their own organizations. Boards will not wait. Regulators will not wait. The deadlines are already on the calendar.
The model in this post is obviously not the only path. This is intended to provide a starting point on a topic that feels in flux and hard to grok for many leaders in the GRC space. If you are running a GRC function and you are not already on this trajectory, the right time to start was 18 months ago. The second-best time is this quarter.
If you want to push back on any of it, I'd welcome it. This is hot topic right now and there are lot of opinions. Mine is one of them 😎
Reference models improve through stress, not blind agreement.