Process step analysis

There are no subsidiary control patterns to this one in this book.

12 Process step analysis

Example: A company needing to check the coverage of its controls over  nancial reporting for a particular accounting cycle might draw that cycle in a diagram showing every data  ow, data store, and process, then generate from this diagram and list of the steps involved. Each process, each store, and each  ow is a step.

PROCESS STEP ANALYSIS is a rigorous way to structure risk around processes and can be used to populate EVOLVING UNCERTAINTY LISTS and RISK REGISTERS.

™™™

In a complex sequence of information processing it is easy to miss important activities and the risk that goes with them.

The ideal framework of risks to use as column headings in a control matrix is one that omits nothing signi cant within the scope of the analysis and matches conveniently with the effects of the internal controls. If the risks are too broad it is dif cult 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  ne the matrix becomes large unnecessarily.

One way to create a breakdown of process-related risks systematically is to draw out the process and then cut it into steps to which a short, standard list of control objectives is applied. Each combination of step and objective is a risk (i.e.

the implied risk of not achieving the objective).

Here’’s how that works in the context of  nancial accounting, an ideal place to use the technique due to the long established use of  xed sets of control objectives.

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 Table 6.5 Advantages of matrix mapping

Risk-list format Matrix mapping 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 organized into control types.

Repetition of controls makes it hard to record extra information about controls, while their disorganized distribution through the matrix makes speci c controls hard to  nd 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.

Does not prompt people to think of controls.

Provides ideas for controls.

Almost useless for designing controls. Ideal for designing controls.

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  nd 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  les), physical transfers of data, data capture steps, and calculations.

Exclude internal control steps such as checks and authorizations, 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 minimize the number of steps while maximizing 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  ip 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 con rm 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 have 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  ows are ‘‘structured’’ in the sense that they are made of units, each of which is itself composed of smaller units. For example, the data  ow may be

made of a series of  les, each of which is composed of a number of records, each of which is made up of a number of  elds 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  ow, 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  nancial 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 con dentiality, 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.)

A control should be shown as applying to a step if it increases the probability that any of the control objectives will be 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:

A hash total is used to check that a  le of data has been copied without

•

alteration from one computer to another. (Let’’s assume the interface is one step in the process breakdown.) The control should be shown as applying to that interface step only.

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.

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.

A computer checks data to see that they match 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).

If the risk framework uses a small set of standardized control objectives as discussed above it is possible to produce a rigorous but extraordinarily compact mapping of risks to controls using a 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 summarize the overall assurance on each step for each control objective.

Table 6.6 shows the basic format. The spreadsheet formulae are simple, using nothing more sophisticated than the sumif( ) function in the summary cells. The elements added to a basic risk control matrix have grey borders.

Table 6.6 Matrix mapping with standard control objectives

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

In theory at least 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.

Table 6.7 shows 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 unquanti ed 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 challenge with the fully quanti ed variant 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.

In summary, this is a systematic way to produce an analysis of risk around a process and in conjunction with MATRIX MAPPING OF RISKS AND CONTROLS can produce extremely compact documentation that is easy to analyse. Therefore:

Map out the information processing in physical terms and generate a list of steps with risks, each step being a data  ow, store, or process in the model.

™™™

There are no subsidiary control patterns to this one in this book.