Skip to content

Assess

Assess is where a programme is measured against a framework, CAF, ISO 27001, NIST CSF, DORA, or a customer’s own control set, and where findings from that assessment turn into either accepted risk or real, tracked work. This is where an assessor and a risk owner spend their time, and it deliberately keeps those two jobs apart.

Assess → Frameworks lists every framework loaded into your instance, each showing its own scale, a framework’s scoring range is data, not something the product assumes. One framework might score 0–3, another 0–5; the catalogue shows each on its own terms rather than forcing every framework through the same hardcoded scale.

Opening a framework shows its structure (objectives, principles, outcomes, or whatever levels that particular framework uses) as a navigable tree.

An assessment is one dated pass over a framework: score each node against the framework’s own scale, and attach a rationale. Trying to score outside the framework’s own valid range is refused immediately, with a clear reason, never silently clamped or accepted.

An assessment moves through a fixed lifecycle, draft, in review, baselined , and every transition previews its own consequence before you commit to it. Moving to “in review” tells you scores stay editable; baselining tells you plainly that once done, the assessment can never be changed again. Once baselined, the scoring screen itself is replaced by a read-only view of the tree, there’s no way to accidentally edit something that’s supposed to be locked.

Baselining a later assessment on the same framework supersedes the earlier one, and the product says so on screen, you’re never left wondering which of two baselined assessments on the same framework is the one that currently counts (only one ever is).

Once you have two assessments on the same framework, the movement view shows what changed, node by node, up, down, unchanged, new or removed, scaled sensibly against that framework’s own range so a small move on a narrow scale and a small move on a wide one aren’t presented as if they meant the same thing.

A finding is raised against a specific node (or generally, against the assessment as a whole), with a severity. From there it’s triaged one of three ways:

  • Challenge it, you dispute the finding.
  • Remediate it, scope it into real, tracked work. This is the one Assess action that goes through the ordinary sitting mechanism, because it can create a brand-new work package: if your instance holds changes until approved, remediating with a new work package is held for review exactly like any other new work package would be, and the screen explains this plainly rather than leaving you at a dead end. Linking to a work package that already exists is not gated this way at all.
  • Accept the risk: see below.

Every other Assess action, scoring, raising a finding, accepting a risk, takes effect immediately, regardless of your instance’s change-review mode; remediating into a new work package is the one exception, because that’s a genuine plan change, not an assurance record.

Accepting risk: a separate stance, on purpose

Section titled “Accepting risk: a separate stance, on purpose”

The person who assessed a finding is never the person who accepts the risk on it. This is enforced structurally, not just by convention: the Assessor role cannot accept risk, and the Risk Owner role cannot score or raise findings. Even someone who genuinely holds both roles is still refused if they try to accept risk on a finding from an assessment they themselves carried out.

An accepted risk always carries an expiry date, accepting a risk is never forever. Once that date passes, the acceptance resurfaces automatically: it’s shown, unprompted, as lapsed, with the exact date that caused it (“expired on 31 January 2020, the expiry that caused this”). Nobody has to remember to review it; the product tells you when it needs a second look, and a dedicated filter on Assess → Risk acceptances shows everything currently lapsed.

A finding’s own detail page can show its derived cost and exposure: the gap (how far the current score is from the top of the framework’s own scale), the exposure (that gap, weighted by how severe the finding is), and an estimated cost to close it, drawn from the remediation work’s own effort. This is a genuine worked-out estimate, not a promise, the cost figure always states plainly that it’s based on an effort estimate, never presented as a recorded actual.

  • A sitting: the mechanism the one gated Assess action (new work package remediation) goes through.
  • The Deliver section, for the work a remediation actually becomes.
  • The Prove section, for how an accepted or lapsed risk ties into the wider governance picture a board pack can show.