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:
| Risk/control objective | Controls |
| Risk A | Controls addressing risk A |
| Risk B | Controls addressing risk B |
| Risk C | Controls addressing risk C |
| Risk D | Controls addressing risk D |
| etc | etc |
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:
| Control | Risk A | Risk B | Risk C | Risk D | etc |
| Control 1 | | 1 | 1 | | |
| Control 2 | | | 1 | | 1 |
| Control 3 | 1 | | | | 1 |
| Control 4 | | | 1 | 1 | 1 |
| etc | | | | | |
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 at 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:
| Obvious format | Correct format |
| Does not conveniently represent many-to-many relations between risks and controls, leading to distortion and repetition of control descriptions. | Very easy to show many-to-many relations. Avoids distortion. Controls are described only once, saving space. |
| Does not provide a list of controls. | Provides a list of controls, which can be neatly organised into control types. |
| Repetition of controls makes it hard to record extra information about controls, while their disorganised distribution through the matrix makes specific controls hard to find quickly. | Extra information can be put against each control and the controls can be grouped meaningfully. For example, it is easy to give each manager a list of the controls he/she is responsible for, or produce a list of all control reports needed from a new system, or pull out the rules for segregation of duties. |
| Hard to automate. | Easily automated on a spreadsheet giving dramatically smaller matrices and the ability to sort controls. (See below for a full explanation.) |
| Does not prompt people to think of controls. | Provides ideas for controls. |
| Almost useless for designing controls. | Ideal for designing controls. |
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:
- Revenue and cost assurance: Mistakes and system flaws cost businesses dear through incomplete billing and over-payment for goods and services received. Systematic mapping of internal controls is one way to identify where this might be happening and find ways to reduce it.
- Data conversion: When data is moved from an old computer system to a new one a set of checks is needed to ensure that data is not lost or damaged in the process.
- Profitable trading: This kind of analysis is concerned with objectives like selling the right goods at a good price and getting paid for them.
- Compliance with laws and regulations: This can be quite a lengthy analysis, even in overview.
- Support processes: For example, people in a company's computer department carry out processes that support others. The computer department's processes can also be analysed for error and fraud risks.
- IT security risks: e-business processes need careful security design and a detailed analysis is needed to confirm that the design is adequate, in principle at least.
- Business unit overview: This is the level at which top level analyses are usually pitched for compliance with corporate governance regulations such as the UK's Turnbull guidance.
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:
- If many accounting cycles are being analysed, decide how to divide up the cycles e.g. "purchases" or "purchases and payables"? It is usually best to go with the longest, most inclusive processes possible. Do not forget to include processes like returns and adjustments that may be infrequent and low value, typically, because these are often weakly controlled areas.
- Identify the underlying information processing, excluding internal control steps. Most people find it helps to draw diagrams but with practice this can be omitted. Look for the physical stores of data (e.g. paper forms, computer databases, and computer files), physical transfers of data, data capture steps, and calculations. Exclude internal control steps such as checks and authorisations, which are things done to ensure that the underlying information processing is done correctly. It is not usually necessary to identify every data movement that happens within a single database used by a single computer application, though this can sometimes be helpful. Be sure to list all the data capture steps including things like bad debt provision entry, and obscure reference data edits.
- Carve up the underlying processing into steps. Typically there will be data capture steps, data transfer steps, and calculation (including summary) steps. It is not necessary to list the steps in any particular order but it is clearer to work in the order of processing transactions, with reference data done last or interleaved with transaction processing steps. There are choices in selecting the steps but aim to minimise the number of steps while maximising the precision of the mapping.
- Apply a standard set of "control objectives" to every step. The traditional control objectives are Completeness, Accuracy, and Validity, to which Uniqueness should be added. (See below for an explanation.) The effect of this is to divide up all possible errors at each step into a small number of standard categories.
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:
- e.g. A hash total is used to check that a file of data has been copied without alteration from one computer to another. (Let's assume the interface is one step in the process break down.) The control should be shown as applying to that interface step only.
- e.g. A reconciliation is performed between data at one point in the processing and another point, three steps later. The control should be shown as applying to all three steps.
- e.g. A control is used to ensure that software programs within an application are not changed by accident. This slightly reduces the risk of error and fraud of various types for all steps performed using that application.
- e.g. A computer checks data to see that it matches a business rule, such as that customer ages should be between 0 and 150 years old. Some mistyped dates of birth will be caught by this check. The assurance applies to all steps prior to this point, because an error at any of these steps could be caught by the check (unless of course exactly the same check is also performed earlier on).
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.
| C | A | V | U | Step A | Step B | Step C | Step D | etc |
| Control 1 | 1 | 1 | | | | 1 | 1 | | |
| Control 2 | 1 | 1 | 1 | | | | 1 | | 1 |
| Control 3 | | | | 1 | 1 | | | | 1 |
| Control 4 | | 1 | 1 | | | | 1 | 1 | 1 |
| etc | | | | | | | | | |
| Summary | | | | | |
| Completeness | 0 | 1 | 2 | 0 | 1 |
| Accuracy | 0 | 1 | 3 | 1 | 2 |
| Validity | 0 | 0 | 2 | 1 | 2 |
| Uniqueness | 1 | 0 | 0 | 0 | 1 |
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:
| Targets | Step A | Step B | Step C | Step D | etc |
| Completeness | 0.5 | 1.0 | 0.2 | 0.6 | 1.0 |
| Accuracy | 1.0 | 0.5 | 0.2 | 2.0 | 1.0 |
| Validity | 1.0 | 1.0 | 0.2 | 0.2 | 1.0 |
| Uniqueness | 0.5 | 1.0 | 1.0 | 2.0 | 1.5 |
| Differences | Step A | Step B | Step C | Step D | etc |
| Completeness | -0.5 | -0.5 | 0.5 | -0.6 | -0.8 |
| Accuracy | -1.0 | 0.5 | 2.8 | -1.0 | 1.0 |
| Validity | -1.0 | -1.0 | 0.6 | -0.1 | -0.2 |
| Uniqueness | 0.0 | -1.0 | -1.0 | -2.0 | -1.0 |
| C | A | V | U | Step A | Step B | Step C | Step D | etc |
| Control 1 | 0.5 | 1.0 | | | | 1 | 1 | | |
| Control 2 | 0.2 | 1.0 | 0.7 | | | | 1 | | 1 |
| Control 3 | | | | 0.5 | 1 | | | | 1 |
| Control 4 | | 1.0 | 0.1 | | | | 1 | 1 | 1 |
| etc | | | | | | | | | |
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:
- Management monitoring
- Process monitoring
- Monitor past effectiveness of the controls and take corrective action, for example by tracking error rates, transactions via exception streams, and lost revenue and changing the process to make it inherently more reliable, or adding checks.
- Monitor future events and adapt the process and its controls in good time, for example through capacity planning, looking ahead for high risk changes and spreading them out, and checking for forthcoming contract changes that will be difficult and time consuming to implement.
- Monitor the controls to ensure they are operating, for example through audit work, reviewing reports of control performance, and control self assessment. Where reliance is placed on exception reporting no news is good news - or the controls have stopped operating. This is particularly important for controls that aim to cover risks that rarely occur.
- Business monitoring
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.
- Control activities
- Protect the process from interference, using physical and software security measures.
- Make the process recoverable, for example through data backups, disaster recovery planning, and building resilience and recoverability into every interface.
- Make the process inherently reliable, for example, by assuring software quality, testing the usability of software which interacts with humans, and using reliable hardware.
- Put checks on data and processing in place, with associated corrective action, to detect process errors, interference with the process such as fraud, and attempts to pass fraud through the process.
- Put audit trails in place, so that auditors can gain assurance of correct functioning, and so that errors can be investigated and corrected easily.
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.
| Sort | C | A | V | U | Step A | Step B | Step C | Step D | etc |
| MONITORING | A | | | | | | | | | |
| BUSINESS MONITORING | AA | | | | | | | | | |
| Weekly margin analysis and meeting | AA1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| PROCESS MONITORING | AB | | | | | | | | | |
| Downtime analysis and meeting | AB1 | 1 | 1 | 1 | 1 | | 1 | 1 | | |
| Quality review statistics | AB2 | | 1 | | | 1 | | | | |
| End-to-end reconciliation summary | AB3 | 1 | | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| CONTROL ACTIVITIES | C | | | | | | | | | |
| PROTECTION | CA | | | | | | | | | |
| Building security guards and alarms | CA1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| Computer room security | CA2 | 1 | 1 | 1 | 1 | | 1 | 1 | | |
| Operating system level passwords | CA3 | 1 | 1 | 1 | 1 | | 1 | 1 | | |
| RECOVERY CONTROLS | CB | | | | | | | | | |
| Nightly backups of main servers | CB1 | 1 | | 1 | 1 | | 1 | 1 | | |
| etc | | | | | | | | | | |
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:
- Design and implementation information: e.g. name of developer, whether software needs to be written, whether the control already exists or not. Obviously, this is relevant if controls are still being developed.
- Manager responsible for operation of the control: Useful for various review and confirmation exercises. Processes almost always cut across departments but people naturally want to know what they are responsible for.
- Frequency of operation of the control: This can sometimes be useful where there is a choice and you want to make the most economic set of decisions about frequencies.
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:
- Stay electronic: Avoid hardcopy altogether if possible. You can get more text on a spreadsheet if you use comments for extended descriptions and comments. These cannot be printed at all.
- Turn the risks through 90 degrees: This allows the columns to be narrower.
- Hide columns: Hide any columns not needed by the person who wants the hardcopy.
- Set column and row headings so every page has them: Possible on some spreadsheet programs. If not, split the matrix by splitting the set of risks/steps.
Finally
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.
Source: http://www.internalcontrolsdesign.co.uk
