NIST Special Publication 800-30 is the document people mean when they say "do the risk assessment the NIST way". Federal programs expect it. HHS points to it in its guidance on the HIPAA risk analysis. Plenty of commercial teams adopt it because it is free, detailed, and recognizable to auditors.
It is also a long 2012 document, much of it appendices of tables. Teams that open it for the first time tend either to copy every table or to skim it and keep their old spreadsheet.
This article sets out what SP 800-30 Revision 1 asks you to do, step by step, and where the effort pays off.
What SP 800-30 is, and where it applies
SP 800-30 Revision 1, "Guide for Conducting Risk Assessments", was published by NIST in September 2012. It is guidance. Nothing in it is a certification requirement, and no assessor will fail you for using different scales.
It sits inside a family. SP 800-39 describes organization-wide risk management. SP 800-37 describes the Risk Management Framework for federal systems. SP 800-53 provides the controls, including RA-3, the risk assessment control. SP 800-30 is the method that feeds all of them. The NIST 800-53 framework page covers the control side.
Two contexts make it close to mandatory in practice:
Federal systems. Agencies and their contractors running the RMF are expected to assess risk in a way consistent with SP 800-30.
HIPAA. The Security Rule requires a risk analysis but specifies no method. HHS guidance on that requirement refers to SP 800-30, which is why many healthcare teams use it. The article on the HIPAA risk analysis requirement covers what HHS expects.
Elsewhere it is one sound option among several. If you are building an ISO 27001 program, ISO 27005 is the more natural companion, though the two methods are compatible.
Which tier you are assessing
SP 800-30 borrows three tiers from SP 800-39. Tier 1 is the organization. Tier 2 is the mission or business process. Tier 3 is the information system. Most compliance-driven assessments work at Tier 3, one system or one defined environment at a time. Say which tier you are at in the scope, because it changes the threats and impacts that are relevant.
The risk model
Before the steps, understand the vocabulary, because the whole method hangs on it. SP 800-30 describes risk as a function of these factors:
Threat source. The cause. Sources are adversarial, accidental, structural (equipment or software failure) or environmental.
Threat event. What the source does or what happens, such as a phishing campaign or a storage failure.
Vulnerability. A weakness the event can exploit.
Predisposing condition. Something about the organization or system that makes an event more or less likely, such as a data center in a flood zone or reliance on a single legacy platform.
Likelihood. How likely the event is to occur and to cause harm.
Impact. The magnitude of harm if it does.
For adversarial sources, the guidance asks you to consider capability, intent and targeting. For the others, you consider the range of effects.
Step 1: prepare for the assessment
This step is short to do and expensive to skip. Write down:
Purpose. Why the assessment is being done: an initial authorization, a periodic reassessment, a proposed change.
Scope. The tier, the systems, the time frame, and what is excluded.
Assumptions and constraints. For example, that the cloud provider's controls operate as described in its assurance reports.
Information sources. Threat intelligence, vulnerability scan results, past incidents, prior assessments.
Risk model and analytic approach. Which scales you will use, and whether your analysis is threat-oriented, asset or impact-oriented, or vulnerability-oriented.
The last item decides whether this year's results can be compared with next year's. Change the scales between assessments and you lose that.
Step 2: conduct the assessment
The core of the method is five tasks, done in this order:
Identify threat sources and threat events
Identify vulnerabilities and predisposing conditions
Determine likelihood of occurrence
Determine magnitude of impact
Determine risk
Likelihood has two parts
This is the detail most spreadsheets miss. SP 800-30 treats overall likelihood as a combination of two judgments: how likely the event is to be initiated or to occur, and how likely it is, once it happens, to cause adverse impact.
The second judgment is where your controls show up. A phishing campaign against your staff is very likely to be initiated. Whether it results in a compromised account depends on MFA, training and email filtering. Rating the two parts separately makes the effect of a control visible, and gives the treatment plan something to change.
Impact is broader than you think
The guidance lists harm to operations, to assets, to individuals, to other organizations, and to the Nation. Commercial teams can drop the last. The category that matters most for most SaaS companies is harm to individuals, because it is the one their customers and regulators care about.
Risk is the combination
The guidance uses five qualitative levels for likelihood, impact and risk: very low, low, moderate, high and very high. It also offers semi-quantitative equivalents. Risk is determined by combining likelihood and impact through a table. You can use that table or define your own, as long as it is documented and applied consistently. The guide to likelihood and impact scoring covers how to word each level so that two assessors agree.
Steps 3 and 4: communicate and maintain
Step 3 is to communicate the results to the people who make risk decisions. The guidance describes what a risk assessment report contains, in brief:
- Not done:
The purpose, scope, assumptions and constraints from step 1
- Not done:
The risk model and the scales used
- Not done:
Each risk, with its threat event, likelihood, impact and level
- Not done:
The information sources relied on
- Not done:
A summary that a decision-maker can read without the detail
Step 4 is to maintain the assessment. That means monitoring the risk factors you identified and updating the assessment when they change: a new vulnerability class, a new integration, a change in who is targeting your sector. Treat the assessment as a record that is kept current, not a report that is filed.
Where teams go wrong
The same mistakes come up repeatedly.
Copying every appendix table. The appendices are examples. A threat list of every event in the guidance, each rated, produces a document nobody reads and nobody updates. Select the events relevant to your scope.
Rating likelihood as a single number. This hides the effect of controls, so the risk does not move when you fix something.
No link to the response. SP 800-30 is about assessment. Deciding what to do about each risk is a separate step, and the assessment should hand off to it with an owner and a decision for each high risk.
Skipping step 4. An assessment done for an authorization or an audit and not touched again is the most common failure, in any method.
How TrustLynce helps
TrustLynce holds your risk register with the likelihood and impact scales you define, so each assessment uses the same criteria. Risks carry owners and treatment plans, and every assessment's results are kept, so step 4 leaves a dated record.