This article is divided into two parts.
You can read the first part here; it covers what OSCAL is, what its seven models do, and what FedRAMP actually requires and when. It also covers where FedRAMP 20x goes its own way, and if you should care about OSCAL even if you don’t need to file FedRamp.
This part covers Gist’s approach to machine-readable compliance.
The Part OSCAL Cannot Standardize
Converting a System Security Plan into valid OSCAL is in many ways a solved problem. Several vendors will do it for you, the schemas are public, and a competent engineer with the NIST reference can produce a file that validates in an afternoon.
But validation is a low bar. A schema checks that your data has the right shape but doesn’t help to determine if the data is true, current, or connected to anything that actually happened. A paragraph saying the organization “maintains appropriate access controls and reviews them periodically” survives an audit because a human reads it charitably and moves on. The same claim as a field wants specifics: which control, implemented by which component, assessed on which date, evidenced by what.
Empty fields show up as empty. So does a control with no evidence attached, an exception with no expiry date, and an assessment result nobody refreshed after the system changed.
So the organizations that struggle with OSCAL will not struggle with syntax. They will struggle because the facts the schema asks for were never captured in the first place. One CISO Gist met with at an insurance company put the current state this way, “We spend a lot of time going back and forth with developers on what they showed us it is versus what it actually is.”
Which raises the question of where those facts should come from.
Where the Evidence Has to Come From
Open the compliance dashboard on a Monday morning and every control reads green. Encryption configured, logging on, access reviews current, vendor list reviewed. The platform checked all of it overnight and found nothing wrong.
Then an auditor asks whether the feature that shipped last Tuesday, the one that added a new customer data field, got a privacy assessment before it went live. The dashboard has no answer, because the question was never one it could ask.
Continuous compliance platforms watch infrastructure. They confirm that controls exist and hold their settings between checks, which is real work and worth doing. What none of them read is a Jira ticket, a design document, or a pull request, so the change that introduces the risk moves through a layer they cannot see.
OSCAL’s later models want facts from exactly that layer. Assessment Results wants to know what somebody tested and when. A POA&M wants open items with owners and due dates. An SSP wants a control implementation that matches the system as it stands today, rather than as somebody described it eighteen months ago.
Reconstructing all of it at audit time is the process most GRC teams run now, and it is the process a machine-readable format makes visibly hard. Capturing it as the change happens is the alternative, and it means governance has to live in the tickets and pull requests where the work already goes on.
This is the gap Gist set out to close.
How Gist Feeds a Machine-Readable Compliance Layer
A team adds an analytics vendor. A design doc describes the event schema, a Jira epic tracks the work, a few pull requests implement it, and somebody issues an API key. Compliance sees a questionnaire during onboarding and hears nothing after that.
Six months later a developer adds an email field to the payload. The vendor now holds customer contact data nobody assessed, the DPA covers a narrower scope than the integration, and the compliance record still describes the original design.
Gist treats the integration as one initiative. The design doc, the tickets, the pull requests, and the deployment link into a single Initiative Risk Record, which carries a current state rather than a signing-day snapshot.
The assessment runs against that record. Gist identifies what customer data crosses the boundary, flags the gap between the DPA and the actual scope, and proposes the controls the integration needs: scoped keys, egress limits, logging, and retention terms. If the DPA is still pending, Gist records a time-bound exception with compensating controls and an expiry date, rather than a note somebody meant to revisit.
Then the email field arrives, and the initiative reopens for review the moment the data scope changes, without waiting on a quarterly cycle.
What the Gist Evidence Ledger holds at the end maps directly to the fields a machine-readable package asks for: what somebody assessed, when, which controls the decision required, who approved it, and what proves those controls held.
Machine-readable compliance is great for the industry. We welcome OSCAL and FedRamp 20x and we will continue to post about how we are helping companies with both.
Governance That Moves at the Speed of Your Changes
OSCAL belongs to a larger movement. Policies and controls that used to live as documents for humans to read and interpret are becoming rules that systems evaluate directly, an idea the field calls Rules as Code. OSCAL applies it to security controls.
The movement matters because change itself has changed. Software once moved at human speed, in releases a review board could plausibly keep up with. Changes now arrive continuously, machines increasingly make them, and risk assessment stays where it has always been: in the same meetings, the same review queues, and the same spreadsheets it occupied a decade ago.
Machine-readable rules meeting hand-assembled evidence is the collision worth planning for. FedRAMP handed the federal market until late 2027. Everyone else has whatever runway their next audit allows.
The work that pays off in that window has little to do with file formats. It has everything to do with your record: what somebody assessed, what the decision required, who approved it, and what proves it held. Either that record comes as a byproduct of real work, or somebody unfortunately has to build it from memory the week before the auditor arrives.
FAQ
Machine-readable compliance is the practice of converting legal rules and regulations into structured, computer-parsable data formats so software can process and monitor adherence automatically. Instead of reading static PDF documents or websites, systems use structured formats like JSON, XML, or semantic web technologies to interpret laws and run instant checks.
A schema validates structure rather than truth. It confirms that your data has the right shape, without checking whether the data is current, accurate, or connected to anything that happened. Organizations that struggle with OSCAL rarely struggle with syntax. They struggle because nobody captured the facts the schema asks for.
Specifics that prose can leave out: which control, implemented by which component, assessed on which date, evidenced by what, and with which exceptions still open. Assessment Results wants to know what somebody tested and when. A POA&M wants open items with named owners and due dates.
Only part of it. Continuous compliance platforms confirm that infrastructure controls exist and hold their settings between checks, which is real and useful work. None of them read a Jira ticket, a design document, or a pull request, so the change that introduces the risk moves through a layer they cannot see.
Governance that runs when a change happens rather than on a quarterly cycle. Gist correlates the design doc, tickets, pull requests, and deployment into one Initiative Risk Record, assesses that record, and captures the decision and its evidence as the work happens rather than reconstructing everything during audit week.
Give every exception an expiry date, a compensating control, and an owner, then re-evaluate when the underlying system changes. Gist records exceptions that way and reopens review when a later change removes a required control or widens the data scope beyond what somebody originally approved.
