Chapter 9. Develop/Review Controls and Procedures




This chapter looks at developing and reviewing controls and procedures, the sixth step in the validation process.

If the computer system is a new one, then you will need to develop the controls and procedures or check the suitability of existing generic procedures applicable to the site or department.

If the computer system is an existing one, then you will need to review the controls and procedures and update them if required.


Controls and Procedures  


Controls and procedures ensure that the system retains its validated status in daily use. They must be approved and implemented before the system can be certified as validated.

Note: The creation and revision of control procedures must be controlled and approved according to site/departmental SOPs.



The responsibility for each control and procedure rests with the department responsible for that activity.



Controls and procedures should (as a minimum) cover the following areas:

·         problem reporting

·         change control

·         back-up

·         recovery

·         business continuity

·         operating procedures

·         security administration

·         database administration

·         purge and archive procedures

·         output controls

These procedures are outlined in the rest of the topics within this chapter. The precise controls and procedures required would be determined when you determine the validation activities that will be undertaken (step 2 in the validation process).



For every procedure that has been identified in the above areas, there should be documented evidence that the people affected by the procedure have been trained on its use.

Training provides a degree of assurance that the procedures are being followed.

Training must be repeated any time that a significant change is made to a procedure.

For procedures that are not routinely used, for example recovery procedures, training should include testing of the procedures. This will ensure that the procedure is adequate and that it can be followed.

Records should be kept of all training/testing activity.


Problem Reporting and Change Control Procedures  


This topic looks at the problem reporting and change control procedures that should be in place.

If these procedures are not in place, then they must be developed, approved and implemented.


Problem reporting

A problem log should be kept and a procedure should be written for logging, tracking and resolving system problems.

The procedure should reference the change control procedure to be followed if the problem resolution involves a change to the system.


Change control

All changes to the system must be controlled and documented by a formal change control procedure.

The procedure must include steps for:

·         assessing the impact of the change

·         testing

·         controlling the implementation

Note: Testing must ensure that the change is put in place with no adverse effect to the functioning of the system.

The change control procedure should be in place prior to the start of the qualification activities to ensure that any changes required during the validation are captured and processed in the correct manner.


Change control procedure

The change control procedure should cover changes to the:

·         hardware

·         system software (operating system)

·         application software

·         data

This should include the process by which application owners are to be notified of changes.


Changes to hardware

Changes to hardware should be controlled so that appropriate testing and documentation upgrades are performed.

Users should be informed of the change and, where appropriate, be involved in testing and approving the change.

Any external consultants making changes to hardware should be aware of this procedure and comply with it.


Changes to system software

Although the system software (operating system) does not require formal validation, it does require a change procedure to be developed.

This is because changes to system software can have an impact on the validated system that runs on it.

Changes to the system software should be performed in a controlled manner according to a written procedure with appropriate testing and notification to end users.


System software does not require formal validation for two reasons:

·         there is usually extensive industry experience with system software

·         system software is validated indirectly through the validation of the application


Changes to application software

Changes to application software should be controlled so that they are only implemented after the appropriate re-validation has been performed.

This would include:

·         testing

·         re-qualification

·         training

·         documentation

Users should be involved in performing the re-validation and approving the change.

Revision control should be in place to ensure that the version of software can be uniquely identified in the present and in the past.


Changes to data

Changes to master data or control data that sets the parameters or configuration of the system should be restricted to authorized personnel and should be tracked. A written procedure should describe how this is to be done.

The degree of control that is placed on changes to master data depends on the effect that data has on the functioning of the system.

Changes to historical data in the database should be covered under Database Administration procedures (See, Operating and Administration Procedures in this chapter).


Back-up, Recovery and Business Continuity Procedures



This topic looks at the back-up, recovery and business continuity procedures that should be in place.

If these procedures are not in place, then they must be developed, approved and implemented.


Back-up procedures

Procedures should be in place for performing regular back-ups of the system.

Back-up procedures should include the following information:

·         back-up frequency (this should be appropriate to the criticality of the system)

·         back-up medium

·         specific back-up procedures

·         how the back-ups will be identified and stored

·         maximum amount of data that could be lost due to the back-up schedule

·         specifications for testing the procedures


Recovery procedures

Procedures should be in place for describing how the system will be restored using the back-ups should it be necessary.

Recovery procedures should include the following information:

·         how the appropriate back-ups are to be identified

·         specific recovery procedures (including partially completed transactions)

·         specifications for testing the procedures


Business continuity

A business continuity plan should be available to describe how the business can continue to operate in the event of the system being unavailable.

The plan should include:

·         contingency procedures

·         disaster recovery procedures


Contingency procedures

Contingency procedures describe how the functions provided by the system can be performed manually in the event of the system being unavailable.

Contingency procedures should include:

·         manual operating procedures

·         the tracking and reconstruction of manual events to update the system when it is restored

·         a reflection of how long the business could operate without the system before there is a danger of material financial loss to the business


Disaster recovery procedures

Disaster recovery procedures describe how the organization can obtain alternate computer resources in the event of the primary computer system being unavailable.

These procedures would be followed if the system were down for longer than manual procedures could feasibly be used.

The disaster recovery procedures should include:

·         alternate hardware and software

·         all peripheral equipment

·         necessary communication lines


Operating and Administration Procedures



This topic looks at the operating procedures, security administration procedures and database administration procedures.

If these procedures are not in place, then they must be developed, approved and implemented.


End-user operating procedures

End-user operating procedures describe how the users are to use the system in their daily jobs.

These procedures differ from the end-user documentation supplied by the supplier or developer in that they are specific to the company, the department, and the task at hand.

The end-user documentation may be referenced to avoid duplicate description of standard system functions.

For a given system there may be multiple procedures for use within different departments or for different tasks.


Systems personnel operating procedures

Operating procedures for systems personnel describe any routine system maintenance activities.

Written procedures are required for activities such as:

·         start-ups

·         shut-downs

·         job scheduling

·         systems logs

·         problem logging


Security administration procedures

Written procedures should describe how security features are authorized, implemented and maintained. They should also designate responsibility for each of these activities.

Security administration covers:

·         physical security of the system

·         security features of the operating system

·         application specific security features, such as application access, transaction authorization and audit trails


Database administration procedure

A written procedure should describe how the application database should be administered.

It should contain a secure method for making changes to the database, including the authorization and tracking of changes.


Purge and Archive Procedures



This topic looks at the purge and archive procedures.

If any of these procedures are not in place, then they must be developed, approved and implemented.



Purge and archive procedures describe how data will be copied, stored in archives and deleted from the system.

These procedures should include:

·         a systematic method for determining which data to archive

·         a method for recording what data was archived

·         a description of where the archived data is to be stored

·         a description of how the archived data will be found and retrieved when required

·         the retention period for archived records

·         the testing specifications for all purge and archive procedures

·         the testing specifications required for testing data recall from archive after software or hardware changes have been made

·         a specification of the appropriate archive media (this will depend on the retention period of the data)


Output Controls Procedures



This topic looks at output controls procedures.

If any of these procedures are not in place, then they must be developed, approved and implemented.



If a computer system produces outputs (such as reports) of a sensitive or proprietary nature, or that must be controlled from a regulatory standpoint, then there should be controls over the logical and physical outputs of the system.

A procedure should be written that:

·         describes the controls that are in place

·         specifies how access to sensitive output may be authorized


Introduction to CSV Validation Responsibilities Before You Start Validation The Process Establish Teams(s) Determine Activities
Write the Protocol System Development Details Perform Qualification Activities Develop &  Review  Procedures Certify the System Review Periodically