The hidden part of the risk iceberg

The cost of security incident can be significant but it’s not the loss of the asset that is the main contributer but the indirect costs that come with a security incident.

This morning I read about another security incident. This time about the one Marriot, a world spanning hotel chain that lost their customers data, has had. The media report enumerated different costs the incident implied. There was some talk about the compensation each victim got, about the fines the organization may expect, the reaction of the markets that negatively influenced the share price, about the recovery costs they had and finally about the assets they have lost and how much they were worth. The (sadly) interesting part was that the actual damage to the asset was almost insignificant in comparison to the rest. I was reminded of a scientific article I wrote almost 15 years ago about how to estimate the consequences of security risks. When looking at incidents that went public – Maersk, Facebook, Equifax – but also incidents I had worked with the last years I find that my scientific analysis held very well in practice. The cost of security incident can be significant but it’s not the loss of the asset that bothers anyone.

Unfortunately, a lot of organizations perform security risk analysis – following ISO 27005 in a very literal way – still by means of:

  1. Define the asset and its value – you may call this information classification
  2. Define the damage the asset suffers
  3. Define a probability that this happens
  4. Calculate risk

It should not come as a big surprise that this process delivers results that are not very valuable for the risk decision making. Or more bluntly said that usually convey the wrong picture. Consequently, and many times to the surprise of security people, most people do not really react at those risks and never feel a sense of relevance or urgency.

We should learn from the actual incidents to represent the security risks. As the asset is hardly of any consequence and we should put the focus somewhere else. It seems reasonable to start the security risk analysis process by looking into “unpleasant” events, caused by security failures, that have a negative impact. We could, as in disaster recovery planning, start from several scenarios that describe the valuable process of the organization and correlate them with the goals for security to keep information secret, correct, available, reliable …. Those scenarios that compromise these goals are worth investigating further. Typical examples would be corruption of customer information, information leak of proprietary information, availability loss of production management, inability to pay invoices and similar.

Based on those scenarios we should continue quantifying how much damage would the organization face. Looking into the systematics of incidents it appears reasonable to describe the damage in four categories. The data suggest that the amount follows a pyramid shape where damage to reputation is highest, followed by liability and fines, correction costs and finally direct damage (caused during the incident). Some examples can be found in the enclosed table. This will automatically rank the scenarios and we can, starting from the top, defining safeguards until we can live with the caused damage (or when the damage is less than the correction costs).





Reputation damage

Marketing efforts
Customer support

Loss of business

Stock price
Market position
Brand value

Liabilities and fines

Supervision case
Internal audit

Supervisions audit
External audit
Court case

Legal efforts

Correction cost

Investigation costs

Data recovery, Security investments, Incident management

Loss of production
Business recovery

Direct damage

Equipment damage

Data leakage
Data loss

Business data integrity

It would be bold of me to claim that there are no challenges. I have experienced that it is for example a bit more difficult to find safeguards, it takes some experience to identify the most valuable business processes to investigate, that there is an argument with the auditor because we do it not according to the “book” and similar. While those pose a challenge, I have found that they can be overcome. My experience is that there is a significant advantage by formulating security risks this way as more people can intuitively understand the risk and react appropriately.