01.02 Submitting a Risk in SimpleRisk

Why this matters

Every entry in the risk register starts with a submission. The submission is where the discipline of "scope a risk you can score, own, and treat" gets enforced — or quietly skipped, which is what produces the spreadsheet of sixty cybersecurity-shaped non-risks that auditors flag every time. The downstream review, scoring, and mitigation work all read what you wrote here.

The form is short. What takes time isn't filling it out; it's having the right answers to type into it.

Before you start

Have these in hand before you open the form:

The Able to Submit New Risks permission on your account. If you don't have it, the sidebar entry won't appear and the form will refuse to save — ask your administrator. (See Permission Reference.)
A specific subject. Not "ransomware." Not "third-party risk." A scenario you can describe in one sentence — see Common pitfalls below for examples.
A name to put in the Owner field. One human, accountable for the risk. If you can't name one, the conversation about ownership comes before the submission, not after.
The scoring methodology your program uses. Classic is a sensible default if you don't have a strong reason otherwise. The full picture is in Risk Scoring Methodologies.
For risks tied to specific systems, the asset names or asset groups in your inventory. The form can attach them, and that linkage is what makes asset-level reporting work later.

Step-by-step

1. Open the Submit Risk form

In the sidebar, expand Risk Management and click Submit Risk. The form loads on /management/index.php. If the Submit Risk entry isn't visible, your account doesn't have the Able to Submit New Risks permission — the sidebar hides what the role doesn't grant.

2. Write the Subject

Subject is the only field SimpleRisk requires. The default character limit is 300, and an administrator can change it per install. An empty Subject blocks save and shows "The subject of a risk cannot be empty."

Treat the Subject as the one thing your future self, the reviewer, and the auditor will see on every dashboard and export. A useful pattern is threat exploiting vulnerability against asset, with consequence:

Bad: Ransomware — Third-party risk
Better: Phishing-delivered ransomware encrypting the finance team's shared file server, blocking month-end close
Better: Vendor X loses SOC 2 attestation, forcing a contract-clause renegotiation under tight timing

If your draft Subject describes a topic rather than a scenario, you have a category, not a risk. Break it down before submitting.

3. Map the risk and the threat (optional)

The Threat Mapping and Risk Mapping fields sit at the top of the form, directly under Subject and in that order. They link the entry to your risk and threat catalogs so cross-cutting reporting can group risks that share an underlying driver. Both are optional by default — though an administrator can make Risk Mapping mandatory for every submission, in which case the form won't save without it. If you've adopted a catalog, populate them; if not, leave them blank and revisit later.

4. Fill in the Details panel (left column)

The left column holds the descriptive fields. None are required, but we recommend filling Category, Owner, and Affected Assets on every submission — those three make the entry searchable, accountable, and tied to the inventory.

Category — dropdown of your configured risk categories. Editable in admin configuration.
Site/Location — multi-select. Useful when a risk only affects one office, region, or environment.
External Reference ID — free text, max 20 characters. Park a ticket number or audit finding ID here. Type a CVE ID and SimpleRisk looks it up for you (see Looking up a CVE below).
Control Regulation and Control Number — link the risk to a regulation and a specific control. Control Number is free text, max 50.
Affected Assets — search and select assets or asset groups from your inventory; you can also create a new asset by typing a name that doesn't yet exist. For high-impact risks, this linkage is what makes the impact real to a reader who wasn't in the room when the risk was identified.
Technology — multi-select; the stack the risk touches.
Team — multi-select; the team or teams responsible for the affected work.
Additional Stakeholders — multi-user picker. People who need to be in the loop but don't own the risk. Notifications surface here when enabled.
Owner — single-user picker. The one person accountable.
Owner's Manager — single-user picker. Routes reviews up the chain when the owner isn't available.

Looking up a CVE

When the risk is a published vulnerability, type its full CVE ID (for example CVE-2021-44228) into External Reference ID. SimpleRisk asks the National Vulnerability Database (NVD) about it and fills in the form: Subject gets a one-line summary, Risk Assessment gets the CVE description, and Additional Notes gets a link to the NVD entry. Your SimpleRisk server needs outbound access to the NVD for this. When the lookup can't get an answer from the NVD, you'll see "Failed to fetch CVE information. Please check the CVE ID and try again" and the form stays as it was.

The lookup also scores the risk. A CVE often carries scores for several CVSS versions, and SimpleRisk picks the newest one the CVE has, in the order CVSS v4.0, CVSS v3.1, CVSS v3.0, CVSS v2.0. The newest version wins even when its score is lower than an older one's. Within a version, the NVD's own score is preferred over the one the CVE Numbering Authority (CNA) supplied. A message tells you what was used, for example "Scored with the CVSS 3.1 vector from the NVD primary score."

The other versions aren't thrown away. They're saved with the risk, so if you later switch Risk Scoring Method to one of them, its vector is already filled in.

Two cases leave the scoring alone. A CVE with no CVSS score at all fills the text fields and leaves the scoring method and score exactly as you had them. And on an existing risk, where the lookup runs from Edit Details, SimpleRisk asks first: "This CVE has a CVSS 3.1 score. Replace the current risk scoring with it?" Choose Yes to rescore with the CVE's vector, or Cancel to keep your scoring. That question covers the scoring only: on an existing risk the lookup still replaces Subject, Risk Assessment, and Additional Notes in the form without asking, and so does retyping the ID later, even to fix a typo. Nothing is saved until you save the form, so if you didn't want the CVE's text, leave the edit without saving and your risk is untouched.

5. Pick a Risk Source and a Scoring Method (right column)

The right column is the scoring side.

Risk Source — dropdown for where the risk surfaced. A stock install ships External, People, Process, and System; administrators usually replace these with the channels their programme actually uses (audit, self-assessment, scanner, incident, threat intel). Useful for reporting on which channels really feed the register.
Risk Scoring Method — nine seeded options: Classic, CVSS v2.0, CVSS v3.0, CVSS v3.1, CVSS v4.0, DREAD, OWASP, Custom, and Contributing Risk. Default is Classic; the choice determines which scoring inputs appear next.
Methodology-specific inputs — every methodology renders its own inputs directly on the form, in a card that appears the moment you pick it from Risk Scoring Method. Classic reveals Current Likelihood and Current Impact dropdowns, and Custom reveals a single Custom Value field. The CVSS versions, DREAD, OWASP, and Contributing Risk each reveal a wider card row with their own factors and a live score that updates as you fill them in. The full breakdown is in the field reference below.
Risk Assessment — a rich-text editor, two or three sentences: what could happen, to whom, with what consequence. The Subject is the headline; this is the abstract.
Additional Notes — a second rich-text editor, for context that didn't fit elsewhere.
Supporting Documentation — file upload for the audit finding, scanner report, policy document, or whatever else supports the risk being on the register.

Pick the methodology that matches the risk shape: Classic for the bulk of risks, a CVSS version when you're scoring a known CVE (use the version your scanner or the NVD entry reports), DREAD or OWASP for application-security work, Custom or Contributing Risk when the program has its own rubric. The deep dive is in Risk Scoring Methodologies.

6. Tag the risk and submit

Below the two columns, attach Tags — free-text labels that surface in search, filtering, and reporting. Each tag is capped at 255 characters.

When everything's filled in, click Submit Risk. SimpleRisk saves the entry, redirects you to the risk's view page at /management/view.php?id={id}, and shows a success alert with the subject text. From there the risk is in the register and ready for review. Clear Form resets every field and snaps Risk Scoring Method back to Classic. The browser will also prompt you before navigating away if Subject has any text — that's intentional, and the warning has saved more than one half-finished submission.

Field reference

Every field on the form, what it captures, and what you can put in it. Only Subject is always required; everything else is optional unless your administrator has configured otherwise.

Subject

What it captures: The risk's headline — the one line shown on every dashboard, report, and export.
What you can enter: Free text, up to 300 characters by default (an administrator can change the limit). Required.

Threat Mapping

What it captures: Links the risk to your threat catalog.
What you can enter: One or more threat-catalog entries.

Risk Mapping

What it captures: Links the risk to entries in your risk catalog so cross-cutting reports can group risks that share a driver.
What you can enter: One or more risk-catalog entries, grouped by risk grouping. Can be made required by an administrator.

Site/Location

What it captures: The site(s) or location(s) the risk affects.
What you can enter: One or more locations from the administrator-managed list.

External Reference ID

What it captures: A ticket number, audit finding ID, or other external reference.
What you can enter: Free text, up to 20 characters. A CVE ID triggers a lookup that fills in the risk details and the CVSS scoring.

Control Regulation

What it captures: The regulation or framework the risk relates to.
What you can enter: One framework from those installed on your instance.

Control Number

What it captures: The specific control within that regulation.
What you can enter: Free text, up to 50 characters.

Affected Assets

What it captures: The assets or asset groups the risk impacts — the linkage that drives asset-level reporting later.
What you can enter: One or more existing assets or asset groups; type a name that doesn't exist yet to create a new asset.

Technology

What it captures: The technology stack the risk touches.
What you can enter: One or more values from the administrator-managed technology list.

Team

What it captures: The team or teams responsible for the affected work.
What you can enter: One or more teams.

Additional Stakeholders

What it captures: People who need to be kept in the loop but don't own the risk.
What you can enter: One or more users. Surfaces in notifications when enabled.

Owner

What it captures: The single person accountable for the risk.
What you can enter: One user.

Owner's Manager

What it captures: Who reviews when the owner isn't available.
What you can enter: One user.

Risk Source

What it captures: Where the risk surfaced (audit, self-assessment, scanner, incident, threat intel, etc.).
What you can enter: One value from the administrator-managed source list.

Risk Scoring Method

What it captures: The methodology used to score the risk; the choice changes which scoring inputs appear (see below).
What you can enter: One of Classic, CVSS v2.0, CVSS v3.0, CVSS v3.1, CVSS v4.0, DREAD, OWASP, Custom, or Contributing Risk. Defaults to Classic.

Risk Assessment

What it captures: The short abstract: what could happen, to whom, with what consequence.
What you can enter: Free-form text.

Additional Notes

What it captures: Any context that didn't fit the other fields.
What you can enter: Free-form text.

Jira Issue Key

What it captures: Links the risk to a Jira issue, or creates one on submit.
What you can enter: A Jira issue key, validated when you save. Appears only with the Jira Integration Extra.

Supporting Documentation

What it captures: Evidence backing the risk — the audit finding, scanner report, or policy document.
What you can enter: One or more file uploads, each within your instance's maximum upload size.

Scoring inputs by method

The Risk Scoring Method you pick determines the inputs that appear beneath it, live on the form — none of the nine methods opens a separate window:

Classic — two dropdowns, Current Likelihood and Current Impact, each drawn from your configured likelihood and impact scales, next to a live score.
CVSS v2.0 — a card covering the base, temporal, and environmental metrics, with the stored score updating as you fill them in.
CVSS v3.0, v3.1, and v4.0 — a Score card with the risk level and the vector, metric cards for the required Base metrics, a collapsed Advanced Metrics section for the optional ones, and a Vector box where you can paste a vector and choose Apply to fill every metric. You cannot submit until the Base metrics are complete. How the widget behaves, and how the versions differ, is covered in Risk Scoring Methodologies.
DREAD — a card with five factors: Damage, Reproducibility, Exploitability, Affected Users, and Discoverability, each on a 0–10 scale, and a live averaged score.
OWASP — a card covering the likelihood and impact factor groups, with a live likelihood, impact, and overall score.
Custom — a single Custom Value field on the form. Any number from 0 to 10, in steps of 0.1; it opens at your instance's default risk score.
Contributing Risk — a card with one overall likelihood dropdown plus an impact value for each subject your program has defined, and a live weighted score.

If you pick a method and don't see its inputs, scroll down — the card sits directly beneath the Risk Scoring Method dropdown, not in a popup.

The methodology deep dive is in Risk Scoring Methodologies.

Two things that change the field set

The Customization Extra replaces the fixed layout above with template-group panels and can add administrator-defined custom fields, or hide fields you don't use. If your form looks different from this reference — extra fields, a different arrangement — that Extra is why, and the exact field set depends on the template group applied to the risk.
The Encrypted Database Extra, when enabled, stores the free-text fields (Subject, Risk Assessment, Additional Notes) encrypted at rest. The form behaves identically; the difference is only in how the data is held.

Common pitfalls

A handful of patterns show up over and over on submissions, and most are best caught here rather than in review.

Subject too generic. Ransomware, insider threat, third-party risk, cloud security. Each is a topic, not a risk. The Subject should describe a scenario specific enough that two people who weren't in the room interpret it the same way. If two reasonable people would disagree on what the entry refers to, rewrite it.
Trying to mitigate at submission time. New submitters often fill Risk Assessment or Additional Notes with the mitigation plan they've started thinking about. Don't. Mitigations belong on the mitigation tab after review; conflating "what's the risk" with "what are we doing about it" skews scoring before anyone's pushed back. There's a separate workflow for mitigation.
Picking the wrong scoring methodology for the risk type. CVSS for a "vendor goes out of business" risk is a misfit — there's no attack vector to score. Classic for a known CVE throws away the NVD data the vendor already published. Match the methodology to the data you have, not to a house preference. We've watched programs adopt CVSS as a house standard, then quietly score most non-vulnerability risks at "Medium / Medium" because the form doesn't have anything more useful to ask.
Assigning to a team instead of a person. IT doesn't own a risk. The security team doesn't own a risk. A named human owns a risk, and that human is the one who gets the review reminder. Use Team for which team is involved; use Owner for the accountable person.
Leaving Risk Assessment blank. Zero sentences forces every reviewer to ping the submitter for context, and review queues already move slowly enough.
Not linking Affected Assets when the risk is asset-shaped. If the risk is "the database server in the colocation facility loses power," Affected Assets should reference that server. Without the link, asset-level reporting won't show the risk, and the inventory you spent six months building stops paying you back on this entry.
Submitting a vulnerability or a threat as a risk. "Server is missing a patch" is a vulnerability. "Nation-state actors target our industry" is a threat. A risk is a threat exploiting a vulnerability against an asset, with a likelihood and an impact you can score. Confusing the three produces inconsistent scores and confusing reports — see What is a Risk Register and From Vulnerability to Risk.