**5.4 Benefits from a standardized risk-assessment framework library**

Currently organizations are developing their own personal language for describing risk. In fact, many risk assessors within the organizations can actually employ their own personal language. When third-party audits and internal audits transpire, there is no way to assess the risk across the risk-assessment reports. For example, one risk-assessor employee could identify a vulnerability as cross-site scripting; whereas, another may document an XSS vulnerability. If the risk has been described differently by all employees, it becomes impossible to identify how many cross-site scripting vulnerabilities really exist within the organization. Hence, the meta-analysis of risk is entirely flawed. As such, it will be improperly conveyed to insurance companies and third-party auditors. Currently, the only way to develop a unified understanding of the risk is to first develop ontologies of potential words used to describe the risk. Then, perhaps aggregate meta-statistics about the organization can be developed by using natural language processing methods on the written reports. For example, modern natural language processing methods would need to take place on penetration tests to evaluate assessment reports among different assessors, each applying different methodologies and terminologies. As such, most insurance companies and third-party auditors are taking large chances on organizations who really do not understand their own cybersecurity concerns.

#### **5.5 Improvements made by introducing a standardized risk library**

Currently, there are no other relevant approaches where the risk language is standardized other than the vulnerability language frameworks of MITER and NIST. This lack of standardized risk language remains a major gap in risk analysis. Schmeelk [26] reports on an analysis for the prototype risk library and connects the library to New York State (NYS) Information Technology Security (ITS) Policies [39]. Standardizing the language used during risk assessments is essential for both internal and external factors. First, if a risk-related case ever goes to court, the phrasing of the risk could play a role in the court verdict. For example, if a business chooses to accept a finding where "unauthorized access" was identified during a risk assessment, the organization may be responsible for accepting the risk. Second, when an organization whose assessments have been written using any plethora of words is trying to collect internal metrics, characterizing the current state of cybersecurity within the organization is nearly impossible. This would be a useful application for Natural Language Processing (NLP), trying to characterize quantitatively exact numbers of password violations, XSS, SQL injection, and other findings. Without standardization, knowing at any time an organizational stance on cybersecurity becomes next to impossible. In addition, remediation efforts and risk mitigation efforts are significantly hindered by text-based risk assessments which do not conform to standards. Lastly, if every organization's employees compose/compile/develop their own libraries, there will be no way to properly coordinate with insurance companies for breach budgeting. Sadly, without any standardization or proper planning, organizations may learn "the hard way" that they are entirely financially responsible for cleaning up a major data breach or ransomware attack.

#### **5.6 Industry concerns addressed by a standardized risk library**

The United States and the world are adopting, either explicitly or implicitly, technology-related risk at an unprecedented rate. In addition, regulations are being adopted across the world at an equally unprecedented rate. In fact, each of the 50 United States and "the District of Columbia, Guam, Puerto Rico and the Virgin Islands have enacted legislation requiring private or governmental entities to notify individuals of security breaches of information involving personally identifiable information [29]." Each state law is potentially different from the other state laws, further complicating situations involving out-of-state patients. Most organizations have adopted Integrated Risk Management (IRM) solutions, but many of these solutions require extreme customization from clients. In addition, not everyone in the organization has an overall "view" of the organizational risks. Since Information Systems (IS) trends remain in silos [40], coordinating risk among the different healthcare departments and all the IS sectors is difficult. In addition, entities within an organization that sign off on risk, typically referred to as system owners, may find an imbalance on the risk they must accept on the behalf of the business. Then, as system owners leave or retire from an organization, subsequent new hires may not fully understand the risks inherited with their positions. In fact, new hires in security high-level positions often ask the organization for audits prior to taking, or during the first year of, a new job. That way they can benchmark the inherited risks.
