Академический Документы
Профессиональный Документы
Культура Документы
html
Internal Controls Design website by Matthew Leitch (consultant, author, educator, and researcher)
Related articles - All articles - The author - Services
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 The author is available to help with work to design controls/audit documentation templates, write guidance on their use, review work done using them for lessons to learn, and (in the UK) to provide relevant training. He can also provide coaching and training in skills for documenting audit work, from engagement risk analyses through to documenting the results of testing, and to reporting.
Controls
Risk/control objective Risk A Risk B Risk C Risk D etc Controls addressing risk A Controls addressing risk B Controls addressing risk C Controls addressing risk D 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:
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.
Does not conveniently represent many- Very easy to show many-to-many relations. Avoids to-many relations between risks and distortion. Controls are described only once, saving space. controls, leading to distortion and repetition of control descriptions. Does not provide a list of controls. 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. Hard to automate. Provides a list of controls, which can be neatly organised into control types. 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. 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. Almost useless for designing controls.
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.
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 nonrepudiation. (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.)
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).
C A V U Step A Step B Step C Step D etc Control 1 1 1 Control 2 1 1 1 Control 3 Control 4 etc Summary Completeness Accuracy Validity Uniqueness 0 0 0 1 1 1 0 0 2 3 2 0 0 1 1 0 1 2 2 1 1 1 1 1 1 1 1 1 1 1 1 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 Accuracy Validity Uniqueness Completeness Accuracy Validity Uniqueness Control 1 0.5 1.0 Control 2 0.2 1.0 0.7 0.5 1.0 1.0 0.5 -0.5 -1.0 -1.0 0.0 1.0 0.5 1.0 1.0 -0.5 0.5 -1.0 -1.0 1 0.2 0.2 0.2 1.0 0.5 2.8 0.6 -1.0 1 1 1 0.6 2.0 0.2 2.0 -0.6 -1.0 -0.1 -2.0 1.0 1.0 1.0 1.5 -0.8 1.0 -0.2 -1.0
0.5
1 1 1
1 1
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.
Management monitoring o 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. o 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 o Protect the process from interference, using physical and software security measures. o Make the process recoverable, for example through data backups, disaster recovery planning, and building resilience and recoverability into every interface. o Make the process inherently reliable, for example, by assuring software quality, testing the usability of software which interacts with humans, and using reliable hardware. o 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. o 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 Step Step Step etc
A MONITORING BUSINESS MONITORING Weekly margin analysis and meeting PROCESS MONITORING Downtime analysis and meeting Quality review statistics CONTROL ACTIVITIES PROTECTION Computer room security Operating system level passwords RECOVERY CONTROLS Nightly backups of main servers etc A AA AA1 1 1 1 1 AB AB1 1 1 1 1 AB2 C CA 1 1 1 1 1 1 1
1 1
1 1 1 1
1 1 1 1
1 1 1 1
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.
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. o 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. o 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:
o
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. o Turn the risks through 90 degrees: This allows the columns to be narrower. o Hide columns: Hide any columns not needed by the person who wants the hardcopy. o 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. If you have any ideas, questions, or concerns please feel free to contact me at matthew@internalcontrolsdesign.co.uk. I normally reply within a few days.
If you found any of these points relevant to you or your organisation please feel free to
contact me to talk about them, pass links or extracts on to colleagues, or just let me know what you think. I can sometimes respond immediately, but usually respond within a few days. Contact details
About the author: Matthew Leitch is an independent consultant, researcher, and author specialising in internal control and risk management. He is also the author of the new website, www.WorkingInUncertainty.co.uk, and has written two breakthrough books. Intelligent internal control and risk management is a powerful and original approach including 60 controls that most organizations should use more. A pocket guide to risk mathematics: Key concepts every auditor should know is the first to provide a strong conceptual understanding of mathematics to auditors who are not mathematicians, without the need to wade through mathematical symbols. Matthew is a Chartered Accountant with a degree in psychology whose past career includes software development, marketing, auditing, accounting, and consulting. He spent 7 years as a controls specialist with PricewaterhouseCoopers, where he pioneered new methods for designing internal control systems for large scale business and financial processes, through projects for internationally known clients. Today he is well known as an expert in uncertainty and how to deal with it. more