GRC Fundamental Component: Risk Ontology

At the heart of GRC is adopting a coordinated, coherent approach to risk management across the organization, and core to that objective is developing and adopting a risk ontology.

What is Risk Ontology?
In the information sciences, ontology “formally represents knowledge as a set of concepts within a domain, and the relationships between those concepts. It can be used to reason about the entities within that domain, and may be used to describe the domain”.
Some people think of ontologies as simply a nomenclature – but an ontology is much more than a shared index, vocabulary or taxonomy.  A Risk Ontology, for example, would include a model with the definition of objects and concepts, and how they relate to one another.  It would include rules about how concepts interact, and provide a basis for calculations and analytics.  It would provide a basis for establishing consensus on the meaning of risk terms, and a model that explains their use.
Organizations manage risk by identifying it, analyzing it and then evaluating whether the risk should be modified by risk treatment in order to satisfy their risk criteria – those concepts, and definitions of risk criteria – most importantly appetites, thresholds, rating schemes – can be part of a risk ontology shared by everyone.

Why do we need Risk Ontology?
We need Risk Ontologies to provide a basis for coordinating risk across the many activities in an organization:

• Since all activities across an organization involve risk, a Risk Ontology can be consistently applied to an entire organization, at its many functions, projects and activities
• While no single definition of risk exists, adoption of consistent concepts within a comprehensive framework can help organizations can improve visibility into the true risk profile
• Risk Onotologies can help organizations establish governance and manage risk more effectively, efficiently and coherently across an organization and externally with 3rd parties
• Risk Ontologies can support variations of approaches, definition of threats and risk criteria across internal organization functions, partners and customers
• Risk Ontologies are essential for driving value out of GRC technology platforms and enabling tools; they are only as good as the underlying frameworks, processes, and ontologies that define their use.

What does Risk Ontology contain?

A complete Risk Ontology would contain:

• Objects: These are the basic ‘objects’ – a person or thing found across your organization – for example, an object may be a person – a risk or control owner, or technical steward. Or on object may be an specific risk determined by applying risk criteria to potential events and consequences: a MEDIUM risk exists that intellectual property associated with the Aurora Project will leak from the Sharepoint site due to absence of data loss prevention policy and controls.
• Classes: These are concepts or types of objects – for example, reputation risk, strategic risk, financial risk, security risk, technology risk, health and safety risk, and so on. A very important class is the Risk Register – a list of all risks of importance to the organization. Classes might also include role, process, information, policy, control, asset, threat, vulnerability, and impact or treatment types.
• Attributes:  These are aspects, properties, features, characteristics, or parameters that objects (and classes) can have – for example, risk criteria such as a risk source, or criteria such as appetite, or a consequences such as a likelihood or impact rating.
• Relations: These are ways in which classes and individuals can be related to one another - for example, a threat source has a relationship to specific vulnerabilities.
• Function terms: These are complex structures formed from certain relations that can be used in place of an individual term in a statement – such as a risk equation, R = Likelihood x Impact, or R = Severity x Frequency.
• Rules:  These are statements in the form of an if-then (antecedent-consequent) sentence that describe the logical inferences that can be drawn from an assertion in a particular form – for example, if a regulation xyz applies to our operations in country, we must abide by it.  Or, as a specific output of a risk equation, rules may look like earthquake strikes our California operations there is a high likelihood that our mission critical processes for order to cash will be impacted for 3-5 days at a cost of $1m revenue per day. 
• Events: These are the changing of attributes or relation – for example, geo-political events effecting the threat landscape, economic indicators, exchange or interest rates.

How Do I start to create one?
Use your governance structures and processes to help you with developing a strong Risk Ontology, which may take many months to fully complete. Start with the very basics and work outwards from there. It takes real collaborative work, but you really can’t get to value-based GRC without it.  Set up working sub­committees of your Risk Councils to get the right people involved with this important work. Some of the core questions that have to be addressed are below. Over upcoming posts we’ll go into more detail about practice models and best practices to leverage in doing this.

• How is risk defined and calculated in each business unit and for each discipline?
• How do you aggregate risk across activities?
• What best practice frameworks are being used now for enterprise or operational risk, compliance, legal, audit, privacy, IT, security or business resilience?
• What are the key entities, attributes, relationships & constraints for risk and compliance?
• What are the key risk sources, criteria and consequences for risk?
• What metrics are required by each stakeholder group?
• How will these metrics be shared/leveraged by other programs such as Operational Risk Management, Audit, Legal, Privacy and Enterprise Risk Management?