Internal Controls Design website by Matthew Leitch (tutor, researcher, author, & consultant)
New website, new perspective: www.WorkingInUncertainty.co.uk - Related articles - All articles - The author - Services

Control Matrices Graphic


Matrix Mapping: the easiest and best way to map internal controls

by Matthew Leitch, 5 January 2003


Stop and check!
Wrong and right formats
Why this is so much better
Different types of analysis
Risk frameworks and control objectives
How to decide if a control applies to a step
Compressing control matrices using control objectives
Helpful control frameworks
Adding information about controls
Formatting to print
Finally

Please note

If you like the idea of matrix mapping – and many people do – the easiest way to master it properly is to engage me, the author, for some individual technical tutoring or teletutoring sessions.

It's not a difficult technique but I've noticed that most people still benefit from some help in getting it just right.

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:

No!

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:

No!

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:

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:

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

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

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

  4. 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:

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: