# Keep it simple: how to avoid drowning in cyber risk information

## Risk managers should feed each level of the company only the risk information it needs

Jack Freund is senior manager, cyber risk framework at TIAA.

A solid operational risk management programme must involve integration of activities between the first, second and third lines of defence. But too often the focus is on separating these duties instead – meeting the letter if not the spirit of the model, and harming efforts to monitor and manage operational risks. In cyber risk, in particular, such cursory first-line risk management practices are not sufficient.

### Asset-level risk assessments

When conducting technology risk assessments, one’s first thought might be to enter everything that is discovered into an enterprise risk register. But there are typically a very large number of things in IT that need fixing and placing all of them in an enterprise issue register is rarely productive. Successful integration of a second-line operational risk management framework and a cyber risk framework depends on maintaining parity; the level of detail that is being unearthed at the technology layer should be at the same level of decomposition as at the other parts of your business. This kind of mismatched reporting makes it difficult to make good comparisons of key risk indicators and key performance indicators and would create lopsided issue finding and reporting.

In order to maintain parity with the rest of the organisation, a solid risk taxonomy is essential.

But because that detailed data is also valuable, it is critical to consider maintaining separate registers and issues lists for IT and the rest of the business. These registers will be integrated using the taxonomy strategy outlined below.

The first question to address is: what form should the entries in the IT risk register take? Far too often, important risk terminology gets confused when discussing technology risk. Basic concepts such as risk, threat and vulnerability are frequently used interchangeably (especially within IT departments). The IT risk register should focus on statements of the loss or damage the organisation would incur under a given scenario. A risk statement that begins with “Lack of…” or “Missing…” is really describing a control that should be in place and does not identify the risk that will befall the organisation. For technology risk, these risk statements typically relate to losses associated with the failure to maintain the confidentiality, integrity or availability of data (the so-called CIA triad). A full risk syntax for IT would look something like this:

<Threat> <Event><Asset> to cause <Impact>

An example of this in practice could be:

Cyber criminals attacking customer databases to cause confidentiality loss

### Taxonomy and depth

When creating risk taxonomies for your technology risk concerns, they should focus on the major CIA triad impacts, and decompose events at the lower levels in an IT risk register. The overarching idea is that we want to illustrate big picture cyber risk for the board and senior leadership, but have supporting risks at the lowest level that allow granular risk management and assignment of controls.

For example, if we list the following risk scenarios in a board-level report, we risk bogging down discussions with minutiae that are irrelevant to their management goals:

• Cyber criminals use ransomware to infect general ledger application resulting in missed regulatory filings
• Malicious insider destroys data in general ledger application resulting in missed regulatory filings
• Cyber criminals manipulate data in general ledger application causing integrity issues with regulatory filings
• Malicious insider manipulates data in general ledger application causing integrity issues with regulatory filings

There are clearly many actors who have many ways to achieve their malicious goals, and these are important to cyber security professionals. For instance, the controls we would use to protect against and repel ransomware differ from those that we would use to prevent insider attacks. That distinction is too fine-grained for high level reporting, so risk register items that might appear in an enterprise risk register could look like this:

• Unavailability of critical accounting applications
• Compromised integrity of critical accounting applications

But even that may be too granular for certain levels of reporting. When building a risk reporting hierarchy, it’s always critical to consider the organisational level to which the taxonomy levels correlate. A typical reporting hierarchy that you might employ could look like this:

• Level 0 - CEO/Board of directors
• Level 1 - Chief information officer (CIO)
• Level 2 - Chief information security officer (CISO)
• Level 3 - IT CRO/Head of IT risk

Your level of decomposition will naturally vary as your reporting lines may differ. At each layer of decomposition, you introduce additional layers of detail about the scenarios, and directly address information risk issues that are the most concerning to the leadership at the corresponding level.

For instance, at the CEO/Board level, questions you might be posed include the following:

• Are we keeping our customers’ information safe?
• Are we protecting our customers’ money?
• Are we complying with rules and regulation?
• Will our systems be there when our customers need us?

These can be expanded depending on your specific business (financial institutions may want to add “Are we managing our customers’ money well?” to the list). As a result of considering these questions, we have the first level of decomposition in our risk hierarchy:

• Safeguard our customers’ data
• Safeguard our customers’ money
• Comply with regulations
• Be available for our customers

#### 7 days in 60 seconds

###### Compounding, venue disrupters and the Fed’s stress buffer

The week on Risk.net, January 11–17, 2020