It doesn’t do a lot of good to think about cybersecurity risks in generalities. It’s even worse to not think about them at all. Imagine contracting a security firm whose slogan was “We’ll wing it!”  

Such vagueness invariably leads to a reactive – and, by definition, porous – risk posture versus a proactive one. As the Roman philosopher, Lucius Seneca advised 2,000 years ago: “The man who has anticipated the coming of troubles takes away their power when they arrive.”  

If Seneca were alive today, he might take a particular interest in the National Institute of Standards and Technology’s (NIST) Risk Assessment (RA) methodology and Risk Assessment Reports (RAR).  

What is a NIST risk assessment? 

A RA is a formalized “hard look” at potential hazards that could affect an entity (e.g., individual, group, organization, nation, etc.) and their consequences, an effort that ultimately helps them be better prepared to avoid or deal with such hazards. Whether they’re focused on natural disasters, workplace violence, or construction site accidents, RAs’ principles can apply to essentially any risk environment. NIST developed Special Publication (SP) 800-30 to guide organizations through the process of identifying and assessing Information Technology (IT) risks that are relevant to them.  

By following SP 800-30’s methodology, groups digest virtually infinite avenues of threats, vulnerabilities, and impacts into tables of measurable values that they can then harness to prioritize threat responses and measure progress over time.   

Why is a NIST risk assessment important? 

Risk assessment is an integral part of the organizational risk management process as defined in NIST SP 800-39 and as required in the Federal Information Security and Modernization Act (FISMA). RAs form the bedrock of a smart and effective risk management strategy. RAs provide the tools and structure to accurately identify internal and external threats that may exploit vulnerabilities to attack your organization or access another organization through it. RAs also help organizations find ways to effectively address risks within time, cost, and/or personnel constraints. They also offer methods to measure how effectively those threat controls are managing risks. 

The four phases of NIST risk assessment 

NIST outlines four primary steps in the RA process: 1) prepare for the assessment; 2) conduct the assessment; 3) communicate the assessment results; and 4) maintain the assessment. Some steps are further divided into subtasks, as outlined below.   

1. Preparation 

As with virtually any large, important endeavor, failure to prepare is preparing to fail. NIST’s first RA step is, therefore, a particularly critical one. During the preparation stage, organizations develop the general context for conducting the RA and they “frame” the risk (called “risk framing”) within a set of assumptions, constraints, tolerances, and priorities for managing them.  

1. Identify the Purpose – Why is this RA being conducted? How are the results of the RA going to be used? 
2. Identify the Scope – What factors need to be considered in the RA? What organizational tiers should this RA apply to? How long should the results be considered relevant to operations?  
3. Identify Assumptions/Constraints – Describe the operational environment in which your organization works; What resources are available to conduct the RA? What is the skill level of those conducting it? Be as explicit and granular as possible to increase reproducibility. 
4. Identify Information Sources – What sources did you consult to find information about the threats/vulnerabilities being considered? Is the information shareable with other organizations?  
5. Identify Risk Model and Analytic Approach – How do you plan to measure your RA (e.g., quantitative, qualitative)? Will you be focused on the threats, the vulnerabilities, or the impacts? 

2. Assessment 

During the second RA development stage, you conduct the actual assessment. You will ultimately develop a list of IS risks – each prioritized by risk level – that will be the basis of risk response decision-making. You build this list by scoring threats against several risk characteristics (columns in a table) then calculating an overall risk score. In practice, you can expect to repeat some (or all) of these subtasks as you conduct your assessment.

Identify Threat Sources 

There is no single security threat. Some may be adversarial. Others may be environmental, structural, or simply accidental. Within each of these categories, there are dozens of sub-groups. For example, a system in Dallas isn’t likely to be vulnerable to a hurricane, but it could become overheated if climate controls fail on a hot summer day. Similarly, not all adversarial threats are external. A knowledgeable disgruntled employee could deal a worse blow than someone on the outside. Is a precariously-placed Big Gulp a threat to your server? 

During this step, identify the threats that your organization – or the managerial tier you’re focusing on – is likely exposed to. Give each threat a unique identifier. Score adversarial threats (e.g., “low”, “medium”, “high”) against their Capability, Intent, and Targeting potential. Similarly score non-adversarial threats against the range of effects that would come from them. As always, stick to those threats that meet the RA’s scope as you defined in the previous step.  

Consult Appendix D of NIST SP 800-30 for helpful lists of examples and scoring suggestions.

Identify Threat Events 

It is critical to fully understand how each of the threat sources you identified would actually go about impacting your organization. Adversarial nations may exploit vulnerabilities in mobile systems on an office network to gain access to sensitive information. Hacktivists may carry out Distributed Denial of Service (DDoS) attacks. Non-adversarial threat events should also be considered. As an example, a corrupted database file in the Federal Aviation Administration’s Notice to Air Missions (NOTAM) system led to the temporary grounding of all domestic flights in early January 2023, resulting in thousands of delays and cancellations.   

Bear in mind that some threat events involve multiple sources.  For example, adversaries may craft phishing attacks that coax an unwitting employee – an accidental threat – to divulge login credentials.  

Refer to Appendix E of NIST SP 800-30 for examples of threat events and guidance on assessing their relevance to your organization. 

Identify Vulnerabilities and Predisposing Conditions 

In this stage, you will consider various risk factors that might affect how likely a threat could be successfully exploited. Did a cybersecurity Red Team identify that mobile devices you distributed to your employees are missing a recent software patch that was featured on the national news? Is your data center located in a flood zone? Maybe the data at this center is redundantly stored in another location on higher ground, where flooding is much less likely. 

Score how concerning identified vulnerabilities are as well as how pervasive they are within your organization.   

Refer to Appendix F of NIST SP 800-30 for guidance on identifying relevant vulnerabilities and assessing how pervasive they are.  

Determine Likelihood of Occurrence 

Next, consider how likely the threat events you’ve identified will result in adverse impacts. Using the examples from Step 3 above, a highly-publicized vulnerability on popular mobile devices could be readily exploited. Flooding is, by definition, more common in flood zones, however, because the data in the flood-prone data center is redundant, data loss would be temporary or unlikely altogether.  

Independently score how likely a threat event would occur and how likely that event would result in adverse impacts. Then, combine the two scores to generate an overall likelihood score. Refer to Appendix G of NIST SP 800-30 for helpful scoring examples and guidance.  

Determine Magnitude of Impact 

Next, for each identified threat/vulnerability, think “what’s the worst that could happen?” Would a threat event impact how your organization operates? Could it result in injury or loss of life? Could it impact the nation as a whole? Think about the repercussions across a range of perspectives from financial cost to legal action to strained relationships and tarnished reputation.  Threats and threat events can have multiple impacts. 

Score each of the anticipated impacts following the guidance in Appendix H of NIST SP 800-30. 

Determine Risk 

At this final stage of RA development, you will score the level of risk by cross-referencing your estimated likelihood that a threat event would occur against the magnitude of impact. For instance, a threat event that you assess has a very high likelihood of occurring but has a low impact might be scored as a “Low” risk. Alternatively, you might calculate that a medium event likelihood with a high level of impact is a “High” risk.  

Refer to Appendix I of NIST SP 800-30 for helpful scoring examples and guidance. 

Ultimately, you will produce a set of tables that lists your findings and your assessment scores for all of the adversarial and non-adversarial risks – one table each because they are assessed differently. Sort your scoring matrices as necessary to identify higher- and lower-priority concerns. Also view your individually-assessed risks in aggregate to see if some scoring adjustments might be warranted or to detect risk clusters that might expose still more vulnerabilities.  

3. Communication 

The third stage in RA report development is to communicate your findings with (in sequential order) organizational decision-makers and other appropriate organizational personnel. If you choose to do so, this is also a good time to share your findings outside of your organization, potentially helping a different agency address a vulnerability they may not have even known about. By communicating with decision-makers first, you can put the prescribed safeguards into place as quickly as possible to safely respond to identified vulnerabilities and threats. 

Provide your findings through executive briefings, assessment reports, digital dashboards, or any other means that meet your policies and information sensitivity guidance. Also, be sure to include evidence that supports your findings where appropriate. 

4. Monitoring and Maintenance  

The fourth step in developing a RA is to maintain the assessment. RAs should never be viewed as one-and-done efforts. Once completed, RAs require sustained vigilance and regular updates to stay current with organizational policies, software and hardware updates, and staffing changes – not to mention those of the ever-evolving threat environment.   

In many ways, the entire purpose of RA development is to facilitate this final stage: to start the monitoring and maintenance process on the right foot.  

Everything that needs to be included in a risk assessment report 

A RAR is the written record of the full RA development process you went through. A thorough and future-facing RAR includes:  

1. a description of the system or process that is the subject of the RA as well as a summary of the scoping and risk framing procedures and findings you followed.  
2. a detailed explanation of why you conducted the RA as well as any assumptions and limitations you were working with.  
3. your rationale for assigning the assessment scores the way that you did; what does a score of “Low” on a particular category mean to you?  
4. risk assessment tables for adversarial and/or non-adversarial threats. 
5. a change record table to document and date each revision and addition; this is necessary because NIST intends for these RARs to be living documents that are frequently updated. 

Use the CNI IPKeys template to generate your NIST assessment report in minutes (leveraging NIST OSCAL) 

NIST offers a set of RA templates in SP 800-30 to help organizations work through the process thoroughly and accurately. However, as NIST advises: “The use of the [provided] templates is not required in order to conduct risk assessments.”  

Why not download IPKeys’ own Risk Assessment Report template? It leverages Open Security Controls Assessment Language (OSCAL), a set of programming languages and file formats that share common risk management vernacular to unify and streamline assessing risk throughout a system or an organization and reporting on them quickly and accurately.  

Automate your cybersecurity program with IPKeys 

Save time and money with automated assessments 

With IPKeys’ CLaaS, you can eliminate hours of analysis and tedious manual work in researching and developing your RAR. Let CLaaS implement the NIST 800-30 methodology right away and scope your assessment across your entire organization or focus it on a single system. Use an intuitive and flexible AI-powered data analysis system to find and record seemingly imperceptible weaknesses and data connections in your own system. Then let CLaaS continuously monitor and maintain your system against these calculated risks, alerting you of needed action through an intuitive dashboard or printable reports. 

Experienced team 

The skilled specialists at IPKeys focus on cybersecurity that is tailored for government organizations. They developed their distinct suite of security tools and smart strategies for Federal Agencies to meet their rigorous specifications. These same tools can keep your data safe and your systems running. 

NIST risk assessment report template – common FAQs 

How long does it take to conduct a NIST risk assessment? 

As much as you hate to read it, when it comes to expected RA turnarounds, the answer is: “It depends.” It depends on numerous factors such as  the scope of your assessment or the resources you have available to conduct it. With that said, digital automation tools, like IPKeys CLaaS platform, can complete RAs in a fraction of the time that one would need following traditional methods. 

Who prepares the NIST risk assessment? 

Anyone who is knowledgeable and who meets your organization’s information security requirements can prepare a NIST RA. In fact, it can be helpful to incorporate a range of perspectives in the RA development process by enlisting different people in different places within an organization – as long as they are within the limitations of the RA’s scope.  

What is the purpose of a NIST risk assessment? 

NIST developed Special Publication (SP) 800-30 to guide organizations through the process of identifying and assessing Information Technology (IT) risks that are relevant to them. By following SP 800-30’s methodology, groups digest virtually infinite avenues of threats, vulnerabilities, and impacts into tables of measurable values, called Risk Assessment Reports (RAR) that they can then harness to prioritize threat responses and measure progress over time. 

When preparing a NIST risk assessment report, are risk models the same as risk factors? 

Risk models and risk factors are different. Risk models are made up of the myriad risk factors that affect how an organization manages their information security.