Vendor Audit Checklist in Pharmaceutical Industry

The pharmaceutical industry plays a pivotal role in the healthcare ecosystem, providing essential medications and therapies to patients worldwide. However, ensuring the safety, quality, and efficacy of pharmaceutical products is of paramount importance. To maintain these standards, pharmaceutical companies often rely on a network of suppliers and vendors who provide vital ingredients, components, and services. The integrity of this supply chain is essential to guaranteeing the overall quality of pharmaceutical products.

Vendor audits are a critical component of quality assurance and risk management in the pharmaceutical industry. These audits involve a systematic and comprehensive assessment of a vendor's facilities, processes, and practices to ensure they adhere to regulatory requirements and industry standards. A well-structured vendor audit checklist is an indispensable tool in this process, serving as a roadmap for auditors to evaluate and monitor vendor performance consistently.

In this context, a vendor audit checklist specific to the pharmaceutical industry becomes crucial. This checklist is a dynamic document that evolves with industry regulations, best practices, and the changing landscape of pharmaceutical manufacturing. It encompasses a wide range of criteria, including the vendor's quality management system, compliance with Good Manufacturing Practices (GMP), data integrity, documentation, and adherence to safety protocols.

The pharmaceutical industry is highly regulated, with stringent oversight from agencies like the FDA, EMA, and other global regulatory bodies. Non-compliance with these regulations can result in serious consequences, including product recalls, legal penalties, and damage to a company's reputation. Therefore, a vendor audit checklist tailored to the pharmaceutical sector not only serves as a tool for evaluating vendors but also as a safeguard against regulatory violations and product quality issues.

This introduction sets the stage for a comprehensive exploration of the importance of a vendor audit checklist in the pharmaceutical industry. In the subsequent sections, we will delve into the key components of an effective vendor audit checklist, best practices for conducting vendor audits, and the overall impact of these audits on pharmaceutical quality and safety.

Vendor Audit Checklist in Pharmaceutical Industry

Vendor: _______________

Address: _______________

Auditor: _______________

Persons Present: _______________

__________________________

__________________________

__________________________

Please remember during all audits (internal or external), your audit may be reviewed by senior management or regulators or even in a court of law. A qualified reviewer is not interested in opinions. The regulatory requirements are clearly documented and so must your verification of compliance be. Where there is compliance with a requirement, there will be records, always include a photocopy of the records (sensitive or personal data may be blocked out) as irrevocable verification of compliance.

ALSO READ: SOP for Vendor Qualification and Management

No records = No compliance

A.	Company Overview	Done	Notes
A.1	Audit details (address, audit team, supplier representatives)
A.2	Company size, structure and summary of history (number of sites, staff, organizational charts, company history)
A.3	Product/service history (main markets, how many sold, use in healthcare sector)
A.4	Summary of product/service under audit (product literature)
A.5	Product/service development plans
A.6	Tour of facility (to verify housekeeping, general working environment, working conditions)
B.	Organization and Quality Management	Done	Notes
B.1	Management structure (roles, responsibilities)
B.2	Method of assuring quality in product/service (quality system, responsibilities for quality)
B.3	Use of a documented Quality Management System (QMS) e.g., existence of a quality policy and objectives, quality manual, process definitions/procedures, standards
B.4	Maturity of QMS (relevance to product/service under audit)
B.5	Control of QMS documentation (reviews, approvals, distribution, updates)
B.6	Maintenance of QMS documentation (regularly reviewed and updated when appropriate)
B.7	QMS certified to a recognized standard (e.g., ISO9001)
B.8	Method of checking compliance with QMS (internal audits, management reviews)
B.9	Qualification and suitability of staff
B.10	Independence of auditors, inspectors, testers, reviewers
B.11	Staff training (general, QMS, product/service related, new staff, changes to QMS, regulatory issues, training records)
B.12	Use of sub-contractors (individuals, companies):
	Method of selection
	Sub-contractor qualifications and training records
	Specification of technical and quality requirements in orders placed
	Method of accepting product delivered by sub-contractor
B.13	Experience of validation process (with other customers, previous Supplier Audits, services provided by supplier, involvement in regulatory inspections)
B.14	Awareness of healthcare regulatory requirements (knowledge of regulations, subscription to publications, attendance of relevant events, involvement in industry groups)
B.15	Continuous improvement programme (use of metrics to evaluate and improve effectiveness of QMS)

ALSO READ: Audit Checklist for Data Integrity

C.	Planning and Product/Project Management	Done	Notes
C.1	Use of quality and project plans (per project/product, defining activities, process definitions/procedures, responsibilities, timescales)
C.2	Status of planning documentation (reviews, approvals, distribution, maintenance, and update)
C.3	Documentation of user/supplier responsibilities
C.4	Use of Validation Plan where supplied by user company
C.5	Project management and monitoring (mechanism, tools, progress reports)
C.6	Accuracy of, and conformance to, planning and management process definitions/procedures
C.7	Use of formal development life cycle
C.8	Evidence of formal contract reviews where applicable
D.	Specifications	Done	Notes
D.1	User Requirements Specifications
D.2	Functional Specifications
D.3	Software Design Specifications
D.4	Hardware Design Specifications
D.5	Relationship between specifications (together forming a complete specification of the system which can be tested objectively)
D.6	Traceability through specifications (e.g., for a given requirement)
D.7	Status of specifications (reviews, approvals, distribution, maintenance and update)
D.8	Accuracy of and conformance to relevant process definitions/procedures
D.9	Use and control of design methodologies (CASE tools)

ALSO READ: Factory Acceptance Testing and Site Acceptance Testing

E.	Implementation	Done	Notes
E.1	Specification of standards covering the use of programming languages (e.g., naming and coding conventions, commenting rules)
E.2	Standards for software identification and traceability (e.g., for each software item: unique name/reference, version, project/product reference, module description, list of build files, change history, traceability to design document)
E.3	Standards for file and directory naming
E.4	Use of build files to compile and link individual software configuration items into a formal release of the software product
E.5	Use and version logging of development tools (e.g., compilers, linkers, debuggers) used for each software configuration item and the formal build and release of the software product
E.6	Evidence of source code reviews prior to formal testing (checking design, adherence to coding standards, logic, redundant code, identification of critical algorithms)
E.7	Independence and qualifications of reviewers
E.8	Source code reviews recorded, indexed, followed-up and closed off (with supporting evidence).  Evidence of timely management action for reviews which remain open.
E.9	Listings and other documents used during source code reviews identified, controlled, and retained with review reports
F.	Testing	Done	Notes
F.1	Explanation of the test strategy employed at each level of development (e.g., module testing, integration testing, system acceptance testing or alpha/beta testing)
F.2	Software Test Specifications
F.3	Hardware Test Specifications
F.4	Integration Test Specifications
F.5	System Acceptance Test Specifications
F.6	Structure and content of each test script (unique reference, unambiguous description of test, acceptance criteria/expected results, cross-reference to controlling specification)
F.7	Relationship between test specifications and controlling specifications (demonstrating that the system has been thoroughly tested with traceability between specifications and tests)
F.8	Evidence that test specifications cover:
	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)
	Abnormal conditions
F.9	Status of test specifications (reviews, approvals, distribution, maintenance, and update)
F.10	Formal testing procedure to execute test specifications (method of recording test results, use of pass/fail, retaining raw data, reviewing test results, progressing and resolving test failures)
F.11	Status of test results and associated review records (indexed, organized, maintained, followed up on failure)
F.12	Involvement of QA function (as witnesses and/or reviewers)
F.13	Independence and qualifications of testers and reviewers
F.14	Accuracy of, and conformance to, relevant test process definitions/procedures
F.15	Control of test software, test data, simulators
F.16	Use of testing tools (documented, controlled, and versions recorded in the test results)
F.17	Traceability of test results back to the appropriate specifications/test scripts

ALSO READ: Checklist for OOS Investigations in Pharmaceutical Industry

G.	Completion and Release	Done	Notes
G.1	Documented responsibility for release of product, such as certificate of conformity, authorization to ship (including evidence that testing has been accepted with/without reservations)
G.2	Handover of project material in accordance with quality plan/contract (e.g., release notes, hardware, copies of documentation/software)
G.3	Provision of user documentation (user manuals, administration/technical manuals, update notice with each release)
G.4	Records of releases (i.e., which customers have which version of system/software)
G.5	Warranties and guarantees
G.6	Archiving of release (software, build files, supporting tools, documentation)
G.7	Availability of source code and documentation for regulatory inspection (e.g., use of ESCROW accounts, and which product releases are covered)
G.8	Customer training (summary of courses provided by staff or third parties)
G.9	Accuracy of, and conformance to, release process definitions/procedures
H.	Support/Maintenance	Done	Notes
H.1	Explanation of support services (agreements, scope, procedures, support organization, responsibilities, provision locally/ internationally, use of third parties, maintenance of support agreements)
H.2	Duration of guaranteed support (number of versions, minimum periods)
H.3	Provision of Help Desk (levels of service, hours of operation)
H.4	Fault reporting mechanism (logging, analysing, categorizing, resolving, informing, closing, documenting, distribution, notification of other customers with/without support agreement)
H.5	Link between fault reporting mechanism and Change Control
H.6	Method of handling of customer complaints
H.7	Accuracy of, and conformance to, support process definitions/procedures
I.	Supporting Processes and Activities	Done	Notes
I.1	Documentation management (covering QMS and product/project documents):
	In accordance with QMS/Quality Plan
	Following documentation standards
	Indexed, organized
	Reviews carried out prior to approval and issue
	Reviews recorded, indexed, followed up and closed off (with supporting evidence)
	Evidence of timely management action for reviews which remain open
	Formal approvals recorded, meaning of approvals defined
	Distribution controlled
	Document history maintained
	Removal of superseded/obsolete documents
I.2	Software Configuration Management:
	System for identifying, controlling and tracking every version of each software configuration item
	System for recording the configuration of each release (i.e., which software configuration items and versions are used)
	Identification of the point at which Change Control is applied to each software configuration item
	Control of build tools and layered software products, including the introduction of new versions
I.3	Change Control covering software, hardware, documentation:
	All change requests formally logged, indexed and assessed
	Rejected requests identified as such, reasons documented, signed by those responsible and the originator informed
	Changes authorized, documented, tested and approved prior to implementation (except for emergencies)
	Emergency process definition/procedure documented covering reviewing, testing, approving, and recording
	Impact of each change (on other items and on requirements for re-test) assessed and documented
I.4	Security process definitions/procedures (physical access, logical access to accounts/software, virus controls)
I.5	Backup and recovery process definitions/procedures (secure storage and handling of media, on-site, off-site, recovery procedure exercised)
I.6	Disaster recovery process definition/procedure (tried) and documented evidence of disaster recovery testing
I.7	Control of purchased items bought on behalf of user (e.g., computer hardware, layered software products), including associated packaging, user documentation, warranties
I.8	Accuracy of, and conformance to, relevant process definitions/procedures

Comments:

__________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Views:
__________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Vendor: _______________

Address: _______________

Auditor: _______________

Persons Present: _______________

__________________________

__________________________

__________________________

ALSO READ: SOP for Vendor Qualification and Approval