Risk and Compliance Management


Risk and compliance are grouped together in this Competency Category as they are often managed by unified functional areas or capabilities (e.g., “Corporate Risk and Compliance”). Note, however, that they are two distinct concerns, to be outlined below.

Risk Management Fundamentals

Risk is defined as the possibility that an event will occur and adversely affect the achievement of objectives. [COSO 2017]
— Committee of Sponsoring Organizations of the Treadway Commission
Internal Control – Integrated Framework

Risk is a fundamental concern of governance. Management (as we have defined it in this Competency Category) may focus on effectiveness and efficiency well enough, but too often disregards risk.

As we noted above, the shop manager may have incentives to maximize income but, usually, does not stand to lose their life savings. The owner, however, does. Fire, theft, disaster – without risk management, the owner does not sleep well.

For this reason, risk management is a large element of governance, as indicated by the popular GRC acronym: Governance, Risk Management, and Compliance.

Defining “Risk”

The definition of “risk” is surprisingly controversial. The ISO 31000 standard [ISO 31000] and the PMI [PMBOK 2013] both define risk as including positive outcomes (benefits). This definition has been strongly criticized by (among others) Douglas Hubbard in The Failure of Risk Management: Why It’s Broken and How To Fix It [Hubbard 2009]. Hubbard points out that, traditionally, risk has meant the chance and consequences of loss.

As this is an an overview text, we will use the more pragmatic, historical definition. Practically speaking, operational risk management as a function focuses on loss. The possibility (“risk”) of benefits is eagerly sought by the organization as a whole and does not need “management” by a dedicated function.

“Loss”, however, can also equate to “failure to achieve anticipated gains”. This form of risk applies, for example, to product and project investments.

Risk management can be seen as both a function and a process; see Risk Management Context. As a function, it may be managed by a dedicated organization (perhaps called Enterprise Risk Management or Operational Risk Management). As a process, it conducts the following activities:

  • Identifying risks

  • Assessing and prioritizing them

  • Coordinating effective responses to risks

  • Ongoing monitoring and reporting of risk management

Risk impacts some asset. Examples in the digital and IT context would include:

  • Operational IT systems

  • Hardware (e.g., computers) and facilities (e.g., data centers)

  • Information (customer or patient records)

It is commonly said that organizations have an “appetite” for risk [ISACA 2013] in terms of the amount of risk the organization is willing to accept. This is a strategic decision, usually reserved for organizational governance.

risk context
Figure 1. Risk Management Context

Risk management typically has strong relationships with the following organizational capabilities:

  • Enterprise governance (e.g., Board-level committees)

  • Security

  • Compliance

  • Audit

  • Policy management

For example, security requires risk assessment as an input, so that security resources focus on the correct priorities. Risk additionally may interact with:

  • Project management

  • Asset management

  • Processes such as change management

and other digital activities. More detail on core risk management activities follows, largely adopted from the COBIT 5 for Risk publication [ISACA2013].

Risk Identification

There are a wide variety of potential risks, and many accounts and anecdotes are constantly circulating. It is critical that risk identification begins with a firm understanding of the organization’s objectives and context.

Risk identification can occur both in a “top-down” and “bottom-up” manner. Industry guidance can assist the operational risk management function in identifying typical risks. For example, the COBIT 5 for Risk publication includes a useful eight-page “Generic Risk Scenarios” section [ISACA2013] to identify risks such as:

  • “Wrong programs are selected for implementation and are misaligned with corporate strategy and priorities”

  • “There is an earthquake”

  • “Sensitive data is lost/disclosed through logical attacks”

These are only three of dozens of scenarios. Risks, of course, extend over a wide variety of areas:

  • Investment

  • Sourcing

  • Operations

  • Availability

  • Continuity

  • Security

and so forth. The same guidance also strongly cautions against over-reliance on these generic scenarios.

Risk Assessment

Risk management has a variety of concepts and techniques both qualitative and quantitative. Risk is often assumed to be the product of probability times impact. For example, if the chance of a fire in a facility is 5% over a given year, and the damage of the fire is estimated at $100,000, the annual risk is $5,000. An enterprise risk management function may attempt to quantify all such risks into an overall portfolio.

Where quantitative approaches are perceived to be difficult, risk may be assessed using simple ordinal scales (e.g., 1 to 5, where 1 is low risk, and 5 is high risk). COBIT 5 for Risk expresses concern regarding “the use of ordinal scales for expressing risk in different categories, and the mathematical difficulties or dangers of using these numbers to do any sort of calculation” [ISACA 2013]. Such approaches are criticized by Doug Hubbard in The Failure of Risk Management: Why It’s Broken and How To Fix It as misleading and potentially more harmful than not managing risk at all [Hubbard 2009].

Hubbard instead suggests that quantitative techniques such as Monte Carlo analysis are rarely infeasible, and recommends their application instead of subjective scales.

The enterprise can also consider evaluating scenarios that have a chance of occurring simultaneously. This is frequently referred to as “stress” testing.

Risk Response

He who fights and runs away lives to fight another day.
— Menander
342 BC – 291 BC

Risk response includes several approaches:

  • Avoidance

  • Acceptance

  • Transference

  • Mitigation

Avoidance means ending the activities or conditions causing the risk; e.g., not engaging in a given initiative or moving operations away from risk factors.

Acceptance means no action is taken. Typically, such “acceptance” must reside with an executive.

Transference means that some sharing arrangement, usually involving financial consideration, is established. Common transfer mechanisms include outsourcing and insurance. (Recall our discussion of Agile approaches to contract management and risk sharing.)

Mitigation means that some compensating mechanism – one or more “controls” is established. This topic is covered in the next section and comprises the remainder of the material on risk management.

(The above discussion was largely derived from the ISACA COBIT 5 framework for Risk [ISACA 2013b]).


The term "control objective" is no longer a mainstream term used in COBIT 5, and the word "control" is used only rarely. Instead, COBIT 5 uses the concepts of process practices and process activities. [ISACA 2013a]
COBIT 5 for Assurance

The term “control” is problematic.

It has distasteful connotations to those who casually encounter it, evoking images of “command and control” management, or “controlling” personalities. COBIT, which once stood for Control Objectives for IT, now deprecates the term control (see the above quote). Yet it retains a prominent role in many discussions of enterprise governance and risk management, as we saw at the start of this Competency Category in the discussion of COSO’s general concept of control. Also (as discussed in our coverage of Scrum’s origins) it is a technical term of art in systems engineering. As such it represents principles essential to understanding large-scale digital organizations.

In this section, we are concerned with controls in a narrower sense, as risk mitigators. Governance elements such as policies, procedures, organizational structures, and the rest are used and intended to ensure that:

  • Investments achieve their intended outcomes

  • Resources are used responsibly, and protected from fraud, theft, abuse, waste, and mismanagement

  • Laws and regulations are adhered to

  • Timely and reliable information is employed for decision-making

But what are examples of “controls”? Take a risk, such as the risk of a service (e.g., e-commerce website) outage resulting in loss of critical revenues. There are a number of ways we might attempt to mitigate this risk:

  • Configuration management (a preventative control)

  • Effective monitoring of system alerts (a detective control)

  • Documented operational responses to detected issues (a corrective control)

  • Clear recovery protocols that are practiced and well understood (a recovery control)

  • System redundancy of key components where appropriate (a compensating control)

and so forth. Another kind of control appropriate to other risks is deterrent (e.g., an armed guard at a bank).

Other types of frequently seen controls include:

  • Separation of duties

  • Audit trails

  • Documentation

  • Standards and guidelines

A control type such as “separation of duties” is very general and might be specified by activity type; for example:

  • Purchasing

  • System development and release

  • Sales revenue recognition

Each of these would require distinct approaches to separation of duties. Some of this may be explicitly defined; if there is no policy or control specific to a given activity, an auditor may identify this as a deficiency.

Policies and processes in their aspect as controls are often what auditors test. In the case of the website above, an auditor might test the configuration management approach, the operational processes, inspect the system redundancy, and so forth. And risk management would maintain an ongoing interest in the system in between audits.

As with most topics in this document, risk management (in and of itself, as well as applied to IT and digital) is an extensive and complex domain, and this discussion was necessarily brief.

Business Continuity

Business continuity is an applied domain of digital and IT risk, like security. Continuity is concerned with large-scale disruptions to organizational operations, such as:

  • Floods

  • Earthquakes

  • Tornadoes

  • Terrorism

  • Hurricanes

  • Industrial catastrophes (e.g., large-scale chemical spills)

A distinction is commonly made between:

  • Business continuity planning

  • Disaster recovery

Disaster recovery is more tactical, including the specific actions taken during the disaster to mitigate damage and restore operations, and often with an IT-specific emphasis.

Continuity planning takes a longer-term view of matters such as long-term availability of replacement space and computing capacity.

There are a variety of standards covering business continuity planning, including:

In general, continuity planning starts with understanding the business impact of various disaster scenarios and developing plans to counter them. Traditional guidance suggests that this should be achieved in a centralized fashion; however, large, centralized efforts of this nature tend to struggle for funding.

While automation alone cannot solve problems such as “where do we put the people if our main call center is destroyed”, it can help considerably in terms of recovering from disasters. If a company has been diligent in applying Infrastructure as Code techniques, and loses its data center, it can theoretically re-establish its system configurations readily, which can otherwise be a very challenging process, especially under time constraints. (Data still needs to have been backed up to multiple locations.)


Compliance is a very general term meaning conformity or adherence to; for example:

  • Laws

  • Regulations

  • Policies

  • Contracts

  • Standards

Corporate compliance functions may first be attentive to legal and regulatory compliance, but the other forms of compliance are matters of concern as well.

A corporate compliance office may be responsible for the maintenance of organizational policies and related training and education, perhaps in partnership with the human resources department. They also may monitor and report on the state of organizational compliance. Compliance offices may also be responsible for codes of ethics. Finally, they may manage channels for anonymous reporting of ethics and policy violations by whistleblowers (individuals who become aware of and wish to report violations while receiving guarantees of protection from retaliation).

Compliance uses techniques similar to risk management and, in fact, non-compliance can be managed as a form of risk, and prioritized and handled much the same way. However, compliance is an information problem as well as a risk problem. There is an ongoing stream of regulations to track, which keeps compliance professionals very busy. In the US alone, these include:


  • SOX

  • Family Educational Rights and Privacy Act (FERPA)

  • PCI Deliver, Service, and Support (DSS)

  • Gramm-Leach-Bliley Act (GLBA) Personally Identifiable Information (PII)

and in the European Union, the Global Data Protection Regulation (GDPR) and various data sovereignty regulations (e.g., German human resources data must remain in Germany).

Some of these regulations specifically call for policy management, and therefore companies that are subject to them may need to institute formal governance earlier than other companies, in terms of the emergence model. Many of them provide penalties for the mismanagement of data, which we will discuss further in this Competency Area and in Competency Area 11. Compliance also includes compliance with the courts (e.g., civil and criminal actions). This will be discussed in the Competency Area 11 section on cyberlaw.

Evidence of Notability

Risk is a fundamental business concern, along with sales and net profits. The entire insurance industry is founded on the premise of risk management. Digital systems are subject to certain risks, and in turn present risks to the organizations that depend on them.


Risk is difficult – but not impossible – to quantify. When risk is not correctly quantified, it can lead to dysfunctional organizational behavior; e.g., spending disproportionate resources to mitigate a given risk. The irony (poorly understood by many risk professionals) is that overly elaborate risk mitigation approaches can themselves be a source of risk, in their imposition of delays and other burdens on the delivery of value.

Related Topics