The Challenge
It is time for audit organizations to reassess their role, take some risk and hopefully gain some new rewards. It is time to improve the customer's view of the audit organization and the benefit of the services provided. There is a basic economic principle. That principle is, as risk increases reward increases; conversely, as risk decreases reward decreases. Those of us working in the audit environment are also affected by this economic principle.
Case in Point - Auditing New Systems/Applications
A case in point can be found in the degree of involvement that an audit organization has in the development of a new automated system or application, commonly called system development. System Development is the earliest phase in the life cycle of a new automated application. It includes design, programming, testing and conversion.
Some audit organizations choose to wait until the automated system or application is finalized and is in full operation, before they begin to evaluate the system or auditability of the transactions that are processed through that system. This decision is based on two primary issues. First, does the audit staff have the technical capability to analyze the automated application, and secondly, can they maintain their professional independence.
Obviously, if the audit organization does not have the skill sets necessary to conduct this review it will not be effective; however, in most cases auditors have special skills that are not always available to the system development team. In particular, auditors are usually skilled in the analysis of internal controls and have a sound foundation in the manual processing environment that is being automated. Any automated system has many of the same control issues that manual systems encounter. Sometimes auditors and managers forget that fundamental element. In many cases, the user community depends almost exclusively on the technical expertise of the information systems personnel to assure that the hardware and software will have the requisite controls. Conversely, the technical staff must rely on the user to understand how the business process fits together. The experienced auditor who understands the manual process can find a niche and sometimes fill a major void in many system development projects.
Audit Independence
In most cases, the difficulty is more likely to be the audit organization's reluctance to take the risk of potentially harming its aura of independence. The school of thought is: If the auditor later finds fault with the system, management might implicate their involvement as part of the reason why the errors or omissions currently exist within the system, or the auditor might feel compelled to overlook these problems because of their earlier advisory role. In effect, the concern is that at some later date, how will the audit department be able to tell management that the system is not operating correctly if it participated in the original evaluation of the application.
Obviously, some important caveats must be understood by both audit and management before a system development engagement is undertaken:
- Clearly define that audit's role is advisory
- Audit should not direct or sign off on system development activities
- During the review process audit should formally provide management with comments and concerns
- The responsibility for system testing and final acceptance belongs to management, even though audit is involved.
New Rewards
The audit organization should look at this type of engagement as an opportunity to provide help to management. To accomplish this the audit organization may have to increase the risk, but this action will also increase the reward. The expectation should be that the auditor will likely identify many, but not necessarily all of the control problems and functional enhancements needed to make the system fully operational. Very likely there exists a potential risk that the system will not function as planned. Very likely it will happen regardless of the auditor's involvement or lack of involvement. Debugging is a common practice and routine element within any automated application. If the audit organization decides not to be involved in the system development due to these risks, it is missing an opportunity that will not present itself again. Waiting obviously reduces the auditor's risk; but also correspondingly reduces the reward or the benefits that accrue to his/her ultimate customer, management. The reward is a chance to make meaningful improvements to a system/application before management invests time and other resources. It also reduces the costs that might be needed to fix problems that are later identified in subsequent audit work.
Summary
If audit organizations expect to be considered a positive influence in the management control system, they should be willing to take risks. Obviously, this does not mean that the auditor is infallible. The auditor's input is based upon the best facts known at that time.
Auditors are often referred to as Monday morning quarterbacks and sometimes worse. The above is just one example of the new type of thinking that must become part of the audit culture in order for auditors to be viewed as a help to management rather than a hinderance. Most audit organizations have the skill sets that can improve a new process before it is put into place. After some positive experiences, possibly management will request assistance before it initiates a policy, procedure or an operational activity. This type of engagement should provide positive opportunities for both management and the audit organization.
|
Quarterly Articles