*5.2.3 Standardizing the actual risk associated with policies and NIST controls*

Historically, organizations should develop policies and standards to help the organization frame their own cybersecurity stance. The NIST Cybersecurity Framework [35] (the NIST CSF Tool is seen in **Figure 9**) is one useful guide for developing an organizational cybersecurity posture and policies/standards.

The category in **Figure 8**, risk assessment library for the NIST controls, is relevant to mapping mitigating controls to well-known NIST vendor agnostic controls. NIST regularly updates the NIST SP 800–30 [14] to account for industry trends.

#### *5.2.4 Standardizing the actual risk to HIPAA requirements*

As Security and Privacy Rules of HIPAA are major and enforceable regulatory legislation in the United States, the related column in the library connects the findings to potential HIPAA regulations. This mapping informs the risk-management process when required regulatory elements are entirely missing or are in jeopardy.

#### *5.2.5 Standardizing the actual risk to other industry-specific regulations*

Other regulations, such as PCI compliance [27], The Sarbanes-Oxley Act (SOX) of 2002 [36], FTC requirements, service-level agreements (SLAs), state data breach laws [29], and research non-disclosure agreements, can also play their roles in risk


#### **Figure 9.**

*NIST cybersecurity framework reference tool [35].*

management. For example, SOX "is mandatory. ALL organizations, large and small, MUST comply [36]." Organizations allowing customers to pay with credit cards may directly or indirectly be under PCI compliance. The column *other-related-legal* provides benchmark connections to other generic requirements from these related regulations.

### *5.2.6 Standardizing the actual budget to estimate breach-associated costs*

The column on *budget* provides approximate figures for breach and regulation violation ramifications. For example, in 2019, Facebook [37] famously announced a proactive budget appropriation of \$3B with futuristic plans to pay off financial penalties related to regulatory breaches. Surprisingly, in some recent healthcare insurance cases, insurance companies have denied financial payouts for healthcare entity victims for malware-related concerns under "Act of Nature" clauses. Such cases of significant financial losses, where healthcare entities are "on their own" for financially responding to the subsequent effects of the malware or breach, can possibly lead to the healthcare entity's going out of business.

## **5.3 Performance metrics for an assessment risk framework library**

There do exist libraries for software development concerns and known vulnerabilities such as the NIST NVD, NIST Bug Framework, and MITER's CWE. They assess their performance. MITER provides an analysis of how the library can be used by stakeholders; however, no formal assessment methodologies exist. Assessing a library framework for performance would be like trying to assess the performance of a spoken language. MITER [38] currently lists the following stakeholders of their weakness enumeration (i.e., framework or library): assessment vendors and customers, software developers and, customers, academic researchers, applied vulnerability researchers, refined vulnerability information (RVI) providers, educators, and specialized communities.

According to Schmeelk [26], the library is currently prototyped as a spreadsheet, similarly to the NIST Cybersecurity Framework Reference Tool spreadsheet representation [35]. Currently, each sheet of the spreadsheet refers to specific domains of findings that can be identified during a risk-assessment process. For example, weakness in the physical, technical, or administrative security requirements would each fall on different spreadsheet pages. In addition, each of these three domains can be further broken into subdomains.

*Risk in Healthcare Information Technology: Creating a Standardized Risk Assessment Framework DOI: http://dx.doi.org/10.5772/intechopen.96456*
