Norman Marks on Governance, Risk Management, and Internal Audit

Congratulations to NIST for recognizing that what matters is not risk to information assets, but risk to enterprise objectives. Or so it might seem at first glance when you read their draft Using Business Impact Analysis to Inform Risk Prioritization and Response.

But first, I want to thank and congratulate Matt Kelly, editor of Radical Compliance, for his summary of the NIST draft. (I recommend subscribing to his newsletter.)

A well-run business impact analysis (BIA) that involves multiple parties from the business as well as IT is absolutely essential.

In fact, a BIA should be mandatory and not just recommended. It helps management understand how a cyber event or other disaster might affect the business.

My only quibble with Matt’s analysis is that it is management’s responsibility to perform a BIA and then maintain it, and internal audit’s responsibility to ensure management has done so.

However, I have many quibbles, in some cases severe criticisms, of NIST.

But first, I want to share my experience with BIAs.

As a vice president in IT for a couple of financial institutions (and occasional acting CIO), my team was responsible not only for information security but also for both IT contingency planning and business resumption planning.

Data services can be lost or degraded as the result of multiple events, including:

• Fire
• Earthquake
• Floods
• Storms
• Power outages
• Network disruption
• Sabotage
• Military actions
• Cyber breaches (internal or external)
• System failures
• A plane crash (we were on the flight path into Burbank airport)
• …and more

We did what we could to be resilient in the face of all such threats. In many ways, it didn’t matter what caused the loss or disruption of services. What mattered was our ability to maintain, or at least recover affected services in an acceptable time.

Once we understood the risk, which was expressed in terms of the impact on the business and what it was trying to achieve (enterprise objectives), we could prioritize our efforts: people, tools, and so on.

We established a communications plan so we could bring the necessary parties together to respond, in addition to ensuring we had appropriate measures in place to limit the likelihood and the potential impact of an event.

The risk from a cyber breach is only one of the sources of risk that management needs to consider in running the business, including making both strategic and tactical decisions. (I discuss this extensively in Making Business Sense of Technology Risk.)

In addition, much of what the organization does to be resilient in the face of a cyber breach will also help them recover from potential fires or earthquakes, and vice versa.

Management’s approach to resilience should not be determined one threat at a time, but should consider all the likely threats and outcomes.

Do you want one team established to respond to a cyber breach and a totally separate one to respond to a power outage or a fire? That doesn’t sound very efficient to me, especially if they use different processes and tools.

But the more significant issue is how risk should inform decision-making.

Imagine that our company is considering opening a new business in Moldova. Executive management needs to consider:

• The forecast revenues for each of the first few years: the range of estimated levels of revenue and their likelihood.
• The forecast profits (also a range) for each of those years.
• The potential for the conflict in neighboring Ukraine to impact operations in Moldova.
• The potential effect of Moldova being granted candidate status for admission into the EU, with full membership following.
• The risk of non-compliance with local laws and regulations.
• The added cybersecurity risk to the company of an extension of the corporate network into Moldova.
• …and many other sources of risk, such as the ability to hire necessary management and staff.

The point is that cyber is just another source of risk to the business.

It should not be treated as if it is the only risk that matters. It needs to be put in context!

Yet NIST wants to put cybersecurity risk in a risk register!

The NIST Interagency or Internal Report (NISTIR) 8286 series has coalesced around the risk register as a construct for storing and a process for communicating risk data [NISTIR8286]. Another critical artifact of risk management that serves as both a construct and a means of communication with the risk register is the Business Impact Analysis (BIA) Register.  The BIA examines the potential impact associated with the loss or degradation of an enterprise’s technology-related assets based on a qualitative or quantitative assessment of the criticality and sensitivity of those assets and stores the results in the BIA Register.

What does this mean? In my humble opinion, NIST may have seen the value of a BIA but then destroys that value by continuing to talk about risk registers (that the rest of the world recognizes are a failed idea) and the value of information assets. They are addressing cyber in a silo, even separate from other IT disasters such as the low of power or the network.

My message to NIST: focus on the ability of the organization to achieve its objectives, which requires management to consider together all the more significant risks (positive and negative) that may affect them.

That requires assessing cyber-related risks in a way that enables aggregation with other sources of risk, such as compliance, safety, economic, supply-chain, etc., etc.

Assessing and prioritizing information assets is managing cyber in a silo.

I welcome your thoughts.