The pain of technical compliance isn't the rules. It's the evidence.
The hard part of technical compliance isn't the controls. It's proving you stayed compliant between scans, with evidence captured at the change.
Ask a compliance engineer what the worst part of the job is and almost nobody says "the controls." The controls are knowable. STIG, CIS, NIST 800-53: long, tedious, but finite. You can read them. You can argue about them. You can, eventually, satisfy them.
The pain is somewhere else. The pain is the morning you get asked: were these two hundred hosts compliant on January 15th? And you realize the honest answer is "they were compliant the last time we scanned, which was the 9th, and I have a PDF that says so, and I genuinely do not know what happened between then and now."
That gap, between what you can assert and what you can prove, is the actual job. And most of the tooling in this space makes the gap worse, not better, because it was built to produce a passing report, not a continuous record of the truth.
Point-in-time is a story about the past
A scan is a photograph. It tells you the state of a system at the instant the shutter opened. It says nothing about the moment after.
This is fine if nothing changes. Nothing never changes. A package gets patched. Someone edits a config at 2 a.m. during an incident and forgets to mention it. An automation flips a setting back to a default. Drift isn't an edge case; it's the normal condition of a running system. The compliant photograph and the non-compliant reality can coexist comfortably, and the only thing standing between them is the date on the report.
So the first source of pain is structural: point-in-time compliance answers a question nobody actually has. Auditors don't care whether you were compliant on the 9th. They care whether you were compliant the whole time, and specifically on the day something went wrong. Your scan can't tell them that. It was looking the other way.
Screenshots aren't evidence. They're a description of evidence.
The second source of pain is what we accept as proof.
Walk into most compliance programs and the evidence is a folder of screenshots, exports, and spreadsheets, assembled by a human, after the fact, under deadline. A screenshot of a terminal showing the right setting. A CSV exported from a scanner. A ticket that says the remediation was done.
None of this is verifiable. A screenshot proves someone saw something on a screen once. It does not prove the system was in that state, that it stayed in that state, or that the person assembling the folder didn't quietly fix three things the morning of the audit. The evidence is a narrative about the system, written by the party with the most incentive to pass. We'd never accept that standard for a financial audit. We accept it for technical compliance because, until recently, it was the best anyone could do.
The work of reconstructing that narrative — chasing down who changed what, exporting the same data four different ways for four different frameworks, reconciling numbers that don't match between the scanner and the spreadsheet — is most of the misery. It is also entirely downstream of one decision: capturing evidence after the change instead of at the change.
The fix is boring, which is why it works
Here is the whole argument in one sentence: compliance stops being painful when evidence is a byproduct of change instead of a project you run later.
If every change to a system captured its own before-state, its own after-state, what was applied, whether it validated, and who or what initiated it, and signed that record at the moment it happened, then "prove you were compliant on January 15th" stops being an archaeology dig. It becomes a query. The evidence already exists, because it was created by the act of changing the system, not reconstructed by a human reading logs three weeks later.
This is not a clever idea. It's double-entry bookkeeping, five centuries late to infrastructure. When Pacioli codified it in 1494, accounting stopped trusting narratives about money and started requiring that every transaction leave a matched, permanent record. Technical compliance is finally arriving at the same conclusion about changes to production: the transaction is the unit of truth, and the evidence should be inseparable from it.
"Continuous compliance" gets sold as a dashboard that refreshes more often. That's not it. Continuous means the system is always emitting the record. Every change, captured and signed as it happens. So posture is something you can ask about at any timestamp, not something you assemble in the week before an assessment. The dashboard is a consequence. The record is the point.
What this asks of a tool
A tool that takes this seriously has to do a few unglamorous things well. It has to watch continuously, not on demand, so the gap between scans stops being a blind spot. It has to notice when today differs from yesterday and say so, rather than waiting to be asked. And it has to treat every change as a transaction with a complete, exportable, machine-verifiable record: the kind of evidence you could hand to an auditor without first spending a weekend assembling it, and the kind a machine can check without trusting the person who produced it.
That last part matters more every year. The systems making changes to production are increasingly not people. An agent that applies a change at machine speed, with no record of intent and no captured pre-state, doesn't make compliance harder. It makes it impossible. The only way that future is survivable is if the evidence is generated by the change itself, automatically, every time, human or not.
On the milestone
We shipped the general availability release of OpenWatch today. It's the continuous eye and control plane built on exactly this premise: that every change should carry its own evidence, and that compliance should be a property of the system, not a performance staged before an audit.
We're not going to oversell what GA means. It means we're comfortable enough that this is solid ground to build on, not that the problem is solved. The pain described above is large and old, and a single release doesn't retire it. What a release does is mark the point where the work stops being a prototype and becomes something other people can stand on.
So this is a beginning, stated plainly. The interesting work, making technical compliance something you can prove continuously instead of narrate after the fact, starts now, in public, where you can read the code and check our claims. Which is, after all, the whole point of evidence.