Compliance · Controls · Draft

A compliance record is a state machine

A risk, a vendor, a control or an exception is not a document. It is a small thing that is always in exactly one state and can move only along allowed paths. If you build it that way in a tool people already use, the audit trail stops being a reconstruction.

Ask a team where its risk register lives and you will often hear "in a spreadsheet, and someone updates it before the audit". The spreadsheet is not the problem. The problem is that nothing stops a row from saying "accepted" without anyone having accepted anything.

There is an older idea that fixes this: the state machine. A thing has a fixed set of states and a fixed set of moves between them. It is in one state at a time. A move can have conditions.

Compliance obligations already behave like that. A risk is identified, assessed, treated, accepted or closed. A vendor is requested, reviewed, approved, monitored and left. A control is planned, implemented, operating and reviewed. An exception is requested, approved until a date, and expired. We just rarely write the rules down as rules.

What you gain when you do

• Reporting becomes counting. Every record is in one state, so "how many risks are untreated" is a query, not a meeting.
• A move can carry a condition: only the owner may accept a risk. It can carry a requirement: a justification must exist before a control is marked not applicable.
• Every move is stored with who and when. That is the audit trail, produced as a by-product instead of rebuilt under pressure.

Where it can live

Most teams already work in an issue tracker whose workflows are exactly this: states, transitions, conditions. Records go in one project, the explanation and live views in a wiki. A risk treatment becomes a task in the team's own backlog, linked back to the risk, so compliance work sits in the same queue as other work. A document such as a Statement of Applicability then becomes a view of the records, which is why it stays true.

Three habits that keep it honest

1. The workflow is a control, so changing it is a controlled act: few people may edit it, and everyone can see the history.
2. Temporary decisions expire. An exception with an end date that reopens by itself cannot quietly become permanent.
3. Start small. A few workflows that people use beat many that nobody opens, and each should replace a spreadsheet rather than sit beside it.

What it does not do

A tracker does not collect machine evidence from your systems; a platform for that can sit alongside. And a state machine makes bypassing visible and harder, not impossible: the permissions around it are still part of the control.

This is the same thought as "hard controls first": do not ask people to remember the rule, build the place where the rule is enforced.