Cost cutting by process based risk analysis – Part 2
In Part 1 of this process based risk analysis approach I have described, how we rate the risk of the processes. Now we know which parts are potentially endangered – activities, sub processes and throwing events. In the second part of this article we will come towards the technical components affecting by a detailed view into these very activities.
Detailed view on activities
To achieve a better overview, now, we use our modelling software to generate a report over all activities that we have identified throughout the entire universe of our processes. A list in descending order based on the process risk is apparently useful. Thus, you will find the most risky activities at the top of the list. Let us start to analyse those in detail.
Click to enlarge: Report over endangered activities
As mentioned before, finally, we cannot protect processes themself but only technical components that are involved in those processes. We have to elaborate those technical things now. There are plenty of methodologies to do so. For example, either activity diagram or robustness diagram serve well. Important is that you dive into every single action of each activity and that you point out their access to technical equipment. Let us begin with the activities at the top of the report.
Click to enlarge: Drilldown from activities to technical components
For this example I use a robustness diagram. The left turning circles are controllers. They symbolize actions within an activity. They access entities. Those are the circles with a line underneath. They stand for technical components. And that is the point of our interest regarding protective means.
Second risk analysis: entities
This step of analysis is based on the process risk, too. When creating a robustness diagram the modelling software shall transfer the activity’s process risk to all of its entities. Thus, all entities are potentially threatened in the same way. Is that really the case? Probably, this is not the case. Therefore, we have to determine for each entity whether it is at risk or not. If we face an entity that is not risky, we indicate it as such. From now on we will not consider it any further.
A little hint: If no endangered entity shows up in your robustness diagram, you have probably forgotten one. Or you have rated the belonging activity as risky by mistake. The principle of this approach requires one sensitive entity at least.
After we have created such a detailed analysis of every activity, we can generate a report over all endangered entities. Again, this list should be compiled in descending order. To ascertain an entity’s priority we have to view the number of its usages. As one might guess, if an entity is used by several activities it becomes more important. Thus we add up the process risk of the belonging activities. And finally, we get the technical risk.
The graphic may give an overview:
Click to enlarge: Over-all risk ratio, risk ratio and singe risk ratio
Activity risk: 10 (left branch) and 6 (right branch) Process risk: 30 = (10 *3) and 18 = (6 * 3) Technical risk: 48 = 30 + 18
Based on the technical risk the modelling suite generates a report of all important entities in a descending order. This list really shows the vulnerable assets of our company / authority.
Click to enlarge: Report on technical components
In the end we receive a detailed understanding of our sensitive technical components. These are the entities that we have to protect by all means. Otherwise we cannot guarantee the stableness of our mission critical processes.
Overview of the procedure
Let me summarize the steps from business processes to the over-all risk rate of a single technical component:
Modelling business processes in BPMN (Part 1)
Rating the activity risk of every activity (Part 1)
If necessary, analysis of sub processes (Part 1)
Reporting all jeopardized activities based on the process risk
In detail analysing endangered activities
Determining and sorting out entities not at risk
Reporting all jeopardized entities based on the technical risk
Advantage of this approach
In opposite to conventional risk management this approach is focused on mission critical processes rather than technical boxes. On this base it derives sensitive technical equipment. How does that play together with typical security strategies? Basically, I do not want to replace those. I would merely like general risk management to access security issues more targeted.
Instead of putting tremendous effort into protection of huge overall-systems we can reduce protective means to smaller system units. By starting from the processes, on one site we can shorten the fence around the house. On the other site we do not protect all houses but only the relevant buildings. And finally, that cuts costs significantly.
Last but not least, I want to thank my friend Philippe Back for playing my mental sparring partner. He really helped me to get my ideas sorted.
I’m looking forward to your comments.
<< Back to part 1 of this process based risk analysis approach: Identifying critical activities
Update
See how this approach works out in reality (well, almost reality). Proceed to an end-to-end example and see this process based risk analysis in real life.