1. Purpose
This Guideline provides guidance on the qualification requirements to be applied to the Information Technology infrastructure. The establishment and maintenance of a qualified infrastructure for any regulated company is fundamental to meeting current business and regulatory requirements in respect of systems stability, reliability and security.
2. Scope and Applicability
This guideline applies to all business functions and contracted third parties, who install, operate, manage or maintain the infrastructure. The requirement for qualification applies to all components of the infrastructure. This is necessary because of the interconnectivity of the network (a fundamental design requirement) and possible (unwanted) interactions that might ensue without conformance to the minimum standards contained in this Guideline.
The following infrastructure elements are covered by this guideline:
– Local and wide area networks (e.g. data transmission cabling, hubs, routers, bridges and switches, etc.).
– Servers and mainframe computers (and their operating systems and supporting software products).
– Clients (and their operating systems).
– Peripheral equipment (e.g. networked printers and storage devices)
– Electrical power supply and heating, ventilating and air conditioning equipment for server rooms and data centers.
– Server rooms and data centers.
– Infrastructure monitoring, management and maintenance systems.
– Middleware or enabling software., e.g. Oracle, SQL etc.)
3.1 Installation Qualification
Documented verification that all physical aspects of a facility or system, which affect product quality, adhere to the approved specification and are correctly installed.
3.2 Operational Qualification
Documented verification that all functional aspects of a facility or system, which affect product quality, perform as intended throughout all anticipated operating ranges.
3.3 Change Request
This is a collective name for a ‘Request for Change’ form.
3.4 Infrastructure Configuration Management
Configuration management is the process and system used to describe the configuration (settings and other specific details) of infrastructure components (e.g. IP addresses, disk, processor and memory capacity etc.) and, where applicable, the relationship between infrastructure components.
3.5 Client
The term applied to an individual’s workstation and the associated operating System.
3.6 Heating, Ventilating & Air Conditioning Equipment (HVAC)
The equipment used to maintain the correct temperature and humidity for infrastructure hardware and usually found in a server room or data centre.
3.7 Infrastructure
Hardware and software components including servers, network devices (routers, hubs, bridges and switches), cabling, operating systems (Windows, Unix, Linux, etc.) and middleware products that reside on infrastructure hardware and operating systems.
3.8 Specifications
Specifications (e.g. ‘requirements’, ‘functional’, ‘technical’, ‘design’, etc.) are detailed documents that describe the precise composition of an infrastructure component. These specifications are used to provide a basis for qualification testing.
3.9 Middleware
Middleware is a term applied to software platforms such as ‘Oracle’, ‘SAP’, ‘SQL’, etc., which are used to build business applications. The underlining Middleware is considered to be part of the infrastructure and is qualified whilst the bespoke middleware that builds the application is part of the application and should be validated.
3.10 Network Diagrams
A network diagram is a comprehensive, detailed view of the infrastructure. It should include both physical and logical components at a Local Area Network and Wide Area Network level.
3. Definitions
3.1. Analytical Procedure
A controlled document that describes in sufficient detail how a specific analysis is performed.
3.2. Analytical Procedure Validation
Confirmation that the performance characteristics of the analytical procedure meet the requirements for the intended application. This is usually established by laboratory studies.
3.3. Analytical Procedure Revalidation
Confirmation that the performance characteristics of the analytical procedure continue to meet the requirements of the intended application, following changes to the specific procedure or the synthetic route/method of manufacture of the test material. This is usually established by laboratory studies.
3.4 Validation Protocol
A validation protocol is written plan or protocol stating how validation, sampling and testing will be conducted, defining roles and responsibilities, and defining acceptance criteria. Analytical procedure validation protocols may be generic or specific and their content will depend on the phase of development or marketing.
4. Role and Responsibilities
To achieve the desired ‘state of control’, suitably qualified and experienced people must be appointed to the following roles, or their equivalents, at each site. In some cases, the same person may hold a number of different but related roles.
4.1 Infrastructure
Owner A person, or persons, who is/are ‘accountable’ for the provision, operation, and management of the infrastructure. This position could have a business wide remit or a local accountability for the infrastructure present on the site. Ultimate accountability for the status of the application lies with the System Owner, and this includes the relevant infrastructure.
4.2 Infrastructure Manager
A person, or persons, who is/are delegated by the Infrastructure Owner to be responsible for the day-to-day management of the infrastructure. A third party may perform this role.
4.3 Network Manager
A person, or persons, who is/are delegated by the Infrastructure Manager to be responsible for the day-to-day operation of network components, e.g. data transmission equipment, cabling, routers, switches and hubs, etc. A third party may perform this role.
4.4 IS Quality Manager
The IS Quality Manager assures that the IS unit operates a documented quality management system and processes to implement the company IS Quality Policy and Principles.
4.5 Functional Quality Assurance
Functional Quality Assurance will assure that regulated processes and supporting IS and IT systems remain compliant. For further guidance, please refer to ‘Roles
4.6 IS Security Manager
The IS Security Manager will advise on all aspects about the security of the infrastructure.
5. Guideline
5.1 Company Quality, Compliance and Security Standards
The standards applied to the management of the infrastructure must meet IS Quality, Compliance and Security policies and standards and the requirements of regulatory agencies (health, financial, etc.).
5.2 Infrastructure Life cycle
For infrastructure development a life cycle model must be used. To maintain the logical order, the deliverables from each stage of the life cycle must be approved before the next stage is commenced. A stage in the life cycle is usually broken down into several activities (see suggestions below).
– Stage 1 – Planning e.g. Change Management or Project
– Stage 2 – Design e.g. requirements, functional specifications, technical specifications,bservice requirements and design specifications including design qualification (DQ)
– Stage 3 – Development e.g. construction, configuration, code development
– Stage 4 – Installation e.g. testing of installation and verification of specifications (IQ)
– Stage 5 – Acceptance e.g. functional tests and verification of specifications (FQ)
– Stage 6 – Operation e.g. operational plans, maintenance, change control, ongoing training
– Stage 7 – Retirement
5.3 Infrastructure Qualification
5.3.1 New and Existing Components
In both cases, a risk assessment must be performed to establish the qualification (and any specific documentation) requirements. If, in the case of existing components, the risk assessment confirms that they are reliable then they do not need to be tested. Simply ensure that information about the components is recorded ‘as is’.
The information must be sufficient to allow the components to be replaced and reconfigured to resume operation as soon as possible if necessary. As a minimum a qualification plan which describes the retrospective qualification exercise for the existing infrastructure, plus technical and configuration specifications for each component or system needs to be in place and the items must be recorded in the asset register.
New infrastructure components must follow an established procurement and qualification process and similarly, sufficient information must be available to allow the component to be specified, maintained, repaired or replaced.
5.3.2 Development Environments
In the special case of ‘thrash and crash’ environments, e.g. ‘sandboxes’ and other development regions of the infrastructure, the interactions, if any, between the development region and the wider infrastructure (if a connection exists between the two regions) must be formally assessed for any security and compliance risks and qualification process must be followed.
5.3.3 Qualification Documentation
Adequate documentation is an essential part of the qualification and infrastructure management processes and all deliverables must be documented. Lack of adequate records will cause costly delays, errors and in some cases possible unwanted actions from regulators.
The documented evidence that is necessary to demonstrate qualification of infrastructure components can be seen in table 1 below. Each deliverable may be a separate document or combined for routine and simple changes and may cover one component which itself may be representative of a class of components. Qualification of common and routine changes may be covered by a pre-determined change procedure and the qualification deliverables documented on the change request documentation.
5.3.3.1 Qualification Deliverables Flow
The illustration “Qualification Deliverable Flow” describes the order in which the deliverables should be produced from planning to completed qualification.
Work on the Qualification Plan may start after the feasibility and/or initiating stage is finished.
Work on Requirements specification also starts at this point, butthe RS must be completed prior to, or at the latest in parallel with the QP. For the actual planning of the qualification work to take place (writing the Test Plan), Functional Specifications, Technical Specifications and Design Specifications are to be completed, so that the correct acceptance criteria can be entered into the Test Plan. Input documents to the QP as well as documents created after completion of the QP are to be appropriately signed, dated and approved. After completion of a QP, tests are to be performed signed and dated. Version control must be used for all documents. All changes must be traceable. All documents, including test results, should be easily made available. These documents will also be used during an audit or inspection
Figure: Qualification Deliverables Flow
5.3.3.2 Deliverables Description
Figure: Deliverables Description
5.4 Supplementary Qualification Processes
In order to maintain infrastructure qualification, the following documented processes (i.e. the subject of an SOP) must be used and applied to all areas of the infrastructure.
5.4.1 Change Management
The principles of ‘change control’ are applicable to all infrastructure components. Urgent or emergency changes are not exempted from the requirements of change control. Pre-determined change procedures are recommended for routine changes. Change management process should be linked to asset management, release management and configuration management.
5.4.2 Risk Management
Risk management techniques must be used to support decisions about qualifying and maintaining the qualified status of the infrastructure.
5.4.3 Network Configuration
The infrastructure must be documented so that the overall configuration of the network including the WAN and LANs can be described and understood logically and ‘as installed’. Any network diagrams should be updated periodically, subject to version control and approved as an official record.
5.4.4 Problem management
Processes should be established to monitor performance and manage problems and breakdowns to ensure that services are available as specified, or resumed within the timeframes agreed.
5.4.5 Backup & Restore and Contingency management
Processes should be established to ensure that tested backup and restoration processes are operated and maintained to secure business data and mitigate data loss. Contingency plans should be established to ensure that normal business operations could be resumed as soon as possible following breakdown.
5.4.6 Record and Document Management
Records associated with infrastructure components should be maintained according to the commonly accepted principles of records and document management. Where required, documents shall be approved by the (local) infrastructure owner and quality assurance and / or IS quality management.
5.4.7 Personnel
Documented roles and responsibilities for all persons directly engaged in infrastructure management and operation must be maintained.
Accountability for the proper functioning of the infrastructure resides with The company. The company must appoint suitably qualified and experienced people to be accountable for managing the infrastructure.
Responsibility for the day- to-day operation of the infrastructure may be vested in a third party. Evidence e.g. training records and CVs, confirming the competencies of persons directly engaged in the operation and management of the infrastructure must be maintained.