Validation Services Clients Projects Careers Links Contact Us



The pharmaceutical industry is heavily regulated and the MHRA in the UK (and the FDA in the US) licence drugs only if they meet stringent safety, quality and efficacy standards. These range from EU guides and annexes to Good Manufacturing Practice (GMP), Good Clinical Practice (GCP) and Good Laboratory Practice (GLP) to FDA codes of federal regulations, such as the 1997 "21 CFR Part 11 Electronic Records; Electronic Signatures" ruling.

The MHRA and the FDA ensure drugs meet these standards through a process of regulation and enforcement. They have a number of powers to protect public health, ranging from working with the manufacturer of the product to legal remedies such as asking the manufacturer to recall a product, having agency officials seize products if a voluntary recall is not done and detaining imports at the port of entry until problems are corrected. If warranted, the FDA and MHRA can also ask the courts to issue injunctions or prosecute those that deliberately violate the law.

Validation, therefore, has to be conducted to a standard that meets or exceeds those demanded by these agencies.


GAMP standard

Validating computer systems to the GAMP standard satisfies this requirement. Established in 1991 and continually updated since in order to meet FDA expectations for compliance of manufacturing and related systems, GAMP defines the following validation lifecycle.

The first stage is Planning. This involves writing a Validation Plan (VP) to determine the validation strategy to be adopted. A risk assessment of the system occurs during which questions are asked such as: Does the system require validation? How much validation is required? What aspects of the system are critical to product and patient safety and to the business? The VP defines the validation activities, the roles and responsibilities of the project team and the validation deliverables. It is a key document and is approved by senior management.

The second stage is Specifications. This involves creating documentation that describes system functionality. A User Requirements Specification (URS) describes what the system should do whilst a Functional Specification (FS) describes what the system will, or does, do.

The third stage is Test Planning. This involves writing qualifications (test scripts) to verify, and challenge, the functionality of the system described in the specification documents. Traditionally, validation has comprised Installation Qualification (IQ), Operational Qualification (OQ) and Performance Qualification (PQ). The IQ provides verification that a system is installed according to approved specifications; the OQ provides verification that a system operates according to approved specifications; and the PQ provides verification that a system is capable of performing system processes according to approved specifications.

The fourth stage is Testing. This involves running the test specifications (IQ, OQ, PQ) against the built system and documenting the results against predefined acceptance criteria described in the test specifications. Each test result should clearly state whether it has passed or failed. The tester and witness sign and date each test.

The fifth stage is Review. This involves reviewing the test results and producing a Validation Report (VR). This summarises the validation activities, any deviations from the Validation Plan, outstanding and corrective actions and a statement of fitness for purpose of the system. Once a system is validated and in operation, plans and procedures should be defined to ensure the system remains in a validated state eg standard operating procedures, training and change control mechanisms.


The GAMP standard defines the documents to be written and the activities to be undertaken to validate a system. It also places the validation lifecycle within the constraints of the classic V-model, shown to the left.

For a validation project, this means that once the Validation Plan has been written (Planning), the URS may be created, followed by an FS and then a Hardware Design Specification (HDS) or Software Design Specification (SDS) or both, as is required (Specifications).

Once these documents are approved (formally agreed), the system is built or delivered as appropriate. After this, the IQ, OQ and PQ tests are written (Test Planning) and executed (Testing) following approval.

The test results are reviewed and if there are no deviations to investigate, the Validation Report is written and the system can go live (Review). It is then subject to formal change control in order to maintain its validated status.


The V-model is a powerful technique and offers many advantages over other formal models (eg waterfall) and informal methods:

  • It structures a project into easily understood stages so that members of a team understand what documentation needs to be produced.

  • It is clear that the left side of the V contains the technical specifications whilst the right side relates to the test specifications.

  • Since the left side acts as the input for the right, not only is each technical specification tested, there is complete traceability from defined requirements to tested requirements.

  • It offers a controlled environment, ideal for regulated industries such as pharmaceuticals (or nuclear or defence). In the V-model, each stage cannot begin unless the previous stage is complete. Therefore, an FS cannot be approved (formally agreed) until the URS has been and test documentation (IQ, OQ, PQ) cannot be approved until the technical specifications are.

  • Current progress in the project is visible because only one stage can ever be current.


How we can help

We are fully experienced at writing all documents in the validation lifecycle to the GAMP standard (or company standards, if preferred). Whether it is reviewing existing documentation or writing all the documentation required for an entire project, we have the consultants with the necessary skills and expertise to do this on your behalf.

 We have written many examples of the technical specifications stipulated by the GAMP standard, including:

  • Validation Plan (VP)

  • User Requirements Specification (URS)

  • Functional Specification (FS)

  • Software Design Specification (SDS)

  • Hardware Design Specifications (HDS)

Similarly, we have produced all manner of test documentation:

  • Installation Qualification (IQ)

  • Operational Qualification (OQ)

  • Performance Qualification (PQ)

  • System Acceptance Test Specification (SATS)

  • Hardware Acceptance Test Specification (HATS)

  • Factory Acceptance Test Specification (FATS)

We have validated many projects and can validate almost any computer system, whether it is a small bespoke package written in Visual Basic, a Microsoft Access database or a large multi-site ERP/MRP application. We do, however, boast particular knowledge and experience of validating the Documentum document management system, which we have been doing since 1996.

Besides writing and reviewing validation documentation to GAMP standards, we also:

  • Perform in-depth quality assessments of systems and software to determine the extent to which validation is required.

  • Assess existing systems to reveal compliance gaps and provide remedial plans for improvement, including 21 CFR Part 11 compliance assessments.

  • Project manage projects.

  • Provide testing services (for both pharmaceutical and non-pharmaceutical clients).

  • Deliver quality assurance and auditing skills to ISO 9001.

  • Technical author documents not present in the formal V-model, eg user manuals, training materials, standard operating procedures (SOPs).

Any level of assistance can be provided, ranging from one-off single document creation to major projects requiring detailed and in-depth expertise. We also offer reviewing services to companies who have written validation documents in-house but require the reassurance of an independent expert. In fact, during the last decade we have helped several companies with their systems.

NB Whilst our speciality is undoubtedly validation consultancy, our strength in document management, writing clear technical documents and testing validated systems has led to a number of non-validation projects. To see these engagements please see our Projects.


To see which companies we have assisted please refer to Clients.

Or you may wish to return to the Home page by clicking on our company logo at the top of the page.