GxP Vendor Qualification

Skip key takeaways

Updated October 20, 2026

• Responsibility stays with the regulated company Annex 11 section 4.5 has the regulated user assess the supplier and take reasonable steps to confirm development under an appropriate quality management system, and EU GMP Chapter 7 puts that assessment ahead of the outsourcing itself.
• Qualify the process when the supplier writes the code A custom partner has no finished product to review, so the check targets its quality management system and the lifecycle evidence Annex 11 expects for bespoke systems.
• Let risk set the depth of the check Annex 11 bases the need for an audit on a risk assessment and PIC/S wants the decision documented. None of the sources cited here sets an audit format or a requalification interval, so both follow the system's GxP impact and the partner's record.
• Give each function its own questions QA, IT and procurement each get their own question set, and a fourth covers AI Act roles and, where personal data is processed, GDPR processor terms.
• Score evidence, not claims The weighted template scores one candidate from 0 to 3 per row on the evidence it can show and stops at knock-out rows such as a refused audit.

Copy takeaways

In short: GxP vendor qualification is the documented check a regulated company runs on a supplier before relying on it for GxP work, repeated while the supplier works for it. For a custom software development partner there is no finished product to inspect, so the check looks at the partner's process and the evidence it produces. EU GMP and ICH Q10 keep responsibility for outsourced work with the regulated company, so qualification settles how far you can rely on a partner's evidence and never moves the responsibility.

This guide is for QA, IT and procurement teams qualifying a partner that will build software for them. It covers the regulated half of how to choose a pharmaceutical software vendor, the half your QA team signs: why the rules reach a development partner, the steps, 25 questions by function, red flags and a weighted scoring template. The delivery side is described on our pharma software development page.

A disclosure: Pharos Production is itself a custom software development partner, so we are one of the suppliers this method tests. The questions, red flags and template apply to us as they apply to any other candidate.

What Is GxP Vendor Qualification?

Vendor qualification in pharma, also called GxP supplier qualification, is the documented decision that a supplier is fit to provide a product or service used in GxP-regulated work, made on evidence before the supplier is relied on and kept current afterward. Vendor and supplier are used interchangeably here. Development work that never touches a GxP record or a regulated activity falls outside GxP qualification.

Software developers fall inside that scope. ISPE's public page for GAMP 5 Second Edition, an industry guide rather than a regulation, says: "Suppliers include providers of software, hardware, equipment, system integration services, IT service providers, and IT support services, both internal and external to the regulated company."

GAMP 5 gives suppliers their own chapter and appendices: its table of contents lists a chapter on supplier activities, a section on leveraging supplier input and appendices on supplier assessment and supplier quality planning. Qualifying the supplier is still not the same as validating the system it delivers.

Why Supplier Qualification Applies to a Development Partner

Start from one rule: the regulated company can hand the work to a partner, but not the responsibility for it. Chapter 7 of EU GMP and ICH Q10 make the regulated company ultimately responsible for control of outsourced work, while Annex 11 and PI 011-3 turn that into supplier agreements and supplier assessment for computerized systems.

EU GMP, ICH Q10 and PIC/S guidance

EU GMP Chapter 7 calls the regulated company the Contract Giver: "The Contract Giver is ultimately responsible to ensure processes are in place to assure the control of outsourced activities." The check comes before the work starts: "Prior to outsourcing activities, the Contract Giver is responsible for assessing the legality, suitability and the competence of the Contract Acceptor to carry out successfully the outsourced activities." Chapter 7 never names software developers, so whether a development engagement falls under it is your judgment.

Section 2.7 of ICH Q10 gives the pharmaceutical company the same ultimate responsibility, for outsourced activities and for the quality of purchased materials. Of its four controls, the first three have the company assess the other party's suitability and competence before outsourcing, define responsibilities in a written agreement and monitor performance afterward, while the fourth covers incoming materials. PI 011-3, PIC/S guidance rather than law, sets the order of work for computerized systems: "it is essential for the regulated user to define a requirement specification prior to selection and to carry out a properly documented supplier assessment and risk analysis for the various system options."

Annex 11, the EU GMP annex on computerized systems, is where software suppliers appear by name. Section 3.1 covers third parties that provide, configure, integrate, validate, maintain, modify or retain a computerized system and says that "formal agreements must exist between the manufacturer and any third parties". Those agreements should state the third party's responsibilities. Section 3.4 expects quality system and audit information on software suppliers to be available to inspectors on request.

Section 4.5 of Annex 11 then makes the partner's way of working the regulated user's concern: "The regulated user should take all reasonable steps, to ensure that the system has been developed in accordance with an appropriate quality management system. The supplier should be assessed appropriately."

The Commission's consultation draft of a revised Annex 11 proposes a supplier and service management section that opens from the same principle: "The regulated user remains fully responsible for these activities based on the risk they constitute on product quality, patient safety and data integrity." Its proposed contract clause lists supplier audits, support during regulatory inspections, communication of quality and security issues, an exit strategy and testing of new versions before release.

FDA and EMA texts, used where they fit

FDA's guidance on quality agreements covers contract drug manufacturing rather than software and is nonbinding, so we use it only as a model for writing responsibilities down. A quality agreement should indicate "which party will be validating processes and qualifying and maintaining equipment and applicable systems relevant to the contracted operations", information technology included. Whoever tests the products, the owner's quality unit stays ultimately responsible for CGMP: "A quality agreement does not change that."

For clinical investigations only, FDA's Part 11 questions and answers state: "Regulated entities are responsible for ensuring that electronic records meet applicable part 11 requirements." FDA recommends a written agreement with each IT service provider and may inspect providers that have assumed regulatory responsibilities. For clinical trials, EMA's guideline on computerized systems and electronic data adds: "The responsible parties can delegate tasks to a service provider, but nevertheless the full responsibility for the data integrity, security and confidentiality resides with them." Neither text governs GMP manufacturing systems.

What Changes When the Supplier Writes the Code

Qualifying a product starts from something that already exists. For commercial off-the-shelf software, Annex 11 section 3.3 says: "Documentation supplied with commercial off-the-shelf products should be reviewed by regulated users to check that user requirements are fulfilled." A custom partner has no finished system to show at selection time. The system will come out of the partner's process, so that process and the evidence it produces are what you qualify. For that evidence, Annex 11 section 4.6 sets the bar for the system you will validate: "For the validation of bespoke or customised computerised systems there should be a process in place that ensures the formal assessment and reporting of quality and performance measures for all the life-cycle stages of the system." Sections 4.4 and 4.7 add traceable user requirements and demonstrated test methods and scenarios. Before you sign, ask for the same kind of evidence from a comparable past project, anonymized.

• The partner's documents can feed your validation. ISPE describes GAMP 5 Second Edition as encouraging regulated companies to maximize supplier involvement, and the 2025 Annex 11 draft proposes that validation documentation may come from a vendor, provided the regulated user reviews and authorizes its use.
• Iterative delivery fits. ISPE's GAMP 5 page describes the Second Edition as "emphasizing that the GAMP specification and verification approach is not inherently linear but also fully supports iterative and incremental methods", so on ISPE's reading sprints can fit a GxP lifecycle when each sprint leaves its evidence behind.
• Source code needs a fallback: unless you hold a copy, only the partner has it. Where access to source code cannot be guaranteed, PI 011-3 expects regulated users to have assessed the business risks and put contingency measures in place in case the supplier fails.

The GxP Supplier Qualification Process

The sources set principles, not a procedure, so the order below is ours, with the regulatory anchor where one exists. They do not make an audit mandatory for every supplier or fix its format.

1. Define the system, its intended use and its GxP impact before choosing a partner, since PI 011-3 expects a requirement specification prior to selection.
2. Set the depth of the check by risk. Annex 11 section 3.2 says: "The competence and reliability of a supplier are key factors when selecting a product or service provider. The need for an audit should be based on a risk assessment." PI 011-3 adds that the decision whether to audit should be documented, including a decision not to.
3. Send the questionnaire below and ask for documents with the answers.
4. Review what comes back: quality procedures, a sample of lifecycle evidence, security evidence and the draft contract terms.
5. Audit where the risk calls for it, remotely or on site. The 2025 Annex 11 draft proposes an audit or a thorough assessment according to risk and system criticality.
6. Sign the quality agreement and the contract before work begins. That timing is our rule for GMP work. For clinical trials, EMA's guideline says: "Clear written agreements should be in place and appropriately signed by all involved parties prior to the provision of services or systems."
7. Record the decision, whether approval, approval with conditions or rejection, with the evidence behind it.
8. Monitor and requalify. Chapter 7 asks the Contract Giver to monitor and review the partner's performance, and PIC/S data integrity guidance PI 041-1, which lists IT services among the services that support supply chains, says: "Initial and periodic re-qualification of supply chain partners and outsourced activities should include consideration of data integrity risks and appropriate control measures." The sources cited here leave the interval open, so we tie it to risk and to changes such as a new subcontractor, hosting provider or team.

GxP Vendor Qualification Questionnaire: 25 Questions

Use the set as a supplier qualification checklist and send it before any audit is planned, because the answers inform the decision on whether to audit. The questions are grouped by the function that owns the answer: QA, IT, procurement and AI governance with personal data.

Questions for QA

1. Which quality management system governs your software development lifecycle (SDLC), and may we read it?
2. What lifecycle evidence comes with each release? A good answer names requirements traced to tests, test scenarios with their results and a quality report per stage.
3. Which of your test documents can we reuse, and for which version?
4. Can you name GxP-regulated systems you have delivered, with their intended use and a client QA contact who can confirm them?
5. Will you host our supplier audit remotely or on site?
6. Do you sign a quality agreement next to the master services agreement? Check that it assigns validation, change control, incident notification, subcontracting approval and audit rights.
7. How do you control changes and releases, and can we test a new version before it reaches production?
8. Which EU and US expectations does your delivery map to, and will you support us during a regulatory inspection? Annex 11 expects supplier quality information to reach inspectors on request.

Questions for IT

1. Which audit trail and access controls does the system provide, and how do you test them? For clinical investigations, FDA lists secure, time-stamped audit trails among its criteria for IT service providers.
2. How do your staff get and lose access to our environments, and who approves it?
3. How is our data protected at rest and in transit?
4. Where will the system be hosted and who operates it? If you run it for us, which service levels and performance indicators will you report?
5. What security evidence can you show, and what exactly does it cover?
6. Which data integrity controls apply to the work you do for us, and how do quality and security issues reach our team?

On security evidence, ISO/IEC 27001 certificates are issued by independent certification bodies, and SOC 2 reports, part of the AICPA's SOC suite, cover controls relevant to security, availability, processing integrity, confidentiality or privacy. None of the regulatory sources cited here makes either one mandatory, so treat both as evidence and check the scope and the issuer of each.

Questions for procurement

1. Who owns the source code and the other deliverables, and where does the code live during the project?
2. What protects us if your company fails? A source code escrow is one arrangement you can propose for continuity, alongside repository access from day one.
3. Do you subcontract any part of the work or the hosting, and will you ask for our approval before any change?
4. Who are the named people on our project, and how do you replace one without losing knowledge?
5. How are your people trained for regulated work?
6. How do we keep control of our data and records when the relationship ends?

Questions on AI governance and personal data

1. Where does AI sit, in the product or in your own delivery, and who is the provider under the EU AI Act for each use?
2. For a high-risk AI system, will you agree in writing the information, technical access and assistance we need as provider?
3. Are the models static, and how is a change of model or model version controlled?
4. Will you sign a GDPR Article 28 processor contract?
5. Where will personal data be processed, and do transfers to a third country follow our documented instructions?

The AI Act defines a provider in Article 3(3) as "a natural or legal person, public authority, agency or other body that develops an AI system or a general-purpose AI model or that has an AI system or a general-purpose AI model developed" and that places it on the market or puts it into service under its own name or trademark. A pharma company that has an AI system built by a partner and puts it into service under its own name meets that definition, so the role follows the facts and does not land on the partner by default. Under Article 3(4), an organization using an AI system under its authority is a deployer.

Once the AI Act's high-risk obligations apply, on the dates in the status snapshot below, Article 25(4) of the consolidated AI Act puts the supply relationship for a high-risk system in writing. Together with the provider, "the third party that supplies an AI system, AI model, tools, services, components, or processes that are used or integrated in a high-risk AI system shall, by written agreement, specify the necessary information, capabilities, technical access and other assistance" that the provider needs. This guide does not classify systems.

For GMP use, the 2025 consultation draft of Annex 22 would apply to AI models used in critical GMP applications with direct impact on patient safety, product quality or data integrity. It states: "The document applies to static models, i.e. models that do not adapt their performance during use by incorporating new data." Like the Annex 11 draft, it is a proposal.

Status snapshot (checked 2026-09-30): the joint European Commission and PIC/S consultation on a revised Chapter 4, a revised Annex 11 and a new Annex 22 on artificial intelligence ran from 7 July 2025 to 7 October 2025, and the Commission's consultation page lists it as closed. None of the sources checked for this guide shows an adopted text or an effective date, so the 2011 Annex 11 remains the text in operation. Under Article 113 of the consolidated AI Act, as amended in 2026 by the Digital Omnibus on AI, Chapter III sections 1 to 3, which hold Article 25, apply from 2 December 2027 for Annex III high-risk systems and from 2 August 2028 for Annex I high-risk systems.

Where the partner processes personal data on your behalf, GDPR Article 28 applies: "the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures". The processor contract limits processing to your documented instructions, transfers to a third country included, and lets you or an auditor you mandate carry out audits and inspections. The processor also needs your prior specific or general written authorization before engaging another processor. A partner that never processes personal data for you is outside Article 28.

Red Flags by Function

Any answer below should stop the qualification until it is resolved. Flags backed by a regulatory text name it, and the others are our judgment.

QA red flags

• The partner declines a supplier audit or support during a regulatory inspection. For clinical trials, EMA's guideline is explicit that where "the service provider is unwilling to support pre-qualification audits or regulatory inspections, systems from such a service provider should not be used in clinical trials."
• Its own validation is offered as a replacement for yours. Annex 11 section 4.1 expects manufacturers to justify their validation standards, protocols, acceptance criteria, procedures and records based on their risk assessment, and PI 011-3 section 4.11 leaves the regulated user ultimately responsible for making documented validation evidence available to GxP inspectors.
• Requirements specifications and other key documents are withheld until after signature. In clinical trials, EMA's guideline rules out providers whose reluctance to share such documents blocks appropriate agreements.
• Work is scheduled to start before the quality agreement is signed. EMA's guideline wants agreements signed before services start in clinical trials.

IT red flags

• Your environments are reached through shared accounts, or no written procedure exists for granting and revoking access. For clinical investigations, FDA's Part 11 questions and answers list such procedures among their criteria.
• Audit trails are presented as a later feature rather than part of the design.
• A security certificate is claimed without its scope or issuing body. ISO's certification page explains that certificates from accredited bodies can be checked in the International Accreditation Forum's IAF CertSearch database.
• No plan exists for returning your data or keeping access to it through the retention period. FDA's Part 11 questions and answers expect such a plan in clinical investigations, and the 2025 Annex 11 draft proposes an exit strategy.

Procurement red flags

• Subcontractors or hosting providers appear only after signature. EU GMP Chapter 7 bars the Contract Acceptor from subcontracting contracted work without the Contract Giver's prior evaluation and approval, so we ask for the names before signature.
• The code lives only in the partner's repository, and no plan covers the case where the company fails.
• People presenting the proposal are not the people who will do the work.

AI governance red flags

• No one on the partner's side can say where AI is used in the product or in delivery.
• The provider role under the AI Act is settled by assumption rather than by the Article 3 definitions.
• A dynamic model, one that keeps learning during use, is proposed for a critical GMP application, although the 2025 consultation draft of Annex 22 says dynamic models should not be used in such applications.

A Weighted Scoring Template, Not a Vendor Ranking

The template scores one candidate at a time against your own requirements. It is not a ranking of vendors and produces no public score. The weights are our starting point for a system with direct GxP impact, so adjust them to your system's risk and fix the pass mark before scoring anyone. For a system with indirect GxP impact the depth drops, for example to the questionnaire and a document review without an audit, and non-GxP tooling needs only your standard vendor checks.

Score each row from 0 to 3: 0 for no evidence, 1 for a claim without documents, 2 for documents reviewed and 3 for evidence verified in an audit or with a client reference. Multiply the weight by the score and divide by 3, so a perfect candidate reaches 100. A knock-out row scored 0 ends the qualification whatever the total.

Criterion	Weight	Evidence to request
Quality management system covering development	15	QMS scope statement and the procedures for requirements, testing and change control
Lifecycle and validation evidence	15	An anonymized trace matrix, test protocols with results and a release record
Audit and inspection access (knock-out)	10	Audit terms in the draft contract and a named contact for inspection support
Quality agreement and contract terms (knock-out)	10	A draft quality agreement covering the duties named in QA question 6
Competence and GxP experience	10	CVs and GxP training records of the named team, client QA contacts for past regulated work
Subcontracting and staffing continuity	10	Subcontractors and hosting providers by name, a replacement plan for key people
Security evidence and access control	10	Where held, a certificate with scope and issuing body or a SOC 2 report; in every case the access procedure and encryption at rest and in transit
Data integrity, hosting and exit	10	Audit trail design, data location, restore test records and an exit plan with data return
IP ownership and source code	5	An IP assignment clause, repository access from day one and a contingency such as escrow
AI governance and personal data	5	An inventory of AI in the product and in delivery, the AI Act role of each party and a GDPR Article 28 contract where personal data is processed

Two rows are knock-outs because the sources come closest to treating them as conditions. EU GMP Chapter 7 expects a written contract that sets out each party's duties and permits audits, and EMA says clinical trial systems from providers unwilling to support audits or inspections should not be used. Where personal data is processed, you may add a third knock-out of your own: no sub-processor without your prior specific or general written authorization, which GDPR Article 28(2) requires. Score it inside the AI governance and personal data row.

An illustrative example with our own numbers: seven rows scored 3 give their full weights, 70 points, competence and security scored 2 give about 13 more, and audit and inspection access scores 0 because the candidate declines supplier audits. The total of 83 clears a pass mark of 70, yet that knock-out ends the qualification.

Applying This Guide to Pharos Production

Pharos Production is a candidate for exactly this assessment. For a pharma engagement we offer the supplier-side items the questions ask for:

• A validation-ready pack with every release, with requirements traced to design, code and tests, plus the test evidence behind them
• A written description of our delivery lifecycle for your supplier assessment
• Named roles and the access each person has to your environments
• Disclosure of any subcontracting before signature, used only with your approval
• Hosted supplier audits and support during regulatory inspections, on request
• A quality agreement next to the master services agreement

Pharos Production holds no ISO 27001 certificate and no SOC 2 report, so score our security row on the controls we offer for a pharma engagement: least-privilege access, no production patient data in development or test, encryption at rest and in transit, secrets management and security testing before release through our cybersecurity services. In our delivery model, validation of the system stays with your QA team, and our QA services would produce the automated test evidence for that team to review. To score us or scope an engagement, start with our pharmaceutical software development services.

Sources: EU GMP Chapter 7, Annex 11 and the 2025 consultation drafts of Annex 11 and Annex 22; ICH Q10; FDA quality agreements and clinical electronic systems guidance; EMA clinical trials guideline; PIC/S PI 011-3 and PI 041-1; ISPE GAMP 5; AICPA SOC suite; ISO/IEC 27001; Regulation (EU) 2024/1689 as adopted and consolidated; GDPR. Qualification guidance, not regulatory or legal advice.

FAQ

Last updated: October 20, 2026

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 7

• What is vendor qualification in pharma?

  Featured question. Copy link Copies a direct link to this answer to your clipboard.

  It is the documented check a regulated company runs on a supplier before relying on it for GxP work, kept current while the supplier works for it. Supplier qualification means the same thing.

  For software suppliers, EU GMP Annex 11 bases the need for an audit on a risk assessment. Under EU GMP Chapter 7 and ICH Q10 the regulated company stays ultimately responsible for the outsourced work, whatever the supplier shows.

• Does a custom software development partner need GxP qualification?

  Copy link Copies a direct link to this answer to your clipboard.

  Yes, when the software supports GxP activities. Under Annex 11, when a third party provides, configures, validates, maintains or retains a computerized system, formal agreements must exist between the manufacturer and that third party.

  The regulated user should also take all reasonable steps to ensure the system was developed under an appropriate quality management system and should assess the supplier appropriately. A bespoke system adds one more expectation: assessment and reporting of quality and performance at each lifecycle stage.

• How does a software vendor support a pharma supplier audit?

  Copy link Copies a direct link to this answer to your clipboard.

  The vendor writes the audit terms into the contract, hosts the audit remotely or on site as you choose and keeps its quality procedures, lifecycle evidence and security documents ready to hand over. Annex 11 also lets inspectors ask for information about a software supplier's quality system and audits, so support during an inspection belongs in the same terms.

  For clinical trials, EMA goes further: a provider that refuses to support pre-qualification audits or regulatory inspections should not have its systems used.

• What should a quality agreement with a software development vendor cover?

  Copy link Copies a direct link to this answer to your clipboard.

  Who validates what, how changes and releases are controlled, how quality and security issues are reported, when subcontracting needs your approval, your audit and inspection rights and the exit terms. Settle those early: what is handed over (data, records and, where agreed, source code), in what format, by when and who confirms the transfer is complete.

  Under GMP, a quality agreement does not move ultimate responsibility off the regulated company. In US clinical investigations, specific obligations can be lawfully transferred to an IT service provider in writing, and the sponsor keeps every obligation it has not transferred.

• What validation documentation should a pharmaceutical software vendor deliver?

  Copy link Copies a direct link to this answer to your clipboard.

  For a bespoke system: formal reporting of quality and performance measures for every lifecycle stage, user requirements that stay traceable and evidence that the test methods and scenarios are appropriate. Annex 11 sections 4.4, 4.6 and 4.7 expect the regulated user's validation to show these, so ask the vendor to supply them.

  The regulated company reviews that documentation and decides how far to rely on it.

• Does a vendor need ISO 27001 or SOC 2 to be qualified?

  Copy link Copies a direct link to this answer to your clipboard.

  Not according to the regulatory sources behind this guide, which make neither one mandatory. An ISO/IEC 27001 certificate from an accredited certification body and a SOC 2 report are evidence you can ask for: check the certificate's scope and issuing body, and read which controls the report covers.

• How often should a GxP vendor be requalified?

  Copy link Copies a direct link to this answer to your clipboard.

  The sources behind this guide leave the interval open. EU GMP Chapter 7 has the regulated company track the supplier's performance over time, and PIC/S PI 041-1 wants data integrity risks weighed at each periodic requalification, so set the interval by risk and by how the supplier has performed.

  We also treat change as a trigger: a new subcontractor, hosting provider or delivery team justifies reassessing before the interval runs out.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.