GAMP 5 Example Assessment and Audit Checklists and

Questionnaires (Use in conjunction with Appendix M2)

Copyright in the whole and every part of this material is owned by ISPE. No reproduction for commercial
purposes, resale, or other commercial use of the whole or any part of this material is allowed without the
written agreement of ISPE.

Where indicated, purchasers of GAMP 5 are free to use and modify this material for internal use within
their organization only. The material is indicative only and intended to be neither exhaustive nor
prescriptive.

The GAMP 5 example templates, forms, checklists, and questionnaires are provided in Microsoft® Word
(suitable for Microsoft® Word 2000 or above) or Adobe® PDF format.

Please note that while every effort has been made to provide the Microsoft® Word documents in a
reusable format, ISPE does not guarantee that they will appear correctly when opened in Microsoft®
Word or another word processing application.

The GAMP 5 example templates, forms, checklists, and questionnaires are provided for your
convenience. They may be used freely within your own organization; however, they remain the property
of ISPE, should not be used for commercial purposes, and are not available for resale.

© Copyright ISPE 2008. All rights reserved.

1. Example of a Postal Audit Questionnaire

2. Example of an OSS Supplier Assessment Questionnaire

3. Example Checklist for On-Site Supplier Audit

1
1: Example of a Postal Audit Questionnaire
(NOTE: This example questionnaire is primarily focused on suppliers of commercially available or
established products, and should be customized as required for specific companies, products, and
projects. It is indicative only and intended to be neither exhaustive nor prescriptive. It also may be a
useful reference when developing a suitable questionnaire for other suppliers, such as system integrators
and service suppliers. Any use of the term commercial is not intended to discriminate against free or open
source software.)

Objective of Questionnaire
The objective of this Postal Audit Questionnaire is to gain insight into the quality management practices,
organization, and experience of your company.

Instructions for Completion

Each question should be answered unambiguously and in sufficient detail to provide evidence of
compliance or non-compliance. Answers may be provided either beneath each question or in a separate
document with a cross-reference to each question number. Copies of example documents are requested
to support the answers to some questions and should be provided if possible. Where appropriate,
extracts from documents may be provided in order to protect copyright, confidentiality, and intellectual
property. If copies cannot be provided then this should be noted with reasons. In such cases generic
templates may be provided instead.
The objective of providing good quality documentary evidence is to enable <regulated company name>
to appraise your company’s products and/or services and, depending on your response and the content
and quality of the documents requested, the need for an on-site audit may be avoided.

Product. In this questionnaire, the term ‘product’ is intended to encompass both stand alone software
(and any associated hardware) and equipment which incorporates software and its associated hardware.

If a third party developed any part of the product or provided any part of any services, the information
below will be required for both your company and the third party.

All information provided to <regulated company name> shall remain confidential and shall only be used
in support of supplier assessment activities.

We thank you for your cooperation in completing this questionnaire and would appreciate a response by
<required date> so that we can complete our supplier assessment process.

A. Company Details
Information is required on your company, its location(s), history, and organization, and its
experience with the pharmaceutical and healthcare industries.

A.1 Provide Company Name, Full Postal Address, Telephone and Fax Number, and Contact Name(s).

A.2 Provide details of your Parent/Holding Company.

2
A.3 Provide a brief history of the company and details of how your company is organized
geographically (locations).

A.4 Provide organizational chart(s) showing the company structure, organization, and the
responsibilities of key individuals within the structure (from Managing Director to Quality Assurance
and personnel responsible for the delivery of the required product/project).

A.5 Provide details of the number of employees in your company broken down as follows:

Global/All Locations Postal Audit Location

Total Staff Total at this location
Total Product Related Product Related at this location
Total QA Inspection QA Inspection at this location

A.6 Provide details of any experience your company has had of working in the pharmaceutical and
healthcare sector. Provide a list of companies and contact names of those who would be prepared
to provide references.

A.7 Provide details of any previous products or services provided to us, the locations involved and
details of your contact at each location.

A.8 Is your company currently involved in any litigation?

B. Products Supplied to the Pharmaceutical and Healthcare Industries

Information is required on the products and/or services that your company provides to the
pharmaceutical and healthcare industries.

B.1 Provide a list of products your company currently supplies to the pharmaceutical and healthcare
industries including any products which you support under a maintenance agreement.

B.2 Which products in the above list (item B.1) are standard or configurable, and which GAMP
category applies (if known)?

B.3 What is the approval process for the release of software products to the pharmaceutical and
healthcare industries?

C. Details of Specific Products

This section is used to provide specific information on a particular product if this is included within
the scope of this postal audit.

3
C.1 Name of the product(s)/services covered under the
scope of this postal audit (Note 1).

Note 1. Enter the name of the product in the box or enter the standard text: “This postal audit is
non-product specific. Section C is not applicable”

C.2 How long has the product been on the market?

C.3 What is the current version of the product?

C.4 How many versions are supported?

C.5 How many staff are working on and supporting the product?

C.6 Provide a reference list of the major installed sites for the product or number of licenses sold.

C.7 Provide details of any legal agreements (e.g., escrow agreement) for providing our company, or
our regulatory authorities, legal access to the product source code and its development tools.

C.8 Provide details of any user community/support groups for the product.

C.9 How is product support provided by your company (e.g., hotline, website, or call-out)?

C.10 What is your company policy for providing support for older or “out of support” versions?

C.11 Sub-Contracted Product Development – General. If the development of the product was sub-
contracted, provide information on the company who developed the product and where this
development took place. A copy of this Postal Audit Questionnaire should be sent to the sub-
contractor for completion and their response submitted with the postal audit response from your
company.

C.12 Sub-Contracted Product Development – Quality Monitoring. If the development of the product
was sub-contracted, provide a copy of the latest report for the audit performed on the sub-
contractor by your company. How often do you audit this sub-contractor?

C.13 Open Source Software (OSS). If the product, or a part of the product, was developed by an Open
Source Supplier (OSS), which may be a commercial firm or community, provide information on who
developed the product and where the development took place. An OSS supplier assessment
should be performed and submitted with the postal audit response of your company.

4
D. Quality Management System – Overview and General Requirements
Information is required on the Quality Management System used to develop the product and/or to
provide the services.

D.1 Provide a copy of your ISO9001 registration certificate or details of the certification achieved for
your Quality Management System. Provide the name of your Certification Body, the date your
current certificate was issued and date of renewal, and the frequency of the audits performed by
your Certification Body. Provide details of what is covered under your Quality Management System
certification (i.e., your scope of certification). What was the date of your first Quality Management
System certification?

D.2 Provide a copy of your registration certificate or details of the certification achieved for software
development (Note: There are several relevant schemes, frameworks, and approaches, including
TickIT, ISO15504 (SPICE), and CMMI). Provide the name of your Certification Body, the date your
current certificate was issued and date of renewal, and the frequency of the audits performed by
your Certification Body. Provide details of what is covered under your software certification (i.e.,
your scope of certification). What was the date of your first registration?

D.3 Provide a list of the quality procedures and any associated work instructions used by your
company.

D.4 If not provided under item D.3, provide a list of the product design, testing, release, and support
procedures, and any associated work instructions used by your company.

D.5 Provide details of any formal Project Management processes (e.g., Projects in Controlled
Environments (PRINCE) project management methodology) used for product development and/or
service provision.

D.6 What is the role of your Quality Organization during product development and/or during service
provision?

E. Quality Management System – Planning and Reporting Processes

Information is required on the quality and project planning processes used to develop the product
and/or to provide the service, and associated documentation.

E.1 Project Planning. Provide details of the procedures, methodologies, tools, and processes followed
when planning and managing projects against project milestones and an example of a Project Plan
for a current (or your most recent) project.

E.2 Quality Planning. Provide details of the procedures, methodologies, tools, and processes followed
when planning and managing quality on projects and an example of a Quality Plan for a current (or
your most recent) project.

5
E.3 Quality Reporting. Provide details of the procedures and processes used when reporting against
project and quality milestones and deliverables, and an example of a recent report.

F. Quality Management System – Software Development Processes

Information is required on the software development life cycle activities used to design, maintain
and test the software product(s) supplied either stand alone or with equipment.

F.1 Software Development. Provide details of the processes and standards that are followed for the
production of software and describe how this maps to the life cycle approach as promoted by the
GAMP guide.

F.2 Software Development. Provide details and examples of the life cycle documentation produced
for each level of development for a current (or your most recent) product. Provide copies of the
cover page, history page and index page for the following system life cycle development
documents or substitute the equivalent documents from your life cycle:

- Functional Specification
- Hardware Design Specification
- Software Design Specification
- Software Module Design Specification

F.3 Design Reviews. Provide details of the process followed for reviewing and recording the design
process at each stage of product development and an example of how this has been implemented
and documented on a current (or your most recent) product.

F.4 Software Coding Standards. Provide details of the processes and standards followed when
developing software. Where external software companies are utilized, provide details of how
software development processes and standards are monitored and controlled.

F.5 Source Code. Provide an example of a code header (with explanation if required) and an example
of code annotation for a current (or your most recent) software product. If more than one
programming language has been used for product development, then an example of a code
header and code annotation is required for each language.

F.6 Software Reviews. Provide details of the process followed for reviewing source code at each
stage of software development and an example of how this has been implemented and
documented on a current (or your most recent) product.

F.7 Software Testing. Provide details of the processes that are followed for software testing at each
stage of product development (including any simulation testing). This should include processes for
handling of issues arising during testing. Make clear distinction between informal and formal (i.e.,
fully documented) testing processes.

6
F.8 Software Testing. Provide details and examples of the life cycle testing documentation produced
for each level of testing for a current (or your most recent) product. Provide copies of the cover
page, history page, and index page for the following system life cycle testing documents or
substitute the equivalent documents from your life cycle:

- Software Module Test Specification

- Software Module Integration Test Specification
- System Integration Test Specification
- System Acceptance Test Specification
- Factory Acceptance Test Specification
- Site Acceptance Test Specification

F.9 Document Reviews/Approvals/Controls. Provide details of the process followed for review,
approval, and control of software related documentation (e.g., specifications, drawings, and
flowcharts). Provide an example of a recent review of a software related document.

F.10 Change Control. Provide details of the process followed for making changes to software and any
associated hardware, and an example of how this has been implemented on a current (or your
most recent) product.

F.11 Configuration Management. Provide details of the process followed for the Configuration
Management of modular software and an example of how this has been implemented on a current
(or your most recent) product (e.g., a build record for a specific version release).

F.12 Requirements Traceability. Provide an example of a Requirements Traceability document for a

current (or your most recent) product. This document should provide traceability between each
appropriate clause in the User Requirements Specification to corresponding clauses in each of the
subsequent life cycle design and testing specifications, and including traceability to code level.
Provide details of any alternative methods that your company uses for achieving this traceability.

F.13 Final Inspection and Testing. Provide details of the processes and standards that are followed
for the inspection/testing of your product. This should include details of the process followed for
ensuring that all product specifications have been inspected and tested.

F.14 Product Release. Provide details of the documentation you produce to support the release of each
version of your product.

F.15 User Documentation. Provide details of the user documentation (manuals, procedures, etc.) that
you would provide to support the operation of the product. For each document, provide a copy of
the cover page, history page, and index page.

F.16 Verification Documentation. Provide details of the verification documentation (plans, protocols,
reports, etc.) that you would provide to support the on-site verification of the product. For each
document, provide a copy of the cover page, history page, and index page.

7
F.17 Customer Training. Provide details of training you would provide to our personnel to enable us to
effectively operate the product. Provide details of how evidence of this training would be
documented.

G. Quality Management System – Infrastructure and Support Processes

Information is required on the business and quality support processes used within your company
and their effectiveness.

G.1 Internal Company Audits. Provide details of the process followed for performing internal audits
under your Quality Management System and an example of a recent internal audit of a software
related area. How are internal audits planned and documented?

G.2 Contract Reviews. Provide details of the process followed for performing and documenting
contract reviews, including information on how contract risks are documented.

G.3 Corrective Actions. Provide details of the process followed for implementing corrective actions
and an example of a recent corrective action for a software related process.

G.4 Customer Complaints. How many customer complaints have been raised and resolved in the last
12 months? Provide details of the process followed to address customer complaints.

G.5 Sub Contractors. If sub-contractors are used to provide any part of the product, how are they
selected, monitored, and controlled? What is the process followed for adding and deleting
companies from the list of approved sub-contractors?

G.6 Training Records – General. Provide details of training provided to personnel associated with the
development and production of your product(s). Provide details of how this training is recorded and
reviewed.

G.7 Training Records – Industry Specific. Provide details of training provided to your personnel on
the regulations governing the pharmaceutical and healthcare industries (e.g., cGMP, 21 CFR Part
11) and how this training has influenced the development of your product.

G.8 Personnel Records. Provide information on the records maintained by your company which
provide evidence that your personnel have the appropriate education, training, skills, and
experience to perform their job functions (e.g., Qualification Certificates, Curriculum Vitae, Job
Descriptions, Competency Assessments, etc.). How does your company determine the accuracy of
these records?

H. Electronic Records And Electronic Signatures

Information is required on how the product has been designed and configured to meet the supplier
specific requirements relating to pharmaceutical regulatory agency regulations on electronic
records and signatures. Answers to these questions will enable us to assess the work required to

8
 integrate the product into our business in order to comply with relevant regulations (e.g., US FDA
21 CFR Part 11).

H.1 Provide documentation (e.g., a white paper) produced for each of your products which describes in
detail how you have interpreted individual requirements on Electronic Records and Electronic
Signatures related to pharmaceutical regulatory agency regulations (e.g., US FDA 21 CFR Part
11), and how each requirement has been addressed for each product.

I. Documentation to be Submitted with the Postal Audit Response

The following documents are required for submission with your response to this postal audit. If
there is a reason why a particular document cannot be submitted or is not relevant then the reason
why must be provided.

Postal Document Name/Type Submitted?

Audit Yes No
Section (and
reason
provided)
A.4 Company organizational chart(s)

A.6 A list of pharmaceutical and healthcare companies your

company has worked with and associated contact names
for references
B.1 A list of products your company currently supplies to the
pharmaceutical and healthcare industries including those
products which you support under a maintenance
agreement
C.6 A reference list of the major installed sites for the product
C.11 A copy of the completed Postal Audit Questionnaire from
the sub-contractor used for product development
C.12 A copy of the latest report for the audit performed on the
sub-contractor by your company
C.13 A copy of any OSS supplier assessments performed
D.1 A copy of your ISO9001 registration certificate
D.2 A copy of your registration certificate if applicable (e.g.,
TickIT)
D.3 A list of the quality procedures used by your company
D.3 A list of the quality work instructions used by your
company
D.4 A list of the product design, testing, release, and support
procedures used by your company
D.4 A list of the product design, testing, release, and support
work instructions used by your company

9
Postal Document Name/Type Submitted?
Audit Yes No
Section (and
reason
provided)
E.1 An example Project Plan for a current (or your most
recent) project
E.2 An example Quality Plan for a current (or your most
recent) project
E.3 An example Quality Report for a current (or your most
recent) project
F.2 Copies of the cover page, history page, and index page
for the following system life cycle development
documents or substitute the equivalent documents from
your life cycle:
- Functional Specification
- Hardware Design Specification
- Software Design Specification
- Software Module Design Specification
F.3 An example of a design review record for a current (or
your most recent) product
F.5 Examples of a code header and code annotation for each
programming language used for a current (or your most
recent) software product
F.6 An example of a source code review record for a current
(or your most recent) product
F.8 Copies of the cover page, history page, and index page
for the following system life cycle testing documents or
substitute the equivalent documents from your life cycle:
- Software Module Test Specification
- Software Integration Test Specification
- System Integration Test Specification
- System Acceptance Test Specification
- Factory Acceptance Test Specification
- Site Acceptance Test Specification
F.9 An example of a recent document review record for a
software related document
F.10 An example of a software (and any associated hardware)
change control document for a current (or your most
recent) product

10
F.11 An example of a software configuration management
document for a current (or your most recent) product
F.12 An example of a Requirements Traceability document for
a current (or your most recent) product
F.15 Copies of the cover page, history page, and index page
for the user documentation (manuals, procedures, etc.)
that you would provide to support the operation of the
product
F.16 Copies of the cover page, history page, and index page
for the verification documentation (plans, protocols,
reports, etc.) that you would provide to support the on-
site verification of the product
F.17 Examples of the training records provided to customers
who are trained by your company
G.1 An example of a recent internal audit of a software
related area
G.3 An example of a recent corrective action for a software
related process
H.1 A copy of the white paper produced for each of your
products which describes in detail how you have
interpreted individual requirements on Electronic Records
and Electronic Signatures related to pharmaceutical
regulatory agency regulations (e.g., US FDA 21 CFR Part
11), and how each requirement has been addressed for
each product.

11
2: Example of OSS Supplier Assessment Questionnaire
(NOTE: this example questionnaire is primarily focused on suppliers of free or open source software, and
should be customized as required for specific companies, products, and projects. It may be applied to
companies and communities. It is indicative only and intended to be neither exhaustive nor prescriptive.)

A. Company/Community Details
Information is required on your company/community, its location(s), history, and organization, and
its experience with the pharmaceutical and healthcare industries.

A.1 Provide Company/Community Name, Full Postal Address, Telephone and Fax Number, Contact
Name(s), Homepage, and Community Details

A.2 Provide details of your Parent/Holding Company.

A.3 Provide details on sponsors or commercial products on same codebase, if applicable.

A.4 Provide a brief history of the company/community and details of how your company/community is
organized geographically (locations).

A.5 Provide organizational chart(s) showing the company/community structure, organization and the
responsibilities of key individuals within the structure (from Managing Director to Quality Assurance
and personnel responsible for the delivery of the required product/project).

A.6 Provide details of the community structure, including Project Management, Definition of Core
Team, and Maintainers of subprojects as appropriate.

A.7 Provide details of the number of employees in your company/community broken down as follows:

Global/All Locations Postal Audit Location

Total Staff Total at this location
Total Product Related Product Related at this location
Total QA Inspection QA Inspection at this location

A.8 Provide details of any experience your company/community has had of working in the
pharmaceutical and healthcare sector. Provide a list of companies and contact names of those who
would be prepared to provide references.

A.9 Provide details of any previous products or services provided to us, the locations involved and
details of your contact at each location.

12
A.10 Is your company/community currently involved in any litigation?

B. Products Supplied to the Pharmaceutical and Healthcare Industries

Information is required on the products and/or services that your company/community provides to
the pharmaceutical and healthcare industries.

B.1 Provide a list of products your company/community currently supplies to the pharmaceutical and
healthcare industries including any products which you support under a maintenance agreement.

B.2 Which products in the above list (item B1) are standard or configurable, and which GAMP category
applies (if known)?

B.3 What is the approval process for the release of software products to the pharmaceutical and
healthcare industries?

C. Details of Specific Products

This section is used to provide specific information on a particular product if this is included within
the scope of this postal audit.

C.1 Name of the product(s)/services covered under the

scope of this postal audit (Note 1).

Note 1. Enter the name of the product in the box or enter the standard text: “This postal audit is
non-product specific. Section C is not applicable”

C.2 How long has the product been on the market?

C.3 What is the current version of the product?

C.4 How many versions are supported?

C.5 How many staff are working on and supporting the product?

C.6 Provide a reference list of the major installed sites for the product or number of licenses sold.

C.7 Provide details of any legal agreements (e.g., escrow agreement) for providing our company, or
our regulatory authorities, legal access to the product source code and its development tools.

13
C.8 Provide details of any user community/support groups for the product.

C.9 How is product support provided by your company/community (e.g., hotline, website, or call-out)?

C.10 What is your company/community policy for providing support for older or “out of support”
versions?

D. Quality Management System – Overview and General Requirements

Information is required on the Quality Management System used to develop the product and/or to
provide the services.

D.1 Provide a copy of your ISO9001 registration certificate or details of the certification achieved for
your Quality Management System. Provide the name of your Certification Body, the date your
current certificate was issued and date of renewal, and the frequency of the audits performed by
your Certification Body. Provide details of what is covered under your Quality Management System
certification (i.e., your scope of certification). What was the date of your first Quality Management
System certification?

D.2 Provide a copy of your registration certificate or details of the certification achieved for software
development (Note: there are several relevant schemes, frameworks, and approaches, including
TickIT, ISO15504 (SPICE), and CMMI). Provide the name of your Certification Body, the date your
current certificate was issued and date of renewal, and the frequency of the audits performed by
your Certification Body. Provide details of what is covered under your software certification (i.e.,
your scope of certification). What was the date of your first registration?

D.3 Provide a list of the quality procedures and any associated work instructions used by your
company/community.

D.4 If not provided under item D.3, provide a list of the product design, testing, release, and support
procedures, and any associated work instructions used by your company/community.

D.5 Provide details of any formal Project Management processes (e.g., Projects in Controlled
Environments (PRINCE) project management methodology) used for product development and/or
service provision.

D.6 What is the role of your Quality Organization during product development and/or during service
provision?

E. Quality Management System – Planning and Reporting Processes

Information is required on the quality and project planning processes used to develop the product
and/or to provide the service, and associated documentation.

14
E.1 Project Planning. Provide details of the procedures, methodologies, tools, and processes followed
when planning and managing projects against project milestones and an example of a Project Plan
for a current (or your most recent) project.

E.2 Quality Planning. Provide details of the procedures, methodologies, tools, and processes followed
when planning and managing quality on projects and an example of a Quality Plan for a current (or
your most recent) project.

E.3 Quality Reporting. Provide details of the procedures and processes used when reporting against
project and quality milestones and deliverables, and an example of a recent report.

F. Quality Management System – Software Development Processes

Information is required on the software development life cycle activities used to design, maintain,
and test the software product(s) supplied either stand alone or with equipment.

F.1 Software Development. Provide details of the processes and standards that are followed for the
production of software and describe how this maps to the life cycle approach as promoted by the
GAMP guide. Provide details and examples of the life cycle documentation produced for each level
of development for a current (or your most recent) product, including as applicable:

Process Model Describe the process of software development from early development
to a final release.

Requirements Describe how requirements of the product were defined. What are the
Definition requirements based upon (e.g., technical specifications/standards,
market requirements, existing products, legal requirements)

Specifications Provide copies of the cover page, history page, and index page for the
following system life cycle development documents or substitute the
equivalent documents from your life cycle:
- Functional Specification
- Hardware Design Specification
- Software Design Specification

- Software Module Design Specification

Documentation Detail the documentation standards and responsibilities. Provide an

example of official product documentation.

Analysis and Describe process and responsibilities of software analysis and design.
Design

Software Provide evidence of how consistent software architecture is

Architecture maintained. (Describe the responsibilities in a collaborative and
distributive environment.)

Implementation Detail the implementation standards and provide examples (e.g., GUI
standards, consistency of date formats).

15
F.2 Design Reviews. Provide details of the process followed for reviewing and recording the design
process at each stage of product development and an example of how this has been implemented
and documented on a current (or your most recent) product.

F.3 Software Coding Standards. Provide details of the processes and standards followed when
developing software. Where external software companies are utilized, provide details of how
software development processes and standards are monitored and controlled.

F.4 Source Code. Provide an example of a code header (with explanation if required) and an example
of code annotation for a current (or your most recent) software product. If more than one
programming language has been used for product development, then an example of a code
header and code annotation is required for each language.

F.5 Software Reviews. Provide details of the process followed for reviewing source code at each
stage of software development and an example of how this has been implemented and
documented on a current (or your most recent) product.

F.6 Software Testing. Provide details of the processes that are followed for software testing at each
stage of product development (including any simulation testing). This should include processes for
handling of issues arising during testing. Make clear distinction between informal and formal (i.e.,
fully documented) testing processes.

F.7 Software Testing. Provide details and examples of the life cycle testing documentation produced
for each level of testing for a current (or your most recent) product. Provide copies of the cover
page, history page, and index page for the following system life cycle testing documents or
substitute the equivalent documents from your life cycle:

- Software Module Test Specification

- Software Module Integration Test Specification
- System Integration Test Specification
- System Acceptance Test Specification
- Factory Acceptance Test Specification
- Site Acceptance Test Specification

F.8 Document Reviews/Approvals/Controls. Provide details of the process followed for review,
approval, and control of software related documentation (e.g., specifications, drawings, flowcharts).
Provide an example of a recent review of a software related document.

F.9 Change Control. Provide details of the process followed for making changes to software and any
associated hardware, and an example of how this has been implemented on a current (or your
most recent) product.

16
F.10 Configuration Management. Provide details of the process followed for the Configuration
Management of modular software and an example of how this has been implemented on a current
(or your most recent) product (e.g., a build record for a specific version release).

F.11 Requirements Traceability. Provide an example of a Requirements Traceability document for a

current (or your most recent) product. This document should provide traceability between each
appropriate clause in the User Requirements Specification to corresponding clauses in each of the
subsequent life cycle design and testing specifications, and including traceability to code level.
Provide details of any alternative methods that your company/community uses for achieving this
traceability.

F.12 Final Inspection and Testing. Provide details of the processes and standards that are followed
for the inspection/testing of your product. This should include details of the process followed for
ensuring that all product specifications have been inspected and tested.

F.13 Product Release. Provide details of the documentation you produce to support the release of each
version of your product, including tracing to buglists.

F.14 User Documentation. Provide details of the user documentation (manuals, procedures, etc.) that
you would provide to support the operation of the product. For each document, provide a copy of
the cover page, history page, and index page.

F.15 Verification Documentation. Provide details of the verification documentation (plans, protocols,
reports, etc.) that you would provide to support the on-site verification of the product. For each
document, provide a copy of the cover page, history page, and index page.

F.16 Customer Training. Provide details of training you would provide to our personnel to enable us to
effectively operate the product. Provide details of how evidence of this training would be
documented.

G. Quality Management System – Infrastructure and Support Processes

Information is required on the business and quality support processes used within your
company/community and their effectiveness.

G.1 Project Infrastructure. Provide details of project infrastructure including Project Server (URL),
Bug Tracking System, and Version Control System.

G.2 Internal Company Audits. Provide details of the process followed for performing internal audits
under your Quality Management System and an example of a recent internal audit of a software
related area. How are internal audits planned and documented? Assess the product homepage
and developer pages for interactivity between programmers and users.

G.3 Contract/License Reviews. Provide details of the process followed for performing and
documenting contract reviews, including information on how contract risks are documented.

17
G.4 Corrective Actions. Provide details of the process followed for implementing corrective actions
and an example of a recent corrective action for a software related process.

G.5 Customer Complaints. How many customer complaints have been raised and resolved in the last
12 months? Provide details of the process followed to address customer complaints.

G.6 Sub Contractors. If sub-contractors are used to provide any part of the product, how are they
selected, monitored, and controlled? What is the process followed for adding and deleting
companies from the list of approved sub-contractors?

G.7 Training Records - General. Provide details of training provided to personnel associated with the
development and production of your product(s). Provide details of how this training is recorded and
reviewed.

G.8 Training Records - Industry Specific. Provide details of training provided to your personnel on
the regulations governing the pharmaceutical and healthcare industries (e.g., cGMP, 21 CFR Part
11) and how this training has influenced the development of your product.

G.9 Personnel Records. Provide information on the records maintained by your company/community
which provide evidence that your personnel have the appropriate education, training, skills, and
experience to perform their job functions (e.g., Qualification Certificates, Curriculum Vitae, Job
Descriptions, Competency Assessments, etc.). How does your company/community determine the
accuracy of these records? Provide specific information on the experience and qualifications of the
OSS project leader and core team member.

H. Electronic Records and Electronic Signatures

Information is required on how the product has been designed and configured to meet the supplier
specific requirements relating to pharmaceutical regulatory agency regulations on electronic
records and signatures. Answers to these questions will enable us to assess the work required to
integrate the product into our business in order to comply with relevant regulations (e.g., US FDA
21 CFR Part 11).

H.1 Provide documentation (e.g., a white paper) produced for each of your products which describes in
detail how you have interpreted individual requirements on Electronic Records and Electronic
Signatures related to pharmaceutical regulatory agency regulations (e.g., US FDA 21 CFR Part 11),
and how each requirement has been addressed for each product.

18
3: Example Checklist for On-Site Supplier Audits
(NOTE: This example checklist is primarily focused on suppliers of commercially available products and
system integrators, and should be customized as required for specific companies, products, and projects.
It is indicative only and intended to be neither exhaustive nor prescriptive. It may also be a useful
reference when developing a suitable checklist for other suppliers, such as service suppliers.)

A. Company Overview

A.1 General audit details:

- Names of audit team from the regulated company
- The address of the supplier’s premises where the audit is taking place
- Names of the supplier representatives during the audit
A.2 Company size, structure, and summary of history:
- The number of locations and the number of staff involved in key activities at each location (e.g.,
production, system development, Quality Assurance, etc.),
- Obtain copies of the supplier’s organizational charts
- Obtain a brief history of the company
A.3 Product/service history:
- What are the main markets for the product/service?
- How many products have been sold overall and how many of these were to the healthcare sector?
A.4 Summary of the product/service under audit:
- Obtain copies of the product documentation/literature (if applicable)
A.5 Product/service development plans:
- What are the future plans for the product and, if applicable, how will it be developed further?
- Are there any forthcoming changes in the technology used for the product and how would this
affect the product?
A.6 Tour of the facility to verify housekeeping:
- Observe the general working environment and working conditions
- Examine the security arrangements for key areas (e.g., the server room, documentation archive,
etc.)

B. Organization and Quality Management

B.1 The Management structure of the supplier’s organization:

- Assigned roles and responsibilities
- This section may be covered by item A.2

19
B.2 Use of a documented Quality Management System (QMS):
- The certification of the QMS to a recognized standard (e.g., to ISO9001 or to a software sector
scheme such as TickIT), the name of the Certification Body, the date of the first certification, the
issue date of the current certificate and date of renewal, the frequency of the audits performed by
the Certification Body, and the scope of the certification (i.e., the areas of the company and
business processes covered by the QMS).
- Existence of a quality policy and objectives, quality manual, process procedures and work
instructions, standards
- Is the quality and auditing function independent from the business processes covered by the
scope of the QMS?
B.3 How does the QMS impact the product/service under audit?
- Is the product/service covered under the scope of the QMS certification
- Are there specific procedures which cover the product/service provided
B.4 Control of QMS documentation:
- Reviewed and approved
- Distributed to the appropriate personnel
- Maintained and updated where required
B.5 Method of checking and communicating compliance with the QMS within the company:
- Communication of the results of internal audits and management reviews
B.6 Staff training:
- Examine general company training, QMS training, product/service related training, training of new
staff, training associated with changes to the QMS, training in regulatory issues
- Have the personnel involved in product development/service provision got the appropriate
education, training, skills, and experience to perform their job functions (e.g., Qualification
Certificates, Curriculum Vitae, Job Descriptions, Competency Assessments, etc.)
- Has the education, training, skills, and experience of personnel been documented (i.e., via training
records) and how is the accuracy of the records verified
- How are personnel training needs identified (e.g., personnel appraisals, reviews)
B.8 Use of sub-contractors (individuals, companies):
- Method of selection, monitoring and periodic re-approval
- Sub-contractor qualifications and training records
- Details of the technical and quality requirements for the product/service clearly specified in the
orders placed on the sub-contractor
- Method of accepting (verifying) the product delivered by the sub-contractor
B.9 The method used for handling of customer complaints:
- Details of how complaints are logged, analyzed, categorized, resolved, and closed
- Is there evidence that timely action is being taken

20
B.10 Experience of compliance requirements:
- Work performed by the supplier with other customers
- Involvement of the supplier in previous supplier audits
- The provision of compliance services by supplier
B.11 Awareness of healthcare regulatory requirements:
- Knowledge of GxP regulations
- Membership of healthcare sector organizations, such as ISPE, and subscription to industry
publications
- Attendance at relevant events, such as ISPE seminars and conferences
- Involvement in industry groups, such as ISPE Special Interest Groups (SIGs) and Communities of
Practice (COPs) such as the GAMP Forum.
B.12 Implementation of a continuous improvement program:
- By using process measurements/metrics against key performance indicators to evaluate and
improve the effectiveness of the QMS and business processes

C. Planning, Reporting, and Product/Project Management

C.1 Use of quality and project plans for each project and/or product:
- Definition of the activities involved (life cycle activities, compliance activities)
- Identification of key milestone dates and any quality checkpoints for each activity
- Assignment of responsibilities covering both the supplier and the regulated company
- Identification of the QMS process procedures to be used for each activity (as applicable)
- Quality and project plans can be combined into a single document
C.2 Status of the planning documentation:
- Reviewed and approved
- Distributed to the appropriate personnel
- Maintained and updated where required
C.3 Project management and monitoring:
- Is any specific approach or methodology used for project management approach (e.g., the use of
the PRINCE methodology)
- Are any project management tools used?
- How often are progress reports produced and is this documented in the Project Plan?
- Are project risks identified and a mitigation strategy defined in the Project Plan? Are the risks
reviewed and updated as the project progresses to account for new issues as they arise?

21
C.4 Use of a formal, documented, development life cycle:
- Examples include: the waterfall; V-model; spiral; evolutionary models such as Dynamic System
Design Methodology for Rapid Application Development
- The system supplier’s programming tools (e.g., for PLCs) may put constraints on the type of life
cycle which can be used (i.e., it may force the programmer to follow a specific design process)
C.5 Verify that contract reviews are being conducted and documented:
- Contract reviews should include an analysis of contract risks
C.6 Verify the accuracy of, and conformance to, the planning and product/project management process
procedures:
- Are the procedures being followed?
C.7 Quality and Project Reports:
- Reports are produced for each associated Plan
- Reports accurately confirm the completion of activities listed in the associated Plan
- Deviations for the associated Plan are listed and the impact evaluated

D. Specifications

The life cycle design documents produced will depend on the complexity of the system to be provided
and may be influenced by the type of programming language used. This section describes a
comprehensive set of life cycle design documents.

D.1 The production of User Requirements Specifications (URS) if these are produced by supplier:
- URS templates can be used to provide consistent specifications.
- Requirements must be complete, unambiguous and, where appropriate, testable.
D.2 The production of Functional Specifications (FS):
- FS templates and/or procedures can be used to provide consistent design specifications
- Sample the content of the FS against an associated URS
- The FS should expand on the description of what the customer wants in the URS, and provide
sufficient detail to enable the design process to commence
D.3 The production of Software Design Specifications (SDS) for each level of life cycle design (as
applicable) down to code level:
- SDS templates and/or procedures can be used to provide consistent design specifications for
each level of life cycle design
- Sample the content of the SDS against the FS and between each subsequent design specification
where lower level (module or unit) software design specifications are produced
- The lowest level specification should contain sufficient detail for code to be written with assistance
from coding standards

22
D.4 The production of Hardware Design Specifications (HDS):
- HDS templates and/or procedures can be used to provide consistent design specifications
- Sample the content of the HDS against the FS
- The HDS should contain sufficient detail for hardware purchase/assembly/production to
commence
D.5 The organization and completeness of the design specifications:
- Do they provide a complete system design which can be tested objectively?
- Design specifications can be combined as appropriate
- The lowest level of design specification must be capable of producing either the software code,
the hardware, or both
D.6 Traceability through specifications for a specific requirement:
- Select an appropriate software requirement and verify that it has been fully analyzed at each level
of the design process down to software code level
- Repeat this sampling process as appropriate and consider any supporting hardware implications
- Where practicable, clause level traceability should be provided between the URS and each
subsequent design specification. This traceability can be provided by a traceability matrix. Verify
how the accuracy of this traceability is maintained (i.e., traceability reviews)
D.7 Status of design specifications:
- Reviewed and approved
- Distributed to the appropriate personnel
- Maintained and updated where required
D.8 Design reviews:
- Design and source code reviews are a mandatory requirement of ISO 9001
- Reviews should be recorded, indexed, followed-up, and closed off (with supporting evidence)
- There should be evidence of timely management action for reviews which remain open
- Is QA involved in design reviews?
D.9 Use and control of design methodologies and tools, including CASE tools:
- The use of Rapid Application Development (RAD) and other Agile software development
methodologies
- The way in which these methodologies are implemented and controlled should be documented
- Consider any risks (e.g., problems with maintaining design traceability) in using the design tools
- For some systems the design may be constrained by the programming tool
- Does the supplier use any document production and management tools which assist with
document development and which provide automatic design traceability between specific clauses
and embedded objects (e.g., diagrams, reference standards, and other documents) in each life
cycle document via hyperlinks? How does the supplier ensure that the documents produced or
maintained by such a system meet the customer’s formatting and layout requirements?
D.10 Verify the accuracy of, and conformance to, the life cycle design process procedures:
- Are the procedures being followed?

23
E. Implementation

E.1 Coding standards:

- Specification of standards covering the use of each programming language used
- The documentation of naming conventions for variables and/or operational functions
- Definition of coding conventions/structure
- The documentation of commenting rules within the code and for headers/identification blocks
The documentation of standard file and directory structures
E.2 Standards for software identification and traceability for each software item:
- Project/product reference and/or unique item name/reference
- Software module/item version and change history
- Module description and traceability to the design document clause(s) used to produce the code
- List of the build files used to compile the module and the use of any configuration management
tools
- Traceability between the source code and its associated design specification can be provided by a
traceability matrix. Verify how the accuracy of this traceability is maintained (i.e., traceability
reviews)
E.3 Software development tools:
- The type and version of the tools(s) used
- The use of proprietary programming languages/tools for process control systems (PLCs, SCADA,
DCS) and embedded control systems (PLCs, proprietary logic controllers)
- The software build tools for high level languages can include compilers, linkers, debuggers which
are used to build each software configuration item into a formal release of the software product
- The software build and release process may be controlled by, and form an integral part of, a
software configuration management tool
E.4 Source code reviews:
- Design and source code reviews are a mandatory requirement of ISO 9001
- Source code reviews should be carried out prior to the start of testing
- Source code reviews should verify the code implementation against the appropriate design
specification and for adherence to the appropriate coding standard(s)
- Typical areas for review include: verification of the code logic; checking for the presence
redundant or dead code; checking for poor coding practice such as code duplication which can
cause problems for code maintenance; identification of critical algorithms
- Reviews should be recorded, indexed, followed-up and closed off (with supporting evidence)
- There should be evidence of timely management action for reviews which remain open
- Listings and other documents used during source code reviews should be identified (unique
name/identification code and version), controlled, and retained with the review reports (if possible)
- Source code reviews should be conducted by suitably qualified and experienced personnel

24
E.5 Independence and qualifications of reviewers:
- The use of code reviewers who are either independent from the software development team or
who are personnel other than the programmer (code author) from within the same team
- What are the qualifications of the reviewer(s)?

F. Testing

The number and type of life cycle test documents produced will depend on the complexity of the system
to be provided and may be influenced by the type of programming language used. This section describes
a comprehensive set of life cycle test documents.

F.1 The production of a Test Plan:

- A document which provides details of the test strategy to be employed
- The extent of testing will depend on the complexity of the system life cycle design process and on
the type of programming language used
- For complex systems, testing can encompass: module testing, module integration testing, system
integration testing, and system acceptance testing. For some types of system, alpha/beta testing
also may be applicable
F.2 The availability of a formal testing procedure:
- Details of how to execute the test specifications. This information can be included in a dedicated
procedure or other appropriate document (e.g., the test plan or each test specification)
- Description of the method to be used to record the test results and their acceptance (e.g., the use
of pass/fail, and where initials and signatures can be used)
- The control and retention of the raw test data (if applicable)
- The process to be used for reviewing the test results
- The method to be used for progressing, documenting, and resolving test failures and issues
arising from testing
F.3 The production of Software Test Specifications (STS):
- STS templates and/or procedures can be used to provide consistent test specifications for each
level of life cycle test from code module (unit) level testing to software/module integration testing
- Sample the content of each STS against the FS and against each subsequent design specification
where lower level (module or unit) software test specifications are produced to ensure test
coverage
- The content of each STS should be sufficient to fully test the software at all design levels. System
hardware may be required for some tests
F.4 The production of Hardware Test Specifications (HTS):
- HTS templates and/or procedures can be used to provide consistent test specifications
- Sample the content of the HTS against the FS and against each subsequent design specification
to ensure test coverage
- The HTS should contain sufficient detail to fully test the hardware. The product software may be
required for some tests.

25
F.5 The production of System Integration Test Specifications (SITS):
- SITS templates and/or procedures can be used to provide consistent test specifications
- Sample the content of the SITS against the FS
- The SITS should fully describe how the system will be tested to verify the design requirements of
the FS
F.6 The production of System Acceptance Test Specifications (ATS):
- Acceptance testing can encompass Factory/Customer Acceptance Testing (FAT/CAT) and Site
Acceptance Testing (SAT)
- ATS templates and/or procedures can be used to provide consistent test specifications
- Sample the content of the ATS against the URS
- The ATS should fully describe how the system will be tested to verify that the customer’s
requirements have been met
F.7 The structure and content of each test script:
- A unique test script reference
- An unambiguous description of the test
- The test acceptance criteria/expected results
- A cross-reference to the associated test specification
F.8 The relationship between the test specifications and their associated design specifications:
- Test specifications should be sufficiently detailed to provide confidence that the system design
has been thoroughly tested at all levels.
- Test specifications can be combined as appropriate
- Each test specification should be traceable at clause level to its associated design specification.
This traceability can be provided by a traceability matrix. Verify how the accuracy of this
traceability is maintained (i.e., traceability reviews)
F.9 The completeness of the test specifications and the areas covered, e.g.:
- Both structural and functional testing
- All requirements
- Each function of the system
- Stress testing (repeat testing under different conditions)
- Performance testing (e.g., adequacy of system performance)
- Regression testing (where new or modified code is added to an existing product)
- The testing environment (use of test hardware; testing on a dedicated test system; testing on the
final production system; use of simulators)
- Abnormal conditions (verify how are these are documented and resolved and the procedures
used
F.10 Status of test specifications:
- Reviewed and approved
- Distributed to the appropriate personnel
- Maintained and updated where required

26
F.11 Traceability of test results back to the appropriate specifications/test scripts
- The test specification/test script reference should be recorded on the associated test results
F.12 Status of test results and associated review records:
- Reviewed and approved
- Distributed to the appropriate personnel
- Maintained and followed up on failure
F.13 Involvement of the QA function during the testing process:
- Use of QA personnel as test witnesses and/or reviewers
F.14 Independence and qualifications of testers and reviewers:
- The use of testers and test reviewers who are either independent from the software development
team or who are personnel other than the programmer (code author) from within the same team
- What are the qualifications of the testers and reviewers
F.15 Verify the accuracy of, and conformance to, the life cycle test process procedures:
- Are the procedures being followed?
F.16 Control of test software, test data, simulators:
- Details (and versions) of any test software, test data sets, and test simulators used during the
testing process should be recorded in the test specifications and on the test results
F.17 Use of testing tools:
- Details (and versions) of any testing tools used during the testing process should be recorded in
the test specifications and on the test results

G. Completion and Release

G.1 Documented responsibility for release of product. Examples could include:

- A certificate of conformity
- An authorization to ship
- Evidence that testing has been accepted either with or without reservations prior to release
G.2 Handover of project deliverables:
- Handover of deliverables in accordance with quality plan/contract
- Copies of life cycle documentation (hardware/software)
- System hardware
- Copies of software
- Software release notes
- User manuals
- Data sheets
- Administration/technical manuals

27
G.3 Records of releases:
- Logging of which customers have which release/version of the system/software product
G.4 Provision of warranties and guarantees
- Details of the warrantees and guarantees available
G.5 Archiving of release materials:
- Software
- Build files
- Supporting tools
- Documentation
G.6 The availability of source code and documentation for regulatory inspection:
- The use of escrow accounts, or similar agreements, which provide legal access to the source
code, and details of the product releases/versions covered by the agreement
G.7 Customer training:
- A summary of courses provided to regulated companies by either the supplier’s staff or by third
parties
G.8 Verify the accuracy of, and conformance to, the release process procedures:
- Are the procedures being followed?

H. Support/Maintenance

H.1 Details of support services available:

- Service level agreements and the options available
- Details of the services which can be provided
- Details of the service procedures used
- Details of the service support organization and responsibilities
- Provision of local and international support
- Use of third party support companies. How are these companies selected and how is the quality
and technical integrity of their work monitored?
- Details of how of support agreements are maintained (renewal process)
- Is there a limit on the duration that support is provided (e.g., number of versions, minimum periods
of time)?
H.2 Provision of Help Desk facilities:
- The levels of support provided and the fault escalation mechanism
- Hours of operation

28
H.3 Fault reporting mechanism:
- Details of how faults are logged, analyzed, categorized, resolved, and closed
- How is the customer kept informed of progress (fault status) from the initial request for support to
closure?
- Faults can encompass a wide range of problems including software bugs and other system
(hardware/software) problems
- How is a fault documented and distributed to appropriate personnel for resolution?
- Is the fault investigation, resolution, and closure process linked to the change control process?
- If a fault affects other customers, how are they notified of the problem and what provision is made
for their systems to be updated?
- If some of the customers who are impacted by a fault do not have support agreements, how are
they notified of the problem and what provision is made for their systems to be updated?
H.4 Method for handling site changes/modifications:
- Verify the process for recording the work done, updating the design and user documentation,
testing the change/modification, closing out the work request
- Verify how electronic downloads and remote (supplier controlled) system updates are handled.
This includes: remote system access control (how is access permission granted and controlled?);
verification of correct data/file transfer; confirming that the correct version was installed; testing of
the change/modification; documentation of the change/modification
H.5 Verify the accuracy of, and conformance to, the system support/maintenance process procedures:
- Are the procedures being followed?

I. Supporting Processes and Activities

I.1 The documentation management process (covering QMS and product/project documents):
- In accordance with QMS/Quality Plan and following established documentation standards
- All documents indexed and organized
- Each document contains a history of changes
- Document reviews carried out prior to approval and issue
- Document reviews recorded, indexed, followed up, and closed off (with supporting evidence)
- Evidence of timely management action for reviews which remain open
- All documents formally approved and the meaning of approvals defined
- Controlled document distribution lists (where appropriate)
- Use of an established process for the removal of superseded/obsolete documents

29
I.2 The software configuration management process:
- The system for identifying, controlling, and tracking every version of each software configuration
item
- The system for recording the configuration of each release of the software products (i.e., which
software configuration items and versions are used for the released products)
- Identification of the point in the software production process at which change control is applied to
each software configuration item
- Application of controls to prevent source code being worked on by more than one individual at a
time
- Source code control/maintenance process including: booking out the source code to be modified
from the source code repository, performing the modifications, and changing the version number
of the source code, recording the changes made, booking the modified source code back into the
source code repository
- Identification and control of build tools and layered software products used for the software
release. Verify how new versions of build tools and layered products are introduced into the
software release process
I.3 The change control process:
- The change control process covers software, hardware, documentation
- Verify that change requests are formally logged, indexed and assessed, and authorized prior to
implementation of the change
- Verify that rejected change requests are clearly identified and that the reason(s) for rejection are
documented. The rejected change request should be signed by those responsible and the
originator should be informed of the decision
- Verify that changes are documented, tested, and approved prior to release of the system for use
(except for emergency changes)
- Verify that the emergency change control process is documented and that it covers the reviewing,
testing, approving, and recording of the change
- Verify that the change control process includes: the assessment of the impact of each change on
other items (e.g., other areas of the software product, other products, impact on hardware, impact
on other systems); identification of areas for re-test/regression testing; and identification of
affected life cycle documentation
I.4 Security processes:
- Security process procedures available
- Control of physical access to equipment and sensitive information (e.g., server room, archive
room)
- Control of logical access to user accounts/software (e.g., restricting the access to source code,
project data, or financial data to a specific team or group)
- Implementation of virus controls and firewalls

30
I.5 Backup and recovery process:
- Verify that back-up and recovery procedures are in place
- Verify the secure storage and handling of media including on-site and off-site storage or other
form of dual location back-up strategy
- Determine how the recovery procedure is verified
I.7 Disaster recovery process:
- Verify that disaster recovery procedures are in place
- Does the supplier have documented evidence of disaster recovery testing
I.8 Control of purchased items bought on behalf of the regulated company:
- This can include computer hardware, layered software products, user documentation, and any
associated warranties
I.5 Control and monitoring of software licenses:
- Are licensed software products being used within the terms of the license agreement (i.e., the
correct number of users) and how is this verified?
- Are there any non-licensed, open source, shareware or freeware products used by the supplier
and, if so, for which products? How does the supplier determine the integrity of these products?
I.9 Verify the accuracy of, and conformance to, the relevant process procedures:
- Are the procedures being followed?
I.10 Supplier IT Infrastructure Control:
- Verify that logical and physical access to IT Infrastructure is documented and controlled
- Is the Infrastructure documented (network diagrams available and up to date, configuration
management tools used)?
- Are adequate anti-virus, firewall security measures in place and monitored?
- Are server rooms secure? Is environmental monitoring/control in place?
- Are company Business Continuity/Disaster Recovery Plans in place that cover loss of IT
Infrastructure?

J. Electronic Records and Electronic Signatures

J.1 Does the system use or manage electronic records or signatures as defined in pharmaceutical
regulatory agency regulations?
If so, check evidence demonstrating approach taken and compliance with the applicable regulations

31