Governance of data-zeroes and ones.jpg Getty Images

Effective Governance of Data Requires Understanding of Risk Relevance

Here's how to develop a "risk relevance" matrix that helps optimize the governance of data in your organization.

My previous article about information risk awareness introduced some terminology for describing and analyzing information risk, as well as concepts such as information management vulnerabilities that can be exploited (either on purpose or inadvertently) with negative consequences to the organization. Effective governance of data and information risk management require discipline in specification: identifying and organizing the different types of data vulnerabilities, determining the threats that can exploit those weaknesses, understanding the scope of the consequences, and assessing the probability that a threat will take place and--if it does--assessing the probability that there will be consequences.

You might think that the best approach would be enumerating the different vulnerabilities and then working from there to consider how those vulnerabilities can be exploited. And, in fact, there are some published guidelines and practices that suggest surveying your organization to assess, describe, and categorize risks as a prelude to developing controls and monitoring for information risk events.

Yet, that approach may not be the most practical to take if your information risk management framework is to be aligned with resource allocation and preventative controls. One immediate challenge is that the domain of potential risks is expansive, and one can survey an entire enterprise of data assets and consider the risks before any substantive vulnerabilities are revealed.

Perhaps it might be better to initially focus on the collection of what we might call “relevant” risks--those that have both a high-magnitude negative consequence and a high probability of occurrence. For example, let’s examine the information risk domain of data loss, and look at the vulnerabilities, potential threats and consequences of some use case scenarios. We’ll then consider the probabilities associated with those use cases. 

Let’s start with a working definition of “data loss” as a situation in which the information presumed to be encapsulated within a data asset is no longer accessible. We can identify and categorize a number of reasons that data sets are lost, which helps to identify the potential vulnerabilities:

Accidental

  • Accidental data deletion: Data is accidentally deleted, either by a human or by an automated process.
  • Accidental loss of key: The key to a deliberately encrypted data asset is lost.

Machine Failure

  • Mechanical environmental failure: There was a failure during a process writing data to a storage location (for example, a power failure in the middle of outputting a data set).
  • Data exchange failure: There was a failure during data transmission/exchange, such as a loss of internet connectivity in the middle of a transmission.
  • Physical asset failure: The physical asset containing the data experienced a failure, such as a hard disk crash.
  • Asset damage: The physical asset containing the data is inadvertently damaged, such as an SD card getting bent or cracked.

Software failure

  • Software-based corruption: There is damage to or corruption of electronic data assets due to software failure.

Asset misplacement

  • Misplacement: The physical asset containing the data is misplaced, such as a missing data tape that was not archived properly.
  • Loss: The physical asset containing the data is lost, such as a portable hard drive falling out of a box when moved.

Technology obsolescence

  • Missing devices: The data asset is stored in a medium that can no longer be read because there are no devices available that are capable of reading the medium.
  • Deterioration: The storage medium has deteriorated to the point that it cannot be read.

Malicious events

  • Machine damage: The physical asset containing the data is maliciously damaged.
  • Theft: The physical asset containing data is stolen.
  • Malicious encryption: A data asset is maliciously encrypted, such as a cyber-attack via ransomware.
  • Malicious deletion: A data asset is maliciously deleted, such as a deletion that occurs when a ransom is not paid.

At the same time, we can consider the different costs associated with data loss, such as:

  • Recovery, or the costs associated with identifying the loss and restoring from backup
  • Revenue disruption, or the inability to continue taking orders and making sales
  • Operational disruption/downtime, or the inability to operate production facilities
  • Inherent value of the data, such as the costs of acquisition or intellectual property
  • Reputational damage associated with negative perception of the organization’s levels of trust

These cost categories help to identify the scale of potential negative consequences associated with a risk of data loss for any particular data asset. For example, an archive containing corporate documents including intellectual property may rate a higher “inherent value” consequence than an “operational downtime” consequence. On the other hand, loss of customer data may rate a high “revenue disruption” consequence.

At this point, one can assemble a risk matrix associated with any specific data domain or data asset, with the vulnerabilities along one axis and the consequences along the other axis.

The first step is to inventory the data assets and prioritize in terms of relevance. For example, customer data is highly relevant, but a copy of a spreadsheet with an expense report might not be highly relevant.

Set a threshold for a level of relevance and for all data assets above that threshold, and estimate the costs associated with loss, vulnerabilities and probabilities that those vulnerabilities can be exploited. In many cases, this categorization and analysis process will not only help reduce the complexity of surveying and assessing risks, but it can also help point you to the preventative measures that can be taken to minimize information risk.

 

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish