Risks

The Risks module is your organization’s risk register. Every risk the organization has identified, with its current assessment, the treatment decision the organization has made, its residual posture after treatment, and a paper trail of who approved what.

Risks is where the formal risk treatment decision lives. Treatment answers: what is the organization going to do about this risk? Reduce it, accept it, avoid it, transfer it, or actively monitor it. Each decision has approvers, an expiry, and a re-review cadence.

When you would reach for this

You set up risks when:

A risk assessment identifies a risk that needs to be formally registered.
A control failure, audit finding, monitoring alert, or AI signal raises a risk candidate that needs to be triaged into a managed risk.
A regulator, customer, or framework requires the organization to maintain a formal risk register with named owners and current postures.
A board, audit committee, or risk committee wants a single authoritative view of the organization’s risk exposure with treatment plans for each item.
An incident has occurred and the post-incident analysis identifies a recurring risk worth tracking.

You don’t reach for this when capturing the work to fix a specific gap (that’s Findings) or recording a temporary waiver from a control (Exceptions). Risks is the strategic decision layer; findings and exceptions are the operational layer.

What lives in a risk

A single record type today (the risk record), with embedded posture snapshots:

Risk carries:

A title and a stable key you pick, plus a description.
A status: identified, assessed, under-treatment, accepted, monitored, closed, etc.
An optional subject: the governed object the risk is anchored to (a service, an asset, a process, a party engagement). Often left blank for portfolio-level risks.
An owner: a responsibility assignment naming who is accountable for the risk.
A risk snapshot: structured posture detail capturing the methodology used, the taxonomy (threat events, vulnerabilities, predisposing conditions, consequences), and any methodology-specific context.
A treatment snapshot: the current treatment decision (reduce / accept / avoid / transfer / monitor), the rationale, the approver, and the review cadence.

Risk assessments, residual snapshots, treatment plans, and acceptance records are layered onto the risk over its life; the risk record is the durable anchor.

A worked example: an investment management firm builds its enterprise risk register

A mid-size investment management firm wants to standardize how it tracks operational, regulatory, third-party, and information-security risks at the enterprise level. The chief risk officer, Aditya, sets up Risks like this.

Step 1: pick the methodology. Aditya defines two evaluation models: an inherent-risk matrix and a residual-risk matrix, both 5×5 with low / medium / high / critical rating buckets. These become the canonical scoring vocabulary the firm uses.

Step 2: register each risk. Aditya works with each business line. For each risk they raise, he creates a record:

A title (e.g., vendor-cloud-availability, mifid-record-keeping-gap, model-drift-quantitative-strategy).
A description capturing the threat event, the conditions that enable it, and the consequence.
The accountable owner (the head of operations for vendor risks, the head of compliance for regulatory risks, the chief data officer for model risks).
An optional subject reference linking to the asset, service, or party the risk concerns.

Step 3: assess. For each registered risk, Aditya conducts an assessment. The assessment scores the inherent likelihood and impact against the canonical 5×5 matrix, references the controls currently in place, and produces a residual rating after accounting for those controls.

Step 4: decide treatment. Based on the residual rating and the firm’s risk appetite, Aditya records a treatment decision for each risk:

For low residual risks, the decision is typically accept, with a review-due date of 12 months.
For medium residual risks, the decision is typically monitor, with quarterly review and an indicator threshold.
For high or critical residual risks, the decision is reduce, with a treatment plan that creates findings for remediation work.

Each treatment decision is approved by an authorized risk owner (the CRO for high/critical, business-line heads for medium/low). The approval is captured in the treatment snapshot with timestamp.

Step 5: live operation. Over time:

A monitoring alert detects a control failure on a vendor; the system creates a finding which traces back to the registered vendor risk and prompts a treatment review.
The quarterly risk committee reviews all monitor and accept decisions approaching their review-due date.
Accepted risks expire and are flagged for reconfirmation.
A new regulatory letter identifies an emerging risk; it’s added as a new record with identified status, then triaged through assessment and treatment.

When the audit committee asks “what is our enterprise risk exposure, by line of business, with current treatment status?”, Aditya filters Risks and exports the view.

Treatment decisions

The five canonical treatment options:

Decision	Meaning
`reduce`	Implement or strengthen controls to lower the risk. Most common for unacceptable residual ratings.
`accept`	The organization formally accepts the risk at its current residual level. Requires an approver, a rationale, and an expiry date.
`avoid`	The organization changes its operations to eliminate the risk source entirely (e.g., exit a market, discontinue a service).
`transfer`	The risk is transferred to another party (insurance, contract clauses, outsourcing).
`monitor`	No active treatment is required, but the risk is watched continuously through indicators or monitoring.

The treatment decision is captured in the risk’s treatment snapshot. Acceptance records have explicit expiry and reconfirmation cadence; reduce decisions typically generate downstream findings and lifecycle work; transfer and avoid decisions reference the change that delivered the outcome.

Risk taxonomy

The methodology snapshot can carry whatever taxonomy your organization uses: threat events, vulnerabilities, predisposing conditions, consequences, impact dimensions (financial, operational, regulatory, reputational), likelihood basis, uncertainty markers, and assumptions. The product does not impose a fixed taxonomy; pick the methodology your organization is using and capture the structured detail in the snapshot.

What you’ll see in the product

Risks lives under Governance → Risks in the workspace.

The Risks list is your enterprise risk register: every risk with current status, owner, residual rating, treatment decision, and review-due date. Filter by status, owner, business line, treatment, residual rating, or scope. This is the page risk committees use.

Inside a risk, you see:

The full title, description, methodology snapshot, treatment snapshot.
The current owner.
Linked controls (which controls treat or contribute to this risk).
Linked obligations (which obligations are at risk from this risk).
Linked assessments (the history of assessments).
Linked acceptances (the formal acceptance decisions with approvers and expiries).
Linked findings (the remediation work driven by this risk).
Linked exceptions (waivers connected to this risk).
Activity history.

Every change is captured in the workspace Audit Log.

Risk candidates

Risks often emerge from signals: a security event, an audit finding, a control monitor failure, an AI signal, an incident debrief. These start life as risk candidates rather than fully-managed risks, so the triage team can decide whether to formalize them.

A candidate can be:

Accepted into a new risk record (formal triage decision).
Dismissed (no risk, or already covered by an existing risk).
Converted into a finding or exception if it’s a concrete gap rather than a strategic risk.
Merged into an existing risk record.

Candidate management lives alongside the formal risk register so nothing falls through the cracks.

Common workflows

Registering a new risk

Risks → New risk. Pick a stable key, title, owner, methodology.
Conduct an initial inherent assessment.
Identify the controls in place, then conduct a residual assessment.
Record the treatment decision with rationale and approver.
Set a review-due date.

Annual risk register review

Filter Risks by review-due date approaching.
For each risk, conduct a refresh assessment.
Confirm or change the treatment decision.
Update the review-due date.
Close risks that no longer apply.

Handling a risk candidate from a monitoring signal

The monitoring system creates a risk candidate from a failed monitor.
The risk owner triages: accept into a new risk record, merge into an existing one, convert to a finding, or dismiss with rationale.
If accepted, follow the new-risk workflow.

Closing a risk

From the risk, set status to closed, providing the rationale (treated and verified, no longer applies, organization no longer exposed, etc.).
Existing assessments, treatments, and linked records remain visible for historical context.
The risk no longer appears in active risk-register views.

Looking for the API?

See Risks API reference for the v1 REST endpoints to list and inspect risks from an external system.

Controls - controls treat risks.
Evaluation Models - the methodology that scores risks.
Assessments - the engagements that assess risks.
Findings - the remediation work driven by reduce treatments.
Exceptions - waivers connected to a risk.
Indicators - KRIs that track risk movement over time.
Monitoring - monitors that surface risk candidates.