Risk records

A record under Risks is one thing that needs attention and one place to work on it: a risk you have identified, or a non-conformity somebody found. It carries how bad it is, who owns it, where it came from, the steps agreed to deal with it, and everything anybody has said about it.

Records live under Risks in the sidebar. Each one belongs to a team, and you see the records of the teams you are in.

The list

The list is the register. Its columns:

Filter by type, severity, status, owner or due date; search by name or code; click a column header to sort by it.

The Actions column reads a dash, not 0%, when there are no actions yet. "Nobody has planned anything" and "nothing has been done" are different states and only one of them is a problem — a record showing 0/4 is behind, a record showing a dash has not been thought about. It carries no colour either: 2/5 done is a fact, not a warning, and the severity two columns to the left is what carries urgency here. See Actions and activity.

There is also a matrix view — the same records plotted by probability against impact — and a personal My risks view that spans every team you belong to and shows the records you own, are assigned or created.

Creating one

New record opens a composer. A name is the only thing it needs; the code is assigned when it saves, and the composer says so rather than showing you a blank code field. Everything else is filled in on the record itself, where you can see what you are shaping.

Records also arrive on their own. A clause review or a control assessment that finds something can push it here as a non-conformity, and it lands carrying the finding's wording, its severity and a link back to the audit that raised it — see From audit below, and Controls and evidence.

The record

Opening a record gives you one page: the title and description on the left, the facts down the right, and below them the actions and the activity thread.

It saves as you type. There is no Save button and no edit mode. The title and the description are editable in place, and the header says Saving… then Saved. Everything else is a row in the properties rail on the right — click the row, pick from the menu.

The properties rail

Properties

• Status — Open, In Progress, Mitigated, Closed. Each one shows as a small coloured dot beside the word rather than a filled badge, so a screenful of records is readable rather than striped.
• Severity — the headline judgement, and the line under it shows where it came from: two numbers you can change in place, an arrow, and the result. P3 × I5 → High.
• Type — Risk or Non-conformity.
• From audit — where the record came from, as a link. It appears only on a record an audit raised, and it names what the audit was looking at: the control, or the clause it failed. Click it to open that audit and read the finding — its reasoning and the evidence it read are there, not here.

People

• Owner — who is accountable for the record. Picking Unassigned clears it.
• Assignee — who is working on it now. Owner and assignee are separate on purpose: the person answerable for a risk is often not the person doing this week's work on it. Unassigned clears this one too.
• Team — which team the record belongs to. Changing it moves the record; you are only offered teams you can actually create records in, so a picker can never hand you a team that then refuses the move. The move is recorded in the thread like any other change.
• Due date — one date, from a normal date picker. The picker's Clear removes it, and the thread records the change with the date written out, not a machine timestamp.

Naming an owner or an assignee tells that person. They get a notice in their inbox — worded differently for the two, because being made accountable for a risk and being handed this week's work on it are not the same message — and it opens straight to the record. This applies whether you set the field on an existing record or raise a record with somebody already on it, which is the common case for a finding.

Three silences are deliberate: clearing a field notifies nobody, since "this is no longer yours" is not work; putting your own name in tells you nothing; and a change to any other field on the record is a line in the thread rather than a notice.

A record you created yourself has no From audit row at all — not a row reading None. Nobody's audit raised it, and its opening line already says who opened it and when, so an empty row would be a reproach rather than a fact.

Severity, and overriding it

Severity is derived: probability × impact gives a score, and the score gives Critical, High, Medium or Low. Change either number and the severity follows immediately.

You can override it. Open the Severity row and pick a level explicitly instead of Auto. The rail then reads the level you chose and adds overridden, and a justification box appears — write down why, because an overridden severity with no reason is the one thing an auditor will ask about. The derivation line stays visible underneath, so both numbers are still on the record.

Where a record came from

A non-conformity is the audit's conclusion, not a copy of the audit. The record says what is wrong, how bad it is and who is dealing with it; From audit in the rail is the way back to the working that produced it — the finding, its reasoning, and the evidence the audit read. Follow the link rather than expecting the record to restate it.

The record used to carry a Linked items editor under the description, where documents, evidence and clauses were attached by hand, with three counting rows in the rail above it. Both are gone. On most records the counts read None, and a record that has to be furnished by hand before it means anything is a form, not a record. What replaced them is the one link the counts never carried: which audit raised this.

If a record carries a corrective-action record from before actions existed, it appears as its own collapsed section under the description. It is read-only history — new work goes into actions.

Versions

Versions in the top bar opens the record's version history: each version of the record, who changed it and when. That is the formal audit trail of the record's own fields. It is not the same thing as the activity thread, which is the running account of everything that happened — including things that never touched a field, like a comment or an action moving to done.

Where the thread reports something that happened to an action, it names that action by its code — "added RSK-014-A2", not a vague "added an action" — so a line in the history points at the step it is about. It also writes states, people and dates the way the rest of the page does: the status a line reports is the same word the action's own chip shows, an assignment names the person rather than their account id, and a moved deadline reads as a date.

Deleting

The bin icon deletes the record after a confirmation naming its code. It leaves the register; its actions and its thread go with it.

Deleting a record is not blocked by anything citing it. Elsewhere — a document, a register, a control, an evidence record — deletion refuses while other people's writing still points at the thing, and names what depends on it. A risk record is exempt today for an honest reason rather than an oversight: nothing a person can edit is able to cite one. The assistant can mention a record in an answer, but a sent message cannot be changed, so a citation living only there could never be cleared by anybody. A refusal you cannot act on is worse than no refusal. When a document body can cite a risk, this record will be guarded like everything else.

Who can do what

The same two layers as everywhere else — your workspace role, and your role in the team that owns the record.

Commenting sits with reading, not with editing. If you can see a record you can say something about it, because a comment is about the record rather than a change to it. Editing or deleting a comment is the one thing no role decides: your own words are yours, and nobody else's are.

What a Reader sees is a read-only page, not a page full of controls that refuse. The action composer is absent rather than disabled-on-click, and the assignee and status controls on an action are inert. Everything a Reader may do — read the record, its actions and its whole thread, comment, resolve and reopen — is offered normally.

Workspace owners and admins are treated as team owners everywhere, exactly as they are for documents. Full detail in Permissions, and the team model in Teams.