Fidé: keeping compliance live instead of quarterly

The policies nobody certifies

When a customer asks whether you're compliant, they're usually asking about a standard. SOC 2 for your controls, ISO 27001 for your security program, HIPAA if you touch health data. Those come with auditors, tooling, and a certificate at the end, and they're the smallest part of the picture. The organizations I've worked with (a law firm and a fintech among them) ran on layers of policy that no certificate covers: internal standards, government regulations specific to their sector, and expectations written into customer contracts.

Two examples show the range. An engineering org decides that every repository must carry a pre-commit config with a specific set of hooks. That's a policy, and someone is supposed to verify it on every repo. A facilities team keeps a standard for what the cafeteria kitchen must stock and how it's maintained. That's a policy too, with a checklist and a person responsible. Code on one end, kitchens on the other, and in between: onboarding steps, access reviews, records retention, vendor requirements. Most of what a company has to enforce looks like this, and none of it comes with an auditor.

Why you can't buy this

The certification side is well served. There's a whole market of tools that automate evidence collection for the big standards, and they're good at that job. But they're built around frameworks that thousands of companies share. Your pre-commit rule and your kitchen standard will never appear in their catalogs, because no vendor can anticipate policy that's yours alone.

So internal policy gets enforced the way it always has been: a wiki page, a spreadsheet, an occasional reminder email, and the diligence of whoever cares most. IT operations usually ends up as the strongest enforcer in the building, because it can codify its rules directly into software through device management and access provisioning. Everything IT doesn't touch runs on the honor system. That gap, an enterprise-wide way to define your own policies and know they're being followed, is the problem Fidé explores.

Controls, checklists, targets

Fidé's design starts from the object model rather than the screens. A control is a single checkable statement: this repo has the required pre-commit hooks, this entity filed its quarterly attestation, this new hire completed security training. Controls group into checklists, which is where a policy lives. A checklist gets applied to targets: the set of repositories, the list of legal entities, this quarter's new hires. Agents keep each check current, re-verifying on a cadence and updating status without anyone asking. The operational question shifts from "when did we last check?" to "which targets are failing right now?"

The main screen flattens all of that into one list, one row per target, each row carrying its live status. In the demo data (placeholder numbers, but the right shape) the filter chips across the top read All 24, Failing 13, Attention 4, Due 6, Complete 1: the whole program in one line, with the failing targets sorted to the top. A legal entity on a quarterly financial-controls checklist sits above source repositories held to a repo baseline, which sit above new hires moving through onboarding. Three departments, one list, because from the program's point of view they're the same kind of object: a target that's either current or overdue for someone's attention.

Two hard problems sit under this design, and a real build would live or die on them. The first is false alarms: the first time an agent flags a repository as failing because a rule got renamed, people start distrusting the red. That's why Attention exists as a status separate from Failing, so "a human should glance at this" never inflates the failure count. The second is ownership: a failing target only gets fixed if a name is attached to it, which is what the prototype's team-and-roles surface is for.

From quarterly reconstruction to a continuous watch

Compare that with how the same program runs today. A deadline lands: a board review, an external audit, a regulator's request. Someone reopens last quarter's spreadsheet, emails a dozen owners for fresh evidence, and spends three days rebuilding a snapshot of a world that kept moving the entire time they were assembling it. By the time the snapshot is done, it's already slightly wrong.

The difference is easiest to see on a timeline.

Same issues, same timeline. In the quarterly model an issue waits, unseen, for the next check; under a continuous watch it surfaces when it occurs. Schematic illustration; the levels carry no data.

Between quarterly checks the state of every policy is unknown, and problems accumulate in the dark: a repo drops a required hook, an onboarding stalls, a control lapses. With agents doing the verification continuously, the same problems still occur. What changes is when you find out. Continuous monitoring doesn't make the problems smaller. It makes them early, while they're still one repo or one stalled onboarding instead of a quarter's worth of drift.

What an audit finds

The payoff shows up when someone checks your work. In an external audit, the evidence is already assembled, because assembling evidence is what the agents have been doing all along. In an internal review, "where do we stand?" has a current answer instead of a project attached to it. And over time something better happens: because issues get caught when they occur, the organization actually operates closer to its own written standards. Compliance run this way stops being a claim you publish once a year and becomes a description of how the company works. That posture is worth more in front of a regulator, or a big customer's security team, than any binder assembled the week before.

Which of your policies does no system check today?

What Fidé is, honestly: a prototype from one of our design sprints. Nobody is running their compliance program on it today; its job is to make a design argument concrete. And it's a working example of the model we describe in bespoke SaaS, because a policy platform is only worth having if it's shaped to your organization's own rules, and that's software you have built for you.

The practical place to start, whether or not you ever build anything: list the policies your organization enforces that no system checks today. The pre-commit configs. The onboarding steps that stall silently. The quarterly attestation someone tracks in a spreadsheet. The kitchen standard, if you have one. It was a long list everywhere we looked, so a long list is normal. The question worth taking to your next ops review is which three of them you'd want under watch first, and who would triage what the watch turns up. If you want to compare notes on the list, we're at [email protected].