End-to-end example of process based risk analysis – Part 2
In the first part of this process based risk analysis example we have identified risky activities and separated them from the activities that we consider to be at no risk. Now we will inspect the remaining endangered activities in more detail. We want to find out, which technical entities are involved and what their technical risk is. The intention is to identify technical entities that we have to protect and to separate entities that we may ignore. That gives us the capability to reduce the amount of protective measures. The result will be a list of sensitive key entities and their technical risk.
Entities involved in activities
We have identified three critical activities so far: Alarm company’s fire fighters, alarm city fire department and alarm company’s security service. If those activities cannot be performed properly our company has a serious problem.
Therefore, we will model those activities in more detail. The “Alarm company’s fire fighters” consists out of two actions. The main action alarm fire fighters gets details of the fire signal using the Internal alarm manager. On that basis our system creates a new internal alarm. This uses the Internal alarm manager too. And of course both actions are using the Internal communication line. For all his actions the guard duty uses a Control desk. The same applies to the guard duty fire fighter, who has to confirm the alarm using his Guard duty control desk.
In the following graphic you see that both actions (alarm fire fighters as well as validate feedback) are logged in the Technical log. This is important for later revision. But it is not critical in terms of managing the fire alarm though. For this reason I do not consider it as a sensitive entity.
Click to enlarge: Alarm company fire fighters - Robustness Diagram
The activity Alarm city fire department runs very similar. But there is one difference: This activity implies an outward-bound communication. For this purpose we have Outward com interface. It is essential for our operation. Of course it is one of those entities that we have to protect. In the graphic below you see also an External communication line and an External alarm manager. Both entities are critical as well. But as they are located outside of our reach they are not marked as sensitive. If we would model those processes from a cross-organisational point of view including our company, the city fire department and the environmental agency, External communication line and External alarm manager would be definitely coloured blue (meaning: endangered!).
Click to enlarge: Alarm fire department - Robustness Diagram
The third activity Alarm company’s security service doesn’t contain any new entities beyond the ones we already know. As I don’t want to bother you too much I will not describe it in detail. The technical components in this diagram are Internal alarm manager, Internal communication line and Guard duty control desk.
After we have analysed those three critical activities we know involved technical components now. Based on the process risk (Part 1 of this article) we can calculate the technical risk.
Just to recapitulate I show the process risk again:
Click to enlarge: Chart of process risk
From the process risk we can deduce the technical risk like this:
Click to enlarge: Chart of technical risk
As expected there are three components that should receive our fullest attention: Internal alarm manager, Internal communication line and Guard duty control desk. All of them have a technical risk of 34. It is the sum of the process risk of those three activities where they are used. It is interesting, but the other two components are clearly left behind. We have a strict prioritization of those components, which we have to focus our protective measures on.
So, this is where our journey from the processes to the technical components ends. We have described the processes with BPMN, we have identified activities at risk and we have done a drill-down into those jeopardized activities. Finally we carved out a small number of technical components that we really have to protect. If those components are undermined, our core business is threatened seriously.
Beginning with seven activities we reduced it to three activities. There are six major entities used in those three activities. Three entities of them are clearly higher prioritized by their technical risk. Whereas the other three components are clearly rated lower.
All in all I think this approach can help us to reduce the number of technical components worth to be protected significantly. Therefore, this opens up the chance cut costs of our protective measures.
On LinkedIn is a discussion about this approach. One question regards the type of risk. In my article I did not differentiate between different kinds of risks. I focussed solely on the technical risk. But of course there are other risks like organizational, personnel, economical, weather etc. And one and the same activity may have a high technical risk and a very low organizational risk. It is easy to reflect to this by adding an identifier to the activity risk. At the end you might have several risks per activity. On that base you can create different reports for each type of risk.
Another aspect in that discussion was about the transient usage of technical components. This means, if one component is broken – and it is used by other components – those other components won’t work as well. This is right. But what does this mean for this approach? To avoid those transient dependencies we will have to design the component model in that way that we isolate critical equipment as much as possible. Otherwise we cannot reduce the number of components to protect nor their extent.
I like to thank Maria and Rémy for bringing up these ideas.<< Back to the first part of this process based risk analysis example