Standards & An IT Auditor
The term 'standards' is defined in any profession irrespective of its nature, as the minimum expected level of performance desired from an individual or an activity relevant to the needs of that particular profession's domain or any of its segments. Information Technology (IT) auditing has been accepted as a distinct profession carved out of two distinctly separate professions of IT-based data communications and Auditing. The standards adopted by the IT auditing profession are admixture of both of these. The thrust of this paper is to describe some of the activity-based standards borrowed from the erstwhile main-frame world and assimilated in IT audit activities and in particular those, generally accepted by the practitioners of this profession. The attention is focused on the standards within an organisation. Here, some form of judgement is also made about the usefulness of standards in contributing to the creation of a controlled computing environment within an organisation.
Standards
All the professional activities carried out by the IT department should be done in a controlled and standardised manner. Such action shall ensure that the aims and objectives within the specified mandate of the organisation are met by the IT auditor or any professional connected to the job. The auditor must be well versed with the relevant standards in order to give an objective review to the work at a later stage.
In the absence of the clearly laid down standards, the IT auditor will move in a non standardised manner. Consequently, what will be acceptable to the auditor may not be acceptable to the rest of the organisation. In case they're acceptable to both, then only audit review shall become a matter of ascertaining whether the standards are followed and it has proved effective. Often standards are unwritten and, are generally accepted. This is in fact counter-productive because if the standards aren't documented, then there is no guarantee that everyone actually understands them and follows or that new employees are even aware of them.
Where do We Need Standards?
IT auditors all over the globe have accepted that standards are needed to be established, stabilised and followed in the following areas of IT auditing with a specific reference to the system development life cycle. This paper restricts itself to this sub-domain of activities as shown in Figure. (1).(Pl. see the attachment)
System development life cycle (SDLC)
This can possibly be considered a classical structure derived from the mainframe world. However, good practices from the mainframe world can be translated into today's client/server, or more complex type of environment, which is becoming more common. The IT auditor needs to have a reasonable understanding of the environment and, more importantly, a good practical and pragmatic approach to the work while reviewing the effectiveness of internal and external controls and the standards, that the organisation intends to follow. There should be a set procedure, commonly known as the systems development life cycle, for the development of new systems. This is comprised of a series of stages to be complied in the development process. Normally, an authorisation is required at each stage along with a review of progress. Generally, the SDLC stages and required procedural standards areas follows:
Feasibility study.
The overall project feasibility is examined at this stage. A report is required to be issued at this stage and a review to ascertain whether the project should be continued. Various levels of authorisation need to be specified, and this authorisation should normally be by user-management.
System design.
The system is specified in outline and estimates of costs and times are made. Again there should be a requirement for review at this stage, especially to consider the cost and time estimates to determine if the project is still feasible.
Detailed design.
The constituent programs and processing flow are specified. There are a variety of methods to do this, ranging from the pencil and paper method of specifying systems to the use of sophisticated prototyping methods, and the use of CASE (Computer-aided Software Engineering) tools. Prototyping is where a dummy system is built, which can be discussed and tried out by the user until satisfied that it is what is required. CASE tools use various automated methods to determine data structures and process flows from which the system can be generated (almost automatically). Whatever method is in operation, it should be consistently applied throughout the organisation. If many methods are in use, there is a danger of total confusion and wasted effort if responsibility for a project changes mid-stream.
Programming.
The programs are written at this time. Again, there are many methods from line-by-line coding to sophisticated code generation, which can be found in CASE tools. The method is unimportant, but standards and consistency are.
Systems testing.
The computer department to ensure that the system functions as specified does this testing. This testing is important to ensure that a working system is handed over to the user for acceptance testing.
Acceptance testing.
The user to ensure that the system functions, as the user actually wanted performs this testing. With prototyping techniques, this stage becomes very much a formality to check the accuracy and completeness of processing. The screen layouts and output should already have been tested during the prototyping phase.
Data capture.
For new systems, base data must be entered. Time and human resources must be allowed for this.
Data conversion.
Where a replacement system is being implemented there may be a requirement to convert data formats. There must be an allowance for this process to ensure that it is done accurately and completely.
Implementation.
In this stage, the system is handed over to the user for live operation. There can also be a period of parallel running to ensure that the system operates as required.
IT auditors should be involved at all stages of this process to ensure that the procedures are being adhered to and to ensure that the system contains all the required controls. Their involvement is discussed later in this series. The main purpose of the audit review of standards is to ensure that they are in place and are adequate. The effectiveness and adherence to these standards will also be reviewed at a later stage during the review of applications under development.
Technical Standards in SDLC Stages
a.. Analysis and programming
In addition to the procedural controls provided by the SDLC standards, technical standards are also needed for systems analysis and programming to ensure continuity in the design and to reduce the reliance on the writer of the system. However, standards should also ensure that bad practices, which could lead to error and inefficiency in the operation of computer systems, are not prevalent.
Such standards can include the method of structured analysis in use and the tools that support it. This may include the software tools used to aid prototyping or CASE software. Programming standards should cover use of the acceptable languages within the installation. For example, assembler languages are fascinating to use and have their uses where efficiency of processing is a major factor. However, programs written in assembler languages are very difficult to maintain particularly if the original author is not available. The standards should also contain details of standard routines to be included to perform specific functions, naming conventions for program paragraphs and data items, and the like.
b.. Data structures
The world is quickly becoming data-oriented. So much data is being stored in databases and exchanged between systems that standardisation for storing it and defining it is of paramount importance. No longer is it acceptable for a programmer to define file (or database) layouts or organisations. An entire organisation has emerged of individuals who are totally concerned with ensuring that data is interchangeable and is freely portable. Programmers must define standards for the way in which they carry out their task. Such standards should include details of acceptable database organisation, naming conventions, and the procedures necessary to define new data items.
c.. Security
With the continuing move toward data communications and open systems interconnection, more people are gaining access to data stored on computers. These people can be employed by the organisation and access the data over the organisation's own networks, or they can be external to the organisation, gaining access through public networks. Security is therefore becoming more and more important, and not just the physical protection of the computer equipment, The logical controls over access to applications and data are equally critical. Consequently, the security requirements defined in the corporate policy must be implemented in a standard manner. This makes the task of defining security mechanisms easier and allows the appropriate level of security to be applied for the sensitivity of the resource being protected. In general, any security standards should take into account the following principles:
All programs and systems should be designed to allow access only to those individuals and programs that need access to that data. Equipment must be protected against damage or destruction, whether accidental or deliberate. To ensure the security of data, access rights (read, update, delete, etc.) must be defined for all staff according to the varying sensitivity of the data. For example, update access to sensitive data should be severely restricted, whereas read access to general corporate data may be available to all.
These security standards should take into account any legislative requirements such as the need to protect personal data or matters of privacy.
d.. Data controls
All programs and systems should contain mechanisms that will provide for control to be exercised over the data being processed. It is essential that control be exercised in a standard fashion. Standards need to be defined for the control mechanisms to be applied. These standards should take into account the following principles.
a.. Recognised mechanisms are necessary to ensure that all input data is accurate, complete and valid.
b.. Recognised mechanisms are required to ensure that all data processed by the applications is processed accurately, completely and correctly.
c.. Recognised mechanisms must be put in place to ensure that all data stored within computer systems is accurate and complete (known as data integrity).
d.. Recognised mechanisms are needed to ensure that data output from computer systems is accurate, complete and valid.
Documentation
Documentation is probably the last thing that any system developer thinks about when designing and developing an application system or any other computer-related development. Documentation is a waste of time! Nobody ever reads it! It's nearly impossible to keep it up to date! This is possibly true. However, in the event that something goes wrong and an inexperienced person is the only one available to correct it, documentation is worth its weight in gold. There must therefore be some discipline applied within any computer installation to produce some form of documentation. This discipline can come, in part, from publishing required standards.
All systems should be documented to assist the maintenance process and to educate the users of the system. All documentation should follow standard formats to ensure that it is intelligible to all readers. Examples of required documentation include system design specifications, program design specifications, and user guides. The media on whom such documents are stored are irrelevant, so long as they are easily accessible and understandable. Many organisations are now making use of online help facilities, replacing printed user guides.
All aspects of the operation of the computing facility should be documented to provide a readily accessible reference source for all relevant persons within the organisation who require information. However, all this information should not be available to those who do not require it for the performance of their jobs.
All documentation will be accurate, complete and current. Examples of areas that should be documented include:
a.. All security standards, procedures, and guidelines for the computer facility
a.. Descriptions of programs, hardware, system configurations, and procedures
b.. The recipients, contents and functions of all output reports
c.. The functions of all utility programs
d.. Operating procedures and instructions for computer operators (These should contain details of all job handling procedures, processing schedules, console messages, error handling, rerun procedures, checkpoint and restart instructions, paper handling and paper types, tape handling, and all other details necessary for them to carry out their jobs effectively.)
e.. Procedural instructions for users of application systems (These instructions should cover such areas as data coding and input keying requirements. These instructions could be programmed into the system itself in the form of help screens that are available for recall by users when needed.)
f.. Correction procedures (These procedures should include types of errors that occur, correction procedures for all errors, recycling of input, and balancing of output reports.)
g.. Database contents, entities, and attributes and all the entity interrelationships, preferably in a data dictionary
h.. Procedures for the ultimate disposal of various computer media that are stored at remote back-up sites
i.. All application system control procedures
User procedures
Many IT auditors (and analysts) seem to forget that the computer application system is only a part (albeit an important one) of a much larger system. Users also require procedures on the computer applications. As computer systems should be governed by standards, so should user procedures. Such standards should cover areas like filing; disposal of printed output, retention of source documents and other documentation and rules governing signing authorities and custody of valuable documents such as cheque stationary.
End-user programming
As computer departments expand into monolithic structures, which cannot deliver all user requirements on time, the users themselves have begin to develop their own computer systems. These are mainly pure management reporting and analysis using report generators or 4th-generation languages (4GLs). This has increased rapidly with the provision of intelligent workstations (PCs) on the users' desktops. However, most of the tools they use have given them the ability to update data, as well as extract and analyse it. There is danger in allowing such systems development outside the controlled (?) environment of the systems development area. Having said this, it is often more economical to allow a user to develop analytical and reporting systems than insist on a formally developed system. In order that the organisation has some sort of assurance that the programmes work and the reports are valid, the user-programmer should be subjected to some form of standards. IT auditor will find these standards equally useful and effective to carry-out the tasks. These possible standards may include:
a.. RULES GOVERNING HOW DATA CAN BE MANIPULATED (for example, can production data be updated by user programmes, or must copies always be used?)
b.. RULES GOVERNING THE TYPES OF SOFTWARE USED FOR END-USER PROGRAMMING (Is standard software provided or is the end-user free to choose the best software for the particular purpose?)
c.. RULES REGARDING THE USES OF OUTPUT FROM END-USER PROGRAMMES (For example, is it acceptable for negotiable documents to be produced by end-user written programs?)
The incorporation of standards in no way should be treated as the imposition of additional burden of bureaucratic job. Many such organisations where this kind of view will be taken up by the employees, are in fact those ones who do not have any set of standards incorporated in the policies. However, the implementation of such policies and standards, although seemingly wastage of time to introduce, will prove highly beneficial in monetary terms. The implementation of standards shall make an organisation consistent and homogeneous in all the respects. This type of consistency will turn an organisation into an efficient and equally effective one.
J.P. Pathak Phd. is a Master's in Financial Management from the University of Rajasthan, Jaipur and earned his Doctorate in Management Studies on his thesis Information Systems Auditing in Distributed Data Processing Environment from University of Goa. He is presently Head of the Department of MOP (A Graduate-level Programme in Modern Administrative Management Area) at Government Polytechnic Institute, Panaji in the State of Goa (INDIA). Dr. Pathak has published many papers on IS/IT auditing in national and international journals and a recently released book on Auditing in Computerised Environments (Allied) New Delhi. He can be contacted at pathakjp@goa1.dot.net.in
