Skip to content
English
Customer portal
Contact us
  • There are no suggestions because the search field is empty.

05.05 The Risk Catalog

SimpleRisk ships a catalog of pre-defined risks and threats that submitters can pick from when filing a new risk. The catalog accelerates and standardizes submissions — instead of writing risk descriptions from scratch, submitters select a catalog entry and the form pre-populates. Manage the catalog at Configure → Risk Catalog.

Why this matters

Two failure modes plague open-text risk submissions: (1) every submitter writes the same well-known risk differently ("Phishing attack" / "Phishing campaign" / "Email-based credential harvest" all turn into separate-looking register entries), and (2) submitters who aren't risk specialists don't know what good risk descriptions look like, so they write thin or vague entries. The risk catalog addresses both: a maintained list of pre-defined risks (and a parallel threat catalog) that submitters can pick from on the submission form. Pick "R-001: Phishing — credential harvest via email link" and the form pre-populates with the standard description; everyone who picks it produces consistent register entries; submitters who don't know what to write get the prompt of "what's already on the catalog?"

The honest scope to know up front: the catalog is opt-in for submitters, not enforced. The submission form lets submitters either pick from the catalog or write a custom risk from scratch. There's no setting that says "must pick from catalog." Programs that want to enforce catalog use rely on operational policy, not a system gate.

The other thing worth knowing: SimpleRisk ships with default catalog content. Out of the box, the risk_catalog and threat_catalog tables contain a starter set of common risks and threats. Most programs find the defaults a useful starting point but extend or replace them with organization-specific entries. The default content is editable; nothing is fixed.

The third thing: the catalog is two related tables, not one. The risk_catalog table holds risk-event entries (what could happen); the threat_catalog table holds threat entries (what could cause it to happen). On the submission form, submitters typically pick one risk-catalog entry plus one or more threat-catalog entries. The two are managed via the same admin page but represent different concepts.

The fourth thing: catalog entries are organized by groupings. Each risk-catalog entry belongs to a risk_grouping (high-level category like "Application Risk," "Vendor Risk," "Operational Risk"); each threat-catalog entry belongs to a threat_grouping ("Adversarial Threats," "Accidental Threats," etc.). The groupings are managed via the dropdown-management surface (Managing Dropdown Values) and provide the structure for the catalog UI's filtering and search.

Before you start

Have these in hand:

  • Admin access to Configure → Risk Catalog for the management UI.
  • A plan for which risks and threats your program needs in the catalog. Don't start by trying to populate every conceivable risk; start with the 10–30 most-common ones for your program. Add more as patterns emerge from real submissions.
  • An understanding of the risk-grouping and threat-grouping taxonomy you'll use. The default groupings ship with SimpleRisk; many programs extend or replace them. Decide on the taxonomy before populating catalog entries (re-organizing later means moving every entry).
  • A backup if you're going to delete or replace the default catalog. Default entries can be useful starting points; once deleted, restoring them requires either a database restore or hand-recreation.

Step-by-step

1. Review the default catalog content

Before customizing, see what ships:

  1. Configure → Risk Catalog opens the catalog management page.
  2. Browse the existing risk-catalog and threat-catalog entries.
  3. Note which entries are useful as-is, which need editing, and which are irrelevant to your program.

The default content covers common information-security and operational risks. Programs in specialized industries (healthcare, financial services, critical infrastructure) may find it generic; programs in mainstream technology may find it directly applicable.

2. Configure the risk and threat groupings

If the default groupings don't fit, edit them via Managing Dropdown Values → risk_grouping and threat_grouping lookups.

Common patterns for risk groupings:

  • By NIST SP 800-30 categories — Information Security, Privacy, Operational, Strategic.
  • By function — Application Security, Vendor Risk, Infrastructure, Compliance, etc.
  • By the program's existing taxonomy — match whatever your program already uses in committee discussions and reporting.

Common patterns for threat groupings:

  • NIST SP 800-30 threat sources — Adversarial, Accidental, Structural, Environmental.
  • MITRE ATT&CK tactics for technology-focused programs.
  • A flat structure if grouping doesn't add much (small programs).

Pick what makes the catalog discoverable for your submitters; don't over-engineer.

3. Add new risk-catalog entries

Sidebar: Configure → Risk Catalog. The page shows the existing entries; the Add Risk button (or equivalent) opens the entry-creation form.

For each new entry:

  • Number — a short identifier (e.g., "R-001"). The convention varies by program; many use a sequential numeric prefix per grouping.
  • Grouping — the risk-grouping this entry belongs to.
  • Name — the risk event name (e.g., "Phishing: credential harvest via email link"). Should be specific enough that a submitter can recognize the risk; don't make it so generic that multiple distinct risks could share it.
  • Description — the standard description that pre-populates the submission form when this entry is picked. Write the description as a complete risk statement: what could happen, what would be affected, why it matters.
  • Function — optional dropdown for risk function classification.

Save. The entry appears in the catalog listing and is immediately available on the submission form.

4. Add new threat-catalog entries

The threat-catalog entries follow the same pattern:

  • Grouping — the threat-grouping.
  • Name — the threat (e.g., "External attacker with phishing capability").
  • Description — what the threat actor or threat condition is and why it matters.

Threats are usually less specific than risks; one threat can manifest in many risks. Don't create per-risk threats; create generic threats that aggregate well.

5. Edit or delete existing entries

To edit:

  1. Click an existing entry.
  2. The entry-editing modal opens with the current values.
  3. Change as needed; save.

To delete:

  1. Confirm the entry isn't currently referenced by any submitted risk (if it is, the deletion may produce orphans similar to dropdown deletion — see Managing Dropdown Values).
  2. Delete via the entry's delete control.

Deleting a catalog entry doesn't delete risks that were submitted using it; the risks keep their description (which was copied from the catalog at submission time) and aren't affected by subsequent catalog edits or deletions.

6. Reorder entries within a grouping

The catalog UI may support drag-to-reorder within a grouping (the page uses the update_order API endpoint to save reordering). Where supported:

  1. Drag entries up or down within the grouping list.
  2. The order saves automatically.

Reordering controls how entries appear in the submission form's catalog picker. Put the most-common-for-your-program entries at the top.

7. Verify the catalog on the submission form

Test from a non-admin account:

  1. Log in as a test submitter.
  2. Open the risk submission form.
  3. Activate the catalog picker (the form typically shows it as a dropdown or modal).
  4. Confirm: - Your groupings appear in the right order. - Your entries appear under the correct groupings. - Picking an entry pre-populates the form with the entry's description.
  5. Submit the test risk; confirm the description was captured correctly.

Iterate until the catalog feels usable from the submitter's perspective.

8. Maintain the catalog over time

The catalog is most useful when it's curated. Periodic reviews:

  • Monthly or quarterly: review which catalog entries are getting picked vs ignored. Drop the unused ones; add new ones for risks that keep getting submitted as custom-text variations.
  • At incidents or audit findings: when an incident or audit surfaces a risk pattern that wasn't in the catalog, add it. Future submitters benefit from the new entry.
  • Annually: revisit the groupings. Did the program's taxonomy shift? Is the catalog still organized usefully?

A maintained catalog is a sharp tool; an unmaintained one becomes stale and submitters stop trusting it. Treat it like documentation: deliberately maintained beats deliberately created and then ignored.

Common pitfalls

A handful of patterns recur with the risk catalog.

  • Dumping every conceivable risk into the catalog at startup. A 500-entry catalog is unusable for submitters; they can't find the right one. Start with 20–30; grow deliberately.

  • Writing catalog entries that are too generic. "Security risk" or "Operational risk" are useless catalog entries — submitters can't pick which "Security risk" they mean. Make entries specific enough to be the right pick for a specific situation.

  • Writing catalog entries that are too specific. "Credential phishing using a Google-themed lure during the third week of December" is too specific to be reusable. Aim for the level of specificity that lets the same entry apply across many submissions.

  • Forgetting that the description pre-populates the submission form. Catalog descriptions become the submitted risk's description. Write them as complete risk statements, not as catalog tags.

  • Treating the catalog as enforced. Submitters can write custom risks that don't reference the catalog. If catalog use matters operationally, communicate the expectation; don't expect the system to enforce it.

  • Letting the catalog grow without curation. Stale entries accumulate; new patterns aren't captured; submitters stop using it. Schedule periodic reviews.

  • Reorganizing the groupings frequently. Each reorganization invalidates training and muscle memory. Get the groupings right early; resist re-shuffling.

  • Conflating risk-catalog and threat-catalog. A risk is what could happen; a threat is what could cause it. Don't put threats in the risk catalog or vice versa; the two have different uses on the submission form.

  • Forgetting that catalog deletes don't cascade to existing risks. A risk submitted using catalog entry "R-042" keeps its description even after R-042 is deleted; the historical record is fine. But future submitters won't see R-042 as a pick. Deletion affects the future, not the past.

  • Not coordinating catalog changes with the team that owns submission training. New entries need to be in training materials; renamed entries break references in old training. Coordinate before bulk catalog updates.

Related

Reference

  • Permission required: check_admin for the Risk Catalog management page; the catalog is read-only for submitters.
  • API endpoint(s): GET /api/v2/admin/risk_catalog/datatable — paginated catalog data for the management page; POST /api/v2/admin/risk_catalog/update_order — drag-to-reorder save.
  • Implementing files: simplerisk/admin/risk_catalog.php (the management UI).
  • Database tables: risk_catalog (id, grouping FK to risk_grouping, number, name ≤1000 chars, description, function); threat_catalog (similar columns; FK to threat_grouping); risk_grouping and threat_grouping (the grouping lookup tables).
  • config_settings keys: None directly; the catalog is table-driven.
  • External dependencies: None.