Chapter 4: Information Risks and Frameworks – Fundamentals of Information Risk Management Auditing: An introduction for managers and auditors



So far we have considered the nature of risk and how it impacts organisations. As information is a key asset of an organisation, a significant area of investment, and one with specific risk implications, it should be high on the agenda of most organisations. Much mystique has arisen around IT assurance because of its technical nature – however, the basic principles are the same as for any other risk impacting the entity. In this chapter we will consider:

•   What is information risk?

•   The frameworks to help analyse and manage risk:

   COBIT 5

   ISO standards


•   Summary

Management frameworks, such as PRINCE2® and ITIL® will be considered later in the book in the relevant chapters. Other frameworks are available, for example the Project Management Body of Knowledge (see

What is information risk?

To fit into the overall enterprise risk management for an entity, any risks for information should relate to the overall business risks. For example, we could consider the risk of penetration of websites; however, this needs to be seen in the context of the related business risk of loss of customer data or intellectual property of the company. We could consider the need for a disaster recovery plan for a computer centre – but this needs to be seen in the context of overall business recovery in the event of an incident. In my opinion, there are no such things as IT risks. Instead, we have risks to the business that have IT causes or consequences. In other words, we only need to consider IT risks if there is a potential business impact. This is a useful sense check to apply.

So what is different about IT risks? The main difference is their pervasive nature increases the level of impact. For example, access to one system can give access to all data and services.

A common mnemonic for summarising IT risks is ‘CIA’ which has been in use for some time now. It is mainly used in the context of security risks and controls, however I find it a useful way to assess risks for any IT scenario. CIA stands for:





Management is sometimes also added as a fourth factor.

Confidentiality relates to data security and privacy. It is about ensuring that data is not lost or disclosed in an unauthorised way. This could be due to physical security, such as leaving a laptop on a train, or allowing unauthorised visitors, or not physically securing laptops to the desk with suitable devices. It could also be due to poor logical security, such as poor passwords, not using screensavers to time out, failing to encrypt key data sent in emails, or poor website and firewall controls. The consequences of any loss of data could include loss of reputation, compliance fines and prosecutions, loss of customers, or loss of intellectual property assets. With Internet fraud on the increase, data has a value and there have been cases of very large amounts of personal employee data or credit card information being traded. We will consider data confidentiality and privacy further in Chapter 7.

Integrity in the security sense applies to preventing data from being changed by unauthorised persons. Legitimate users of data need to have comfort and assurance that the data they use is accurate and complete. I was in a restaurant once and left a tip of £12 on a bill of £120. The restaurant entered it incorrectly (after I had verified the transaction) and a few days later I received a call from my credit card company saying that there was a large/unusual transaction. The tip had been entered as £12,000! These sorts of errors should not occur.

To me integrity is about more than security. From an IT controls perspective it also includes the integrity of systems and processes that amend data. Therefore, I also consider the following under integrity:

•   Change control processes for systems should ensure that full testing of changes is made prior to them being implemented in a live environment (see Chapter 7).

•   Governance and other controls in the system development lifecycle for projects and programmes to produce new systems (also see Chapter 7).

•   Data processing controls, for example to ensure that interfaces and batch processes are run completely, timely and accurately (see Chapter 9).

•   Controls within applications to ensure that all transactions produce accurate, complete and reliable results. This may include validation of data entered via screens, or management information to monitor the output of key processes (also Chapter 9).

Availability in the IT security context relates to ensuring that authorised users, etc. can access information when it is needed. The main availability security risks are preventing denial-of-service attacks (DoS). Downtime of key websites could be extremely costly to reputation and loss of business if customers are unable to place orders online. Availability can also be lost through physical incidents, such as power loss, floods, fire or even pestilence! The following examples are all cases I have come across:

•   Computer and communications suite located below ground level and under the works canteen (the IT staff entered the room in wellington boots after the inevitable flood from the kitchen).

•   Smoking being allowed in a room on the same air conditioning circuit as the computer suite (the director’s pipe set off the system and flooded the room).

•   Computer situated under a flat roof that leaked (the mainframe had a plastic sheet over it).

•   Main computing centre for a US based company was on top of the San Andreas Fault. Another centre was in a hurricane zone.

The main ways to ensure availability are to build in resilience, such as alternate processing capabilities and ensuring data is regularly and fully backed up and stored offsite.

I also include the ability to respond and resolve small incidents as part of availability. To a user the availability relates to the systems and data they want to use. Hence if there is a problem with a particular application, this can have as big an impact to some users as the whole system being unavailable.

A comprehensive and regularly tested disaster recovery plan is also vital.

We will consider these issues further in Chapter 8.

The management of IT can also be a risk area. IT represents a large investment. There is also an increasing trend for bring your own devices (BYOD) and other DIY approaches, which whilst they may be appropriate for domestic use and reduce costs of delivery, do reduce the level of control an organisation has over its own IT. For example, I know of one company where staff felt that the IT support they received from the service desk provider was too slow and ineffective. There were a couple of people on the factory floor who therefore decided to fix the problems themselves. This included introducing software to identify and fix problems, which unknown to them contained viruses.

Management risks of IT include:

•   Poor administration or governance of the service (see Chapter 5).

•   Lack of strategic direction for the development of the service and IT investment – failure to provide what the business needs now or in the future.

•   Poor control over third parties providing IS services.

The CIA (M) mnemonic is very useful – I have used it in interviews as well as in reviewing new client situations.


COBIT 5 (originally known as Control Objectives for Business and Information Technology – now just known by the acronym) is the latest version of a series of tools developed by ISACA (originally known as the Information Systems Audit and Control Association, but now just known by the acronym). COBIT is a valuable toolkit for information risk management, as it provides a structure and guidance for a number of the reviews that IRM specialists are likely to be asked to perform. Many of the tools are available free of charge to ISACA members – or can be purchased on licence from ISACA for reasonable fees (see ISACA describe COBIT 5 as “The only business framework for the governance and management of enterprise IT”. The tool is available as an online version or as a series of guides. At the time of writing the tool is useable, however additional features and documents are planned to be added in due course. I have listed below some of the main publications available:

•   A Business Framework for the Governance and Management of Enterprise IT

•   COBIT 5 Enabler Guides (see

•   COBIT 5 Professional Guides (see

The ISACA website also provides other tools to assist with assessments, laminate summaries and conversion from earlier versions of COBIT. The tool is used very widely internationally, often adapted for use within specific organisations. Training and certification in its use is also available.

The tool is extremely sophisticated and contains many elements. The easiest way to get an overview is to read A Business Framework for the Governance and Management of Enterprise IT (see This includes:

•   A summary of the framework documents

•   An introduction to information governance

•   Descriptions for the five principles in COBIT 5:

Principle 1: Meeting stakeholder needs

Principle 2: Covering the enterprise E2E

Principle 3: Applying a single integrated framework

Principle 4: Enabling an holistic approach

Principle 5: Separating governance from management.

These principles place information governance in a firm context within ERM (see previous chapter). The guide provides more details on each of the steps and identifies 37 governance and process areas:

Table 5: COBIT 5 Summary of process areas


Number of processes

Example of processes

Evaluation, direction and monitoring (Governance)


Ensure benefit delivery

Align, plan and organise (Mgt)


Manage service agreements

Build, acquire and implement (Mgt)


Manage configuration

Deliver service and support


Manage operations

Monitor, evaluate and assess MEA


MEA of system of internal control

The framework document:

•   provides guidance for the implementation of COBIT 5, including making a business case.

•   outlines the process capability model.

•   provides supporting appendices, including mapping of COBIT 5 to the ISO/IEC 38500 framework.

Knowing about security does not make you a good auditor – you also need other skills and tools. COBIT can provide a structure and framework to help. There are also mappings for COBIT 5 to ISO27001.

Whilst COBIT 4 is no longer supported, you may find it still in use at some organisations that prefer the older style presentation based on control objectives.

ISO frameworks

ISO (International Organization for Standardization) is an independent, non-governmental membership organisation based in Geneva who develop voluntary International Standards. These standards provide globally accepted specifications for products, services and systems. Compliance is often requested in international contracts, including for outsourced IT services. ISO has published over 19,500 International Standards covering almost every industry, including technology.

The main standards of relevance to information risk management are:

•   ISO31000 – Risk management (see Chapter 2)

•   ISO27001 – Information security (see Chapter 6)

•   ISO22301 – Business Continuity (See Chapter 8).


The IT Infrastructure Library promoted the CCTA Risk Analysis and Management Method (CRAMM). I have not seen this methodology used recently but it may still be in circulation so I have included it for completeness. CRAMM was a software tool with a number of associated useful templates and tools, requiring heavy training of users. It used templates to capture and assess risks in a structured way and then enabled management of these through mitigations. There were three main stages:

1.  Identification and valuation of assets

2.  Threat and vulnerability assessment

3.  Countermeasure selection and recommendation.

Summary and key take-aways

The use of CIA (Confidentiality, Integrity and Availability) provides a good way to summarise IT and information risks and provides a basis for audit and assessment. There are also a number of useful internationally recognised standards and policies that the IRM specialist must be aware of, the main ones being COBIT 5 and ISO27001.