NIST SP 800-171 Framework Series: Risk Assessment

Article NIST Framework
Risk Assessment


Part 11 of CampusGuard’s series covering each of the critical controls from NIST SP 800-171 rev.2

What is a risk assessment, in the context of cybersecurity compliance? What does it involve? How often should an assessment be performed? How do we get started?

With the recent release of the amended FTC Safeguards Rule that went into effect January 10, 2022, the updated rule includes a requirement for a documented (written) risk assessment that addresses criteria for evaluating security risks and threats to sensitive customer information, and describes how the identified risks will be mitigated or accepted.

Basic Security Requirement 3.11.1 of the NIST Special Publication 800-171 requires organizations to periodically assess the risk to organizational operations, organizational assets, and individuals that are involved in the processing, storage, or transmission of Controlled Unclassified Information (CUI).

There is no set schedule for performing risk assessments, with flexibility in what is considered periodic. It is generally recommended that assessments are performed annually, or as any significant changes or new systems are introduced to the environment.

For those institutions working to verify compliance with the GLBA Safeguards Rule, the updated requirements for protecting sensitive customer data, however, are placing a higher level of formality on the risk assessment process and the elements that must be included and documented.

Before you start the actual risk assessment, your organization needs to define the current asset inventory in order to understand where all data is located. Identify all in-scope systems and applications on which sensitive data is collected, stored, or transmitted, as well as any connected systems. The language in the amended Safeguards Rule that includes systems “connected to a system that contains customer information” is an expansion of scope for many institutions previously only considering their GLBA environment as those systems used for student financial aid data.

The inventory process should also not only include systems internal to the organization, but should also consider involvement from third-party service providers and contractors and any information they are accessing on behalf of your organization.

From there, classify all data according to your organization’s data classification categories. The risk assessment process will then identify each assets’ inherent risk based on possible vulnerabilities/threats, likelihood, sensitivity, and possible impact on the organization, and evaluate any current mitigating controls. This process will determine whether existing security measures are sufficiently protecting customer data and/or the resulting residual risk.

When evaluating the current security controls and measures in place, the assessment will include a review of:

  • Network security controls (access controls, passwords, segmentation controls, remote access, anti-malware, auditing, logging, penetration testing, etc.)
  • Security policies and procedures
  • Physical security of IT assets
  • Incident response procedures
  • User education and awareness
  • Disaster recovery and business continuity plans
  • Third-party security

The new FTC Safeguards Rule does define more specific requirements for security measures like access control, encryption of data at rest, multi-factor authentication, change management, penetration testing, and vulnerability scanning. For some of the other areas, such as security policies and procedures, or disaster recovery and business continuity plans, the organization needs to confirm that the policies and plans exist, they function as designed, they clearly define roles, and that key stakeholders/staff responsible are aware of the procedures and are trained to follow them.

NIST SP 800-171 also specifically calls out vulnerability management as a security control that should be in place. Derived Security Requirement 3.11.2 states that organizations must scan for potential vulnerabilities in organizational systems and applications periodically, and when new vulnerabilities affecting those systems and applications are identified. Vulnerability management includes scanning for patch levels; scanning for functions, ports, protocols, and services that should not be accessible to users or devices; and scanning for improperly configured or incorrectly operating control mechanisms.

The required level of vulnerability scanning is flexible based on the organization’s capabilities and the sensitivity of the data being handled, but it is important to include all system components, ensuring that potential sources of vulnerabilities such as networked printers, copy machines, fax machines, etc., are not overlooked.

Any potential vulnerabilities identified should be addressed as quickly as possible, but Derived Requirement 3.11.3 considers that vulnerabilities should be remediated based on the related assessment of risk. Using a risk scale of critical, high, medium, low, etc. remediation for vulnerabilities can be prioritized based on available resources and capabilities.

Risk assessments are essential to an organization’s ability to secure and protect information systems. It is important to formalize and document the process ongoing, as the required security controls and an organization’s ability to implement such controls are tied back to the level of acceptable risk for each individual institution. The updated Safeguards Rule does not require an institution to mitigate every risk identified, but instead allows organizations to accept a risk if the assessment reveals that the chance the risk will produce a security event is low, the consequences are minimal, or the cost of mitigating the risk far outweighs the benefits. In the event your organization is audited, having a documented risk assessment detailing how and why identified risks were addressed or accepted, why specific controls were not implemented, etc. will be critical.

Don’t perform a risk assessment so your organization can just check the compliance box. The exercise should be informational and provide real value to the organization by looking at individual systems and then using those results to take the higher priority risks identified back to your executive team and board. The assessment can help your teams attain funding for additional security tools and/or resources in order to maintain an acceptable level of risk and achieve the organization’s primary goal of protecting customer data.

Additional guidance from the Security Advisor Team below:

[King]: Developing a process for performing a risk assessment and performing the assessment according to that plan should be a top priority for institutions that do not yet have these processes in place. Another requirement to start preparing for are regular reports to the board. A written risk assessment is a valuable tool to understand and communicate overall risk for the organization to the board and other stakeholders. While certain requirements will not take effect for several months, these processes will take resources and a commitment from management for a timely completion. Start working toward implementing these controls now to ensure the organization is prepared to demonstrate compliance with the GLBA Safeguards rule before the end of the year.


About the Author
Katie Johnson

Katie Johnson


Manager, Operations Support

As the manager of Operations Support, Katie leads the team responsible for supporting and delivering CampusGuard services including online training, vulnerability scanning, and the CampusGuard Central® portal. With over 15 years of experience in information security awareness training, Katie is also the Product Lead for CampusGuard’s online training services. As a Senior Customer Relationship Manager for a limited number of customers, Katie assists organizations with their information security and compliance programs and is responsible for coordinating the various teams involved.