Actions that get done
A lightweight, auditable way to track the work — raised from risks, controls, events, or an audit finding, consolidated in one place, and closed with a comment that stays on the record.
Start free trialThe work, tracked where it belongs
Actions support first-line management activity: they make work easy to track, consolidate effort arising from several drivers, and give a clear, auditable view of progress and closure. They are never mandatory — a management tool used at your discretion, not a workflow imposed on you. An action can arise from a risk review, a control gap, an event, or an audit and assurance finding — internal audit, external audit, client due diligence, a regulatory review.
A clear path from draft to closed
Actions move through four explicit states — Draft for early capture and refinement, In Progress for active work, Close-Pending for proposed closure awaiting finalisation, and Closed for completed work. The state of every action is unambiguous at a glance.
Once closed, an action stays closed — it can't be quietly reopened. If more work is needed, you raise a new action and reference the closed one as an input. The history stays honest, and nothing is rewritten after the fact.
One action, every driver behind it
An action can link to one or more risks, controls, and events at once, so a single piece of work can consolidate everything driving it — rather than spawning near-duplicate tasks across three different places. Linking is informational: it gives context and traceability without imposing dependency or enforcement.
Whatever triggered an action, the line back to it is always visible. Nothing gets orphaned, and nobody has to reconstruct why a piece of work exists.
Run it like a ticket, keep it auditable
A chronological update history
Actions are updated in the style of a lightweight ticketing system, with a chronological history of updates and comments. Every update, every ownership change, every status change is auditable. Evidence can be attached to an action and follows the same evidence rules as controls — tagged, retained, never silently deleted.
Due dates that flag themselves
Due dates are optional, and changes to them are auditable. When a due date passes and the action isn't closed, it is flagged overdue — on the action detail, in lists and summary views, and in reports. Overdue status is a signal, not a straitjacket: it never blocks work or forces a lifecycle change.
One owner, and closure that means something
Every action has exactly one owner, assigned to a role using the same single-member role pattern as risks, registers, and controls. Ownership is mandatory at creation, can change over time, and every change is recorded.
Closing an action requires a closure comment — you say why it's done, and that note stays on the record alongside the closure date and the person who closed it. Where your framework calls for it, closure can require a second party to agree first: the action holds in Close-Pending until that agreement is recorded. Second-party closure agreement is configurable at framework level, subject to tier eligibility.
Where actions come from
Risks
Raise an action from a risk to manage it down. Actions don't constrain the risk lifecycle — they sit alongside it as the work being done.
RisksControls
Turn a weak or overdue control assessment into an action with an owner and a due date, linked straight back to the control.
ControlsEvents
Respond to an incident or near-miss by raising actions from the event, so what happened drives what gets done next.
Events