Compliance audit trail state machine
Track changes, approvals, and compliance checkpoints as states.
Compliance is about proving what changed and who approved it. When a regulator asks "did anyone delete user data without approval?", you need an audit trail that shows every change, every approval, and every retention period. This template models how an action or change flows through approval and logging states so nothing disappears without a record.
The state machine makes clear that compliance is not a one-time event: a change can be rejected and returned to drafting, or cancelled entirely. Each path has audit implications. The Archived state shows where old records live after retention periods expire, so you can demonstrate that you retained data as required.
When to use this template
- Building audit systems — before you code compliance logging, sketch state transitions. This forces you to name all possible outcomes and think about edge cases: what happens if a change is rejected? Where does it go?
- Designing data retention policies — the diagram makes visible when records transition to archives and when they expire. Regulators see at a glance that you comply with retention windows.
- Incident post-mortems — when a compliance incident happens, trace it through this state machine. Did the Approved state get skipped? Did something move to Archived without review? The diagram helps your team see where controls broke.
How to adapt it
Start by mapping your actual compliance workflow:
- Add escalation states — if a change is Rejected, can it be Escalated to a higher authority? Add an Escalated state that transitions to Approved or Further Rejected.
- Extend logging — split Logged into separate states for different record types: AuditLogged, DatabaseLogged, TelemetryLogged.
- Add retention rules — use state labels to show time windows:
Logged [timeout 90 days] → Archivedtells teams how long records live.
Visual edits regenerate clean code, so you can add states and adjust retention windows without writing state-machine syntax.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
stateDiagram-v2
[*] --> Draft
Draft --> Submitted: User submits change
Draft --> Cancelled: User cancels
Submitted --> Approved: Compliance review passes
Submitted --> Rejected: Compliance review fails
Rejected --> Draft: Return to drafting
Rejected --> Cancelled: Abandon change
Approved --> Logged: Record audit entry
Logged --> Archived: 90-day retention met
Cancelled --> Archived: Archive cancelled change
Archived --> [*]
Frequently asked questions
- What is a compliance audit trail state machine?
- It models how a change or action moves through compliance states: from Draft through Submitted for approval, either Approved or Rejected, then Logged in the audit trail, and finally Archived after retention periods are met. Each state transition leaves a record, so regulators can see what changed, who approved it, and when.
- Why use a state diagram instead of a flowchart for audit trails?
- State diagrams explicitly show that an audit trail is a sequence of discrete states, not just a linear flow. A change can return to Draft if rejected, or move to Cancelled. State machines also make timeouts and retention rules visible: a change stays in Approved state until the audit entry is Logged, then expires after 90 days in Archived. Flowcharts obscure this structure.
- What information should I log at each state transition?
- Log who made the change, what changed, the timestamp, and why (Draft reason, rejection reason, approval notes). The state transition itself is the audit event: transitioning from Submitted to Approved means compliance review happened and succeeded. Use a table in your system to record: old_state, new_state, timestamp, actor, reason.
- How do I adapt this for my compliance system?
- Rename states to match your workflow: Request → Approved → Scheduled → Executed → Verified. Add states for escalations (Escalated) or holds (On Hold). The visual editor lets you drag states and draw transitions — no syntax required. Each transition is an audit event your system records automatically.