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

01.02 Submitting a Risk in SimpleRisk

Walk through the Risk Submission form field-by-field, from Subject and Risk Source through Owner assignment and initial scoring.

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.

Sidebar with Risk Management expanded and Submit Risk highlighted as the first sub-item under it

2. Write the Subject

Subject is the only field SimpleRisk requires. The default character limit is 300, configurable per install via the maximum_risk_subject_length setting. 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.

Top of the Submit Risk form showing the Subject field with a specific scenario typed in, with the Risk Mapping and Threat Mapping selectize widgets visible underneath

3. Map the risk and the threat (optional)

The Risk Mapping and Threat Mapping fields sit at the top of the form. 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. 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.
  • 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.

Left column of the Submit Risk form showing Category, Site/Location, External Reference ID, Control Regulation, Control Number, Affected Assets (with the asset selectize widget), Technology, Team, Additional Stakeholders, Owner, and Owner's Manager fields stacked vertically

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 (audit finding, self-assessment, scanner, incident, threat intelligence, etc.). Useful for reporting on which channels actually feed the register.
  • Risk Scoring Method — six seeded options: Classic, CVSS, DREAD, OWASP, Custom, and Contributing Risk. Default is Classic; the choice determines which scoring inputs appear next.
  • Methodology-specific inputs — Classic reveals Current Likelihood and Current Impact dropdowns; CVSS, DREAD, and OWASP open their own scoring modals; Custom takes a single numeric score; Contributing Risk asks for likelihood plus impact factors.
  • Risk Assessment — textarea, two or three sentences: what could happen, to whom, with what consequence. The Subject is the headline; this is the abstract.
  • Additional Notes — textarea 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.

Right column of the Submit Risk form with Risk Source, Risk Scoring Method dropdown set to Classic (showing Current Likelihood and Current Impact dropdowns underneath), Risk Assessment textarea, Additional Notes textarea, and Supporting Documentation upload visible

Pick the methodology that matches the risk shape: Classic for the bulk of risks, CVSS when you're scoring a known CVE, 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= , 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.

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.

Related