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.
- 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.
- 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.
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 |
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: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:
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
postingan yang bagus...
ReplyDelete