Standards & scoring

Every risk is scored Likelihood × Impact, each rated 1–5, giving a number from 1 to 25 that maps to a severity band. This likelihood × impact method is the standard risk-assessment approach in NIST SP 800-30 and ISO/IEC 27005:2022; ISO 31000:2018 frames the wider process. CIS RAM uses the same impact×likelihood idea alongside the CIS Controls.

Important, so you can defend it to an auditor: the method is standard, but the exact band cut-offs and SLA days below are this tool's convention, not a regulation. NIST and ISO deliberately leave the scale to each organization to set in its own risk methodology — which is what the seeded Risk Management Policy is for. Change them here to match yours.

How many levels — is it by law? No. This tool uses four levels (Low / Medium / High / Critical, the common CVSS-style convention). No statute fixes the number: laws (HIPAA, FISMA, GLBA…) require a documented risk assessment but leave the scale to you. The one mandatory scale — NIST FIPS 199, which US federal systems must use under FISMA — defines three impact levels (Low / Moderate / High), while NIST SP 800-30 gives example three- and five-level scales. The count is a local calibration.

Inherent vs residual. The inherent score is the risk before your controls. The residual score is what's left after a control is applied — you re-score Likelihood × Impact with the control in place (usually a lower likelihood, sometimes lower impact). Recording a residual is how you show a control actually reduced the risk.

The risk matrix. Every Likelihood (1–5) × Impact (1–5) combination, coloured by the band it falls in — the visual behind every score:

Rows = Likelihood (5 at top), columns = Impact (1–5). The number in each cell is the score; recalculated live from your band cut-offs above.

A good risk statement makes four things clear: the threat / event, the weakness it exploits, the asset at stake, and the consequence. Framing risk this way is the approach in NIST SP 800-30.

Rule of thumb: if you can't name a clear consequence, it may not be a real risk yet — or it belongs in governance instead.

The risk owner is the person with the accountability and authority to manage the risk — to decide whether to treat it, how far, or to formally accept it. That is the definition in ISO 31000:2018.

The owner is not necessarily the person who fixes it. In RACI terms (Responsible, Accountable, Consulted, Informed): the owner is Accountable; whoever applies the control is Responsible.

To pick one, ask three questions:

• Who owns the affected asset or process? The risk owner is usually whoever is accountable for the thing at risk.
• Do they have the authority to act — approve the fix, spend the time/budget, or accept the leftover risk?
• Is the seniority right for the severity? A Critical risk should sit with someone senior enough to accept it if needed — the Authorizing Official role in NIST SP 800-37.

PlumbTrack suggests an owner by severity (Critical/High → the accountable lead; Medium/Low → the backlog). That is only a starting point — override it with the real accountable person.

An asset is anything worth protecting: a system, server, application, database, or the data itself. Every risk is about a specific asset — so you name the asset a risk affects.

Inventory comes first. You can't assess or protect what you haven't identified. In NIST CSF 2.0 this is the Identify function — Asset Management (ID.AM); in CIS Controls v8 it is Controls 1 & 2 (Inventory of Enterprise Assets, and of Software Assets), literally the first two of the eighteen.

So the order is: inventory your assets → then log risks against them. When you create a risk, put the affected asset in the Asset affected field (e.g. MariaDB database on VM 111 (10.10.10.111)). It is not preset — you assign it once you know what is at stake.

Asset types — the recognized classes

The Type field's suggestions map to the asset classes the inventory standards call out. It's a combobox — you can type your own if something doesn't fit.

Rate an asset by the impact if it were lost, exposed, or made unavailable — its confidentiality, integrity and availability. Prioritizing assets by criticality is NIST CSF 2.0 (ID.AM-05); the one mandatory federal impact scale is NIST FIPS 199 (three levels). A High or Critical rating requires a written justification in this tool. Use these 15 examples per level to calibrate — if your asset is more consequential than the examples one band down and less than the band up, you've probably found its level.

critical Critical · score band 16-25

1. Primary customer database holding all personal + payment data
2. Identity provider / single sign-on (its loss locks out everyone)
3. Domain controller / Active Directory (controls all access)
4. Core banking or payment-processing system
5. Secrets vault / key-management service (Vault, KMS)
6. Certificate authority (issues trust for everything)
7. Electronic health-record system (patient safety, HIPAA)
8. Industrial control system / SCADA affecting physical safety
9. Financial ledger / ERP of record (SOX)
10. Public checkout / revenue system (direct sales impact)
11. Master 'source of truth' data store
12. The backup system all recovery depends on
13. Network core / primary firewall
14. Regulatory-reporting system with legal deadlines
15. Production encryption-key store

high High · score band 10-15

1. Customer-facing web portal (no payments)
2. Internal app handling employee personal data
3. Bastion / jump host for admin access
4. CI/CD pipeline or build server (supply-chain risk)
5. Source-code repository (intellectual property)
6. VPN concentrator / remote-access gateway
7. Shared file server with confidential documents
8. CRM / ticketing with customer contact data
9. SIEM / central logging platform
10. Staging environment that mirrors production data
11. Internal DNS server
12. Container registry
13. Privileged admin workstation / laptop
14. Reporting database (copy of production data)
15. Secondary authentication service (MFA)

medium Medium · score band 5-9

1. Departmental app used by a single team
2. Internal dashboard with non-sensitive metrics
3. QA / test database with synthetic data
4. Read-only replica of a database
5. Internal wiki / knowledge base (routine content)
6. Print server
7. Meeting-room booking system
8. Marketing website (brochureware, no data)
9. Batch-job / scheduler host (non-critical)
10. Internal status page
11. Helpdesk chatbot
12. Training / sandbox environment
13. Log archive (cold storage)
14. Developer workstation
15. Internal file share (internal-only docs)

low Low · score band 1-4

1. Static informational intranet page
2. Public FAQ / documentation site
3. Guest Wi-Fi network
4. Digital signage / lobby display
5. Disposable demo VM
6. Personal scratch / sandbox database
7. Decommissioned server holding no data
8. Public marketing asset on a CDN
9. Internal poll / survey tool
10. Temporary file cache
11. Cafeteria-menu screen
12. Non-production monitoring test node
13. Lab environment with disposable data
14. Read-only mirror of a public dataset
15. Individual contributor's non-privileged laptop

Where criticality is this tool's single business-priority band, FIPS 199 is the federal standard that rates an asset separately on three security objectives — the impact if its information lost Confidentiality (unauthorized disclosure), Integrity (unauthorized modification or destruction) or Availability (disruption of access). Each is rated on FIPS 199's three levels:

• Low — a limited adverse effect on operations, assets, or individuals.
• Moderate — a serious adverse effect.
• High — a severe or catastrophic adverse effect.

The overall categorization is the high-water mark — the highest of the three. An asset rated {C: moderate, I: high, A: low} is High overall. That overall level is what drives the baseline set of controls a system must implement (the tailoring step in NIST SP 800-37 / NIST SP 800-53). NIST SP 800-60 maps common information types to suggested C/I/A levels if you want a starting point. Set each asset's C/I/A on its detail page; the overall level shows on the inventory.

Inventorying an asset (Identify) is step one; the next is Protect — harden it — and then prove it. Hardening means applying the asset's control baseline (the SP 800-53B set its FIPS 199 level selects) and configuring it securely to a recognized benchmark (a CIS Benchmark or DISA STIG). In CIS Controls v8 this is Control 4, Secure Configuration of Enterprise Assets & Software; in NIST CSF 2.0 the Protect function (PR.PS); in SP 800-53 the CM family (CM-2 baseline config, CM-6 config settings, CM-7 least functionality) plus RA-5 and SI-2.

The evidence that it worked is a secure-configuration baseline attestation, a clean vulnerability scan, or a control test — a NIST SP 800-53A assessment finding NIST SP 800-53A. Record it on the asset's Hardening panel: set each baseline control's status for that asset and attach the proof. A High/Critical asset with no hardening evidence is flagged on the POA&M.

Hardening proves a control worked once. Continuous monitoring keeps that assurance current: point-in-time evidence — a control test, vulnerability scan or attestation — decays, so it must be re-collected on a defined cadence (a freshness horizon). This is the RMF Monitor step NIST SP 800-37 and the ISCM discipline (Information Security Continuous Monitoring) in NIST SP 800-137. PlumbTrack ages evidence against the virtual clock — items go fresh → aging → stale; stale assurance is flagged on the evidence register and raises a POA&M item, and an authorized system whose hardening evidence has gone stale is failing continuous monitoring even while its ATO is still valid.

You are only as secure as the third parties you depend on — the cloud that hosts you, the SaaS that sees your data, the processor that touches cardholder data. Supply-chain risk management (C-SCRM) means keeping a register of those vendors, rating each for the impact if it is breached or unavailable and the data / access it holds, and reassessing it on a cadence — the same govern-and-review discipline you apply to your own controls. This is NIST SP 800-161 (Cybersecurity Supply Chain Risk Management) and, in CSF 2.0, the GV.SC category (Cybersecurity Supply Chain Risk Management) of the Govern function. Record third parties on the Vendor register; a High/Critical vendor that is never assessed, or any active vendor overdue for reassessment, is flagged on the POA&M — and, like every date in PlumbTrack, the review cadence advances against the virtual clock.

Once you have a control set, an auditor asks a simple question of every control: does it apply here, and if so, is it in place — and if not, why not? The Statement of Applicability (SoA) answers that in one table. It is a required artifact of an ISO/IEC 27001:2022 ISMS (clause 6.1.3): for each control, declare it Applicable or excluded (Not applicable), record its implementation status, and give a justification. PlumbTrack derives the SoA straight from the control library — a control's status sets its applicability and implementation, and its notes are the justification — so it never drifts from the controls themselves. An applicable control left without a justification is flagged on the POA&M.

Controls are what you choose to do; obligations are what you are required to do — by a regulation (GDPR, HIPAA), a law (SOX), a standard you must meet (PCI DSS), or a contract (a customer's security addendum). Knowing them, who owns each, and whether you actually comply is the first job of governance — in CSF 2.0 the Govern function's GV.OC (Organizational Context: legal, regulatory and contractual requirements are understood). Track them on the obligations register: each carries an authority, a compliance status (compliant / partial / non-compliant / not assessed) and a review cadence. A non-compliant or never-assessed obligation, or one overdue for review, is flagged on the POA&M — the same closed-loop discipline as every other finding.

A control (or treatment) is what you do about a risk. Once you have assessed it you choose one of four risk-treatment responses ISO 31000:2018 IR 8286. Record the choice in the Treatment strategy field on the risk — it is the strategy, separate from the workflow state:

• Mitigate / reduce — apply a control to lower the likelihood or impact (the usual choice), e.g. bind the database to localhost and add a firewall rule. Record the control, residual, and dated actions on the treatment plan.
• Transfer / share — shift some of the risk to a third party (insurance, a provider). You still own the residual.
• Avoid — stop doing the risky thing (decommission the exposed service).
• Accept — consciously carry the residual (record a formal Risk Acceptance on the risk).

A serious (High/Critical) risk under active management with no chosen response is flagged on the POA&M as an undecided-treatment gap. In the Control / treatment field, describe the specific control you applied. NIST catalogs these as named controls 800-53; naming what you did is the evidence an auditor looks for.

The chain of command, the authorized senior approvers, and the break-glass override key (encryption of authority) live on the dedicated Authority tab.