NIST SP 800-30 information security risk assessments

What it is

NIST Special Publication 800-30 Revision 1, "Guide for Conducting Risk Assessments," is a methodology document published by the National Institute of Standards and Technology in September 2012. It sets out how to run an information security risk assessment: identify threat sources and the events they could initiate, the vulnerabilities and predisposing conditions that would let those events cause harm, how likely that is, and how bad the impact would be, then combine likelihood and impact into a level of risk. It amplifies the broader risk-management process in NIST SP 800-39 and feeds directly into the Risk Management Framework in NIST SP 800-37, where risk assessment results inform security categorisation, control selection, implementation, assessment, and the decision to authorise a system to operate.

NIST developed the guide under its statutory responsibilities for federal information security under FISMA, and the document states that it "satisfies the requirements of FISMA and meets or exceeds the information security requirements established for executive agencies" set by the Office of Management and Budget. Its guidelines apply to federal information systems other than those designated national security systems, though they may be used for national security systems too with the approval of the relevant policy authority. Outside the federal government, none of this binds anyone directly: the guide says it "may be used by nongovernmental organizations on a voluntary basis," and it explicitly encourages state, local and tribal governments and private-sector organisations to consider using it.

Who has to care

The document names its audience by function, in its own Section 1.2: those with oversight responsibility for risk management, those running an organisation's missions and business functions, those acquiring information technology, those designing and implementing information systems, those managing information security day to day, and those actually assessing or auditing risk. For someone outside the federal government, the practical trigger is usually a customer contract or a security questionnaire that already uses this vocabulary, since the document itself creates no obligation on its own.

The four-step process

The guide's substance is a four-step process, each step made up of named tasks with a summary of key activities.

Prepare sets the context: the purpose of the assessment, its scope (which parts of the organisation, what time frame, what architecture), the assumptions and constraints under which it runs, the information sources to be used, and the risk model and analytic approach (quantitative, qualitative, or a semi-quantitative mix of both; oriented around threats, assets and impacts, or vulnerabilities).

Conduct is the longest step. It works through: identifying and characterising threat sources, adversarial sources by capability, intent and targeting, non-adversarial sources (errors, structural failures, natural disasters) by range of effects; identifying the threat events those sources could initiate and how relevant each one is, drawing on an extensive catalogue of adversarial tactics and techniques and representative non-adversarial events such as fire, flood, or resource depletion; identifying vulnerabilities and predisposing conditions and assessing their severity and pervasiveness; determining the likelihood that a threat event is initiated or occurs, and the likelihood it causes harm if it does; determining the magnitude of impact to organisational operations, assets, individuals, other organisations, or the Nation; and combining likelihood and impact into an overall level of risk.

Communicate results to decision-makers and shares the supporting information across the organisation, typically through a risk assessment report covering the purpose and scope of the assessment, the assumptions made, the risk model and analytic approach used, a rationale for the judgement calls, and the prioritised list of risks found.

Maintain the assessment through ongoing monitoring of the risk factors involved, updating the assessment as monitoring, security control assessments, or incidents change the picture.

An auditor or reviewer looks for the completed working tables behind each of these steps (threat sources and events, vulnerabilities and predisposing conditions, likelihood and impact determinations, and the resulting risk levels), each with a documented rationale, plus a report along these lines.

What stands out

Three things separate this from a prescriptive checklist standard. First, there is no mandated methodology: the guide says plainly that "organizations have maximum flexibility on how risk assessments are conducted." Second, it insists on three tiers of assessment, organisation, mission/business process, and information system, and warns that risk assessments that only look at the information-system tier "tend to overlook other significant risk factors" visible only at the organisation or process level. Third, "likelihood" here is a scored judgement, not a statistical probability: risk assessors "do not define a likelihood function in the statistical sense," they assign a score based on evidence, experience and expert judgement.

How it is evaluated

There is no certification and no accreditation scheme for SP 800-30. It is guidance describing a methodology, not a management-system standard, and nothing in it describes a body that certifies conformance to it.

For a federal agency, oversight runs through the wider FISMA regime, and the document is specific about what that oversight actually checks: Inspectors General, evaluators, auditors and assessors "consider the intent of the security concepts and principles articulated within the specific guidance document and how the agency applied the guidance" to its own mission and environment, rather than auditing word-for-word conformance to a template. The assessment feeds a concrete decision inside that process too: an authorizing official's decision, under the Risk Management Framework, on whether to operate a system in its current security posture. What that decision (and any later review) draws on is the completed risk tables and a risk assessment report recording the purpose, scope, assumptions, risk model, and the rationale behind each judgement call. Outside federal government, nothing checks any of this unless a customer contract creates its own requirement to.

Standards it references

NIST SP 800-30 sits inside a family of NIST publications: it amplifies NIST SP 800-39 (the parent risk-management process) and feeds NIST SP 800-37 (the Risk Management Framework), drawing on NIST SP 800-53 and SP 800-53A for the security controls a risk assessment helps select and assess, and on FIPS 199 and FIPS 200 for the security categorisation and minimum requirements a Tier 3 assessment assumes are already in place. None of these are in our catalogue yet, so they are named here rather than linked.

The document also names ISO/IEC 27005, the international information-security risk-management standard, alongside ISO/IEC 31000 and ISO/IEC Guide 73, saying its own concepts are "intended to be similar to and consistent with" that family of standards, to reduce the burden on organisations that answer to both ISO/IEC and NIST.

Standards it references

• ISO/IEC 27005Background