Almost every organisation past two hundred people manages risk in two separate places. There is a risk register — a spreadsheet, a GRC tool, a standalone module — that captures what could go wrong. And there is a work system — Jira, Asana, Monday, a project portfolio tool — that captures what is being done. The two systems rarely talk to each other in any meaningful way. They sit in different parts of the organisation, owned by different people, reviewed on different cadences.
That is not risk management. That is risk documentation. And the difference matters more than most leadership teams realise — usually until something that was sitting in the register for six months turns into something that was not sitting there long enough.
The structural flaw in the register
A risk register has a quiet structural flaw: it assumes risk is a thing you identify once and then track separately from the work. You add the risk. You rate it. You assign a mitigation owner. You set a review cadence. Job done.
Here is what actually happens. The risk is added to the register. The mitigation is assigned. The monthly review arrives. 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 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, or a quick verbal "yeah, we're on it" from the mitigation owner who has nine other things on his mind.
The register becomes a static artefact. It reflects which risks were identified, not what is being done about them and whether it is actually working. Six months later, when the risk materialises, the post-mortem reads: "the risk was on the register." That sentence is a tombstone, not a defence.
Where risk actually lives
The architectural error is treating risk as a category of content. It is not. Risk is a property of work.
A work item carries risk when it is behind schedule, under-resourced, dependent on a decision that has not been made, or dependent on another work item that is itself at risk. A goal carries risk when the work beneath it has stalled, when the work that was promised has not been started, or when the named owner is overcommitted across three other initiatives. None of that lives in a register — all of it lives in the day-to-day state of the work, where it changes constantly.
Risk that is defined as a property of work is live. It updates automatically when the work changes. When the engineer finishes the dependency, the risk resolves on its own. When the work stalls, the risk escalates without anyone having to remember to escalate it. Leadership does not need a monthly risk review; they need a risk view that reflects the current state of the work, in the moment they look at it.
What "risk as a live attribute" looks like
In practice it has three characteristics. Every work item carries a risk attribute — not a freeform text field for "risks and issues" that nobody reads, but a structured field that links to the goal it would affect, the owner who is accountable, and the resolution path. When the work item turns red, the associated goal's risk indicator updates automatically. No meeting required.
Goals surface their risk state from the work beneath them. A goal is not at risk because someone changed the dropdown to "at risk" in a review meeting. It is 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 has not resolved. The colour of the goal is a derived signal, not an assertion.
Leadership can drill. When an executive sees a goal at risk on Thursday morning, 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 next month. On Thursday morning, before the problem compounds for another two weeks.
The register that still makes sense
There is a legitimate use case for a separate risk register — but it is much smaller than current practice would suggest. Organisational-level risks that are not tied to specific work items belong there: regulatory exposure, market risks, key-person dependencies, geopolitical events, single-vendor concentration. These are not properties of any specific work item. They are properties of the organisation itself, and they need to be visible at the board and audit-committee level.
But the vast majority of what currently goes into most risk registers — project risks, dependency risks, execution risks, capacity risks, integration risks — should not live in a register at all. It should live next to the work it relates to, visible and live and updated automatically as the work changes. A risk that lives separately from the work that creates or resolves it will always be stale. That is not a process problem. It is an architecture problem.
Why this is hard to retrofit
The reason most organisations have not solved this is that the work system and the risk system are usually different products from different vendors, often owned by different functions. The risk register is owned by Compliance or PMO; the work system is owned by Engineering or Operations. Getting them to share a data model is a political project, not just a technical one. So organisations settle for integrations — nightly syncs, status pulls, manual updates — which give the appearance of connection without the underlying live state.
The right fix is not a better integration. It is treating risk as part of the same data model as the work itself, from the start.
The Vindaris view
We built risk as a native attribute of work and goals, not as a separate module bolted on after the fact. When work stalls, the goals it supports surface that risk automatically. When a goal's risk changes, leadership sees it in context — alongside the work currently driving it, the owner accountable, and the bandwidth allocated to resolve it. The register is not gone. It is just where it belongs: holding the organisational risks that genuinely do not have a work item. Everything else lives where it can actually be managed — next to the work.
If your risk reviews routinely surface things that were technically on the register but functionally invisible, you do not have a discipline problem. You have an architecture problem. And the architecture is the thing you can actually change.