04.04 Tying Risks to Assets

Why this matters

A risk in the abstract is a sentence on a screen. A risk linked to the specific asset it threatens is operational: leadership reads "phishing-delivered ransomware encrypting the finance team's shared file server" and knows which file server, which team, which dependencies will be affected if the risk materializes. The linkage between risks and assets is what turns the risk register from an abstract artifact into a concrete picture of where the program's exposure lives.

The other reason this matters is that the linkage is bidirectional. Risks-by-asset reporting answers "what could go wrong with this server" and is the view a system owner reads to understand their exposure. Assets-by-risk reporting answers "which systems does this risk affect" and is the view incident responders read when a risk materializes and they need to scope the blast radius quickly. Both views read from the same underlying linkage; without the linkage, neither view works.

The third thing worth knowing: SimpleRisk supports linking risks to individual assets and to asset groups. The two paths produce the same downstream rollup behavior (a risk linked to a group reports as affecting every current member of the group) but the maintenance story differs. Per-asset linkage is precise but requires updating risks when membership changes; group linkage is loose but auto-updates as the group's membership evolves. The right choice depends on how the asset population changes and how often.

The fourth thing: the linkage feeds risk-scoring math. Each linked asset's Asset Valuation contributes to the risk's impact calculation. A risk linked only to low-valuation assets has a lower computed impact than the same risk linked to high-valuation assets, automatically and without the risk submitter doing the calculation. The linkage isn't decorative; it's part of the scoring substrate.

Before you start

Have these in hand before linking risks to assets:

The Asset Management permission on your account (the underlying permission key is asset). Without it, the Affected Assets widget on the risk form is read-only and you can't add new linkages. (See Permission Reference.)
The risk-submission or risk-modification permission appropriate to what you're doing — Able to Submit New Risks for new submissions, Able to Modify Risk Details for editing existing risks.
A current asset inventory. The Affected Assets widget can search the inventory and create new assets inline (see Managing Assets in SimpleRisk), but the cleanest workflow is to have the assets you want to link already in the inventory before you start linking. Inline creation puts the new assets into the unverified queue, which an admin then has to verify or discard.
A clear sense of the right linkage granularity. A risk affecting one specific server should link to that server. A risk affecting "all production database servers" should link to an asset group named for that population, not to twenty individual servers (the maintenance story is much better). Pick the granularity that matches the risk's actual scope.

Step-by-step

1. Open or create the risk

Linkage happens on the risk form, not on the asset side. Open the risk you want to link from (Sidebar: Risk Management → All Open Risks, then click the risk to open /management/view.php?id=) or open a new submission (Sidebar: Risk Management → Submit Risk, opening /management/index.php).

2. Find the Affected Assets field

On the Submit Risk form, Affected Assets is in the left column of the form (see Submitting a Risk). On an existing risk's detail view, the Risk Details tab carries the same field. The field is a multi-select widget with these characteristics:

Search-as-you-type. Start typing an asset name and matching assets from the inventory appear in the dropdown.
Asset and asset-group selection. The dropdown returns both individual assets and asset groups. The widget placeholder is "Select an Asset or Asset Group."
Inline create for new assets. Type a name that doesn't match any existing asset and the widget offers to create it as a new asset. The new asset lands in the Unverified Assets queue (see Managing Assets in SimpleRisk) for an admin to verify later.

3. Pick the right granularity

Three patterns cover most cases:

One specific asset. If the risk genuinely affects only one named system ("the customer data warehouse on the east-coast cluster"), link to that one asset. The linkage writes to risks_to_assets.
A small set of named assets. If the risk affects three or four specific systems and the population won't change ("the three legacy file servers being decommissioned in Q3"), link to each of them individually. The linkage writes one row per asset to risks_to_assets.
An asset group. If the risk affects a population that has its own logical name ("all PCI-scope systems," "all production-tier database servers," "all customer-facing API endpoints"), link to the asset group instead of to its current members. The linkage writes to risks_to_asset_groups. When the group's membership changes, the risk's effective scope updates automatically.

You can mix the three on a single risk — link to one specific asset and to an asset group, or to two specific assets and to two groups, etc. Reporting de-duplicates at read time.

4. Save the risk

Click Submit Risk (for a new submission) or save the change (for an existing risk's edit). SimpleRisk writes the linkage rows and recomputes the risk's score using the linked assets' valuations. The risk's detail view shows the linked assets (and groups) under Affected Assets.

For programmatic linkage (useful when integrating with an external tool that submits risks tied to specific assets, or when bulk-updating asset-linkage on existing risks) the v2 API supports the linkage as part of the standard risk endpoints:

POST /api/v2/risks/submit accepts an assets_asset_groups parameter (an array of asset IDs and/or asset group IDs).
PATCH /api/v2/risks/{id} updates the linkage on an existing risk; pass the full new array, since the patch replaces rather than appends.
GET /api/v2/risks/{id} includes an affected_assets array in the response, with the asset and asset-group references resolved to names.

5. Read the risks-by-asset view

Open any asset in the Asset Management module to see the Associated Risks section, which lists every risk linked to that asset. The view answers "what could go wrong with this asset?" and is the view a system owner reads when reviewing their exposure.

For asset groups, the Manage Asset Groups view shows the risks linked to each group. The risks here are only the ones linked to the group itself, not the union of risks linked to the individual member assets — those are visible on each individual asset's view.

6. Read the assets-by-risk view

Open any risk's detail view to see the Affected Assets section, which lists every asset (and asset group) linked to that risk. The view answers "which systems does this risk affect?" and is the view incident responders read when scoping the blast radius of a materialized risk.

For risks linked to asset groups, the asset-side view expands the group at read time so each member asset shows the risk on its Associated Risks list. The expansion is dynamic: if you add a new asset to a group later, risks already linked to the group automatically appear on the new asset's list.

7. Use the linkage on dashboards and reports

The Risk Management Dashboard widgets read from the asset linkage to produce the Asset Exposure rollups (when those widgets are added to the dashboard layout — see The Risk Dashboard). The standard report library exposes asset-shaped views including:

Risks and Assets (/reports/risks_and_assets.php) — the matrix of risks by asset.
All Open Risks By Team By Level — implicitly draws on asset-team assignments for the team grouping.
High Risk Report — surfaces risks where the asset-derived impact contribution is high.

For programs whose risk reporting needs to roll up by asset population (PCI scope, customer-facing tier, regulated environment), build asset groups for those populations and use the group-linked risks plus the group-membership rollups to produce the cuts leadership wants.

Common pitfalls

A handful of patterns recur when teams use the linkage.

Risks linked to no assets at all. A risk with no asset linkage produces a register entry that doesn't surface in any asset-side view. The auditor reading the asset's profile won't see the risk; the system owner reviewing exposure won't see it either. For asset-shaped risks (which is most risks), always link. The exceptions — risks that genuinely don't have an asset substrate, like reputational risks or some compliance risks — should be the small minority.
Linking to twenty individual assets when one group would do. A risk linked to twenty individual asset rows requires twenty linkage updates the next time the population changes. The same risk linked to one asset group requires zero updates as long as the group's membership stays current. Reach for the group abstraction whenever the assets you're linking to are a recognizable population.
Inline asset creation as the default workflow. The Affected Assets widget can create new assets inline, which is convenient and creates a queue of unverified assets the admin team has to clean up. When the inventory is well-maintained, inline creation should be rare; when it's the default path, it's a sign that the inventory isn't keeping pace with the systems being deployed. Fix the upstream inventory pipeline; reserve inline creation for genuine one-off cases.
Linking to a group whose membership doesn't reflect the risk's scope. Linking a risk to "Production Database Cluster" when the risk actually affects "Production and DR Database Cluster" is a maintenance trap — the risk under-represents its scope, and discovering the mismatch usually happens during incident response when there's no time to fix it. Either link to multiple groups, or expand the group to match the actual risk scope (and review whether the group definition was correct in the first place).
Forgetting that asset deletion orphans linkages. Deleting an asset doesn't unlink the risks that referenced it; it leaves the rows in risks_to_assets pointing at a now-nonexistent asset ID. The risk's view shows the dangling reference as an unresolved entry, and the affected-asset count drops without the program noticing why. Before deleting an asset, audit its Associated Risks and decide whether to retire-with-rename (preserving the linkage history) or delete-and-accept (orphaning the linkages). See Managing Assets in SimpleRisk.
Treating the linkage as a one-time act. Asset linkage on a risk is supposed to be revisited as the risk evolves. A risk submitted last year linked to a server that's since been decommissioned and re-platformed needs the linkage updated to reflect the current systems; otherwise the risk-by-asset view shows the risk against a system that no longer exists. The per-risk review cycle (see Tracking Risks Over Time) is when linkage updates should happen as a matter of course.
Ignoring the asset-derived impact contribution. A risk linked to high-valuation assets should have higher impact than a risk linked to low-valuation assets. When the program's risk-scoring math doesn't show that differentiation, two things are usually going on: either the asset valuations aren't calibrated (see Data Classification and Asset Criticality) or the risks aren't actually linked to the right assets. Either way, the math is missing inputs it needs.
Linking risks to the asset group and to the asset members simultaneously. A risk linked both to "Production Database Cluster" and to each individual server in that cluster produces double-counting in some downstream queries. The right pattern is one or the other: link to the group when the risk affects the population; link to specific members when the risk affects a specific subset that doesn't have its own group. If a different subset comes up often, make a new group for it.