Risk identification of the issues surrounding the collecting, storage and use of data is relatively easy if we apply the confidentiality, integrity and availability (CIA) framework. Even risk prioritisation is pretty straightforward. The difficult part is the risk management and assurance components.
Why is this the case? Well, the first two (identification and prioritisation) only involve talking, whereas the last two usually require some action to be taken. For anything other than tolerate the risk, something has to be done to either terminate, transfer or mitigate the risk.
If we visualise IT as a pyramid with hardware at the bottom and information at the top, then the successive layers between the two are: base software (i.e. operating system), middle software (i.e. database management), application software (i.e. payroll) and data.
This last level is stored and manipulated by the lower levels to produce information. The network which provides the interconnectivity to distribute this information can be imagined as running up the spine of the pyramid. This means that for information to be reliable and available when required we must manage every underlying asset and process.
The underlying risks are the usual CIA ones, plus compliance, which is often forgotten, but may be the biggest risk of all as we shall see later. Taken together these are a huge risk management challenge, especially when it comes to providing assurance that the end product of our investment, the information, can be relied on.
BCS has a specialist group that deals with this challenge; the Information Risk Management and Assurance (IRMA) group is one of the oldest within BCS and this year celebrates its 50th anniversary. It has gone through three name changes along the way (Auditing by Computer, Computer Audit and now IRMA), which illustrates its attempt to keep pace with the changes in risk due to changes in technology.
It is interesting to note that 50 years ago, in the very early days of computing, some far sighted people realised the need to develop a control framework to provide assurance that the information being created by the technology could be relied on.
Data collection and subsequent processing stages need to be controlled in a way which provides for confidentiality, integrity, availability and compliance at each stage of the journey from raw data to management information. When I reflect on what is involved in that journey I am amazed that we get anything approaching reliable output; and yet by and large we do.
This is because over the years we have identified the key risks and put in appropriate controls to manage them to an acceptable level. This is not the same as no risk and the acceptable level will vary from industry sector to sector, from company to company and even from system to system, but we now have a pretty good understanding as to what that level of acceptability should be for any given situation.
The only reason that we have all that hardware, software and networks is to capture the raw data, store it and then process it to produce information for (hopefully) sensible decision making. The necessary control framework is formidable. We must provide for confidentiality, integrity, availability and compliance within the world-wide regulatory framework.
Although this is a daunting concept your compliance friends (for indeed we are) have developed just such an assurance framework. We have dissembled IT into 36 key processes spread across five domains, which are applicable regardless of industry sector or technology. For each process we have identified the key controls and, even more importantly, ways of measuring the operational effectiveness of those controls.
We can even measure the effectiveness of the IT governance framework in meeting IT objectives which should align with business objectives. We call this framework Control Objectives for IT (COBITTM), which is now in its fifth version since its inception in 1996.
COBIT was originally developed by the Information Systems Audit and Control Association (ISACA) as a result of a quarter of a million dollars grant from IBM, who realised the need for assurance over the technology that it was selling.
COBIT provides the capability for mapping enterprise goals, to IT goals, and then to IT processes, with further drill-down into activities, key goals, key performance indicators, capability maturity modelling and assessment against ISO 15504. It is a truly awesome concentration of risk and control knowledge. It starts with the concept that as IT is there to support the business, then IT risks are business risks.
If we know which IT components are being used to achieve a particular business objective, then we can risk assess and manage those components whether they are infrastructure, hardware, software or people related. That way we can assess HR processes to ensure that we have the appropriate IT personnel in place; the design and implementation stages; and the operational and support phases.
Every three years ISACA conducts a statistically valid world-wide survey to ascertain what the real risks are and how they are being managed. This is supported by research into technological developments and whether we need to adjust our information risk management and assurance tactics accordingly.
This has enabled us to adjust our control paradigms to recognise the changing risk profiles caused by the move from mainframe computers to tablets, from batch processing to real-time systems, from LANs to cloud, from internal to outsourced management and from centralised to de-centralised data collection and processing.
We do not claim to know all the answers, but the identification of the risks is an important first step. We are also able to dispel myths, such as trust being a control, by mathematically measuring the effectiveness of a specific control in managing a particular risk.
To effectively manage a risk you ideally need to manage both the likelihood and the consequence. A single control can only manage one side of the risk equation so you need a minimum of two controls for each risk and this assumes that both controls operate to a 100 per cent effectiveness.
Most controls do not achieve anywhere near this effectiveness level so we may well need multiple controls to manage the risk to the appropriate level. By applying such assurance techniques we can help management to identify weaknesses in their IRMA structure.
It is then up to them to decide whether they are willing to live with it (tolerate), remove it (terminate), adjust it (treat) or share it with another party (transfer). You will notice that every decision, apart from tolerate, requires some action to be taken. These improvement programmes are where you need to speak to your assurance professional.
There are multiple ways of achieving a particular control objective and they can help the IT professional decide on the most appropriate approach. This should be a team effort. The IT people know the technology and us assurance professionals know the controls. Working together makes sense, collaboration is so much better than confrontation.
