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.
Conclusion
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
