Platform
Modules
By sector
By sector
By standard
Blog
News
Events
NIST SP 800-30
US federal agencies and contractors running an information security risk assessment, plus anyone adopting NIST's approach voluntarily
NIST's guide to running an information security risk assessment, from threat sources and vulnerabilities through to a level of risk.
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.
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 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.
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.
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.
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.
SP 800-30 describes a methodology for producing an artefact, a risk assessment, not a management system to implement or a product feature to build. The judgement calls it asks for, how capable a threat source is, how severe a vulnerability is, how likely an event is to cause harm, are expert analysis carried out by named risk assessors, not something a compliance platform performs on an organisation's behalf.
What evidencing this kind of work involves in practice is what evidencing any documented risk process involves: a controlled procedure recording the risk model, assessment approach, and assumptions an organisation has chosen; training records showing the people who filled in the threat, vulnerability, likelihood and impact tables were qualified to do so; and a version-controlled risk assessment report that an authorizing official, an auditor, or a customer can review later and see the reasoning behind each call. ComplyTrain, as a quality management and evidence system, supports exactly that kind of work in general: controlled documents, training records, and an audit trail connecting a decision back to the procedure and the person who made it.
ComplyTrain does not run the risk assessment itself, does not judge a threat source's capability or a vulnerability's severity, and does not decide what level of risk an organisation should accept. If your organisation needs to hold the documentation and training trail behind a NIST-style risk assessment, talk to us; see the standards explorer for what else sits alongside SP 800-30 in a federal risk-management programme.
Tell us how you need to work with NIST SP 800-30 and what you need from it. We will come back to you about what ComplyTrain can do.
Thank you. Your list is on its way to your inbox, and we will come back to you on what working with these standards in ComplyTrain involves, usually within one business day.
Only for US federal agencies, and even then indirectly: it becomes binding through FISMA and OMB policy rather than through the document itself. Outside federal government it is voluntary; the guide explicitly encourages state, local and tribal governments and private-sector organisations to consider using it, without requiring anything.
No. SP 800-30 is a NIST guidance document describing a risk assessment methodology, not a management-system standard, and it names no accreditation scheme or certifying body. There is nothing to be certified against.
SP 800-39 sets out the whole risk-management process, framing risk, assessing it, responding to it, and monitoring it. SP 800-30 amplifies just the assessment step, providing the detailed process, taxonomies and assessment scales for identifying threats, vulnerabilities, likelihood and impact.
Not by default. Its guidelines apply to federal information systems other than those designated national security systems, though they may be used for national security systems as well with the approval of the appropriate federal officials exercising policy authority over those systems.
No. The guide states there are no specific requirements on the formality, rigour, methodology, tools, or reporting format of a risk assessment, and that organisations have maximum flexibility in how they conduct one, tailoring the scales and templates it provides to their own needs.
One system for the whole compliance programme. Start with the module you need most.
Collect information the same way every time, and decide in advance what happens next.
Know whether your controls are operating, not just whether a policy says they exist.
Turn the compliance work you already know about into a plan with owners, dependencies and dates.
Know what you can offer, and hold the evidence behind every configuration you offer it in.
Eight built-in reports across every module, scheduled, delivered, and filed where the evidence lives.
The sector news that matters to your organisation - read and rated by AI, and delivered as a scheduled digest in your own language.
AI reads the tender pack and pulls out the requirements, deadlines and rules - then helps you draft the response from your own approved content, with you reviewing every step.
One current register of the suppliers and partners you depend on - each risk-assessed, re-assessing itself on schedule, and wired straight into your risk register.
See every requirement you face - across every standard, plus your own contracts and policies - traced to the documents, evidence and processes that satisfy it.
Identify, score, treat and review your risks in one place - with AI to help anyone run a proper assessment, and a defensible trail behind every decision.
Assign training, prove it was understood, and hold the competence records an auditor asks for.
Draft compliance documents with AI, keep every version under control, and export them beautifully branded - all in one place.
Audits, corrective actions, processes and approvals in one quality system, organised around ISO 9001.
A 90-day plan for the smallest defence suppliers: let the tender set your scope, document what you already do, fix the security basics primes check, and keep the system small enough for two people to maintain.
Learn how to qualify, approve and monitor sub-suppliers, flow down requirements through purchase orders, and keep the records an auditor will ask to see under ISO 9001 clause 8.4 and AQAP.
Learn how to run an ISO 9001 Clause 9.3 management review that turns evidence into decisions, with the right inputs, actionable outputs, and a cadence that fits your risks.