Working In Uncertainty
The easiest and best matrices for documenting internal controls
Stop and check!
The most common format for documenting internal controls (i.e. format for ‘control matrices’) takes far too long to write and produces huge documents of little practical use. It's so inefficient that people naturally cut corners giving a distorted view of controls and risk. I should know; I made the wrong choice myself once. Never again!
If your company has documented its internal controls using some kind of matrices or has to do so in future it is well worth getting the right format in place. This is one of those details that makes a huge difference. If you already have matrices check them and, if they are the wrong style, plan to reformat them as soon as possible. If you have still to start them or have just started a project to write control matrices, stop, check, and restart your project using the right style of matrix. If you don't you will regret it later.
Wrong and right formats
The format most people think of first when asked to map internal controls to risks is the obvious one: a list of risks, with controls written against each risk to show the risk is covered. The layout is some variation on the one below, with other columns added for extra information and cross referencing:
At first glance this seems sensible and there is no obvious objection in principle. However, this is a disastrous choice. If the format your company uses, or plans to use, is like this then read on.
A vastly superior format is to list controls down the left hand column, and risks across the column headings, then mark off where controls address risks within a matrix of small cells, like this:
In this example, Risk A is covered by Control 3 only. Risk B is covered by Control 1 only. Risk C is covered by Controls 1, 2, and 4. And so on.
At first glance this seems unpromising. Surely there will be lots of wasted space? Won't the column headings be difficult to read? What if there are too many risks to fit across the page?
All these are minor issues whose impact can be minimised, and they are insignificant next to the hidden drawbacks of the more obvious approach. The next section looks in more detail and the advantages and disadvantages of each type.
Why this is so much better
The big problem in designing control matrices is that the relation between risks and controls is many-to-many. Each risk is typically addressed by several controls, and each control typically contributes to covering several risks. This cannot be eliminated by choosing a special set of risks or controls, so the format has to support these many-to-many relations conveniently.
The obvious format fails to do this, leaving matrix writers with a choice between repeating the same control wherever it applies, or not repeating it every time, to save space and avoid repetition, and so recording the mapping innaccurately. In practice most people try to fudge the risk descriptions to reduce the repetition problem, then mention each control only once unless that would leave a risk with no controls against it.
The result is a distorted picture that under-states the actual level of control and encourages people to place too much trust in individual controls instead of seeing the control system as have multiple lines of defence. Real control systems are made from multiple layers, but this is almost impossible to see or understand if the wrong matrix layout is used.
There are a number of other factors, summarised here:
Different types of analysis
The most common type of analysis is one that goes through accounting processes (e.g. sales from sales order through to collection of cash) looking at controls that help ensure the accounts are correct, or at least acceptably accurate. In this analysis it is not important whether the company is trading successfully, so long as the accounts accurately reflect performance.
As corporate governance rules have developed in various countries it is these matrices that are usually among the first requirements, directly or indirectly.
However, other types of analysis are also possible. For example:
Risk frameworks and control objectives
The ideal framework of risks to use as column headings in a control matrix is one that omits nothing significant within the scope of the analysis and matches conveniently with the effects of the internal controls. If the risks are too broad it is difficult to show coverage accurately. (A control has to be put against the risk but it is not clear that the control only covers part of that particular risk.) On the other hand, if the risks are too fine the matrix becomes large unnecessarily.
If the scope of the analysis is to ensure correct accounting there is a simple and systematic way to generate a framework of risks. Here it is, step by step:
Control objectives are just the flip side of risks. If the risk is ‘Incomplete posting of sales to the sales ledger’, then the objective is ‘Complete posting of sales to the sales ledger.’ The traditional trio of Completeness, Accuracy, and Validity is based on the idea that accounting processes mainly involve copying information from one place to another, item by item (e.g. sale by sale). ‘Complete’ means that all items that should have been copied across have been. ‘Accurate’ means that all items copied across kept their value or any calculation is correct. ‘Valid’ means no items are inserted without having been copied from the previous stage i.e. nothing has been made up. There is one further error that could occur, which is for an item to be copied across more than once. Traditionally, this is included under either Completeness or Validity, but neither approach is satisfactory as many controls confirm Completeness or Validity without helping on duplication. It is best to introduce a fourth control objective, ‘Uniqueness.’
These control objectives are always with respect to the previous stage of processing, rather than to original truth. For example, controls often ensure that some data has been copied Completely from one database to another, but not that the data are a complete record of the business activities they represent. So, Complete, Accurate, Valid, and Unique always mean compared with the data at the previous step.
Some data flows are ‘structured’ in the sense that they are made of units, each of which is itself composed of smaller units. For example, the data flow may be made of a series of files, each of which is composed of a number of records, each of which is made up of a number of fields of data.
If some of the controls apply to one or more levels but not all it is possible to show this distinction on the control matrix by using multiple Steps (i.e. columns) for the data flow, one for each level of the structure you want to analyse separately.
Debt management is often included as an extra control objective. Strictly this is not directly an issue for financial reporting, provided bad debt provisions are accurate. However, it is comforting to know that doubtful debts are not taken on as this reduces the risk of provisions turning out to be incorrect.
Three other control objectives that might be used are confidentiality, auditability, and non-repudiation. (Non-repudiation relates to electronic records of contracts. Suppose a customer places an order but later claims not to have done. If you provide an ordinary computer record of the order the customer could say you made it up. However, modern cryptographic techniques allow you to retain a record of an order received electronically from a customer in such a way that you could not have made it up, and so the customer cannot "repudiate" the order.)
How to decide if a control applies to a step
A control should be shown as applying to a step if it increases the probability that any of the control objectives have been met for that step. The set of steps a control applies to can be called the ‘span’ of the control. Here are some examples to show the principle:
Compressing control matrices using control objectives
If the risk framework uses a small set of standardised control objectives as discussed above it is possible to produce a rigorous but extraordinarily compact matrix.
The control objectives addressed by an internal control are a property of the control, and do not change depending on where it is applied. Therefore, it is enough to provide a column for each step in the processing cycle and show in the matrix which steps each control provides assurance over. To capture the analysis at the more detailed level of control objectives, use the spreadsheet to record the control objectives addressed by each control and then summarise the overall assurance on each step for each control objective.
Here is the basic format to use. The spreadsheet formulae are simple, using nothing more sophisticated than the sumif() function in the summary cells. The new elements of the layout are coloured.
In practice it is better to put the summary cells at the top of the page so they can be frozen on screen as you scroll around the matrix. This way you can always see the summarised position as you work.
It is also helpful to set up rows to show the perceived risk of each type of error for each step - think of it as a target for the total coverage score. In the example above the assurance provided by each control for each control objective is shown as all or nothing i.e. 1 or 0. However, controls vary greatly in their effectiveness and this can be shown by using factors other than one.
The difference between the coverage target and the coverage achieved can be calculated by the spreadsheet and on some spreadsheet programs it is possible to colour code the differences automatically using conditional formatting to show where weaknesses lie.
Here is an example showing these techniques:
In this example there are obviously some problems with the coverage. There are many gaps but also some over-controlled steps where it may be possible to cut out some work and complexity from the controls.
These numbers are all subjective judgements, but this is still better than unquantified judgement. In some cases it may be possible to support judgements with data and calculations based on data, but this is unlikely to be worthwhile except with the most costly processes.
One problem with this technique is to calibrate the targets correctly. You can get a feel for targets by scoring actual controls on a process that is thought to be well controlled and where performance has been good (i.e. errors known and tolerably low). These scores provide a guide for setting targets on other processes.
This kind of sophistication is helpful if you can do it but not essential. Even without targets and coverage factors the spreadsheet analysis is still far more precise than it would be with the conventional approach.
Another enhancement to the basic spreadsheet is to add another worksheet to show a coloured version of the original matrix, for each control objective individually. This can be done using a sheet for each control objective or a single sheet with a cell into which you type the one letter abbreviation of the objective whose analysis is to be displayed.
Helpful control frameworks
The ideal control framework groups all possible controls into a set of layers, or lines of defence, on the basis of the nature of the control. By finding or designing controls under each category it should be possible to produce a complete system covering all relevant levels of management control. If it is difficult to design effective controls at one level it should be easy to see the other levels at which compensating strength can be designed.
It is pointless to try to group controls according to the control objectives they address, though many people do this, or are taught to.
Here's the multi-layer model I like and recommend for controlling financial cycles, starting at the top:
Reporting trading performance through information derived through the process itself. In a business unit there may be many business processes, each with monitoring as above, each providing information about trading performance. This is relevant to ensuring financial information is correct because scrutiny of trading performance can identify unexpected numbers, that may then be incorrect.
Of course other control frameworks can be used, but whatever framework you use it is a good idea to use headings and sub-headings at least to organise the list of controls in the control matrix.
Controls can be given a code so that if they get out of order they can be sorted back into the original order of the control framework.
This is particularly useful if you build a database of controls and control types. By selecting the controls that apply to a particular process you can sort them up into the control matrix area. For example, if you go for the WebTrust seal of approval there is quite detailed guidance about the controls expected so these can be used as a starting point in any analysis under WebTrust.
Here is an example illustrating control framework headings and sort codes. Note that only some of the controls are shown, in order to keep the example short and the new elements are yellow.
Another refinement is to add a summary worksheet that computes the coverage achieved from each type of control within the control framework. This could be useful if you have a high level design for the controls that specifies certain levels of control from each type of control. High level designs are extremely useful but beyond the scope of this paper.
Adding information about controls
If the control matrices are on spreadsheet and the controls are listed vertically as recommended it is easy to add columns to capture useful information about each control (in addition to its profile of coverage of control objectives). This information can be sorted and reported to meet various needs. But what information is useful? Here are some suggestions:
If you are designing controls within a project to implement a new system, or set of systems, expect to be asked to specify requirements for software (e.g. access controls, reports, interface checks) months before other decisions about control have to be taken, and probably a bit before you are ready.
The format recommended in this paper was developed from my experiences in this kind of project. It makes it easier to identify controls with an implication for software, while high level design of control systems makes it possible to respond to even the most demanding software developers (though this is outside the scope of this paper). The technique of marking off controls against risks makes it easier to make changes to the matrices as the software and process people change their minds about how things will work, which is another major practical advantage.
Formatting to print
If you've been paying attention up to this point you will have realised that most control matrix spreadsheets will not fit onto one sheet of paper. Compared to the more obvious format, the format recommended is far more compact, but it can be difficult to fit to the width of a page even in landscape format.
The following techniques reduce the problem:
Mapping internal controls to risks is something more and more companies are expected to do. Every year, countless people waste countless hours doing it in inefficient and inaccurate ways. This paper explains a way to do the work more easily, and yet also produce a more useful and accurate result.
If you have any ideas, questions, or concerns please feel free to contact me at firstname.lastname@example.org. I normally reply within a few days.
Hundreds of people receive notification of new publications every month. They include company directors, heads of finance, of internal audit, of risk management, and of internal control, professors, and other influential authors and researchers.
Please share: Tweet
Words © 2003 Matthew Leitch. First published 5 January 2003.