Why risk belongs next to the work — not in a separate register

Most organizations manage risk in two separate places: a risk register (a spreadsheet, a GRC tool, or a standalone module) and a work system (Jira, Asana, Monday, or a project management layer). The risk register captures what could go wrong. The work system captures what's being done. The two rarely talk.

That's not risk management. That's risk documentation.

The problem with the register

A risk register has a structural flaw: it assumes risk is a thing you identify and then track separately from the work. Add the risk to the register. Rate it. Assign a mitigation owner. Review it monthly.

Here's what actually happens: the risk is added to the register. The mitigation is assigned. The monthly review comes. The risk status is still "in progress." Nobody quite knows whether the mitigation is working, because the mitigation lives in the work system and the risk register has no way to see it. The person reviewing the register updates the status based on a Slack conversation they half-remember from last week.

The register becomes a static artifact. It reflects what risks were identified, not what's being done about them and whether it's working.

Where risk actually lives

Risk isn't a category of content. It's a property of work.

A work item carries risk when it's behind schedule, under-resourced, dependent on a decision that hasn't been made, or dependent on another work item that's itself at risk. A goal carries risk when the work beneath it is stalled, missing, or allocated to owners who are overcommitted.

Risk that's defined as a property of work — not as a separate object in a separate register — is live. It updates automatically when the work changes. When the engineer finishes the dependency, the risk resolves. When the work stalls, the risk escalates. Leadership doesn't need a monthly risk review; they need a risk view that reflects the current state of the work.

A risk that lives separately from the work that creates it will always be stale. That's not a process problem. That's an architecture problem.

What "risk as a live attribute" looks like

In practice, it looks like this:

Every work item has a risk attribute — not a freeform text field for "risks and issues" but a structured field that links to the goal it would affect, the owner who's accountable, and the resolution path. When the work item turns red, the associated goal's risk indicator updates automatically.

Goals surface their risk state from the work. A goal isn't at risk because someone changed the status to "at risk" in a review meeting. It's at risk because three of the five work items currently driving it have been stalled for two weeks, or because the owner is over-allocated, or because the key dependency hasn't resolved.

Leadership can drill. When an executive sees a goal at risk, she can drill from the goal to the specific work items driving it, see which ones are stalled and why, and make a decision: reassign resources, descope the goal, escalate the dependency. Not in a risk review meeting. On Thursday morning, before the problem gets worse.

The register that still makes sense

There's a legitimate use case for a risk register: organizational-level risks that aren't tied to specific work items. Regulatory exposure. Market risks. Key-person dependencies. These aren't properties of a specific work item — they're properties of the organization. They belong in a separate register.

But the vast majority of what goes into most risk registers — project risks, dependency risks, execution risks — should live next to the work. It should be visible, live, and updated automatically as the work changes.

The Vindaris position

We built risk as a native attribute of work and goals, not as a separate module. When work stalls, goals surface risk automatically. When a goal's risk changes, leadership sees it in context — alongside the work currently driving it and the bandwidth allocated to resolve it. The risk register isn't gone. It's just where it belongs: for the organizational risks that don't have a work item. Everything else lives in the work layer.

Die meisten Organisationen managen Risiken an zwei getrennten Orten: einem Risikoregister und einem Arbeitssystem. Das Register erfasst, was schiefgehen könnte. Das Arbeitssystem erfasst, was getan wird. Die beiden sprechen selten miteinander.

Das ist kein Risikomanagement. Das ist Risikoarchivierung.

Das strukturelle Problem

Ein Risikoregister geht davon aus, dass Risiko etwas ist, das du identifizierst und dann separat verfolgst. In der Praxis: Das Risiko wird eingetragen, eine Mitigation assigned, monatlich reviewed. Niemand weiß, ob die Mitigation funktioniert, weil sie im Arbeitssystem lebt und das Register sie nicht sieht.

Wo Risiko wirklich lebt

Risiko ist keine Inhaltskategorie. Es ist eine Eigenschaft von Arbeit. Ein Arbeitspaket trägt Risiko, wenn es hinter dem Plan ist, unterbesetzt oder von einer ungelösten Abhängigkeit blockiert.

Risiko, das als Eigenschaft von Arbeit definiert ist, ist live. Es aktualisiert sich automatisch, wenn sich die Arbeit ändert. Wenn die Arbeit stockt, eskaliert das Risiko. Leadership braucht keinen monatlichen Risiko-Review – sie brauchen eine Risikoansicht, die den aktuellen Arbeitsstand widerspiegelt.