Managing risk is an everyday occurrence for most people. We manage risk of theft or home intrusion by setting an alarm system or locking the door when we leave our homes. We plan for natural disasters (e.g., hurricane fire, etc) by storing important documents in a safe or safety deposit box and stocking extra food and water. However, personal (or family) risk management is usually an ad hoc process with no preset structure (e.g., a document or requirement specification) for how risks are to be managed.
Organizations and companies also manage risk, but often on a larger and more complex scale as compared to individualized risk. Organizational risks include financial issues (e.g., the price of oil spiking), environmental issues (how to respond to a tornado warning), accidents (a misrouted sales purchase), deliberate attacks (a computer security breach), legal issues (complying with various taxes, regulations, and laws), and many more.
In addition to managing risks, organizations are also generally concerned with governance and compliance issues. Governance is the ability to ensure that reliable and accurate information is given to the correct people within an organization (e.g., senior level executives). Compliance is how a company complies with the legal, statutory, contractual, etc. issues that affect the company. Taken together governance, risk management, and compliance (GRC) are of central concern to how organizations (e.g., publically traded companies) operate. Given the importance of these areas, computerized solutions have been developed to assist in addressing the problems present in these areas.
Computer-based GRC solutions provide functionality to model risk structures (e.g., create a risk model) that are used by organizations to manage their risk. Generally speaking, risk structures (or models) include three separate model elements: (1) object elements; (2) risk elements; and (3) control elements. With these three elements, a risk model can model risks that are associated with (1) objects (e.g., business processes and objectives, IT assets, financial information, projects, etc) and how the (2) risks (e.g., what could go wrong) for those objects are to be mitigated or (3) controlled.
With this basic understanding of how a risk model can be created, a set of requirements, called a meta-model, are defined to ensure that all risk models are appropriately created. Specifically, a meta-model provides a defined structure from which a model is created. For example, the definitions in the meta-model may prevent controls from being directly associated with IT assets and instead require all IT assets to have an associated risk. Without this type of underlying structural requirement, it may be difficult to successfully conduct audits, run risk assessments, or do required tasks such as risk reporting because there are no verifiable rules regarding how each model was initially created.
However, fixed meta-models are also problematic for organizations because they can be difficult to change once defined. In particular, a programmer or other technical person may be needed to adjust the meta-model. When the technical complexity of modifying a meta-model is combined with an initially provided general meta-model (e.g., one that is not specific to any one organization) it may be difficult for an organization to properly define more specific/complex risk models. In other words, organizations may purchase or be provided with a generic meta-model that can be used to model their specific risk structures. However, the resulting risk structures may be lacking in terms of complexity and/or specificity because the provided meta-model is generic (e.g., particular scenarios of the organization may not be modeled correctly in a resulting risk structure).
For example, risks and controls may have relations to multiple other model elements (e.g. a risk of business process, a first object model element, may also impact a business objective, a second object model element, or may have a relation to an IT asset, a third object model element), such that certain relationships are no longer easily supported by the object-risk-control relationships that are defined in an associated fixed or base meta-model. However, an organization may desire to distinguish between different types of mitigating measures—e.g., controls, risk measures, policies, where each one of these elements needs to be documented differently at different levels of detail. It may also be necessary to distinguish between different risk types and/or differentiate between abstraction levels—e.g., operational risks may require more detail than strategic risks. Modeling these types of aspects with a fixed meta-model approach can be difficult because one cannot differentiate between, for example, multiple control elements such as risk measures and policies.
An alternative to the fixed meta-model approach is a completely custom solution. However, while a custom solution may better define the needs of an individual organization, there are downsides to this approach. For example, custom systems are typically very expensive (more so than the fixed systems) as a dedicated team is needed to first implement the base meta-model and it's associated supporting infrastructure (e.g., how to create a model from the meta-model). Accordingly, the total cost of ownership of such a system is relatively high because upgrading the system for future releases (e.g., that include changes to the meta-model) may require re-customization and adaptation of previous customizations. This may make it difficult to successfully upgrade systems to future releases. Further, when modifying a customized system (e.g., adjusting a previously developed meta-model), hard-coded changes may be needed that may be affect the entire system. In other words, models in the system that have been created with a prior meta-model may be adversely affected by these changes. An additional consideration is that while organizations may be knowledgeable about their own risks, they may also have trouble correctly modeling such risks in a manner that provides effective audits, risk assessments, and risk reporting, etc. (e.g., risk modeling and setup may require specialized knowledge).
In view of these and other problems, there is a need for technical improvements in this field so that organizations can fit specific processes, risks, controls, etc into a workable and flexible environment that provides the benefits of a GRC system. In other words, a GRC system is needed that while providing some defined structure in terms of a meta-model also allows implementation of organization specific risk models.
USPTO Backgrounds
USPTO Backgrounds