Security & Privacy Risk Management Model (SP-RMM)

The concept of creating the SP-RMM was to create an efficient methodology to identify, assess, report and mitigate risk. This project was approached from the perspective of asking the question, “How should I management risk?” and was a collaboration between ComplianceForge and the Secure Controls Framework (SCF). The SP-RMM takes a holistic approach to controls, risks and threats as a way to reduce or eliminate the traditional Fear, Uncertainty and Doubt (FUD) that makes many risk assessments meaningless. The SP-RMM is free to use and is licensed under the Creative Commons licensing model.

All organizations have a need to manage risk. Most organizations are compelled to management risk and these requirements come from a broad range of statutory, regulatory and contractual origins. Regardless of your industry, requirements to manage cybersecurity risk exist and failing to manage risk could leave your organization exposed to liabilities from non-compliance:

• NIST 800-171 & CMMC. Protecting CUI in Nonfederal Information Systems and Organizations – Multiple sections of NIST SP 800-171 & CMMC requires risk to be periodically assessed (see Appendix A for more information on this).
• Federal Trade Commission (FTC) Act. 15 U.S. Code § 45 deems unfair or deceptive acts or practices in or affecting commerce to be unlawful - poor security practices are covered under this requirement and not managing cybersecurity risk is an indication of poor security practices.
• Payment Card Industry Data Security Standard (PCI DSS). Section#12.2 requires companies to perform a formal risk assessment.
• Health Insurance Portability and Accountability Act (HIPAA). Security Rule (Section 45 C.F.R. §§ 164.302 – 318) requires companies to conduct an accurate & thorough assessment of potential risks.
• Gramm-Leach-Bliley Act (GLBA). Safeguard Rule requires company to identify and assess risks to customer information.
• Massachusetts MA 201 CMR 17.00. Section# 17.03(2)(b) requires companies to "identify & assess" reasonably-foreseeable internal and external risks.
• Oregon Identity Theft Protection Act. Section 646A.622(2)(d)(B)(ii) requires companies to assess risks in information processing, transmission & storage.

In risk management, the old adage of “the path to hell is paved with good intentions” is very applicable. The reason for this is all too often, risk management personnel are tasked with generating risk assessments and creating the questions to ask in those assessments without having a centralized set of organization-wide cybersecurity and privacy controls to work from. This generally leads to risk teams making up risks and asking questions that are not supported by the organization’s policies and standards. For example, an organization is an “ISO shop” that operates an ISO 27002-based Information Security Management System (ISMS) to govern its policies and standards, but its risk team is asking questions about NIST SP 800-53 or 800-171 controls that are not applicable to the organization. This scenario of “making up risks” points to a few security program governance issues:

• If the need for additional controls to cover risks is legitimate, then the organization is improperly scoped and does not have the appropriate cybersecurity and privacy controls to address its applicable statutory, regulatory, contractual or industry-expected practices. 
• If the organization is properly scoped, then the risk team is essentially making up requirements that are not supported by the organization’s policies and standards.

 

SP-RMM: Risk Management Steps

The SP-RMM is designed to have a "start to finish" approach to risk management, where risk management is broken down into 16 steps (these correspond to the infographic shown above - click the graphic to see a larger version).

1. IDENTIFY RISK MANAGEMENT PRINCIPLES
It is necessary to identify one or more risk management principles that will form the basis of how the entity approaches its risk management processes. The alignment with risk management principles must support the entity's policies and standards for risk management objectives.

Common risk frameworks include:

• NIST SP 800-37
• ISO 31010
• COSO 2019
• OMB A-123

2. IDENTIFY, IMPLEMENT & DOCUMENT CRITICAL DEPENDENCIES. 
This is a multi-step process that involves identifying, implementing and documenting the critical dependencies that are necessary to legitimately identify, assess and manage risk:

2A. RISK MANAGEMENT DEPENDENCIES
It is vitally important to establish the fundamental risk management dependencies. These need to be standardized entity-wide or the entity will be hampered by conflicting definitions and expectations:

• Define the “acceptable risk” threshold for your entity.
• Define risk occurrence likelihoods.
• Define risk impact effects.
• Define risk levels.
• Define the various levels of entity management who can “sign off” on risk levels.
• Establish a Plan of Action & Milestones (POA&M), risk register or some other method to track risks from identification through remediation.

2B. TECHNOLOGY DEPENDENCIES
In order to support risk management processes, it is necessary to establish the technology dependencies that affect risk management decisions:

• Maintain accurate and current hardware and software inventories.
• Maintain accurate and current network diagrams.
• Maintain accurate and current Data Flow Diagrams (DFD).
• Document the technology dependencies that affect operations (e.g., supporting systems, applications and services).
• Consistent application of security and privacy controls across the entity.
• Situational awareness of technology-related across the entity (e.g., vulnerability scanning & patch management levels).

2C. BUSINESS DEPENDENCIES
In order to support risk management processes, it is necessary to establish the business dependencies that affect risk management decisions:

• A data classification scheme needs to exist that is consistent across the entity, including an understanding of what constitutes the “crown jewels” of that require enhanced data protection requirements.
• Business leadership needs to dictate the technology support it requires for business operations to function properly. This enables technology and security leadership to define “what right looks like” from a necessary maturity level for security and privacy controls.
• A multi-discipline effort needs to establish and maintain a Supply Chain Risk Management (SCRM) program that governs the entity’s supply chain. This requires legal, procurement, security, privacy and Line of Business (LOB) involvement.
• Policies and standards must be uniformly applied across the entity.
• LOB management needs to ensure its project teams properly document business practices and provide that information to technology, security and privacy personnel in order to ensure a shared understanding of business practices and requirements exists. This information is necessary to build out a System Security & Privacy Plan (SSPP).
• Since “the business” owns risk management decisions, the entity needs to ensure that those individuals in roles that make risk management decisions are competent and appropriately trained to make risk-related decisions.

3. FORMALIZE RISK MANAGEMENT PRACTICES
Document a formal Risk Management Program (RMP) that supports the entity's policies & standards. The RMP is meant to document the program-level guidance that defines the "who, what, why, when & how" about the entity's specific risk management practices.

4. ESTABLISH A RISK CATALOG
It is necessary to develop a risk catalog that identifies the possible risks that affect the entity. In the context of the SP-RMM, “risk” is defined as:

• noun A situation where someone or something valued is exposed to danger, harm or loss. 
• verb To expose someone or something valued to danger, harm or loss.

In the context of this definition of risk, it is important to define underlying components of this risk definition:

• Danger: state of possibly suffering harm or injury
• Harm: material / physical damage
• Loss: destruction, deprivation or inability to use

With this understanding of what risk is, the Secure Controls Framework (SCF) contains a catalog of third-two (32) risks that are directly mapped to each of the SCF’s controls.

 

5. ESTABLISH A THREAT CATALOG
It is necessary to develop a threat catalog that identifies possible natural and man-made threats that affect the entity's security & privacy controls. In the context of the SP-RMM, “threat” is defined as:

• noun A person or thing likely to cause damage or danger.
• verb To indicate impending damage or danger.

This threat catalog is sorted by natural and man-made threats:

6. ESTABLISH A CONTROLS CATALOG
It is necessary to develop a catalog of security and privacy controls that addresses the entity's applicable statutory, regulatory and contractual obligations. Risks must map to the entity's security & privacy controls. Ideally, the controls are weighted since not all security & privacy controls are equal.

Note: The SCF has built-In Control Weighting Values [1-10], a maturity model and the SCF controls written in question format.

7. DEFINE CAPABILITY MATURITY MODEL (CMM) TARGETS
It is necessary for an entity to define “what right looks like” for the level of maturity it expects for deployed security and privacy controls. This is generally defined by aligning with a Capability Maturity Model (CMM). While there are several to choose from, the SCF’s Security & Privacy Capability Maturity Model (SP-CMM) contains control-level criteria for each of the levels of the maturity model.

Maturity model criteria should be used by the organization as the benchmark to evaluate security and privacy controls.

8. PERFORM RISK ASSESSMENTS
With the previous steps addressed, an assessor will leverage those deliverables (e.g., Risk Management Program (RMP), threat catalog, risk catalog, controls catalogs, etc.) to implement a functional capability to assess risk across the entity. That documented assessment criteria from the previous steps exists to guide the assessor when performing risk assessments.

Assessing risks in the context of the SP-RMM applies to various assessment scenarios:

• Cybersecurity Risk Assessment
• Third-Party Risk Assessment
• Data Protection Impact Assessment (DPIA)
• Business Impact Assessment (BIA)
• Privacy Impact Assessment (PIA)

9. ESTABLISH THE CONTEXT FOR ASSESSING RISKS
Now that a methodology exists to assess risk, it is necessary for the assessor to establish the context of the Security & Privacy Risk Environment (SPRE). The SPRE is the overall operating environment that is in scope for the risk assessment. This is where the threats, risks and vulnerabilities affect the entity’s protection measures.

An assessor can generally find this information in a well-documented System Security & Privacy Plan (SSPP). If the scoping is incorrect, the context will likely also be incorrect, which can lead to a misguided and inaccurate risk assessment.

10. CONTROLS GAP ASSESSMENT
Based on the applicable statutory, regulatory and contractual obligations that impact the SPRE, the entity is expected to have an applicable set of controls to cover those needs. That set of controls identifies the in-scope requirements that must be evaluated to determine what risk exists. This is generally considered to be a “gap assessment” where the assessor:

• Evaluates those controls based on the entity's THREAT CATALOG to identify current or potential control deficiencies; and
• Utilize the RISK CATALOG to identify the applicable risks, based on the identified control deficiencies.

11. ASSESS RISKS
When the control deficiencies are identified, the assessor must utilize an entity-accepted method to assess the risk in the most objective method possible. Methods for assessing a control for deficiencies is generally defined as either:

• Qualitative;
• Semi-Qualitative; or
• Quantitative

In most cases, it is not feasible to have an entirely quantitative assessment, so assessments should be expected to include semi-qualitative or qualitative aspects.

There are multiple methods to actually assess and calculate risk. The SP-RMM leverages work done in this area by ComplianceForge’s Risk Management Program (RMP) to simplify risk management practices.

12. DETERMINE RISK
At the end of the day, risk needs to be understandable. This is generally why risk is bucketed into a set of pre-defined categories. The SP-RMM leverages the following categories of risk, based on the ComplianceForge RMP:

• Low
• Moderate
• High
• Severe
• Extreme

Before a risk report can be documented, it is very important to clarify if the results of the assessment are “inherent risk” or “residual risk” since those have entirely different meanings and implications. Some people want to see both inherent and residual risk, while some people just want to be presented with residual risk. That is why it is important to understand what story the risk scores tell:

• INHERENT RISK: The Occurrence Likelihood (OL), in combination with the Impact Effect (IE) will provide the "inherent risk" score. This is considered a raw or unmitigated risk score. It is important to note that inherent risk does not take into account any control weighting, the maturity of implemented controls or any other mitigating factors.
• RESIDUAL RISK: To understand the "residual risk" that takes into account control weighting, the maturity of implemented controls and other mitigating factor, it requires expanding upon inherent risk calculations. To identify the residual risk score, Occurrence Likelihood (OL) is calculated by Risk Impact Effect (IE), Control Weighting (CW), Maturity Level (ML) and Mitigating Factors (MF).

You can read more about the differences in calculating inherent and residual risk in the CALCULATING RISK: INHERENT RISK VS RESIDUAL RISK section of this document.

13. PRIORITIZE & DOCUMENT RISKS
Once risk has been identified, it is necessary to prioritize and document the identified risk(s). Generally, risk is prioritized by one of the following:

• Emergency;
• Elevated; or
• Standard

Every entity is different in how it documents risk. The following methodologies are commonly used:

• Risk Assessment Report;
• Plan of Action & Milestones (POA&M);
• Risk Register; and/or
• System Security & Privacy Plan (SSPP)

14. IDENTIFY THE APPROPRIATE MANAGEMENT AUDIENCE
It is an unfortunate and common problem within risk management to run across individuals who are directly impacted by risk and simply say, “I accept the risk” with the intent to “wish away” the risks away so that the project/initiative can proceed without having to first address deficiencies. This is why it is critically important that as part of an entity’s program to manage risk that various levels of management are identified with varying authority, each with a pre-described ability to make risk management decisions. This helps prevent low-level managers from recklessly accepting risk that should be reserved for more senior management.

A common tiered structure for risk management decisions includes:

• Line Management
• Senior Management
• Executive Management
• Board of Directors

15. MANAGEMENT DETERMINES RISK TREATMENT
Risk management is a management decision:

• Cybersecurity and IT generally do not “own” identified risk.
• The ultimate responsibility is on the management structure of the team/department/line of business that “owns” the business process or technology that is in use.

Common risk treatment options include:

• Reduce the risk to an acceptable level
• Avoid the risk
• Transfer the risk to another party
• Accept the risk

Right or wrong, management is ultimately able to decide how risk is to be handled. Where this benefits security, technology and privacy personnel is the “get out of jail” documentation that quality risk assessments and risk management can provide. Instead of executive leadership hanging blame on the CIO or CISO, quality risk management documentation can prove that reasonable steps were taken to identify, assess, report and mitigate risk, which firmly puts the responsibility back on the management team of the team/department/line of business that “owns” the risk.

16. IMPLEMENT & DOCUMENT RISK TREATMENT
When managing risk, it should be kept as simple as possible. Realistically, risk treatment is either “open” or “closed” but it can sometimes be useful to provide more granularity into open items to assist in reporting on risk management activities:

• Open (unacceptable risk)
• Open (acceptable risk)
• Closed

Calculating Risk: Inherent Risk vs Residual Risk

It is possible to use a straightforward method to calculate risk using SP-RMM. Both Inherent Risk & Residual Risk map into the SP-RMM Risk Matrix (graphic shown below.

• For Inherent Risk, find the cell where Occurrence Likelihood (OL) intersects Impact Effect (IE) to determine the risk level.
• For Residual Risk, utilize the calculated Residual Risk values (see chart above) to determine the corresponding risk level.

STEP 1: CALCULATE THE INHERENT RISK
To determine the inherent risk, calculate the Occurrent Likelihood (OL) by the Impact Effect (IE).

STEP 2: ACCOUNT FOR CONTROL WEIGHTING
Not all security and privacy controls are equal, so it is important to apply weighting to the importance of controls. The SCF contains pre-defined control weightings that can be edited for an entity’s unique requirements. This Control Weighting (CW) is multiplied by the inherent risk score from Step 1.

STEP 3: ACCOUNT FOR MATURITY LEVEL TARGETS
The next step is meant to determine a weighted maturity score that takes control maturity into account. The more mature a control is, the greater the risk should be reduced. Maturity Level (ML) is multiplied by the value determined in Step 2.

STEP 4: ACCOUNT FOR MITIGATING FACTORS TO DETERMINE RESIDUAL RISK
The final step is to account for Mitigating Factors (MF), which can be compensating controls or other process/technology considerations that mitigate risk, specific to the identified threats.

The end calculation to determine residual risk is: OL * IE * CW * ML * MF

Leveraging the by ComplianceForge’s Risk Management Program (RMP) structure, it is straightforward to translate the calculated value of the residual risk score into a user-friendly risk category:

 

SP-RMM: Applicability To NIST 800-171 & CMMC

An immediate need for many organizations is compliance with NIST SP 800-171 and the Cybersecurity Maturity Model Certification (CMMC). The Security & Privacy Risk Management Model (SP-RMM) is a tool that can be used to address the following requirements:

CMMC PROCESSES & PRACTICES

These CMMC processes and practices are directly impacted by the SP-RMM:

"CMMC 2.0" PRACTICES (LEVELS 1 & 2)

• AT.2.056 . Ensure that managers, system administrators and users of organizational systems are made aware of the security risks associated with their activities and of the applicable policies, standards and procedures related to the security of those systems.
• RM.2.141. Periodically assess the risk to organizational operations (including mission, functions, image or reputation), organizational assets and individuals, resulting from the operation of organizational systems and the associated processing, storage or transmission of CUI.
• RM.2.143. Remediate vulnerabilities in accordance with risk assessments.
• CA.2.159. Develop and implement plans of action (e.g., POA&M) designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.
• CA.3.161. Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls.

NIST SP 800-171 CONTROLS

These NIST SP 800-171 controls are directly impacted by the SP-RMM:

• 3.11.1. Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI.
• 3.11.2. Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.
• 3.11.3. Remediate vulnerabilities in accordance with risk assessments.
• 3.12.1. Periodically assess the security controls in organizational systems to determine if the controls are effective in their application.
• 3.12.2. Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.
• 3.12.3. Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls. 

Find Out Exclusive Information On Cybersecurity

• NIST SP 800-171 R3 - policies, standards & procedures

  ComplianceForge is focused on making the documentation side of the NIST SP 800-171 R3 upgrade as pa...

• DSP version 2022.3 release

  ComplianceForge is pleased to announce the release of version 2022.3 of the Digital Security Program...

• Cybersecurity Supply Chain Risk Management (C-SCRM) Strategy & Implementation Plan

  ComplianceForge is pleased to announce the release of a new product: Cybersecurity Supply Chain Risk...

• CMMC "DIBCAC Battled Tested" Compliance Documentation

  Congratulations to Cybersec Investments for passing its DIBCAC audit to become a CMMC Third-Party As...

---

• Visit our FAQs

  Questions about our products?

  More Info

• Customer Service

  Our customer service is here to help you get answers quickly!

  More Info

• Why Cybersecurity

  Find out the importance of these documents for your business.

  More Info

• Blog

  Read exclusive information about cybersecurity from Compliance Forge.

  More Info