Wednesday, July 15, 2015

Using a risk and controls matrix to support your project audit

In previous articles, I described why your IT project might be audited, and an overview of the major steps in the audit for an application development or implementation project. In this article, I’ll describe the IT project risk and controls matrix, which you can use to prepare for the audit.

Risk and controls matrix

A risk and controls matrix is one of the most common methods that companies and auditors use to document risks and controls. Although some companies have more formal applications, often Excel spreadsheets or Word tables are used for this documentation. The function of the matrix is simply to provide structure for the documentation. You could certainly write narratives instead, but the matrix is easy to read and is a familiar format for those who document or audit controls.

Columns in the matrix

The columns in the matrix (from left to right) generally include:
·         Risk description
·         Likelihood
·         Impact
·         Control objective
·         Control activity.

Documenting risks
First, the risks documented are inherent risks, which are the risks that exist assuming there are no controls in your environment. Keep in mind that although you may have risks that are specific to the project, there are some risks you can identify without even knowing what the specific IT project is. We are talking about inherent risk, so this is easier than it sounds.

Here’s an example, “The system may not meet the needs of the business, or deliver what management expects.”  Some companies write this in more formal language but it isn't necessary to do so. 

For each risk, indicate how likely it is and what the impact would be if the risk occurred. You can get numerically fancy if you like, but it is very common to use high, medium, and low for these indicators. Where the likelihood and impact are high, the controls should be particularly stringent, and their operation should be well documented for reference and audit. If you had no controls at all on your project, the likelihood of not meeting business needs or management objectives would be a high-probability and high-impact risk.

Control objectives
Generally, the control objectives are opposite to the risks, as they represent the outcome you want. For example, the control objective for the above risk would be, “The system meets the needs of the business and is what management expects it to be.”

No joke, it’s often as obvious as that. As a result, some companies don’t bother to document the risk and just start with the control objective. However, it is much more common to include the risk because the entire purpose of the controls is to address risk.

Control activities
The control activities are what your company or project team is doing to mitigate the inherent risk and satisfy the control objective.

For the example above, there would usually be several control activities. For example, one of the key ways to ensure that the application functions according to expectations is to test it in several different ways. You might write a control activity such as “Unit testing, interface testing, and user acceptance testing will be performed.”

Another control you likely have is formal sign off from the business user on the requirements, on the application design, or on the completed application test results.

In trying to ensure the application will meet the needs of the business and management when it is implemented, there are generally environmental controls that are enforced not just company wide, but also at the project level. For example development, testing, and production environments are restricted based on the role of the individual. In addition, you do all of the application testing in an environment that as closely as possible reflects the expected production environment. 

In ensuring the application will deliver its expected results, the project usually also trains end users to make sure they will use the application correctly and follow the associated new processes.

So, now you have a set of control activities that together can satisfy the control objective and mitigate the specified inherent risk.

Other typical risks
Now that you’ve seen a detailed example of one of the risks, here are some other risks that you may wish to include in your matrix:
·         Project does not meet the expectations of management: For this risk, the control activities are usually the project approval and project oversight processes you have. For example, project approvals by management, project advisory and steering committees, etc.
·         Systems implemented interfere with normal business operations: The control activities you might document for this risk are the system outage permission processes, as well as the updates to documentation for the application and the production operations teams. You may also obtain source code or arrange an escrow agreement for purchased applications.
·         Data converted to the new system may not be complete, accurate, or valid: This is a risk you would normally include if you are converting data from an older system to the new one.

Project-specific risks
The risks outlined above apply to nearly all IT application development or implementation projects. You may also have additional risks to consider based on the specific project you are delivering.


Documenting your project risks, control objectives, and control activities can help you prepare your project for an audit. The controls matrix is a typical approach used in other areas of the business and by auditors, as it provides structure for the assessment of controls.

Copyright 2015 Debbie Gallagher