Risks

Scope

Risk registers lose value when they drift away from the controls, evidence, and remediation state they are meant to represent. This public guide keeps that linkage visible and removes private internals.

Creating a Risk

1. Open Risk in the sidebar to land on the relevant workflow.
2. Use the Program selector if you want to narrow the account-wide register to one program. Leave it unset when you want to record a shared account-level risk.
3. Click New Risk.
4. Fill in: - Risk Reference: Unique identifier within the account (e.g., “RISK-001”) - Category: Technical, Operational, Compliance, Strategic, or Financial - Title: Brief description of the risk - Likelihood (1–5) and Impact (1–5) — inherent score is computed automatically - Scoring rationale — why you chose those two values
5. Optionally add description, initial treatment strategy/context, and residual scoring. Complete the governed treatment or acceptance workflow from the risk detail page.

If you selected a program, the risk is tagged to that program. If you did not, the risk stays in the account-wide register with no program-specific scope. Meridian does not support assigning that existing row to a program later: if governed acceptance becomes necessary, create a program-scoped successor with a new reference and record the original reference in its description so the relationship remains explainable.

The new risk lands on the risk detail page where you can transition its status, link mitigating controls, or edit it.

Choosing likelihood and impact

Each slider is labelled with the meaning of the value you have selected, and shows the full definition beneath it. Hover any rung to read its definition without moving the slider.

Two rules make scores comparable across your register:

• Likelihood is assessed over one year. An event that is near-certain over a decade is rare over a quarter, so pick your value against a one-year window.

• Impact is the worst credible outcome, not the average one. Score across whichever dimension is most severe — service, financial, regulatory or reputational. Averaging hides exactly the tail risk worth managing.

Recording why

The Scoring rationale field records why this risk got those values. The anchors tell you what a 4 is supposed to mean; the rationale is where you say why this risk is one. Cite what you relied on — an incident, a control gap, a contractual exposure. This is the field an auditor reads when they ask why the score is what it is.

It is optional, and risks created before this field existed have none. When you re-score a risk, the rationale in force at that moment is kept with the old score in the risk’s score history, so revising it never rewrites the reasoning behind earlier scores. Correcting a rationale on its own also records a new point in that history. Clearing the field removes the rationale entirely.

Owner Assignment

Risk ownership uses the same tenant user directory picker as MAPs and other operator workflows. Pick an owner from the SearchableSelect backed

If an API caller or stale browser session submits an unknown, inactive, message:

Editing a Risk

1. Open the risk detail page (the relevant workflow).
2. Click Edit in the header. This navigates to the relevant workflow.

3. Update any field — risk reference, title, category, likelihood, impact, treatment strategy/context, residual scoring, or review date. Editing these decision inputs makes any pending acceptance request stale by design.

4. Click Save Changes. The inherent and residual scores recompute on submit; the backend rejects the save if you set residual likelihood or residual impact without the other.

Status changes are not edited inline on this form. They are made from the status-action toolbar on the detail page so the state-machine guard is explicit and confirms before each transition.

Retiring a Risk

There is no delete action for risks. Every risk carries score history from the moment it is created, and that history is retained as governance evidence — hard delete is refused for every risk, regardless of status. To retire a risk, use the status-action toolbar on the risk detail page (the relevant workflow) to transition it to Closed, with a closure rationale or a verified treatment plan as the basis. See Updating Risk Status and Closed is permanent below.

Residual Risk Scoring Modes

Every risk exposes two residual scores:

• Manual residual (residual_score): Entered by the operator via the Edit form. The risk’s likelihood and impact components are independently stated.
• Computed residual (computed_residual_score): Automatically derived from the statuses of all linked mitigating controls.

Computed residual formula

The system uses a simple mitigation model:

Interpretation:

• All controls implemented → computed residual ≈ 50% of inherent score
• All controls failing/not-started → computed residual equals inherent score (no mitigation)
• No controls linked → computed residual is blank (cannot be derived)

The computed score updates automatically when a control’s status changes — no operator action required.

Switching modes

The Scoring panel on the risk detail page shows both scores and a Switch to computed / manual button.

• Manual mode (default): The operator-entered residual is displayed. Use this when your residual scoring is based on factors outside Meridian (insurance, contractual transfers, business context) rather than purely control pass/fail.
• Computed mode: The system-derived score is displayed. Use this when you want the risk register to reflect live control effectiveness automatically.

You can switch modes at any time from the risk detail page. The other score remains stored and visible regardless of which mode is active.

Best practice

1. Start with manual residual scoring when onboarding a risk — this lets you capture your initial assessment before controls are configured.
2. Once controls are linked and their statuses stabilise, review the computed residual alongside the manual one.
3. If the computed residual matches your professional judgement, switch the risk to computed mode so the register self-updates as controls change.
4. Keep manual mode for risks where business context (e.g., insurance, third-party SLAs) materially reduces exposure beyond what control status alone captures.

Understanding the Heat Map

Navigate to the relevant workflow to see the 5x5 grid:

• Y-axis: Likelihood (1 at bottom, 5 at top)
• X-axis: Impact (1 at left, 5 at right)
• Color: Green (low) → Yellow (medium) → Red (high/critical)
• Number in cell: Count of risks at that score combination

Toggle between Inherent (pre-treatment) and Residual (post-treatment) views.

Click a cell to see the specific risks at that score.

Residual view can also show a warning banner and a separate list of “Residual Risks Not Plotted On Grid”. Those are risks in computed mode: Meridian can rank them by their control-derived residual score, but it cannot truthfully place them on the 5x5 grid unless an operator has also set residual likelihood and residual impact manually.

The Capture Snapshot action on the heat map is shown only to operators with Meridian.manage or Meridian.risks.manage. Read-only risk viewers can see the posture-trend history but cannot mint new snapshot rows.

Loading and recovery

Risk lists, detail records, library templates, heat-map cells, and posture rows are validated before Meridian displays them. A malformed or incomplete server response is not treated as an empty register or an all-clear heat map. The page shows an actionable error and Retry instead. If a save response is malformed, do not blindly resubmit: open the register, verify whether the risk was created or updated, then continue from the authoritative record. Create, update, import, and snapshot actions disable duplicate submissions while a request is in flight.

Risk Score Interpretation

Score	Level	Action
1–5	Low	Monitor, review annually
6–10	Medium	Treat or accept with justification
11–15	High	Active treatment required
16–25	Critical	Immediate action required

Updating Risk Status

Risk status tracks treatment progress:

• Open → Treating: Start active treatment
• Open/Treating → Pending Approval: Submit a frozen request to an explicit qualified reviewer
• Pending Approval → Accepted: The assigned, tier-qualified reviewer approves the request
• Pending Approval → Open/Treating: The request is rejected, withdrawn, stale, or expired
• Accepted → Open/Treating: The time-bound approval expires or an authorized reviewer revokes it
• Any → Closed: Risk no longer applicable

Accepting Risk

Risk acceptance is a program-governed, two-person workflow with a frozen evidence record.

1. Open a program-scoped Open or Treating risk. The Acceptance panel explains any prerequisites that are not ready. An account-level risk without a program remains usable in the register, but it cannot be accepted because there is no program appetite authority; create a program-scoped successor with a new risk reference and link the original reference in its description.

2. Confirm the program has an active appetite profile and matching tolerance rule, the risk has a residual score, and at least one eligible reviewer exists.

3. Click Request acceptance. Select a named reviewer returned by the server-side qualified-person search. Enter the business rationale, compensating controls, an expiry within 365 days, and a future next review date on or before expiry. The requester cannot be the reviewer.

4. The reviewer sees the request in My Reviews → My risk acceptance reviews. The same queue also remains available at the top of the Risk Register for risk-focused work. The risk detail shows the frozen risk/program/appetite/rule, treatment-plan, mitigating-control, request-term, actor, hash, assignment, decision, and audit evidence.

5. The assigned reviewer records Approve or Reject with a rationale. Governance requests require the governance approval permission. Executive requests require the separate executive approval authority as well.

6. A risk manager may reassign a pending request with a reason. If the reviewer is deactivated or loses the required grant, the queue says reassignment is required and no decision is allowed until a qualified reviewer is assigned.

The requester may withdraw their pending request. A different qualified reviewer may revoke an active approval. Expiry is automatic. Rejection, withdrawal, staleness, expiry, and revocation return the risk to Treating when an active treatment plan exists or Open otherwise, while all prior requests, assignments, rationales, timestamps, hashes, decisions, and audit IDs remain visible.

If the risk, residual score, appetite, treatment plan, or linked-control state changes while review is pending, Meridian marks the request Stale. Submit a new request version after reviewing the changed inputs. Do not retry a stale or already-decided command: refresh the ledger and follow the current outcome. Archived programs block every acceptance mutation.

Closed is permanent

Closing a risk is one-way. Once you transition a risk to Closed, the status-action toolbar stops offering any further transitions and the backend rejects any attempt to move it back to Open, Treating, or Accepted with a 422 error. This is deliberate — a closed risk is frozen audit evidence, and every compliance framework Meridian supports expects the risk register to be an immutable record of decisions once a risk is resolved.

If a closed risk recurs and needs active tracking again, create a new risk with a fresh risk reference. Link back to the closed one from the new risk’s description so the history stays traceable. Do not try to “undo” the closure — there is no undo.

Filtering and Register Scope

The top-level the relevant workflow page is one register for the whole account. Program is a filter so operators can review cross-program exposure from one place, then drill into a single program only when they need heat maps or a program-only slice of the register. Unscoped risks stay visible in the account register but do not automatically appear in every program view.

The Closed button is shown as the final action on the status toolbar specifically so operators notice that clicking it is a terminal decision. Think of it like archiving — the record stays, but you cannot change it afterward.

Treatment Planning

1. Open Treatment plan on the risk detail page and select Mitigate, Transfer, Avoid, or Accept through treatment plan.

2. Record the plan owner, accountable executive, resources, optional budget, start and target-completion dates, expected residual score, and independent verification method. These fields apply to every strategy.

3. For Mitigate, define the initial milestone, completion criteria, owner, and due date. Transfer, avoid, and accept plans do not ask for a mitigation milestone that the selected strategy will not execute.

4. Submit the versioned draft for independent approval. Complete mitigation milestones with linked evidence, then have a different authorized operator record the effectiveness result and supporting evidence.

5. Link Controls that mitigate the risk and keep the plan current when its scope, dates, resources, or expected residual exposure changes.

Raising a Risk from an Audit Finding

When an audit finding shows a control is not working, you can put it on the risk register without retyping it.

1. Open the finding.
2. Choose Raise a risk.

3. Meridian suggests a likelihood, an impact, and a category, and explains how it got them. Correct anything that looks wrong.

4. Confirm.

The new risk is linked to the finding. Afterwards the finding shows View raised risk instead, and will not raise a second one — a second risk would split the story of the same problem across two records.

Meridian does not do this automatically, on purpose. Not every finding is a risk: an observation about a naming convention is a finding and nothing more. You decide which ones belong on the register.

Two things you cannot do:

• Raise a risk from a draft finding. A draft is not yet agreed, and the register should not carry a contested statement as established fact. Finalize the finding first.

• Raise a second risk from the same finding. Update the existing one.

The suggested scores are a starting point, not an answer. Likelihood never starts below “possible”, because a finding is evidence the control already failed at least once, and repeat findings start higher still. Check them against the scale anchors before you rely on them.

Sending a Milestone to Jira or ServiceNow

If your team works delivery in a ticketing system, you can file a treatment milestone there instead of re-keying it.

1. Open the risk and find the milestone under its treatment plan.
2. Pick a ticketing connector from the dropdown beside Complete milestone.
3. Choose Create ticket.

The dropdown only appears when your account has an active Jira, ServiceNow, or GitHub connector that supports remediation tickets. If you do not see it, the connector needs configuring in Settings.

The ticket carries the risk, the plan, the milestone, its due date, and the residual score the plan is aiming for, so whoever picks it up does not have to come back here for context. Its priority follows the risk’s severity.

You cannot create a ticket for a milestone that is already completed or cancelled, and you cannot create a second ticket for the same milestone on the same connector. When the milestone is completed or cancelled in Meridian, the ticket closes on the next reconcile.

Milestones on account-level risks — risks with no program — cannot be ticketed, because a remediation ticket is filed against a program.

Treatment Milestone Reminders

Every milestone on a treatment plan has an owner and a due date, and Meridian now uses both.

• Seven days before it is due, the owner is notified once. This is the window in which the milestone can still be finished on time.

• Once it is overdue, an alert opens on the program and a task lands in the owner’s queue. Both stay until the milestone is completed or cancelled, or the plan is superseded.

• Fourteen days overdue, the plan’s accountable executive is notified. This fires once, not daily.

Only milestones on an approved, in-progress or implemented plan are chased. Milestones on a draft plan are left alone — nobody has agreed to that work yet.

If a milestone is not going to happen, the fix is to revise the treatment plan rather than to let the milestone sit overdue. The plan’s expected residual score assumes the milestone lands; leaving it open keeps that assumption in your risk numbers.

Linking Controls

From the risk detail page you can link existing controls that mitigate the risk. Controls must belong to the same compliance program as the risk.

1. On the risk detail page, click Link Control in the “Mitigating Controls” section.

2. A searchable picker appears. Type a control ref or title to find a control in this program. Controls already linked to this risk are hidden so you can never double-link.

3. Pick a control and click Link Control.

4. To remove a link, click Remove next to the linked control row and confirm in the dialog.

Use the risk-to-control linkage to demonstrate that controls address identified risks — this is evidence of risk treatment in a SOC 2 audit.