|
|
| |
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 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. |
|
|
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
|
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
The change control procedure should cover changes to
the:
·
hardware
·
system software (operating
system)
·
application software
·
data
|
|
|
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. |
|
|
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.
Note:
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 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 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). |
|
|
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. |
|
|
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 |
|
|
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 |
|
|
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 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 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
|
|
|
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 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. |
|
|
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 |
|
|
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 |
|
|
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. |
|
|
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) |
|
|
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 |
|
|
|
