View source for RIAM:Overview: Control Implementation Services (CIS)

==Introduction==

From the audit perspective, incorporation of CIS in the internal auditor's service offering is a dramatic advance in prevention of errors in systems by involving specially trained Internal Audit staff in the design phase of both manual and computer systems.  We call these specialists "'''''Controls Analysts'''''".  


A Controls Analyst must generally be trained both in the CIS techniques and the underlying discipline to which the system relates. For example, in the computer environment, where CIS originated, this means skilling as dual specialty as an Internal Auditor and Systems Analyst.


In a nutshell, the idea behind CIS is that the auditor participates as an advisor to a systems implementation / development team during the design stage and at each module delivery phase. Properly performed, CIS should provide substantial cost savings both in initial systems development, and subsequent systems maintenance and review.


In general management consultancy terms we might describe the CIS function as process reengineering, process design, system analyst, business simplification, and a host of other names essentially refering to the function of designing business processes.


From the internal audit perspective, the particular dimension of the function that interests us is the control model embodied in the process. RIAM therefore includes the CIS as part of its control verification model, because we aim to eliminate control failure at the earliest possible point in any process.


If we consider the function of developing or implementing a new business system as a control process in itself, logic dictates that we should stop a bad system at the source...not just after it has gone live.



==Aren't auditors only meant to shoot the wounded?==

The idea that auditors should participate in systems delivery in some form, is contentious in auditing circles.  The argument advanced by those opposed to auditors participating in system design is that processes and systems are management's reponsibility, and auditors must maintain independence in order to be able to assess them.  While reasonable, this argument ignores the mechanics of the audit process.  Our argument is simple:

<ol>
<li>  As auditors, we review systems that are already in place and make recommendations as to how these systems should be changed to satisfy some independent standard of control. In a properly governed organisation, these recommendations come with the full force of the audit committee, which is a committee of the board, or governing council of the entity.  Assuming the recommendations are endorsed by the Audit Committee, management have no choice but to implement them.


<li>  The whole point behind RIAM is that auditors should be sufficiently confident of their analytic skill set, to make firm systen redesign recommendations, not just recommend that management "take another look" at the system.


<li>  If, as part of management, you implement a system, and I as the auditor recommend various changes to the processes to improve control, which you then assess, accept and implement under the mandate of the Audit Committee...who has really designed the resulting system?  In the event that the redesigned system fails because of its design management can still claim that they merely implemented audit's recommendations.


<li>  Worse, as the cost of retro-fitting new processes and controls climbs as the software nears completion (or goes into production), waiting until after the system has gone live, and a failure has occurred to review the control model as tantamount to professional negligence.

</ol>



If we, as auditors, are eventually going to review a system in production, we should be doing as early in the implementation as possible so that thye costs of implementing a decent control regime are minimised.

If our real reason for delaying, is because we are not capable of making correct judgement calls on the sufficiency of control, or standards of good control design, then as a profession we are beneath contempt, and deserve to be relegated to the periphery.  

There is little benefit from wandering arround the battle after a strategic disaster clubbing the wounded and counting the dead to prove that the battle was badly planned, when everyone who paeticipated already knows this.  Far better to fix the strategy before it is applied, and ensure victory.


  
==Scoping the Control Implementation Service==

Lets start by clarifying what is NOT part of the CIS: 

1. The purpose of the process.  The purpose of the process or system is management's responsiblity.  

2. The cost benefit ratio of the process.  The relationship between risk, cost and return is also management's responsibilty.


CIS is about taking those structural parameters and applying scientific control modelling to optimise processes/systems with a control regime that makes those planned outcomes as predictable and reliable as possible.  


The Internal Auditor works with the business analyst and other designers to:


* Translate defined system specific objectives, existing business policies, external regulations & statutory obligations and already mandated business procedures into control standards for the new system.
* Make recommendations of new policies and procedures that may be required or desirable as a consequence of implementing the new system.
* Assess risk and properly inform management of risks and treatments so they can make the decisions to Tolerate, Treat, Terminate or Transfer/share risk, or apportion their reaponse between those options.
* Design the control procedures, within agreed transactional throughput and reliability levels where treatment is selected as the strategy by management.
* Specify test sets/test scripts that will verify successful design (or design failure) during the project, and adequacy of imp0lementation of the control design.


The method of operation is therefore one of a consultant. 


The Internal Auditor works independently of the business design team, possibly as part of the testing team to verify that:


* The control design works as expected,
* Has been implemented as intended.


Ideally a separate auditor/audit team monitors and reports on the implementation project itself.  In any case, this is a normal internal audit function and not delivered as part of the CIS.
 

==What are the CIS Control Attributes?==

The narrower focus of the controls analyst comparecd to the more general business analyst, allows us to precisely specify the focus of the consultant's work.


Using a specially developed process of Annotated Data Flow Diagrams you should analyse developing systems at points of:

* Input;		
* Processing;
* Output;
* Data Storage; and
* Transmission.


The reader will quickly notice the link between the CIS service focus and the ALSBA method (see [[RIAM:VLA:DOCUMENTING & ANALYSING THE SYSTEM OF INTERNAL CONTROL]] & [[RIAM:VLA:ASSERTIONS]]).  In fact there is virtually no difference.  Manual and computerised information systems are evaluated within a frame work of Control Attributes such as:

<table >
<tr >
<td >
* Access Security</td><td>Ability to protect information and other resources against unauthorised, accidental or deliberate modification, disclosure or use.
</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.
</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, and reliable.
</td>
</tr>
<tr >
<td >
* Process Integrity</td><td>Ability to ensure that the process is consistent complete, correct and timely.
</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.
</td>
</tr>
</table >



==How is the CIS Engagement Implemented?==

The process of CIS involves the auditor becoming part of the development team working in tandem with the Systems Analyst, from the initial planning and specification stages through to the design stage. To preserve independence, the auditor must NOT be part of the implementation or maintenance of the system, but may participate in the testing, evaluation and review phases.


The basic steps in the CIS engagement are:

# Development of User Requirements;
# Threat based Risk Analysis;
# Feasibility analysis;
# Assumption Specification
# Specification of the Control Requirements;
# System Design;
# System Testing;
# Acceptance Testing;
# Crash Testing
# System and Performance Evaluation; and
# Review.



==The Method of Performing CIS==

The technical details of process modeling and design used in CIS can be found in the RiskWiki under [[Business Process Reengineering - Introduction]].

The technical detail and the theorectical control model to apply as the control portion of the process objectives in the [[Business Process Reengineering - Introduction| Business process model]] for conducting control analysis used in CIS can be found in the RiskWiki under [[RIAM:VLA:DOCUMENTING & ANALYSING THE SYSTEM OF INTERNAL CONTROL]], [[RIAM:VLA:ASSERTIONS]], and [[RIAM:Overview: The Assertion Linked Systems Based Audit (ALSBA)]].

==Backlinks==

* [[RIAM:Overview of the Method| Back To The RIAM : Overview (Main)]]  ||  
* [[RIAM:Overview: The Five Arms of RIAM - At a Glance | Back To The Five Arms - At a Glance]]