View source for RIAM:VLA:DOCUMENTING & ANALYSING THE SYSTEM OF INTERNAL CONTROL

=PHASE 2: DOCUMENTING & ANALYSING THE SYSTEM OF INTERNAL CONTROL=

==Introduction==


When conducting a Systems Based Audit it is necessary for the auditor to gain an understanding of the system and its related internal controls.  The examination and assessment of internal controls will enable the auditor to determine the nature, timing, and extent of audit testing. This phase is also applicable to Key Control Audits and Audit Packages but only in the initial formation of such packages.


To gain an understanding of the System the auditor must perform two major processes:

* Systems Documentation & Modelling
* Control Analysis.


Documentation of the system must be completed before the control analysis is completed.  These two processes will be discussed in detail after a brief look at internal controls.



==Internal Controls==


Internal control has been defined as:

* The plan of organisation and all the co-ordinated methods and measures  adopted within an entity to safeguard its assets, check the accuracy and reliability of its accounting records, promote operational efficiency, and encourage adherence to managerial policies.


This definition covers both accounting and administrative controls.  Accounting controls are primarily concerned with safeguarding assets and the reliability of financial records.  Administrative controls are primarily concerned with operational efficiency and adherence to managerial policies.


The internal control system is the whole system of controls established by management in order to carry on the operations of the organisation in an orderly manner, and to safeguard the accuracy and reliability of records and financial information.


A strong system of internal controls may reduce the need for audit to use substantive testing procedures.  A weak system of internal controls may increase the risk of fraud or error and therefore, require audit to perform extended substantive testing procedures. For a discussion of testing procedures and the relationship of risk assessment to test design, refer to the following sections of the manual.


At the most general level, the purpose of an internal audit review is to express an opinion about the design and operation of a system. The Internal Auditor is a Systems Analyst with a particular specialty in control systems design. We describe this specialty by reference to 5 goals of opinion formation. These are equivalent to the Institute of Internal Auditor's "Scope of Work".

 
==Assertions - The Apex of The Analysis Tree==


RIAM provides a highly structured method of systems analysis. The basis to the approach is the establishment of assertions. An assertion is:

* '''''A truth we wish to sustain about a system in order to express a favourable opinion about the operation of that system.'''''


The 5 goals of opinion formation are nothing more than the 5 general classes of assertions under which we classify and form our opinion about a system. Assertions are discussed greater detail later.


The RIAM control system opinion focus uses the following five assertion classes:


<table border=1 align=center>
<tr>
<th >ITEM</th ><th >OPINION FOCUS</th ><th >SUB FOCUS</th >
</tr>
<tr>
<td >
1
</td>
<td>
Reliability and Integrity of Information
</td>
<td>
* Accurate Information
* Reliable Information
* Timely Information
* Complete Information
* Useful Information
* Correctly Accumulated Information
* Fully and Correctly Disclosed
</td>
</tr >
<tr >
<td>
2
</td>
<td>
Compliance With
</td>
<td>
* Policies
* Plans
* Procedures
* Legislation
* Regulations and Treaties
</td>
</tr >
<tr >
<td>
3
</td>
<td>
Assets are Safeguarded.	
</td>
<td>
</td>
</tr >
<tr >
<td>
4
</td>
<td>
Efficient and Effective Use of Resources.	
</td>
<td>
</td>
</tr >
<tr >
<td>
5
</td>
<td>
Accomplishment of Goals, Objectives for Programs, Policies and Management's Critical Success Factors (Effectiveness).
</td>
<td>
</tr >
</table >



These classes form the apex of our analytic structure. Every finding in the review is ultimately related back to one or more of these assertion classes. Our purpose is to perform sufficient analysis to express a "pass" or "fail" conclusion over each of these classes. 


Not every review will use all five classes, but where some classes are excluded, these should be clearly identified in the scope and boundary of the report.


In effect, the five classes represent an abstraction, or model, of the system under review. We will use additional modelling techniques such as flowcharting and narrations to reach our final conclusions, but all other procedures are 'shaped' by the desire to express our opinion into these 5 classes.



==Management Action Areas - The Second Level of The Analysis Tree==


The process of system modelling, is one of abstraction. As auditors we impose a particular 'view' of a real system that highlights particular characteristics of the system which are germaine to our analytic requirements. The second level of the analysis tree classifies management's "action areas" into 10 control classes:



<table border=1 align=center >
<tr><th>ITEM</th><th>MANAGEMENT ACTION AREA/CONTROL CLASS</th></tr>
<tr><td >1</td><td>Organisation of the section</td></tr>
<tr><td >2</td><td>Personnel</td></tr>
<tr><td >3</td><td>Policies</td></tr>
<tr><td >4</td><td>Procedures</td></tr>
<tr><td >5</td><td>Accounting</td></tr>
<tr><td >6</td><td>Budgeting and Planning</td></tr>
<tr><td >7</td><td>Reporting</td></tr>
<tr><td >8</td><td>Documentation</td></tr>
<tr><td >9</td><td>Internal Review</td></tr>
<tr><td >10</td><td>(Physical) Security</td></tr>
</table>



Many other classification methods at this level may be appropriate and the list may be interchanged with alternative classification systems as appropriate. The list presented above is an expanded version of Sawyer's control classes.


The important point to note is the range of management responsibilities that impact on the completeness of the conclusions formed in the assertion classes.



==Control Attributes - The Third Level of the Analysis Tree==

Within each of the management action areas, controls will be defined. Each control, and control sub-system will have features we term "Control Attributes". These control attributes are summarised:

<table >
<tr >
<td >
* Access Security</td><td>Ability to protect information and other resources against accidental or deliberate unauthorised modification, disclosure or use.  (Note: This includes the distribution of reports)
</td>
</tr>
<tr >
<td >
* Accountability</td><td>Ability to establish a relationship between information and the entity or individual which/whom created or updated it.
</td>
</tr>
<tr >
<td >
* Auditability</td><td>Ability to provide documentary evidence of processing which can be used to trace between transactions and related records and reports.
</td>
</tr>
<tr >
<td >
* Continuity</td><td>Ability to minimise the impact of interruptions to operations and processing support for business functions.
</td>
</tr>
<tr >
<td >
* Information Integrity</td><td>Ability to ensure that information is complete, accurate, reliable and timely.
</td>
</tr>
<tr >
<td >
* Process Integrity</td><td>Ability to ensure that the process is consistent complete, andb accurate (correct).
</td>
</tr>
<tr >
<td >
* Effectiveness</td><td>Ability to accomplish the intended purpose of the system by consistency of design with the intended business functions, and purposes of those functions.
</td>
</tr>
<tr >
<td >
* Efficiency</td><td>Ability to achieve stated objectives with the minimum of cost. Cost is measured in a variety of ways.
</td>
</tr>
<tr >
<td >
* Timeliness</td><td>Ability to ensure that the control system achieves prevention, detection and correction in a timely fashion, and processes inputs into outputs within a useable timeframe .
</td>
</tr>
</table >



==Types of Controls - The Fourth Level of the Analysis Tree==



The control system's ability to support the assertions and therefore the key controls identified are analysed into three types of controls:


* ''Preventive Controls''
** Including direct controls such as authorisation and certification of forms, indirect controls such as training, maintenance of up-to-date reference material, section administration and organisation;


* ''Detective Controls''
** Such as supervisor review, batch control totals, edit checks and periodic system reconciliations;


* ''Corrective Controls''
** Such as routing an error back through the same control system that originally processed and detected the error and response to exception reports.


The key point to be drawn at this level is the issue of cost. As a general guide, the cost of operating a control escalates as we move from preventive controls to corrective controls. The reason for this is simple: preventive controls operate before an error has occurred and the associated effort has been expended, while a corrective control operates after the error has occurred requiring additional effort to correct the error.


The figure on the following page represents the structure of the RIAM control model as detailed thus far.
 

<table border="0" style="background-color:transparent;margin-right:0.9em" cellpadding="2" cellspacing="1" align="left">
<tr>
<td>
<div class="center">
[[Image:ALSBA.png]]
</div>
</td>
</tr>
</table>

==Building The Model - System Documentation==

===Introduction===


To gain an understanding of any system the auditor needs to examine the system to identify and record all relationships and interactions within the system between people, machines, procedures.  To do this the auditor must gather information, and from that information, document the system.  The extent of documentation required will be determined by the nature and complexity of the system being examined, together with the degree of reliance intended to be placed upon the system.


The documentation process can be seen as one of filling in the leaves of the analysis tree outlined in section 3 to 5. Documentation is not a function separate from the systems analysis but part of the analytic process.


A system model in RIAM is therefore considerably more than just a flow chart of steps in a process. It incorporates issues of management influence such as resources, training, ergonomics, economics, history and, of course, transaction flows. It is quite likely that we will have available Desired Control Models for parts of the model, such as a transaction flow.


In RIAM we view the process of analysing and documenting the control system as one of model building. The detailed structure into which the documentation is written as we evaluate the system, categorises and  models that system, supporting analysis by either comparison to predefined "ideal" models (we call these Desired Control Models) or where such is unavailable, by logical testing of the assertions against identified threats.


In analysing the model we have built of the "real system" we use Desired Control Models as a short-cut to assertion testing. The Desired Control Model represents a description of the system as required to satisfy selected assertions.


For example: after documenting the legislative requirements for purchasing, we might construct a desired control model for the document transaction flow that satisfies the "Compliance with Legislation" assertion class. Having established this desired control model we can then compare our "real system" model noting those steps present in the desired model yet not in  the "real system" model. Evidently if there are no such steps identified, the "real system" model passes on that assertion.


In other cases the desired control model will not be definable economically. In these cases our model may be analysed by structured means, such as threat analysis or one of a range of unstructured means, such as experience!

 

===The Steps to Building the System Model===

<ol>
<li> The first step in documenting the system is to collect relevant background information relating to the review and the section(s) associated with the review prior to building a brief description of the system/section under review. Core background information should be found in the audit file:

<table align=center border=1>
<tr><th>CLASS OF INFORMATION</th><th>	SCT</th></tr>
<tr><td>Organisation Objectives</td><td></td></tr>	
<tr><td>Organisation Operating Policies</td><td></td></tr>	
<tr><td>Organisation Financial Policies</td><td></td></tr>
<tr><td>Performance Measures</td><td></td></tr>
<tr><td>Industry/Other Performance Criteria</td><td></td></tr>
<tr><td>Legislative Requirements</td><td></td></tr>	
<tr><td>Record of Entrance Interview</td><td></td></tr>
<tr><td>Matters Held Over From Last Audit</td><td></td></tr>
<tr><td>Matters Specifically Requested by Audit Committee</td><td></td></tr>	
<tr><td>Matters Specifically Requested by Client</td><td></td></tr>
<tr><td>Engagement Brief</td><td></td></tr>
<tr><td>Organisation Structure of the Target Sections</td><td></td></tr>
<tr><td>Contacts</td><td></td></tr>
<tr><td>Important Contracts and Agreements</td><td></td></tr>
<tr><td>Other Background Information</td><td></td></tr>
</table>	

<br>
<br>

<li> The second step is to form a brief description of the key static elements of the system under review. These elements provide a quick overview or description of the system under review. In most cases they are simple lists with references to the parts of the Audit File containing examples or more information:

<table align=center border=1>
<tr><th>ITEM</th><th>TITLE</th><th>REF</th></tr>
<tr><td>1</td><td>Purpose and Objectives (ie the Process) of the System</td></tr>
<tr><td>2</td><td>Organisation Structure</td></tr>
<tr><td>3</td><td>Documents (Control Forms, etc)</td></tr>	
<tr><td>4</td><td>Records - Manual</td></tr>
<tr><td>5</td><td>Records - Computer</td></tr>
<tr><td>6</td><td>Inputs to the System</td></tr>
<tr><td>7</td><td>Outputs from the System - Primary System Deliverables</td></tr>
<tr><td>8</td><td>Outputs from the System - Reports</td></tr>
<tr><td>9</td><td>Industry and Other Performance Criteria</td></tr>
<tr><td>10</td><td>Matters held over from previous audit</td></tr>
</table>	
		
<br>
<br>

<li> The third step is to identify or construct any desired control models definable from the data so far collected. In some cases the desired control model will be available from the BAG, the Internal Audit Technical Library, other reviews, the Introduction To Internal Audit course, or the appendices of this manual.

* Desired Control Models are discussed in sections 6.6.1 and 6.8
<br>
<br> 

<li> The fourth step is to document the system in a structured manner that supports the concurrent analysis of the system. The following phases must be addressed during systems analysis:

<table align=center border=1>
<tr><th>PHASE</th><th>ACTION</th><th>REF</th></tr>
<tr><td>1</td><td>Conclusion (Opinion)</td><td></td></tr>
<tr><td>2</td><td>Objectives (Purpose) of the Control System</td><td></td></tr>	
<tr><td>3</td><td>Framework of Analysis (Assertions to be supported)</td><td></td></tr>
<tr><td>4</td><td>Assertion Conclusion Matrix (Assertions mapped to S&W)</td><td></td></tr>
<tr><td>5</td><td>Strength and Weaknesses Schedule (S&W)</td><td></td></tr>
<tr><td>6</td><td>Key Controls (Mapped to Assertions)</td><td></td></tr>
<tr><td>7</td><td>Overview of the Control System (Principal Flows)</td><td></td></tr>
<tr><td>8</td><td>Control System Flowcharts/Documentation</td><td></td></tr>
<tr><td>9</td><td>Files & Records in the System</td><td></td></tr>
<tr><td>10</td><td>Cycles in the System</td><td></td></tr>
<tr><td>11</td><td>Transactions and Value</td><td></td></tr>
<tr><td>12</td><td>Documents in the System</td><td></td></tr>
<tr><td>13</td><td>Segregation of Duties Chart</td><td></td></tr>
<tr><td>14</td><td>Other</td><td></td></tr>
</table>	

<br>
<br>

To operate effectively a sound system of internal control should include the following characteristics;

* A simple and flexible plan of organisation which provides clear lines of authority and responsibility.
* A separation of duties between operating, custodial and accounting functions.
* Separation of duties and delegation of authority within each section.
* Duties and responsibilities of all functions should be clearly laid down.
* Clear instructions on the method of authorising and recording transactions providing adequate accounting control over assets, income and expenses.
* Competent executives and department heads to carry out the laid down procedures efficiently and effectively.  Such persons should have capabilities commensurate with their responsibilities.
* Some means to be provided for a continuous internal appraisal of the effectiveness with which internal control procedures are being carried out.
<br>
<br>

</ol>
 



==Systems Documentation Techniques==


Within our assertion structured systems model are many subsystems. These are documented throughout the documentation "tree". Each susbsystem should be documented in the way that best suites our anlalytic needs. For transaction flows this might be some type of data flow, for a delegations analysis it might be an organisation chart, and for a risk analysis it might be a Fitzgerald Matrix, etc.


There are a number of techniques available to the auditor for use in documenting systems of internal control, such as:

* Narration
* Process and Document Flows
* Annotated Data Flows
* Organisation Charts
* Segregation of Duties Chart
* Assertion Matrix
* Lancaster Modelling
* Alogorithm Pseudo-programming
* Simulation


Irrespective of which method is chosen, documentation should include:

* the origin of every document and record in the system
* all processing that takes place on the document
* the disposition of every document and record in the system
* a description of internal controls operating within the system



==Analysing the Model & The Desired Control Model==


At the top level the Desired Control Model is all the selected assertions in the 5 assertion classes being sustained !  Below this level other Desired Control Models map proof conditions for each assertion. 


We generally think of the desired control model in terms of the detailed control features we would wish to see present in the control model in order for these assertions to be supported.


Many Desired Control Models may exist simultaneously for the one system. Each model may address only certain of the requirements dictated by the audit assertions.


The formulation of these models starts at the planning stage when we establish the detailed assertion list for the particular review, and is enhanced throughout the review as our detail of the structure and operation of the system grows.


In simple transaction systems, such as purchasing and payroll systems, the control principles and design requirements can often be established with a high degree of accuracy and detail at the start of the review because experience and legislation lays down in considerable detail the most appropriate method of operation of the system. Many reviews, however, are not so clearly laid down and the auditor must develop a desired model specific to the system.


In building such a model attention should be paid to the 10 management action areas rather than simple the flow of documents or information through the system. At all times the control model should be related back to the assertions which are the purpose of the review to ensure that only relevant controls are being included.


In Section 6.6.1 we discussed how Desired Control Models can be used to analyse the control system when they are formulated in accordance with our assertions. Targetting the desired model directly at specific assertions (rather than generally at all assertions) is more likely to assure us of completeness of analysis of a given assertion. We would therefore expect multiple desired control models to apply.



==Analysing the Model & Information Flow==


Most systems involve a sequence of processes between which information flows. At the highest level (as depicted in the second step of section 6.6) the system consists of:


* Input
* Process
* Output
* Storage


We refer to these four components as "Control Points". Each component is separately controllable.


Each control point is recursively defined. Like a Babooshka Doll, the system is constructed from sub-systems made up of input/process/output/storage which are in turn made from sub-systems of input/process/output/storage components. Each control point is a sub-system. 


We analyse each control point for controls exhibiting one or more of the seven control attributes identified above.


At the information flow documentation stage, we wish to extract these control points from the system and focus our controls analysis on these points. The flowcharting, or flow documentation "language" adopted should facilitate this analysis.



==Analysing the Model & Assertion Testing==


We shall look at the assertion basis to analysing control models in the absence of a Desired Control Model in sections 7 and following.  In particular the method of applying Assertion Testing is outlined in Section 7.7.


==Backlinks==
* [[RIAM:VLA:The Four Phases of the RALSBA| Back To The Four Phases of RALSBA]]
* [[RIAM:Conduct of the Very Large Audit| Back To Conduct of the Very Large Audit (Main)]]
* [[Internal Audit Method| Back To The RIAM (Main)]]

* [[RIAM:Overview: Control Implementation Services (CIS)| Back to CIS]]