Managing risks

The risk register

Open Risks from the sidebar. You will see every risk in the current tenant with its title, category, severity, owner, status, and last update.

At the top of the register, a KPI strip shows Total Risks, Critical / High, Deferred, Needs Assessment (risks that have no score yet), Exceptions, and Resolved. This is the at-a-glance view you want at the top of every meeting.

You can filter the register by:

• All: every risk in the tenant.
• Deferred: risks with treatment set to Defer (the operator hasn't decided what to do yet).
• Needs Assessment: risks with no impact/likelihood score yet (manual entries that skipped scoring).
• Open / Active: work in flight.
• Resolved: risks that are mitigated, accepted, or closed.
• Exceptions: risks accepted through a formal risk exception.

Switch between Review, List, and Board views, and search by title, category, owner, or severity.

Creating a risk

Three ways to create a risk:

1. 1
   Manually. Click New Risk. Give it a title, description, category, and owner. Save. If you skip scoring at creation, the risk lands under the Needs Assessment filter until you set Impact and Likelihood.
2. 2
   From the onboarding wizard. When you first onboard a client, the wizard seeds ten starter risks covering common gaps. These are editable and owned by you until you reassign them.
3. 3
   From an integration. Deep integrations create risks automatically when they detect something worth flagging (a misconfigured S3 bucket, a user without MFA, an impossible travel login). See Risks from integrations below.

Scoring a risk

Open any risk to see the scoring panel. Every risk is scored on a 1 to 4 scale for impact and a 1 to 4 scale for likelihood. The product is a 1 to 16 composite score that maps to a severity badge (Low, Medium, High, Critical).

You can score manually by picking values from the dropdowns. Or click AI Suggest, and Radius360 will analyze the risk title, description, and category and propose impact and likelihood values with reasoning. Accept, adjust, or override.

How risk scores are calculated

Radius360's risk scoring methodology aligns with NIST SP 800-30 Rev. 1 (Guide for Conducting Risk Assessments), the US federal standard for information security risk assessments. Every risk has two dimensions: impact (adverse effect if the event occurs) and likelihood (probability of occurrence within the assessment period). Each is scored on a 1 to 4 ordinal scale, consistent with NIST 800-30 Appendix H level-of-risk matrices.

The composite score is impact multiplied by likelihood, producing a value from 1 to 16. That number maps to a severity badge:

• Low: composite score 1 to 3
• Medium: composite score 4 to 7
• High: composite score 8 to 11
• Critical: composite score 12 to 16

The 1 to 16 composite gives more granularity than the 4 severity bands, so the register sorts within a severity band by raw score (a High with composite 11 sits above a High with composite 8).

When you use AI Suggest, the model is given your risk's title, description, category, and tenant context (industry, active frameworks, size), and returns values on the same 1 to 4 scale with a short rationale. It is never a black box: you see exactly why the AI scored the way it did and can override.

Auto-assessed risks (from integrations)

When a deep integration creates a risk, it sets Impact, Likelihood, and the matrix score automatically using sensible defaults per finding type (e.g. "no DMARC" gets Medium / Likely / 6). Those rows arrive flagged auto_assessed = true. The Risk Detail Overview tab shows a violet Auto-assessed by Radius360 banner with a one-click Confirm button.

Until you Confirm (or edit and save), every sync run will refresh Impact / Likelihood / score against the integration's current default. The moment you Confirm, the flag flips to false and your assessment becomes locked; sync runs stop overwriting it. This is the "trust but verify" loop: the system makes a starting assessment, you ratify or override, and your decision sticks.

The likelihood vocabulary on the Overview matrix is Rare / Possible / Likely / Almost Certain (the standard 4×4 matrix axis labels). Impact uses Low / Medium / High / Critical. risk_score = impact value × likelihood value, capped at 16.

Risk treatment

Every risk carries a treatment decision separate from its status. Treatment is what you've decided to do about the risk; status is where it is in its lifecycle. The five treatment options:

• Mitigate: reduce the risk via controls (most common).
• Accept: acknowledge and monitor; cost to fix exceeds impact.
• Transfer: insurance, vendor SLA, or contract clause shifts liability.
• Avoid: stop the activity that creates the risk.
• Defer: pending decision; routes to the Deferred filter.

The Treatment dropdown on Risk Detail's Overview tab is inline-editable. Pick a value and it saves immediately. No Edit-mode toggle required. Treatment Justification and Approval workflow live in the full Edit panel for tenants who need an audit trail on the decision.

Risks from integrations

Each deep integration has a set of detection rules that turn findings into risks. Examples:

• Okta. Users without MFA, stale admin accounts, impossible travel logins, unreviewed privileged sessions.
• AWS. Unencrypted S3 buckets, overly permissive IAM policies, security groups exposing sensitive ports, unrotated access keys.
• Microsoft 365. External sharing on sensitive sites, admin accounts without Conditional Access, legacy auth enabled.
• CrowdStrike / SentinelOne. Critical detections, endpoints with containment actions, high-risk behavior patterns.
• Tenable / Rapid7 / Qualys. Critical and high CVEs on production assets.

Risks from integrations are tagged with their source, a reference ID that links back to the originating alert, and the asset or user context. Radius360 deduplicates: if the same integration reports the same finding twice, the existing risk is updated rather than a duplicate being created.

Mitigation tasks

Every risk can have one or more mitigation tasks attached. Tasks are lightweight (title, owner, due date, status) and are the unit of remediation work. When all mitigation tasks for a risk are marked complete, Radius360 prompts you to move the risk to Mitigated status.

If you use Jira, tasks can sync bidirectionally. A mitigation task in Radius360 creates a Jira issue; status changes in Jira reflect back in Radius360.

SLA tracking

Each severity has a default SLA: Critical within 7 days, High within 30 days, Medium within 90 days, Low within 180 days. The register highlights risks approaching or past their SLA in the Needs Attention column.

SLAs are editable per tenant. Go to Settings, Security (the Posture and SLA section) to adjust the defaults for a given client's risk appetite.

Exporting the register

Click Export at the top of the register. You get a PDF of the current filtered view with the KPI strip, every visible risk, and a summary page. Use this for board meetings, audit responses, or internal reviews.

For programmatic access, the Radius360 API exposes the register as JSON. See API and webhooks.