A task is a unit of work with an owner, a due date and a status. Adopt a framework and its tasks seed themselves, linked to the controls they serve; add your own alongside. Filter the list by framework, status or owner, and nothing falls through the cracks between adoption and the audit.
Adopting a framework writes the worklist, roles and people own the items, and statuses carry each one from to-do to done.
Each framework ships task templates for the work it actually requires. When you adopt it, those clone into your worklist linked to the relevant controls — so instead of staring at 93 controls, you start with a concrete list of things to do.
Assign to a business role so ownership survives people changes, or to a person for one-off work. Set priority and deadline, and overdue work flags itself in red on the list and the dashboard.
A task can link one record — a control, risk, policy, evidence item, asset, vendor or audit. Open the task and jump straight to the thing the work is on, or add a task from the record’s own Tasks tab and the link fills itself in.
To do, in progress, in review, done, cancelled — the worklist reads at a glance, per framework and per owner. The same tasks feed the Roadmap, where their deadlines are laid out on a timeline toward your audit-ready date.
Four choices behind how tasks work here — each one something you can check, not an adjective.
Adopt a framework and its task templates clone into your worklist, each linked to the control it serves — the “what do we actually have to do?” list writes itself on day one.
Assign a task to a business role and ownership survives every personnel change; assign to a person when it’s genuinely one-off. Either way, everyone’s own tasks show on their profile.
A task can link one record (a control, risk, policy, evidence item, asset, vendor or audit), so you jump from the work item straight to the thing the work is on.
ISO 27001, SOC 2 and GDPR work sit in the same filterable worklist with stable TSK IDs, so each owner sees their open work without hopping between framework silos.
Hosted in Switzerland by default, in German and English, with on-premise possible. Your data and evidence are yours and exportable in full at any time, with no lock-in.
Tasks are the human work of the program — seeded by the frameworks you adopt, planned on the roadmap, due alongside everything else on the calendar.
Your open tasks on a timeline, planned toward a target.
Adopting a framework seeds its tasks, linked to controls.
Automated runs on a schedule — tasks are the human work.
Reviews and renewals, alongside your task due dates.
Both. Adopting a framework seeds tasks automatically from that framework’s templates, each linked to the relevant control. And you can create tasks manually at any time — from the worklist, or directly from the record the work is about.
A task is a unit of human work with an owner, a due date and a status. An action is an automated run devguard executes on a schedule or a trigger. A treatment action is a remediation tied to specific risks. Three different things, kept apart on purpose so none of them turns into a junk drawer.
A business role or an individual member. Role ownership keeps tasks stable as people change positions; personal assignment fits one-off work. A person’s tasks, direct or via their roles, are listed on their profile, so “what’s on my plate?” has one answer.
A generic list doesn’t know what a control is. A devguard task is linked to the control, risk or policy it serves, carries framework context, shows up on the Roadmap timeline, and was seeded from the framework you adopted — so the list is the compliance program, not a copy of it.
Swiss-hosted by default, in German and English, with on-premise possible. Your worklist is yours and exportable in full at any time, with no lock-in.
Adopt a framework and start from a seeded worklist instead of a blank page — every task owned, dated and linked to the control it serves.