Risk assessment methodology

Standards that require a risk assessment usually ask for an "industry-accepted" or "documented" methodology rather than naming one. This page is that document for assessments built with the risk assessment tool. Reports produced by the tool link here, so an assessor can read the method behind the numbers.

Basis

The structure and vocabulary follow NIST Special Publication 800-30 Revision 1, Guide for Conducting Risk Assessments. It is a qualitative assessment: risk is expressed in levels, not in dollars. There is no annualized loss expectancy and no probability distribution, because a first assessment rarely has data to support either, and an invented number is worse than an honest ranking.

Terms

Term	What it means here
Asset	Something the organization depends on: data, a system, a device, a process, a person or role, a place, or a vendor.
Threat source	Who or what could cause harm. Grouped as adversarial, accidental, structural, or environmental, following SP 800-30 Appendix D.
Threat event	What could actually happen, following the style of SP 800-30 Appendix E.
Vulnerability	The weakness or predisposing condition that lets a threat event cause harm (Appendix F).
Risk scenario	One asset, one threat event, and the weakness that allows it. Scenarios are the rows of the register.
Likelihood	How likely the event is to happen and cause harm, given the controls in place at the time of the assessment.
Impact	The consequence to the organization if it happened.
Risk	Likelihood and impact combined through the matrix below.
Treatment	The decision about what to do: mitigate, accept, transfer, or avoid.

Where this simplifies SP 800-30

Three deliberate simplifications, so a first-timer can finish:

• One likelihood, not two. SP 800-30 separates the likelihood that a threat event is initiated or occurs from the likelihood that it results in adverse impact. The tool asks for a single combined likelihood.
• Current risk, not inherent and residual. Scores are assessed against the controls that exist today. Planned controls produce an optional target likelihood and impact, which the register shows as a target level. The words "inherent" and "residual" are not used.
• One impact scale. Confidentiality, integrity, and availability appear inside the impact definitions rather than as three separate scores.

An assessment can be edited: the scale wording, the matrix, and the acceptance threshold all travel inside each assessment, and the generated report states the scales actually used. The defaults below are the starting point.

Likelihood scale

How likely it is, given what the organization has in place today.

Value	Label	Definition
1	Very Low	Hard to imagine happening here. No known cases in similar organizations.
2	Low	Could happen, but rarely. Maybe once in several years.
3	Moderate	A realistic possibility. Could happen in the next year or two.
4	High	Likely within the next year. Happens regularly to organizations like yours.
5	Very High	Expected. Either it already happens or it is only a matter of time.

Impact scale

How bad it would be: disruption, exposed data, notification duties, fines, and lost customers or accreditation.

Value	Label	Definition
1	Very Low	Minor inconvenience. No sensitive data exposed, no downtime worth noting, no reporting obligation.
2	Low	Small disruption handled in a day. Limited internal data exposed. No regulator or customer notification.
3	Moderate	Noticeable disruption for days. Some regulated or customer data exposed. Notification may be required. Recoverable cost.
4	High	Major disruption for a week or more. Significant regulated data exposed. Notifications, fines, or contract penalties likely.
5	Very High	Threatens the organization's ability to operate. Large-scale exposure, regulatory action, loss of key customers or accreditation.

Risk matrix

Risk level comes from this grid, adapted from SP 800-30 Rev. 1 Appendix I, Table I-2. The numeric product of likelihood and impact is used only to order scenarios inside a level, never to set the level. That matters: a very unlikely event with catastrophic impact and a near-certain event with trivial impact can share a product of 5 without deserving the same attention.

Acceptance threshold and treatment

The default acceptance threshold is Moderate. Every scenario at or above the threshold must record a treatment decision:

• Mitigate. Add or improve controls to reduce likelihood or impact. Needs at least one planned control, an owner, and a date.
• Accept. Take the risk knowingly. At High or Very High this requires a written rationale and a named approver.
• Transfer. Shift the consequence to someone else through insurance or contract terms.
• Avoid. Stop or change the activity that creates the risk.

An assessment cannot be marked final while any scenario at or above the threshold has an incomplete decision, and it requires a named person signing off. This is deliberate: an unapproved register is not a risk assessment, it is a list.

Review cycle

The default cycle is every 12 months, and again when something significant changes: a new system or location, a new kind of data, a merger, a major vendor change, or an incident. Most standards phrase it as "at least annually and upon significant change."

Starting the next assessment from the previous export keeps asset and scenario identifiers stable, so the two can be compared. The review step shows what carried forward, what has not been re-reviewed, and which treatments are still open.

Limits

A risk assessment records judgment, and the quality of the output depends on the honesty of the input. The tool supplies a starting catalog of threats, weaknesses, and default scores based on what commonly affects small and mid-sized organizations. Those defaults are a prompt, not a finding. They are meant to be argued with.

This is also not a test of whether controls work. Confirming that requires a vulnerability assessment, a security assessment, or a penetration test: separate pieces of work with their own methods.