Help center

Action plans

An action plan is a concrete task with an owner and a due date. It's what turns "we should do that" into "done, verified, dated". Without action plans, your risk register stays a dead document.

When to create an action plan?

A risk needs a control you don't have yet.
An audit reveals a gap to close.
An existing control needs improvement or re-testing.
An incident revealed a vulnerability to close.

Why a "Verified" status?

The split between Completed ("the assignee says it's done") and Verified ("a third party confirms") is intentional. It's what auditors call segregation of duties — a key NIS2 / ISO 27001 principle.

Concrete example: Marc is assigned to "Deploy MFA on all admin accounts". He deploys, marks the plan completed, attaches a screenshot. Sophie (manager) opens the plan, actually verifies it's applied, and switches it to verified. That double-check is what proves to auditors the work was done correctly.

Completion evidence

The "Completion evidence" field is what turns your plan into an auditable artifact. Be specific about what an auditor can independently verify.

Jira/GitLab ticket number ("MFA-1234")
Link to the updated procedure
Screenshot of the applied configuration
Test report (pentest, backup restore, crisis exercise)
Confirmation email from a customer or supplier

Automatic notifications

The assignee is notified on creation and re-assignment.
Notification 7 days before due date, then again on overdue.
The parent Risk/Control owner is notified when the plan is completed.
The assignee is notified when the plan is verified — positive feedback.