"It is impossible for ideas to compete in the marketplace if no forum for
  their presentation is provided or available."           Thomas Mann, 1896

The Business Forum Journal

 

Information Technology Standards for
Control, Security, and Quality Assurance

By  Dr. Paul H. Rosenthal

 

Introduction

This paper presents a set of information technology based internal control standards suitable for adaptation by the vast majority of commercial organizations with extensive information systems operations.  Their objective is to set uniform standards for internal controls, data and physical security and quality assurance, that are usable by information systems, user, customer, and internal IS auditing organizations.

They should apply to all information technology/systems operations in an organization, including centralized, decentralized, and personal computing activities.  The standards presented differ from their implementing procedures in that "procedures" relate to how the work is to be performed, and is often dependent on the specific equipment, software, and applications involved.

All management and professionals involved with information systems have a responsibility to their organization and to the public to comply with these type standards and with Codes of Practice and Ethics accepted by their fellow practitioners.

1.1        Administrative Standards \ Administrative Standards

It is essential that standards and procedure manuals such as those presented in this paper reflect current technologies and practices.

Administrative Standard No. 1 ‑ Maintenance of Standards and Procedures.

Information systems standards and procedures shall be periodically developed, reviewed, and revised by management to reflect the current technological and business environment.

The information systems standards presented are intended to be applicable to almost all situations.  They include such areas as: project management, programming, personnel practices, programming methods, data and physical security, and environmental controls.

The standards shall be maintained by responsible information systems entities in conjunction with such support organizations as internal audit, controllers, and security organizations.

Administrative Standard No. 2 ‑ Approval of Variances.

A procedure shall be provided for justifying, authorizing, and documenting variances from information systems policies, procedures, and standards.

When the occasional situation occurs that requires a deviation from a standard, procedure, or policy, it is important that any variance be properly justified, authorized, and documented.  Such a formal variance procedure allows management and internal audit to properly evaluate information systems functions and can serve as a basis for considering a revision of the standard, procedure, or policy.  Variance procedures should involve all key stakeholders in the decision‑making process to ensure the evaluation of all relevant factors and shall include approval by an impartial executive.
 

1.2        Professional Practice Standards \ Professional Practice Standards

Information Systems Professional Practice Standards concern themselves with: (a) the professional knowledge and qualities, (b) the procedures to be performed, and the judgements exercised by the Information Systems Professional in the planning, development, testing, and operational monitoring of computer‑based information systems.

A recommended set of such standards follow:

• 1.2.1     General Standards of Professional Practice \ 3 General Standards of Professional Practice

The general standards of professional practice are personal in nature and are concerned with the qualifications of the information systems professional and the quality of their performance and communications.

Administrative Standard No. 3 ‑ Proficiency

The development and support of information systems is to be performed by a person or persons having adequate technical training and proficiency.

Administrative Standard No. 4 ‑ Independence

In all matters relating to the development and support of information systems, independence in mental attitude is to be maintained.

Administrative Standard No. 5 ‑ Care

Due professional care is to be exercised in the development of information systems and in the preparation of communications and documentation.

• 1.2.2     Standards of Professional Performance \  Standards of Professional Performance

The professional performance standards relate to development and operational support of cost/effective information systems that meet reasonable organizational needs.

Administrative Standard No. 6 ‑ Planning

The work is to be adequately planned and assistants, if any, are to be properly supervised.

Administrative Standard No. 7 ‑ Feasibility

There is to be a proper study and evaluation of proposed information systems to serve as a reasonable basis for judging that the resultant systems will be cost/effective and meet reasonable organizational needs.

Administrative Standard No. 8 ‑ Productivity

During the development and testing of information systems, generally accepted productivity and quality assurance tools and methods are to be used as applicable.

Administrative Standard No. 9 ‑ Testing

Prior to production operations, information systems shall be adequately tested and documented.

Adequate testing shall include the use of data and procedures that exercise and validate the proper functioning of specified normal and error procedures and conditions.  Adequate documentation shall include user’s operation guides or procedures, computer operations guides or procedures, and generally accepted program and system documentation.

• 1.2.3     Standards of Professional Communication 3  Standards of Professional Communication

The communication standards relate to the reporting of all relevant matters to all significant stakeholders in an information system.

Administrative Standard No. 10 ‑ Reservations

Before designing or implementing an information system, all significant matters and any reservations regarding anticipated benefits, costs, or requirements are to be communicated to all significant stakeholders.

Administrative Standard No. 11 ‑ Significance

All significant matters relating to the design, development, operation, and cost of an information system, are to be communicated promptly to all significant stakeholders in an understandable fashion.

These standards, to a great extent, are interrelated and interdependent.  Moreover, the circumstances which are germane to a determination of whether one standard is met may apply equally to another.  The concepts of relative quality of planning, testing, documentation, and performance underlie the application of all standards.

1.3        Applicability 2 Applicability

The standards and policies included in this document should apply to all information systems including such entities as:

• ·        Decentralized information systems organizations.

• ·        Production operation of Personal Computers ‑‑ including use of Personal Computers and Professional Workstations for production information systems that maintain or produce information deemed an asset to the organization.

1.4        IT Auditing 2 IS Auditing

An IT audit function is normally centralized in the organization, and is responsible for verifying the effectiveness of internal controls and the completeness of information systems results.  They periodically audit all information technology and systems entities to:

• ·       Review and appraise the soundness, adequacy, reasonableness, and application of information systems quality and security controls.

• ·       Ascertain the level of compliance with established information systems policies, plans, standards, and procedures.

• ·       Ascertain the extent to which the organization's financial, physical, data, and human assets are accounted for and safeguarded from losses of all kinds.

• ·       Ascertain the reliability of management and operational data developed within the organization.

• ·       Appraise whether the quality of information systems and operations meets management's objectives.

• ·       Recommend improvements identified during their audits.
   

The effectiveness of IS security and quality assurance depends on the activities of responsible personnel.  For this reason, well‑structured and properly functioning information systems and user organizations are an important factor in information systems control.  Information system organizational standards encompass:

• ·         Controls over IS organizations initiating or authorizing transactions

• ·         Segregation of functions between IS and User organizations

• ·         Segregation of functions within IS and user organizations.

Organizational Standard No.  1 ‑ Segregation of IS and User Functions.

Segregation of functions between IS and User organizations shall be maintained.

To the extent feasible, a segregation of functions between the origination and use of data, and the processing of data shall be maintained.  Specifically, one person shall not have complete control of a transaction from origination through posting.

To maintain such separation all significant IS operations organizations shall be independent of their user organizations.  For small distributed IS operations organizations where such independence is not feasible, specific responsibility for maintaining the maximum separation shall be assigned to an impartial manager.

Organizational Standard No.  2 ‑ Segregation of IS Functions.

To the extent feasible, there shall be a segregation of functions within the IS Department.

A segregation of functions between input preparation, processing, librarian, control, and development shall be maintained, where feasible and practical.

All significant IS organizations shall have separate: computer operations, programming, data control, and librarian functions; control procedures such as closed shop operations so that systems analysts and application programmers do not have access to production hardware, production files, or production programs; rotation of operators; code checking of programs; and required vacations for all employees.  For small distributed IS organizations where such separation of duties is infeasible, specific responsibility for maintaining the maximum segregation and job rotation feasible shall be assigned to an impartial user manager.

Organizational Standard No.  3 ‑ Controls Over Authorization.

There shall be controls over IS organizations initiating or authorizing transactions.

IS organization personnel should not originate or authorize transactions, perform initial data preparation for transactions, have custody of or controls over non‑IS assets, be responsible for maintaining application controls, or have the authority to originate master file changes.  Additionally, the IS organization shall not routinely correct errors unless they originate within IS, for example data entry errors.

Organizational Standard No.  4 ‑ Management Control Over IS.

Management shall exercise effective control over employment of information systems development and operations resources.

The information systems organization shall report to an executive with sufficient authority, sufficient knowledge and the available time to ensure that it receives effective management.  Additionally, as appropriate, the allocation of development resources shall be supported by formally established information systems steering/review committee(s).
 

3 - IS APPLICATION SYSTEM CONTROL STANDARDS 3 - IS APPLICATION SYSTEM CONTROL STANDARDS

The accuracy and completeness of information systems is primarily dependent upon computer application systems controls.  These controls cover the security and quality of: the preparation, flows and processing of transactions; the maintenance of records and files; and the preparation and handling of output reports.  The level of controls built into specific application systems should be based on the materiality and cost/benefit considerations of the application, the level of potential exposure, and user requirements.

The application system controls presented in this section are organized into the six areas defined in Figure 1.  These six areas represent different stages in application processing and include:

·       Transaction Origination by Users

Transaction origination covers the manual preparation and processing of transactions prior to batch submission to information systems as well as direct user terminal data entry.

·       Information systems Transaction Entry

Transaction entry covers the conversion of batches of transactions to machine readable form as well as batch and transaction validation and error handling.

        Computer Processing

Computer processing covers both on‑line transaction processing and batch processing.

·       Data Storage and Retrieval

Data storage and retrieval refers to the management of on‑line files as well as the library management of off-line files.

        D.P. Output Processing

D.P. output processing refers to the validation and distribution of output reports and control totals.

        Data Communications

Data communications refers to transmission of data between remote terminal and remote job entry locations and processing centers.

The extent of application system controls is a matter of system design and audit judgement.  Some control features tend to be redundant, so that absence of individual controls may or may not be significant.  Controls instead should be viewed in terms of overall internal control, security, and quality objectives for the entire application.

3.1 ‑     Transaction Origination Control Standards 2 Transaction Origination Control Standards

Transaction origination control standards govern documentation and processing in the areas of: source document authorization and approval, source document creation, source document error handling, source document retention, and source data control total balancing.  These controls are normally defined in user documentation defining the manual aspects of the application system.  User documentation is expected to include the following:

 a.            Description of the system

 b.            Description of input formats, forms, or screens

 c.            Procedure for submission or direct entry of input transactions such as: transaction identifiers, batch creation, logging and transmittal, and validation of format and coding.
 

 d.            Control and error correction procedures

 e.            Cutoff deadlines and procedures for submission/transmission of data

 f.              Source document storage procedures

 g.             Organizational elements responsible for each procedure/function

 h.             Description of output reports and procedures for balancing report to input controls.

 

Application Standard No.  1 ‑ Authorized Input.

Only properly authorized and approved input, prepared in accordance with management's general and specific authorization, should be accepted for processing by IS.

Each application shall include a procedure for authorizing input transactions.  Authorization is normally evidenced by a signature or a stamp on each source document or by user department approval of a batch of documents.  In on‑line systems where input is not supported by documents, authorization may be controlled  by a program that checks an internal table in the computer to determine that the individual is authorized to both operate the terminal and enter that specific type of transaction.

When input transactions are not approved before processing, controls may be provided by one or more of the following techniques:

  1.          An independent review of transaction output, by either an independent group or by separate individuals within the user department that originated the input.

  2.          A review of input data after it has been processed.  The review may be performed by personnel who have the authority to approve transactions.

  3.         A post‑input review and approval applied to transactions in excess of a specified dollar limit, or selected random transactions, on an exception basis.  This technique is particularly useful in large‑volume applications where many transactions have a low dollar value.

Application Standard No.  2 ‑ Input Recording.

Procedures and forms or screens shall be used to ensure the proper, timely and accurate recording of source data.

Each type of source data should utilize appropriate balancing procedures, and forms or screens for control of the data creation process.  The user documentation should describe these methods and provide for use of one or more of the following techniques:

   1.  Special purpose forms or screens to guide initial recording of data.

   2.  Source document numbering with preprinted or computer assigned numbers to facilitate transaction serialization.

   3.  Special purpose batch control forms or screens to control batching and balancing.

   4.  Transaction type identification to specify the type of processing to be provided.

    5.  Verification of all significant codes and consistency checking of data as feasibe.

Application Standard No.  3 ‑ Input Error Handling.

Procedures and Controls shall be used to ensure that all transactions rejected during transaction origination are corrected and re‑entered into the systems in a timely manner.

Procedures should ensure that all identified errors are accounted for at the end of the processing cycle and corrected and reentered in a timely fashion.  The user documentation shall describe these methods and provide for the use of one or more of the following techniques:

     1.  Visual review of documents, transaction listings or transaction computer files and logging of errors.

     2.  Written error procedures specifying correction methods and responsibilities.

     3.  Verification of re‑entered data and logging of errors corrected.

Application Standard No.  4 ‑ Document Retention.

Procedures and controls shall be used to ensure the proper retention of source documents or information.

Retention of source documents or of information entered in an online basis is needed to provide the capability to recreate data lost or destroyed during processing or due to a disaster.

Limited period storage of source information in user areas is normally the most convenient approach, provided access to record storage facilities is controlled and limited to authorized activities.

Application Standard No.  5 ‑ Control Totals.

Control totals should be produced at the completion of each major processing stage and reconciled with source data control totals.

The application system shall facilitate balancing source data control totals with control totals produced during each stage of processing.  Such balancing shall be performed by someone other than the individual who inputs the data, and should include manual or automated reconciliation of input data totals, file maintenance processing totals, and report totals to source data control totals.

3.2 ‑ IS Transaction Entry Control Standards 2 IS Transaction Entry Control Standards

Transaction entry control standards are necessary to ensure that source data batches are completely and accurately entered into the application system.  These can be classified as: transaction entry, data validation, batch balancing, and error handling controls.  The processing power of data entry devices and local computing systems should be used to automate these controls to the maximum extent possible.

Application Standard No.  6 ‑ Data Conversion.

Conversion of data into machine‑readable form should be controlled utilizing both automated and manual processes.

Conversion of data into machine‑readable form from source documents is often a major source of error.  The most common mistakes involve keying errors and the losing or dropping of records.  Techniques available to minimize errors include:

  1.          Record Counts.  The transactions to be converted are counted.  After conversion, the new records are counted and the total is compared to the original count.

  2.          Batch Controls.  Items to be processed are collected into groups and counted (batched).  After processing, a control total, for example, sales dollars, or cash total, such as, the sum of all account numbers, for each batch is reconciled to the original control total.  Batches can also be numbered, and the computer can be programmed to account for numerical sequence and provide a printed report of missing batches.

  3.         Computer Editing.  The computer can perform a wide range of edit tests on input records including tests of reasonableness, cross‑checks between files to verify relationships, tests for non‑numeric data in a numeric field, verification of all significant codes, and check digit verification.

  4.           Verification.  Data conversion is performed on a dual basis.  After conversion, the two results are compared.

  5.         Anticipated Control.  This technique is based on the anticipated receipt of particular data.  For example, a payroll application may be programmed to expect a time card for each employee and to print an exception listing of those employees from whom no time card is received.

Application Standard No.  7 ‑ Processing Error Handling.

The correction of all errors detected by the application system and the submission of corrected transactions should be reviewed and controlled.

The application system should maintain control over any errors detected until they have been resolved.  Effective control is usually achieved by assigning this responsibility to a specific individual or group.  The errors should be corrected either by the group which caused them or by an independent third party who reviews them with the originator.  The IS organization usually corrects only those errors that originated within IS, such as data entry errors.  A correction or revision that is entered into the system should be subjected to the same edits and controls that were applied to the original transaction that gave rise to the error.

3.3 ‑ Computer Processing Control Standards 2 Computer Processing Control Standards

Computer processing control standards are necessary to ensure that complete and accurate applications data is processed from data entry to output.  These controls are normally implemented through application program functions to verify that all transactions and master records are completely processed, and that control totals balance between processes; and through procedures to verify that processing controls are not bypassed and that separation of functions exists in the operations area.

The application's specific manual controls are normally defined in operations documentation which includes the following:

   a. Brief description of the system

   b. Charts or descriptions of the flow of the processing including definitions of inputs, outputs, files, and processes

   c. Setup and operating instructions specific to the application

   d. Control procedures to be performed by operations

   e. Recovery, restart, and other emergency procedures specific to the application

   f. Estimated normal and maximum run time or availability period of online systems.

Application Standard No.  8 ‑ Operation Error Handling.

Job control procedures should prevent processing the wrong file, detect errors in file manipulation and, highlight operationally caused errors.

As feasible, application programs should check file identification, dates, revision numbers etc. to determine that the proper transaction and master files are being used.

Bypassing of these controls shall be performed only by an appropriate level of management.  Resolution of errors identified by these controls shall be reviewed.

Application Standard No.  9 ‑ Processing Validation.

Validity and balancing checks should be incorporated in processing programs.

Each application program should perform the maximum feasible validation of data and processing including such controls as: limit checks, inconsistent transaction code and master file record status, inconsistent logical relationships between fields, cross‑footing of totals, and validation of self‑checking numbers.

Application Standard No.  10 ‑ Automated Transaction Origination.

Computer generated transactions shall be monitored to ensure that they are prepared in accordance with management's specific authorization.

Computer generated transactions shall be documented, balanced, and reviewed by either an independent group or by the responsible user organization.

3.4 ‑ Data Storage and Retrieval Control Standards 2  Data Storage and Retrieval Control Standards

Data storage and retrieval control standards govern the process of file storage and file error handling.  They differ from computer processing controls in that data controls apply during the preparation of files for storage or removal of files from storage for use by the information system.  Computer processing controls start to apply when the data enters the application program.

Data storage and retrieval controls are implemented primarily through systems software (such as file management, disk management, and data base management systems and through manual backup and librarian procedures.  Therefore, these controls are a mixture of automated and manual procedures encompassing the complete range of applications being processed.

Application Standard No.  11 ‑ Librarian Function.

File librarian procedures shall be implemented encompassing: storage and disposition of detachable media; separation of production, testing, and personal computing files, and management of file generations.

A formal library procedure coupled with safe and controlled on‑site and off‑site storage of backup detachable media and documentation is essential to preserving the vital organizational assets contained in computerized files.

Application Standard No.  12 ‑ File Access.

File access procedures shall be implemented that limit data access to authorized personnel.

Data access controls, as appropriate, shall be based on the security level of data and programs; utilize password systems for persons and programs; provide for separate read, update, delete, add and execute authorization; and for logging of permitted and denied authorizations.

Application Standard No.  13 ‑ File Maintenance.

File maintenance methodologies shall be used that implement backup and restart procedures for protecting the completeness and integrity of data.

On‑line master file maintenance systems utilize transaction logging and periodic master file duplication to provide backup.  Adequate generations of log files, master file dump files, and master files shall be stored both on‑site and off‑site to ensure recovery in the event of an interruption or disaster.

Application Standard No.  14 ‑ File Handling.

File error handling procedures shall be implemented that assure that file usage errors detected, are corrected in a timely fashion.

Procedures shall be implemented providing for reporting of errors and irregularities such as: operator intervention, file usage error correction, file balancing error correction and re‑entry.  Controls should ensure that all file usage errors are accounted for at the end of any processing cycle.

3.5 ‑ IS Output Processing Control Standards 2 IS Output Processing Control Standards

Output controls are used to ensure the integrity of output data from the completion of computer processing until their delivery to the ultimate user.

Application Standard No.  15 ‑ Output Reconciliation.

Output reports shall contain control totals which are reconciled with input and processing control totals.

Output reports shall be designed so that they contain control totals which are capable of reconciliation to input and processing control totals.  When feasible, control total reconciliation shall be performed by both an information systems control group and by the ultimate user.

Application Standard No.  16 ‑ Output Distribution.

System output shall be distributed in a secure manner only to authorized users.

Procedures should ensure that output is delivered in a timely and secure manner only to authorized users.  Special procedures such as dual custody shall be provided when confidential data (such as payroll checks or product costs) is to be distributed.

Output distribution control procedures should include:

• ·        Cover sheets for each report labeled with recipient's name and location.

• ·        Automated or manual distribution management system for directing and logging distribution of all reports.

• ·        Standard distribution schedule for reports so the user knows when to anticipate receipt, and can initiate follow‑up action as appropriate.

• ·        Copy control procedures to ensure that only the authorized number of copies are produced.

• ·        Disposal control procedures to ensure that the output of aborted processing or printing is properly disposed of.

Application Standard No.  17 ‑ Accountable Documents.

Accountable documents storage and handling shall be under dual control of IS and the user.

The storage, handling and distribution of accountable documents (such as blank check stock or negotiable documents) shall be under the control of procedures requiring joint handling by authorized IS and user personnel.

3.6 ‑ Data Communications Control Standards 2 Data Communications Control Standards

Data communication control standards are concerned with ensuring the integrity of data as it passes through both wide-area (WAN) and local-area (LAN) communication channels, and with terminal, message and user identification, and authentication.  Of particular concern is the use of terminals (including networked workstations and personal computers) not utilizing dedicated channels at secure organization locations.

Data communication controls are implemented through a combination of: systems software (such as telecommunications monitors), specialized hardware (such as encryption chips), and procedures (such as sequence numbering of transactions, call‑backs to dialing terminals, and encryption key management systems).  Therefore, these controls are a mixture of automated and manual procedures encompassing the complete range of applications utilizing network approaches.

Application Standard No.  18 ‑ Data Integrity.

Comprehensive procedures shall be utilized to ensure the integrity of data utilizing a telecommunication channel.

Typical communication channels are error prone and not secure.  Therefore, the level of controls needed to ensure the integrity of data deemed "material" can require the use of one or more of the following methods:

• Sequence Numbering ‑ procedures for sequencing and time stamping transactions are normally sufficient to protect against transaction deletion or insertion.

• Dedicated Channels ‑ unauthorized access to dedicated channels requires tapping (except for microwave and satellite links), which is normally sufficient to protect against intrusion by the casual penetrator.

•  Error Checking/Correction ‑ error detection codes, retransmission, echo checking, and check sums are a few of the many methods available for assuring relatively error free transmission.

• Encryption ‑ link or transaction encryption coupled with procedures for key management are normally sufficient to protect against unauthorized transaction modification or insertion.

Application Standard No.  19 ‑ Secure Terminal Access.

Identification procedures shall be utilized for controlling usage from terminals in secure organization locations utilizing dedicated lines.

Identification procedures shall include terminal (including networked workstations and personal computers) identification when appropriate and shall always utilize user passwords and account numbers when controlling access from secure terminals.  Single sign-on methods may be implemented, without additional hardware authentication procedures, only from secure terminals.

Application Standard No.  20 ‑ Insecure Terminal Access.

Identification and authentication procedures shall be utilized for controlling usage from insecure terminals.

Terminals (including networked workstations and personal computers) with network access or not in a secure organization location shall utilize both identification procedures such as hardware-based operator and/or terminal identification and user passwords/account numbers; and authentication procedures such as disconnect and call back or multi‑level password/ identification systems.  Single sign-on methods from insecure terminals shall only be used with both hardware and software authentication procedures.

Application Standard No.  21 ‑ Usage Review.

Network/terminal/transaction usage and attempted usage shall be monitored and reviewed.

On a periodic basis, usage of network based systems shall be reviewed for potential misuse or intrusion.  On a timely basis, denied access to the system (particularly frequent multiple attempts) shall be reviewed for attempted penetration.

Suspected intrusions, attempted penetration or extensive browsing shall be promptly reported to the organization's security organization.

3.7 ‑ Transaction Reconcilement Standards 2 Transaction Reconcilement Standards

An adequate audit trail should exist that permits the identification and location of input, output, and file documents and file records involved in processing a transaction or group of transactions.

Application Standard No.  22 ‑ Audit Trails.

Methods for tracing specific pieces of data through the input/process/output cycle shall be an integral part of an application system.

Creation of adequate audit trails normally involves such approaches as: dating and batch/item numbering all transactions, filing manual documents in a sequence which facilitates retrieval, uniquely identifying all file records and including such identification codes in output reports, and identification of transaction originators.

Computer data center operations standards encompass controls for: security of hardware, software, data and program documentation, and personnel resources; contingency planning in the event of interruptions or disasters; providing a high quality of service; and ensuring efficient utilization of resources.

4.1 ‑ Data Security Standards 2 Data Security Standards

Information systems facilities equipment and files, as an important asset, must be so managed as to minimize the risk of loss of information systems and telecommunications capability.  This implies procedures and systems for protection against people‑created hazards such as fraud and sabotage, and for controlling access only to authorized personnel.

These standards are designed to protect: machine‑readable information, and documentation.

Operations Standard No.  1 ‑ Access to Hardware.

Access to computer and telecommunications equipment and facilities shall be limited to authorized individuals

Physical access to equipment, facilities, and related assets should be restricted to individuals requiring access during the performance of their duties.  Limited access is normally implemented through the use of such tools as: guard services, escorts, sign‑in/out registers, TV monitors, card keys, secure safes, badges, turnstiles, and paper shredders.  Additionally the introduction of potential dangerous or destructive material into the data center or the removal of assets from the data center shall be prevented.

Operations Standard No.  2 ‑ Access to Files.

Access to computer readable information including data files, applications programs, and systems programs shall be limited to those persons or programs specifically authorized.

Access to "critical" information such as payroll files, accounts payable program, and password indexes shall be controlled by comprehensive access control tools and procedures which permit access only on a "needed information" basis and under "dual custody" when feasible.

Access to "routine" information shall be controlled by procedures based on access authorization by class of person or program.  Typical examples are limiting access of programmers to production files, and limiting access of computer operators to application program documentation.

Operations Standard No.  3 ‑ Access to Documentation.

Access to application programs, systems programs, and operations documentation shall be limited to those persons who require it in the performance of their duties.

Program and operations documentation is a valuable asset that should be securely stored and subject to restricted access.  To preclude misuse, it is often appropriate to keep documentation of critical programs in a controlled library and maintain a log of their use.  To the extent practical, detail knowledge of critical applications should be divided between two or more persons.

4.2 ‑ Contingency Planning Standards 2 Contingency Planning Standards

Security procedures are to reduce the possibility that natural events and human activities will cause interruptions in service or loss of capability or assets, while contingency planning is responsible for assuring the continued availability following an interruption or disaster of sufficient manual, computer and telecommunications processing resources sufficient to handle critical applications.  Contingency planning should include provision of facilities, supplies, communications, hardware, software, personnel, and security for both manual and automated processing by information systems and user organizations.

Operations Standard No. 4 ‑ Contingency Planning.

Plans shall be maintained and exercised for assuring the ability to process critical applications in a timely manner during emergencies.

The contingency plans should cover both interruptions, such as power failures, and disasters such as a fire.  The plan should encompass activation, notification, mobilization, emergency operations, recovery, and off‑site storage of data, programs, and documentation.  Exercising the plan should, where applicable, consist of periodic disaster simulations to test management aspects of the plan; regular test runs of critical software at backup sites using off‑site data and documentation; and periodic instruction to all personnel in their duties during an emergency.

4.3 ‑ Service Quality Control Standards 2 Service Quality Control Standards

Procedures should be implemented for assuring that computer service centers provides a dependable and high quality service to users and systems developers.

Operations Standard No.  5 ‑ Hardware/Software Features.

The control and maintenance features available in equipment and software shall be utilized to the maximum possible extent to provide control over operations and to provide reliable services.

Security, accuracy, reliability, and maintenance procedures and systems available: from computer and communications hardware, from systems and applications software, and from vendor services shall be utilized to the maximum feasible.  Bypassing of controls or scheduled maintenance, including actions justified by emergency conditions, shall be reviewed by management to evaluate their potential impact on operational control and availability.

Operations Standard No.  6 ‑ Change Control.

Change control procedures shall be applied to hardware, systems software, applications software, and procedures.

Procedures for change control shall be implemented covering use of such methods as: regression testing, parallel operation of test and production systems, review of change plans and specifications, review of test results, maintaining records of changes, and maintaining capability to return to the previous production system.

Operations Standard No.  7 ‑ Control Group.

A control function, organizationally independent of computer operations, should exist when feasible.

A control function either within a user organization or as an independent group outside of computer operations, should be responsible for: receiving all data to be processed; ensuring that all data received is recorded and processed; following up errors detected during recording and processing to see that they are corrected and resubmitted; for balancing input, processing, and output control totals; for monitoring operational schedules; and for verifying the proper distribution of output.

Operations Standard No.  8 ‑ Operations Documentation.

Operations documentation for computer, peripheral, and telecommunication‑based systems shall be prepared.

Operations guidelines or charts that clearly define operational steps to be followed should be available covering both normal and abnormal conditions.  Such documentation is extremely useful in handling abnormal conditions, in training operators, and in comparing actual performance to planned performance.

The documentation normally encompasses: responses to error messages, recovery/restart procedures, detachable media storage instructions, environmental equipment operations, emergency procedures for both interruptions and disasters, input/output logistics procedures, job initiation and termination procedures, and normal/abnormal system responses.

Operations Standard No.  9 ‑ Systems Testing.

A multi‑discipline systems/acceptance test team or other independent group shall test and evaluate all systems prior to production cutover.

In accordance with systems development standards, a team made up of both user and systems analysis representatives has the primary responsibility for system and acceptance testing.  The operational organization should monitor such testing, assure the validity of production programs and data, and perform production cutover at the successful completion of the testing procedures.

Operations Standard No.  10 ‑ Librarian Group.

A media library group or other persons independent of computer operations and users shall maintain both an on‑site and an off‑site storage facility for detachable media and documentation.

Retention rules vary by system and criticality, and normally are specified during the systems design phase.  Normally these rules specify the retention of one generation of master file and transaction media on‑site and two generations off‑site.  The on‑site and off‑site locations should be sufficiently separated, secure and equipped with reliable environmental system to ensure that a natural or man‑made disaster will not seriously affect an acceptance test team or other independent group’s capability to test and evaluate all systems prior to production cutover.

4.4 ‑ Resource Utilization Control Standards 2 Resource Utilization Control Standards

Information systems and telecommunications are valuable but expensive resources.  Their proper utilization requires effective capacity planning and charge‑back procedures.

Operations Standard No.  11 ‑ Capacity Planning.

Periodic capacity planning shall be performed to assure a proper level of information systems and telecommunications capability.

Capacity plans are normally produced several times a year for a two‑ or three‑year planning horizon.  These plans normally encompass: equipment, services, supplies, facilities, systems software, and operations personnel; and should reflect both current and planned applications.

Realistic capacity planning should also encompass anticipated technology change and new IS tools.  The regular pace of new product introductions in the information systems area often permits planning for the use of the next generation of system to meet new application or growth requirements.

Operations Standard No.  12 ‑ Charging for Services.

User organizations shall be equitably charged for their use of information systems and telecommunications resources.

The billing or charge‑back of information systems and telecommunications usage must be equitable, planned and reported in order to permit users to budget for their use and to determine their cost/ effectiveness.

4.5 Facility Security Standards 2 Facility Security Standards

Data center facilities shall be sited, designed, constructed and operated with sufficient safeguards to protect the facilities, its contents, and personnel from an appropriate level of threats from man‑made and natural disasters and interruptions.

Operations Standard No.  13 ‑ Physical Security.

Protective facilities, devices and services shall be used at a cost/effective level to counter an appropriate level of threats.

The overall security of a data center is based on the physical security related to its site, construction, protective features and operations.  Protection from emergencies related to fire, water, and power/heating/cooling and from intrusions should be designed into the facility and kept at a high level of readiness during operations.

As applicable, such elements of efficient protection, such as: insurance, Halon, fire/smoke/water detectors, hazard inspections, grounds lighting, guards, badges, TV surveillance, log in/out, uninterruptable power supplies and card activated locks shall be utilized.

5 - APPLICATION DEVELOPMENT CONTROL STANDARDS 5 - APPLICATION DEVELOPMENT CONTROL STANDARDS

The objectives of application development control standards are to assure the quality of an application system, and to assure that they contain appropriate Application Processing Controls.  The development control standards presented are based on a development methodology that utilizes a:

•   Quality Circle Approach

The quality circle approach utilizes participative techniques to reduce the roles of quality assurance and security organizations.  Teams representing the stakeholders in a system formally assume full responsibility for assuring system quality and for incorporating an optimum level of controls and security.

•    Project Development Framework

A project development framework is based on a life cycle approach including such phases as: feasibility study, system analysis, system design, system construction, implementation, and post‑implementation review.

•    Project Management Guidelines

Project management guidelines relate the level of project manager responsibility and the level of project development framework tasks to be used; to the size and risk of a particular system.  The guidelines also define the level of approvals, management reviews, user reviews, and technical reviews/ walk-throughs/ inspections required; as well as guidelines for evaluating system quality.

5.1 ‑ Project Authorization Control Standards 2 Project Authorization Control Standards

Project feasibility determination and approval activities apply to the authorization of several levels of projects.

  Change Requests

Evaluation of user change requests should emphasize a team planning approach to assure that all areas of potential impact are considered, and to estimate the resources needed to implement the change.  User management then authorizes implementation of the change.

Small Development/Enhancement Requests

Evaluation of user requests for small implementation projects should utilize the project development framework for project planning as well as a team planning approach to assure that all areas of impact and resource requirements are considered.  Management then approves the project and authorizes implementation.

       Major Development Projects

Major development projects require the performance of a formal feasibility study that defines: requirements, systems approach, project plan, economics, cross impacts, and risk level anticipated.  A formal project review committee is then responsible for approving the project and authorizing implementation.

The objective of a formal project authorization procedure is to reduce the chance of initiating projects that were in trouble the day they started:

Development Standard No.  1 ‑ Project Authorization.

Management shall implement various levels of project authorization procedures to assure that there is a complete knowledge of the projects scope, cost, plans, requirements, impacts, and risks.

The project authorization procedure produces a project charter which represents a commitment by information systems and the user to the systems priority, functions, and implementation plan.  Project authorization control procedures should be in place that assure that the authorization decision is made with full knowledge and understanding of all parties.

5.2 ‑ Project Management Control Standards 2 Project Management Control Standards

Project management is a series of techniques that provide a formal means of monitoring and measuring progress during systems development.  The elements of project management include:

•  Intermediate Work Products that are reviewable by technical, user, and management personnel.
   

•  Review Procedures that define the responsibilities of review teams and personnel.
   

•  Project Status Reports that monitor expenditures versus budget and actual completion versus scheduled completion.

Development Standard No.  2 ‑ Project Management.

Procedures and practices shall provide that the assigned project manager has the responsibility to ensure that all work on the project is in accordance with relevant standards, including quality and security controls, and should hold him responsible for every aspect of system quality and operability.

Project manager education and guidelines to assist in fulfilling these responsibilities normally encompass such activities as: directing progress meetings, producing and maintaining project plans, user relations and change management, determining impact of standards and procedures, and supervising project personnel.

Project management techniques and standards are normally provided to assist the project leader, user management, and D.P. management in formally monitoring and directing the system development process.  Separate levels of procedures and techniques are normally provided for centralized, distributed, and personal computer applications.

Development Standard No.  3 ‑ Project Deliverables.

Every system shall have phased deliverables which are reviewed by appropriate levels of technical, user, and management personnel.

Such deliverables as feasibility studies, functional requirements, system designs, program documentation, implementation/test/conversion plans, operations run books, user operations manuals, testing output, conversion operations, and post‑implementation reports should be produced at the completion of each phase of the development life cycle and reviewed and approved prior to the start of the next phase.

Development Standard No.  4 ‑ Project Participation.

The procedures for feasibility study, acquisition of application packages, development of functional specifications, systems and acceptance testing and post‑implementation review shall require active participation by representatives of users, management and, as appropriate, finance and internal audit personnel.

The quality of an information system is a function of technical quality (the role of information systems), usability (the role of users), and operability (the role of controls) of a system.  The development of effective IS/user communications and understanding is an essential element of producing such a quality system and is provided through extensive user involvement in such activities as:

•         Evaluation of feasibility study and agreements on schedules, costs, benefits, and cross‑impacts.

•         Assistance in producing system specifications and conceptual designs.

•         Assistance in producing user operations specifications.

•         Production of manual procedures and design of forms and reports.

•         Assistance in planning and performing systems testing, acceptance testing, and conversion particularly in the area of generation of test data and validation of results.

•         Participation in key reviews and walkthroughs.

5.3 ‑ Programming Control Standards 2 Programming Control Standards

The procedures for management of the programming process involve such life cycle functions as: production of functional specifications; production of detailed system and file designs; production of development, testing, and implementation plans; programming and testing, production of user, program and operations documentation; and performance of systems and acceptance testing.

Development Standard No.  5 ‑ Programming Process.

Procedures that define a sequential programming life cycle with management, technical, and user reviews at appropriate points, shall be produced and their usage monitored.

The steps involved in the programming life cycle can vary based on the tools to be used.  When using traditional procedural language tools, a typical life cycle includes:

• Design inputs and outputs

• Design files and processing structures

• Estimate equipment, system software and operational requirements

• Produce training, documentation, testing, acceptance and conversion plans

• Design programs and procedures

• Code, test, and document production and conversion programs

• Produce user and operational procedures

• Create test data and projected results

• Perform system test

• Train users and operators

• Perform conversion and acceptance tests

• Convert/implement new system

• Review new system performance

Development Standard No.  6 ‑ Programming Practices.

Programming procedures encompassing such areas as: estimation, naming, data dictionary usage, procedural and nonprocedural language usage, data base management system usage, and automated design, testing, and documentation tool usage shall be produced and their usage monitored.

Procedures for programming practices should invoke proven industry methodologies relevant to the tools being utilized.  Procedures will typically encompass such approaches as: estimation involving estimates of application size, complexity, risk and personnel experience; naming conventions reflecting user and application; usage of data dictionaries for cross‑indexing of fields, records, files, programs and systems; and usage rules for automated tools.

Development Standard No.  7 ‑ Activation Approvals.

Procedures for acceptance testing shall require final approval from appropriate levels of information systems personnel, applicable user personnel, and appropriate levels of management.

Before being used in production operations, a new, revised, or corrected system should receive final approvals from all appropriate stakeholders based on an examination of final test results, a review of documentation, a review of procedures for conversion and operations, and a review of the extent of user and operations training.

5.4 ‑ Implementation Control Standards 2 Implementation Control Standards

Implementation management involves such life cycle functions as: conversion, monitoring of early systems operations, and post‑implementation review.

Development Standard No.  8 ‑ File Conversion.

All master file and transaction file conversion shall be planned and controlled to prevent unauthorized changes and to provide accurate and complete results in a timely fashion.

Review and control procedures shall be utilized to reconcile converted files to original files.  In some particularly sensitive applications, confirmation requests may be sent to third parties; such as employees, vendors, or suppliers, asking them to confirm their data on the files.

Development Standard No.  9 ‑ Post‑Implementation Review.

A post‑implementation review shall be conducted to evaluate the projects: quality, security, planning, management, and performance.

A final report on all projects permits an evaluation of the technical and managerial aspects of the system development process.  A typical post‑implementation review report covers the following information:

•         Is the system considered satisfactory and in accordance with the agreed plan by the users and IS?

•        Comparison of the actual and planned resource utilization, schedule, and cost of the system and the reasons for discrepancies.

•        The extent to which planned benefits have been achieved and the reasons for discrepancies.  Are there any unplanned benefits?

•         The adequacy of controls and any difficulties in operations.

•         Recommendations for future work or changes and their impact on IS and users.

5.5 ‑ Documentation Standards 2 Documentation Standards

Documentation deliverables are not required just for the review process, but because they also are the product of a high quality system development process.

Development Standard No.  10 ‑ Documentation Standards.

Management shall provide standards for the various levels of documentation that define the system and the development process.

Depending on the size, complexity, and risk of an application system, the level of documentation and the persons reviewing such documentation will vary.  Such documentation can include:

• ·         Feasibility Report

• ·         Project Plan (including objectives, scope, and solution approach)

• ·         Functional Requirements

• ·         System Design Specifications

• ·         Implementation Plan (including testing, acceptance, conversion, training, and operations)

• ·         System Operations and User Operations Manuals

• ·         Naming Conventions

• ·         System Run Books

• ·         Project Status Reports (including technical review,  walkthru, and inspection results)

• ·         Post Implementation Report

The standards may define the contents and formats of documentation at various levels of importance (e.g., mandatory, preferred, optional elements).  Such standards shall be kept up-to-date and compatible with current practices.

 

6 - QUALITY ASSURANCE STANDARDS 6 - QUALITY ASSURANCE STANDARDS

The Quality Assurance function associated with an information systems organization is often responsible for a wide variety of functions including:

• ·         Development of Standards

• ·         Administering the Software Implementation Process

• ·         Administering the Quality Process

This section presents standards for the administration of the application implementation and the quality processes of IS functions.

6.1 - Administering the Software Implementation Process 2 Administering the Software Implementation Process

The implementation standards and procedures discussed in this section apply to all software systems including applications software, data conversion software, and systems software.  The most common software implementation process, installing an application system, is presented in figure 2.  The process shown applies however to both applications and systems software.

Quality Assurance Standard No. 1 ‑ Systems Test.

The System Test procedure shall assure the software meets operability, recoverability, and changeability quality requirements; as well as meeting user functional requirements.

The System Test procedure should use selected production data as well as specialized test data containing all known unusual data and error conditions.  The types of tests performed will normally include:

• ·         Functions Testing

• ·         Regression Testing

• ·         Performance Testing

• ·         Stress and High Volume Testing

• ·         Security/Access Control Testing

• ·         Recoverability Testing

• ·         Usability Testing

• ·         Documentation Assessment

• ·         Training Assessment

Quality Assurance Standard No. 2 ‑ Acceptance & Certification Test.

The Acceptance and Certification Test procedure shall assure that the systems can be operated by users and IS operations personnel; and that the system meets user expectations in terms of functionality and service levels.

The test procedures should assure that service levels can be sustained at peak production volumes.  Participants in the acceptance test should include personnel typical of the staffing that will be responsible for production operations.

Quality Assurance Standard No. 3 ‑ Conversion & Installation Verification.

The Conversion and Installation Verification procedure shall assure that routine production operations have been achieved and that the prior system has been terminated.

In order to assure a smooth conversion process, an appropriate mix of conversion approaches shall be planned and executed.  Parallel, phased, pilot, and direct cutover approaches shall be utilized where and when suitable

6.2 - Administering the Quality Process 2 Administering the Quality Process

The Quality Circle (QC) approach to administering the quality of information systems development, support and operations quality assurance and security utilizes participative techniques involves line and project personnel instead of dedicated quality assurance and security staff organizations.

The traditional dedicated staff organization approach requires that quality assurance and security functions be performed by members of a quality assurance or security organization who are not members of the project team.  The function of the dedicated organizations is to certify to the system security and quality.  This certification can only be as good as their knowledge of the system and their level of exposure to the justification, design, programming, testing, and conversion process.  Additionally, dedicated groups operate through a review process, so that their recommendations are normally additions, rather than integrated into the fabric of the system and the development process.

The QC participative organization approach requires that all members of line management and the project team assume responsibility for the quality and security of a system.  Formally organized teams representing the stakeholders in a system or operation, assume full responsibility for assuring system quality and for incorporating an optimum level of controls into the system.

Quality Assurance Standard No. 4 ‑ Management Commitment.

Executive, user, and information systems management shall demonstrate their commitment to quality and security through their actions and communications.

Although the actual operation of an information systems QC program involves primarily project, user, and operations personnel and their immediate supervisors, management plays a critical supporting role.  Their most important function is to establish a quality and security consciousness throughout the organization and demonstrate strongly their commitment.  This commitment is often demonstrated by incorporating quality and security goals in the performance appraisal of lower level managers and technical personnel.

Quality Assurance Standard No. 5 ‑ Security & Quality Measurement.

The level of quality and security of systems and operations shall be measured and results feed back to appropriate QC teams and management.

Management needs to develop quantitative measures of the level of quality and security desired and achieved, provide for the periodic collection and distribution of such data and utilize the data in the administration of information systems development, operations, and support.

Measurements that can be used include such measures as:

• ·         Availability percentage of system

• ·         Response time distribution

• ·         Reruns following a release installation

• ·         Number of compiles during module test

• ·         Number of retries of systems test

• ·         Counting status scores on a detailed security or quality assurance checklist

Quality Assurance Standard No. 6 ‑ Team Responsibilities.

Formal quality circle teams shall be formed and made responsible for monitoring all quality and security goals and standards.

Both functional oriented and project oriented QC teams should be formally created based on shared areas of responsibility.  They should meet periodically to evaluate their efforts and to identify, analyze, and propose solutions to their quality, security, development, and operations problems.

For example, every information systems facility shall appoint a site security officer QC Team that is responsible for enforcing physical and data security policies and procedures; and has the needed authority to penalize violators.

Quality Assurance Standard No. 7 ‑ Resource Availability.

Management shall provide sufficient time and resources for the proper implementation of the Quality Circle program.

Resources and personnel time must be provided for such activities as: training of personnel in QC operations, internal control and security principles, quality techniques; reviews and assessments; researching problem areas, analysis of results; and attending regular meetings of their teams.

The Quality Circle program can not only contribute to meeting quality and security goals but can also be a major contributor to improving the productivity and morale of the entire information systems organization.  The participative environment created by the program is quite compatible with the realities of working in an information systems organization.

---

Doctor Paul H. Rosenthal, is a Professor of Information Systems at California State University, Los Angeles.  Dr. Rosenthal teaches a variety of courses encompassing information systems technology, management, political economy, and systems audit and assessment   Paul has a BS in Education and an MA in Applied Mathematics from Temple University, an MBA from UCLA, and a DBA from the University of Southern California, and has been active in the Information Systems, Computing Science, and Scientific Computing areas for 50 years as a programmer, analyst, manager, consultant, and academic. His early projects included producing the first mainframe sort/merge package for UNIVAC I, writing the proposal for the first mainframe commercial application at GE’s Major Appliance Center, and installing the first mainframe data center at Remington Rand in New York.  He then spent over thirty years in a wide variety of consulting, professional, and managerial positions.  His current research interests encompass the manual and computerized infrastructure aspects of mission-critical transaction processing systems.   Prior to joining California State University, Los Angeles, he spent thirty six years in industry and as a consultant in the United States and in Asia.  His research interests and current projects involve business continuity management, IS/IT education assessment and IS/IT Infrastructure Planning and Technology Systems Assessment.

---

 Visit the Authors Web Site

http://www.calstatela.edu

---

Return to

The Business Forum Journal

---

Search Our Site

Search the ENTIRE Business Forum site. Search includes the Business
Forum Library, The Business Forum Journal and the Calendar Pages.

---

Editorial Policy: Nothing you read in The Business Forum Journal should ever be construed to be the opinion of, statements condoned by, or advice from, The Business Forum, its staff, workers, officers, members, directors, sponsors or shareholders. We pass no opinion whatsoever on the content of what we publish, nor do we accept any responsibility for the claims, or any of the statements made, within anything published herein.  We merely aim to provide an academic forum and an information sourcing vehicle for the benefit of the business and the academic communities of the Pacific States of America and the World.  Therefore, readers must always determine for themselves where the statistics, comments, statements and advice that are published herein are gained from and act, or not act, upon such entirely and always at their own risk.  We accept absolutely no liability whatsoever, nor take any responsibility for what anyone does, or does not do, based upon what is published herein, or information gained through the use of links to other web sites included herein.                     Please refer to our:  legal disclaimer
 

---

Home    Calendar    The Business Forum Journal    Features
Concept     History     Library    Formats    Guest Testimonials
Client Testimonials      Search      News Wire     Why Sponsor
Tell-A-Friend     Join    Experts   Contact The Business Forum

 

---

 

The Business Forum

Beverly Hills, California United States of America

Email:  john@bizforum.org

Graphics by DawsonDesign

Webmaster:  bruceclay.com
 

---

© Copyright The Business Forum Institute 1982 - 2012  All rights reserved.