The Systems

Development
Audit
Chris Nelms

key area of responsibility of best qualified to do this are by:

13 A the computer auditor is the

audit of systems under devel-
opment: by contributing ad-
vice at the design stage, the auditor
makes it far easier to take account of
1. Helping control the ‘exposures’
resulting from the project, and;
2. giving management reasonable as-
surance that this has been done.
his or her advice than it would be after ‘Exposure’ is the product of the
the system has been built. Much has probability of an event occurring, and
been written on how to tackle various the cost of that event occurring. Thus
parts of the systems development it is controlled by reducing either the
audit. This article attempts to put the chances of the event, or its effects, or
constituent parts of the system devel- both.
opment audit in perspective, by pro-
viding a framework defining the Thus the auditor’s role is to:
objectives, scope, and nature of that 1. Identify exposures;
involvement. It provides an overview
of what a computer auditor should be 2. assess whether they are within
aiming to achieve by his or her acceptable limits;
involvement in a systems development 3. consider how to reduce excessive
project. What are the purposes of exposures, commensurate with
becoming involved in a systems devel- the cost of control and the likely
opment project? How does one go rewards for taking the risk; and
about it? What aspects of the project 4. provide timely, independent advice
should the auditor be looking at? What
on this to management and the
sorts of advice is s/he best qualified to
development team.
give? This article attempts to answer
these questions. There are two main types of ex-
posure arising from any system devel-
opment project:
1. Project exposures. These would
Objectives mean return on the investment if
The computer auditor’s overaIl objec- the project misses the target,
tive, like everyone else involved, is to because, e.g., the system is not
contribute to the success of the what the business requires, does
project. The ways in which s/he is not produce the expected benefits,

Computer Audit Update l June 1996

0 1996, Elsevier Science Ltd.
 costs more than budgeted for, Systems development
takes longer to develop than
methodology and project
planned, suffers premature obso-
lescence, or is costly to operate or management methodology
maintain.
Review of the systems develop-
2. Lack of built-in automatic con- ment and project management
trols. This would necessitate methodologies, to ensure that
costly retrofitting of controls, op- best applicable practices are fol-
erating laborious and less reliable lowed in developing the new
manual controls, or suffering the system, notably in the treatment
consequences of lack of control. of security and control issues. This
These could include errors, costly should be carried out at the start of
control failures, embarrassment, or the project, and contIrmed from
loss of competitive advantage. available evidence during the pro-
The methods for addressing these ject.
two types of exposure are dealt with Review of project deliverables
below. The amount of work that will at each stage in the project for
be required to gain sufftcient assur- compliance with the methodology
ance in each area will vary depending, and best practice. This includes the
among other things, on the rigour of review of deliverables presented at
the systems development methods formal approval points, to help
used. Where recognized systems de- management in the approval pro-
velopment and project management cess. However, it remains up to the
methodologies are used, it is far easier users to ensure the deliverables are
to gain assurance that best practice is giving the business the system it
being followed. The existence of pro- requires. This part of the audit is
ject documentation will reduce effort critically dependent on the quality
by enabling reliance to be placed as far of the methodologies followed, and
as is reasonable on evidence of work the quality of project documenta-
done by others. tion produced; deficiencies in
either makes it far harder and more
time consuming to assess whether
acceptable practices are being fol-
Project exposure lowed.
This can arise from: 3. Review of project management
monitoring reports throughout
Deficiencies in systems develop-
the project for evidence of satis-
ment methodology and project
factory reporting and control of
management methodology, or its
time and costs.
application.
4. Review of system and user
Lack of security in the technical
documentation, to ensure that
environment in which develop-
the system can be used, operated,
ment is carried out, causing, e.g.,
and maintained, efficiently and
loss or unauthorized modification
effectively.
of program code, unauthorized
disclosure of program code to
competitors, or unauthorized dis-
Security of the development
closure of sensitive data used for
testing. and live environments
Problems with data conversion, This is an audit in itself, and should
causing, e.g., data corruption or include as a minimum:
unavailability.
1. Review of logical access and pro-
These can be addressed as follows.

Computer Audit Update l June 1996

‘c 1996, Elsevier Science Ltd.

II
 gram version control procedures 6. Auditability. Ensuring that there
in the development environment. are sufficient audit trails to enable
2. Review of logical access and pro- the system to be audited, and
gram change control procedures, queries resolved.
once there are live data and pro- It is the responsibility of the project
grams to protect. team to design and implement appro-
3. Review of access to any sensitive priate internal controls, using the tools
live data used as test data. and techniques of its choice. Audit’s
role is to advise and review throughout
the project, from its earliest stages, to
help ensure that appropriate controls
Data conversion
are identified and implemented. The
This, too, is an audit in itself, a mini auditor should discuss the timing and
systems development audit. In addi- methods for designing controls early in
tion, it needs to include: the project, to ensure that s/he is
effectively involved at the appropriate
1. Reviewing arrangements for ensur-
time, and that the methods used are
ing that data is converted comple-
satisfactory. The use of software
tely and accurately.
packages rather than bespoke devel-
2. Reviewing the results of data con- opment will limit the extent to which
version for evidence that data was controls can be built in; and many
in fact converted completely and should already be there. There is,
accurately. however, a need to ensure that full
use is made of the package’s control
features.
Internal Controls At the requirements specification
Everyone seems to have their own list and design stages, the computer audi-
of the objectives of internal controls, tor should advise on the exposures to
but they all tend to cover the follow- the system, or conversely the control
ing: objectives, to ensure they are identi-
fied, and assess the appropriateness
1. Security, i.e. protection of data and adequacy of the internal controls
from: specified.
a) accidental or deliberate disclo-
Once the system is built (or the
sure to unauthorized persons;
software package acquired) the com-
or
puter auditor should assess the control
b) unauthorized modification or features and advise on implementing
destruction. them effectively. After implementa-
2. Privacy. Protecting the rights of tion, s/he should assess the effective-
individuals and organizations to ness with which they have been put to
determine for themselves when, use.
how, and to what extent informa- Three types of control are needed:
tion about them is to be trans-
mitted to others. Preventive, to stop errors in the
first place (e.g. password-con-
3. Accuracy. Ensuring that data is trolled access to the system; users
correct, valid, and up-to-date. restricted to certain menus and
4. Completeness. Ensuring that all options; input validation checks).
data which should have been Detective, to spot any that get
processed, has been. through, or prove that none have
5. Resilience. Safeguards against sys- (e.g. exception reports; enforced
tem failure, and provision for re- segregation of duties; management
covery. reports; control total reports to

Computer Audit Update l June 1996

0 1996, Elsevier Science Ltd.
 prove that processes have worked; suggestions can most easily be taken
audit trails to enable the system to account of. Conversely, the auditor
be audited). should ensure s/he is easily accessible
3. Corrective, to help put them right to project staff, even when spending
periods of time on other assignments.
(e.g. audit trails enabling queried
transactions to be traced from start
to end, or end to start).
Independence and
reporting

Carrying out the work The key attribute of audit is to provide

management with independent advice
This section is concerned with the and opinions.
ground rules within which the auditor
carries out his or her work, and is The auditor can only be indepen-
considered under the following head- dent, and be seen to be independent, if
ings: his or her role is restricted to stating
his or her opinion, and s/he takes no
1. Access to project staff and deliver- responsibility for the design of any part
ables. of the system, or of controls. Hence
2. Audit independence and reporting
lines.
3. Staffing and timing of audit work.

Access
Audit opinion is of most use if given in
good time. For this to happen, the
computer auditor requires timely ac-
cess to information both on demand
advice and assistance should be pro-
and on a routine basis, e.g.:
vided to management, but opinions
1. Inclusion on circulation lists of should be offered only by indepen-
significant project documents and dently reporting on the proposed
deliverables, e.g. management re- system. The auditor should not be
ports, technical reports, project responsible for signing off the system
plans, project progress reports, jointly with management or engaging
reports of special studies, quality in any other act which indicates that s/
assurance reviews, terms of refer- he shares responsibility with manage-
ence, draft contracts, etc. ment for the proposed system, such as
2. Inclusion on circulation lists of designing or implementing systems of
steering committee minutes. internal control. S/he may, however.
issue reports or memos concurrently
3. Inclusion on invitee lists for sig- with management ‘sign-offs’, which
nificant meetings, e.g. the steering indicates his or her view on the system
committee. development, based on the work done.
Ideally this should be built in to the The results of audit work should be
project administration and plan, and reported by means of formal reports to
development staff including consul- the Project Director at key stages in
tants and contractors should be the project, supplemented by memos
authorized and encouraged by the and meetings as necessary, and less
Project Director to spend time with formal comments to project staff on
the auditor and invite comments on draft project documents. Periodic re-
deliverables while still in draft, when ports summarizing this activity, and

Computer Audit Update lJune 1996

#T 1996, Elsevier Science Ltd.
 the main recommendations and con- audit programme should address at
clusions arising from it, should be each point in the project.
prepared for senior management.
1. Project initiation and estab-
lishment. Review deliverables
for evidence of:
Stafing and timing
a) Clear scope and objectives.
Where internal audit staff who are not
computer audit specialists have a b) Sound choice of technical ap-
better knowledge than the computer proach.
auditor of the business and of the c) Good reasons for going ahead.
objectives of internal controls, they
2. Project management. At appro-
should be asked to provide specific
priate times, seek evidence of good
advice on the design of internal con-
project management in terms of:
trols in their areas of expertise.
a) Quality of management and de-
The timing of the work is of course velopment methodologies.
dependent on the timing of the pro-
b) Quality and quantity of staff.
c) Appropriate project structure
and organization.
d) Good project planning.
e) Good systems for monitoring of
time and costs and taking cor-
rective action.
3. Outline design (User require-
ments definition/Feasibility study/
package evaluation). Seek evidence
that users’ requirements are accu-
rately and comprehensively docu-
ject, which it should follow as closely mented, in terms both of functions
as possible. The aim is to perform and of system performance, capa-
numerous short audits at the appro- city, and resilience. Review the
priate stages in the project. If the more detailed versions of the initial
auditor is not assigned full-time to deliverables for evidence of:
the project, this would enable him or a) Clear scope and objectives.
her to fit other computer audit work
b) Sound choice of technical ap-
between and around these audits. S/he
proach.
should, however, aim to remain con-
tinuously available for consultation and c) Good reasons for going ahead.
planning. 4. Detailed design and specifica-
tion. Seek evidence that:
Specifications are accurate and
Audit work at each comprehensive.

project stage b)Contracts adequately protect

the organization.
So much for the theory. To help
translate it into practice, a suggested c) Adequate internal controls and
summary of the audit work that should audit trails are included in the
be carried out at each stage in a design, advising as necessary.
systems development project is set d) There are good reasons to go
out below, indicating the areas the ahead.

Computer Audit Update l June 1996

0 1996, Elsevier Science Ltd.
5. Programming. Seek evidence William E Perry Enterprises Inc
that: 1981.
a) Programs are adequately docu- 7. Travis, B.J.: Auditing the develop-
mented and tested. ment of computing systems, But-
b) The development environment terworths.
is secure. 8. FitzGerald, Jerry: Designing Con-
6. File creation and data conver- trols into Computerized Systems.
sion. Seek evidence that data is Jerry FitzGerald & Associates.
converted completely and accu-
9. Thomas A.J., & Douglas I.J.: Audit of
rately. Computer Systems. NCC
7. User acceptance testing. Seek
10. The EDP Auditors Foundation, Inc:
evidence that testing is well
Control Objectives.
planned and carried out, problems
dealt with, and users are satisfied 11. IIA Computer Audit Control and
that their system enables them to Security Manual.
do what they need to do (including
12. BS7799: Code of Practice for In-
controlling the system).
formation Security Management.
8. Implementation. Seek evidence
of: 13. CIPFA Computer Audit Guidelines.

a) Good planning. 14. Ollerenshaw, Zoe: ‘Purchasing

quality software - meeting agreed
b) Good user training. criteria within an agreed timeta-
c) Secure configuration of the sys- ble’, Computer Audit Update, April
tem. 1993.
9. Post-implementation. Seek evi- 15. Doughty, Ken: ‘Red flag auditing of
dence of: information systems development’,
EDPACS, December 1994
a>Realization of benefits.
16. Rothberg, G.B.: Structured EDP
b) Learning of lessons for future Auditing, Lifetime Learning Publi-
developments.
cations.
c>Effectiveness of planned con-
17. Morriss, Peter: ‘The Auditor’s Role
trols.
in Creating Successful Systems’.
Computer Audit Update, March
1991.
Bibliography 18. Vallabhaneni, S. Rao, Information
1. ICAEW IT STATEMENTS: 2 - Systems Audit Process, EDP Audi-
Good accounting software. tors Foundation Inc.

2. ICAEW IT STATEMENTS: 3 -
Costs and benefits of IT projects.
3. ICAEW IT STATEMENTS: 6 - Chris Nelms MSc, BSc(Econ) , FCA,
Systems development and acquisi-
CISA is Computer Audit Manager
tion.
with MEPC pk. Having trained
4. ICAEW IT STATEMENTS: 7 - with what are now KFMG, he
Quality Assurance. has over a dozen years’ experience
in computer audit in banking
5. ICAEW IT STATEMENTS: 8 - The and financial services, and
Acquisition of Computer Systems.
writes regularly on computer
6. Perry, William E., Audit participa- audit matters.
tion in EDP Systems Development,

Computer Audit Update l June 1996

;i-,l 1996, Elsevier Science Ltd.