Supplier Qualification Process for GxP Software Partners: What Your Quality Unit Will Ask Before the Project Starts

Supplier qualification is how a company that makes medicines or medical devices decides if it can trust an outside partner with its work. Before the partner starts, the company reviews how the partner works and approves it only if the partner can meet its quality standards. The review is done by the company’s quality department, which regulations call the quality unit.

For a software development partner, this review is especially important. The partner’s code becomes part of systems that store production records and test results, and if that data is wrong, the company answers for it to regulators even though an outside team wrote the code.

The U.S. Food and Drug Administration (FDA) says testing alone is usually not enough to prove that software works as it should, so the quality unit must see how the partner writes, tests, and controls the code before the work begins.

That is why we wrote this guide. It walks you through the supplier qualification process step by step and lists the questions your quality unit is likely to ask, with the evidence to request for each. You will also see how this looks from the partner’s side, based on our engineers’ work inside MasterControl’s product teams.

By the end, you will know what your quality unit needs to see before it approves a software partner and how to prepare the answers before the project starts.

What Is Supplier Qualification?

In the intro, we described supplier qualification as the review a company that makes medicines or medical devices carries out before it trusts an outside partner with its work. Here, we look at it in more detail, because the exact meaning determines which suppliers need this review and what it must include.

Supplier qualification, also called vendor qualification, covers the company’s whole relationship with a supplier:

• Before the work starts, the company checks if the supplier can do the job well.
• The company sets the depth of this check by how much the work can affect product quality.
• After the company approves the supplier, it continues to monitor the supplier’s work and rechecks it over time.

The company keeps written records of every check, so it can later show regulators how and why it chose the supplier.

We built this definition from three documents that set supplier rules for companies that make medicines and medical devices:

• The ICH Q10 guideline from the International Council for Harmonization (ICH).
• The medical device standard ISO 13485 from the International Organization for Standardization (ISO), as FDA explains it.
• The European Union (EU) Good Manufacturing Practice (GMP) rules on outsourced work.

For a software project, the main question is if a development team falls under these rules. It does, because all three documents use the word “supplier” broadly. A supplier is any outside company whose work can affect product quality, whether it sells raw materials, tests samples in a lab, or writes software.

Industry organizations and FDA read the term the same way. The United States Pharmacopeia (USP) lists research and development among supplier services, and the International Society for Pharmaceutical Engineering (ISPE) counts software and information technology (IT) service providers as suppliers in its guide to Good Automated Manufacturing Practice, known as GAMP 5.

In the final rule on its Quality Management System Regulation (QMSR), FDA names consulting as a service that a medical device company must assess.

For you, this means your quality unit will treat a software development partner as a supplier and check it before the project starts. A development team provides an outside service in the same way a consultant does, so in our reading the same rules apply to it.

A software project usually involves two more checks, and teams often mix them up with supplier qualification:

• A supplier audit is a visit to the supplier or a review of its documents. It is one way to collect evidence and only one part of supplier qualification.
• Validation checks a software system and shows that it fits its intended use. Supplier qualification checks the company that builds that software.

An audit and a validated system do not replace supplier qualification, so your quality unit plans each of these checks separately. Each one rests on specific rules, and the next section shows which ones apply today.

Supplier Qualification Requirements: What FDA, EU GMP and ICH Say

Supplier qualification requirements come from U.S. Food and Drug Administration (FDA) regulations, European Union (EU) Good Manufacturing Practice (GMP) rules, and International Council for Harmonization (ICH) guidelines. Your quality unit relies on these documents when it decides what to check in a software partner. Some of them are binding law, and some are recommendations, so it helps to know which is which before you plan the check.

In the U.S., FDA supplier qualification rules depend on what the company makes. Medical device companies follow FDA’s Quality Management System Regulation (QMSR), which requires them to evaluate each supplier by risk, then keep monitoring and re-evaluating it. Drug companies follow section 211.22(a) of Title 21 of the Code of Federal Regulations (21 CFR), where the quality control unit approves or rejects drug products that another company makes under contract.

The QMSR is a recent change. It took effect on February 2, 2026, and made the international standard ISO 13485:2016 part of U.S. law. Since then, supplier checks follow clause 7.4 of that standard, as FDA explains it, and the old section 21 CFR 820.50 no longer applies.

The QMSR also changed what FDA can see during an inspection. FDA can now inspect supplier audit reports, so a report about your partner may end up in front of an FDA investigator. Our guide on what QMSR means for software vendors explains the regulation in more detail.

EU GMP rules cover medicine manufacturing in Europe, and regulators in many countries follow ICH guidelines. Both require a company to assess a contractor before outsourcing work, agree on responsibilities in writing, and monitor the contractor’s work afterward. Annex 11 of EU GMP covers computerized systems and adds that the need for a supplier audit should depend on a risk assessment.

Together, these rules are often called GxP, short for “good practice,” where the “x” stands for an area such as manufacturing or clinical work.

The GxP supplier qualification documents differ in how binding they are, and they agree on two points that matter for your project:

• Responsibility. The company that hires the partner stays responsible for the work.
• Risk. The depth of the check depends on how risky the work is.

Responsibility is the point the sources state most firmly, and in manufacturing or device work, a contract cannot move it to the partner. EU GMP Chapter 7 and ICH Q10 keep ultimate responsibility with the company that outsources the work, and the Pharmaceutical Inspection Co-operation Scheme (PIC/S) says the same about outsourced computerized systems.

The 2025 draft of Annex 11 goes in the same direction and proposes that the company “remains fully responsible” for work it hands to a vendor.

The risk point lets your quality unit match the effort to the work. A small task with little effect on product quality needs a lighter check than work on a system that stores production records or test results.

The table below brings all these documents together. For each one, you can see what kind of document it is, whom it covers, what it says about suppliers, and its status as of October 2026. Use it to find the right source when you write your own supplier procedure.

When you cite a document, keep it within its scope. For example, the CSA guidance covers only software used in device production or in a QMS, and the 2025 Annex 11 text is still a draft.

These rules tell your quality unit what to look for in a partner. The next section turns them into a process it can follow step by step.

The Supplier Qualification Process Step by Step

The supplier qualification process gives your company six steps to follow when working with a software partner, from rating the risk of the work to monitoring the partner once the project is underway.

When you follow them in order, your quality unit avoids gaps, and you keep records that show regulators how and why you chose the partner. You follow the same steps for any supplier, and with a software partner you mainly change the evidence you collect and the terms you agree on.

Before you start, your company needs a supplier qualification program. This is a written procedure that tells your team how to check suppliers and lets your quality unit decide how deep each check goes. ISPE authors who write about software providers give the quality unit this role.

Step 1 – Define the work and rate its GxP impact

Start by writing down what the partner will do for you and which of your systems and records the work will touch. Then rate what a failure in that work could mean for your product quality, for patient safety, and for data integrity, which means keeping your records complete and accurate. The 2025 draft of Annex 11 names these three areas as the main risks to consider.

Your rating sets how deep you go in every later step. ISPE’s GAMP 5 guide scales the effort by the GxP impact, complexity, and novelty of the work. ISO 13485 clause 7.4, as FDA explains it, asks you to evaluate a supplier by the work’s effect on quality and its risk.

If you are still choosing between several candidates, our guide on choosing a software development partner can help you decide.

• Result: a written scope of work with a risk rating.
• Done when: your quality unit approves the rating and the scope it covers.

Step 2 – Collect evidence with a questionnaire and documents

Now you need proof that the partner can handle work at this level of risk. The easiest way to start is a supplier questionnaire, which is a list of written questions about how the partner builds, tests, and controls its work. The international inspection network PIC/S also recommends questionnaires, and later in this guide you will find a ready list of questions to send.

Next, ask the partner for documents on its development, quality assurance, and cybersecurity practices. FDA’s CSA guidance lists these documents as inputs for your vendor review. You can also ask for System and Organization Controls (SOC) reports and ISO certificates, and treat them as one input among others.

Check that the partner can show you a documented quality system. Austria’s medicines regulator expects a software supplier to have at least a documented quality assurance system that you can assess in an audit.

• Result: the partner’s answers and documents.
• Done when: you have checked each answer against your risk rating and listed the gaps that are still open.

Step 3 – Decide if you need an audit and in what form

The answers from Step 2 tell you if you need to look deeper. An audit is one way to do that, and the next section helps you choose its format and depth by risk.

• Result: a decision on the audit.
• Done when: you have recorded the decision and its reason, and if you audit, you keep the report and findings on file.

Step 4 – Approve and record the supplier

Once you have the evidence, your quality unit decides on approval and records the decision. PIC/S expects your records to show how and why your company selected each software supplier. In the QMSR final rule, FDA also says device manufacturers must document the type and extent of control they plan to apply to a supplier.

Then add the partner to your approved supplier list (ASL) with the scope you approved. This list shows which suppliers your company may use, and you can keep it in your QMS or in a supplier management tool.

Result: an approval record for the partner.

Done when: you see the partner on your approved supplier list with its scope, risk rating, and the type and extent of control.

Step 5 – Put responsibilities in a quality agreement

Approval tells you the partner can do the work, and the agreement tells both sides who does what. A quality agreement is a written contract that divides quality duties between your company and the partner. Annex 11 says formal agreements must exist with any third party that provides, configures, validates, maintains, or modifies a computerized system, and ICH Q10 also asks you to put responsibilities in writing.

If your partner provides IT services, FDA recommends a written agreement, such as a master service agreement with a service level agreement or a quality agreement. You can find this advice in FDA’s Q&A on electronic systems in clinical investigations.

Make sure your agreement covers these points:

• Data integrity terms and a duty to tell you when data integrity fails.
• Subcontracting only with your prior approval.
• Your right to audit the partner.
• Advance notice of changes and security breaches.
• What happens to your code, data, and documents when the work ends.

The agreement divides duties, and your company stays responsible for the work. Under EU GMP, you remain ultimately responsible for the work you outsource. ISPE authors who write about quality agreements for software as a service (SaaS) state that “The quality agreement must not delegate GxP accountabilities to the SaaS provider.”

FDA’s guidance on quality agreements covers contract drug manufacturing and does not cover medical devices. Use it only as a model for how to structure your own agreement.

• Result: a signed quality agreement.
• Done when: your agreement names who is responsible for development, testing, changes, data integrity, subcontracting, audits, and exit.

Step 6 – Monitor and re-evaluate

Your work with the partner continues after you approve it, so supplier qualification and monitoring go together. The partner’s team and methods can change over time. FDA notes that the QMSR requires you to monitor and re-evaluate suppliers, and ICH Q10 asks you to monitor the contractor’s performance.

PIC/S also expects you to re-qualify outsourced partners from time to time and to look at data integrity risks each time.

We recommend that you watch three things in the partner’s work:

• Deviations and audit findings.
• Changes in the team or subcontractors.
• Changes to the partner’s procedures.

You decide how often to re-evaluate the partner based on risk, and the FAQ covers this question in more detail.

• Result: a monitoring plan for the partner.
• Done when: your plan names what you watch and which events start a new evaluation.

Supplier Audit, Questionnaire or Certificates: How Much Evidence Is Enough?

How much evidence is enough depends on the risk of the work you hand to the partner. You make this decision in Step 3, and a wrong call costs you in both directions. Too little evidence leaves gaps that an inspector can find, and too much turns a small task into a long audit project.

Regulators leave this decision to your company and ask you to base it on risk:

• Annex 11 says a risk assessment should decide if you need a supplier audit.
• PIC/S calls audits good practice and leaves their need and scope to your company.
• FDA’s CSA guidance accepts that a software vendor audit may not be feasible or appropriate for device production and QMS software.

For a custom development partner, the bar is higher. In the PIC/S table of software types, custom software is the category where the guidance says to audit the supplier. In our reading, an audit fits here because you need to see how the partner works, and an audit shows you that process directly.

A supplier qualification audit can take several forms. You can visit the partner on site, conduct a remote audit, send a written audit by mail, or review documents and certificates instead. ISPE authors who write about SaaS providers suggest choosing the format based on intended use and risk, and leave the type and depth of the check to your quality unit.

Certificates provide useful evidence, but you still need to confirm what they cover. A SOC 2 Type 2 report shows how an independent auditor tested the partner’s security controls over time. ISO 9001 covers quality management, and ISO 27001 covers information security.

FDA states in the QMSR final rule that “certification may not provide adequate assurances of supplier quality without further evaluation.” For critical systems, PIC/S adds that a QMS certificate alone is unlikely to settle the question.

The table below shows how the evidence you need changes with the situation. Find the row that matches your partner, then check what may be enough and which source supports it.

The last row comes from the EMA guideline on computerized systems and electronic data in clinical trials. Outside clinical trials, a partner that will not share key documents or support audits is a strong signal to stop and look elsewhere.

Whatever form your vendor audit takes, write the report with care. Under the QMSR, FDA can inspect supplier audit reports, so we recommend recording each finding and how the partner closed it in a way an investigator can follow.

The custom software row in the table shows why your usual supplier template may not fit a development partner. The next section compares this partner with a materials supplier and a SaaS vendor.

Materials Supplier, SaaS Vendor or Development Partner: What Changes for Quality

The main change for your quality unit is the thing it checks. Most suppliers deliver a product that your company can inspect, and a development partner delivers code built only for you. So with a development partner, your quality unit has to check how the partner works.

This difference is easiest to see when you compare the three kinds of suppliers that drug and medical device companies usually work with:

• Materials suppliers sell ingredients, packaging, and other goods that your company uses to make its products.
• Software vendors sell ready software that many companies use, such as a cloud system for quality records. This group includes commercial off-the-shelf (COTS) products and software as a service (SaaS).
• Custom development partners write software only for your company, such as new features in the system that stores your production records.

Your usual supplier template was likely written for the first group, so it focuses mostly on the product. If you use it for a development partner, you miss the questions that matter most. Here is how the check changes from one group to the next.

Checking a materials supplier. You can test what the supplier ships when it arrives. For key raw materials, qualification relies on approving the supplier’s certificate of analysis, the lab report that comes with each delivery, and on at least one identity test at your site. ISPE authors describe this approach in their article on qualifying suppliers of key raw materials.

Checking a software vendor. Software vendor qualification for a ready product relies mostly on the vendor’s controls, which FDA’s CSA guidance asks you to assess through a risk-based analysis. FDA also recognizes that your access to the vendor’s internal information may be limited.

Checking a custom development partner. FDA says testing software on its own is usually not enough to show that it fits its intended use, so you cannot rely on testing the finished code. For custom software, PIC/S says to audit the supplier and validate the complete system, and Annex 11 requires you to ensure the system was developed under a suitable quality management system.

In GxP vendor qualification, this means your quality unit looks at how the partner builds and tests the software and who does the work. The table below compares the three supplier types side by side. Read it row by row to see how each part of the check changes, and use it to adjust your own supplier template for a development partner.

Cells cite regulators, industry guides, and ISPE journal articles. “Our reading” marks our conclusions.

FDA’s CSA guidance lets device companies build on the work developers and suppliers have already done, and our guide on computer software assurance for software vendors explains how that reuse works.

Before you start the check, ask whose development process the work will follow. A partner can work under its own software development life cycle (SDLC), or its engineers can join your product teams and follow your process, as Zoolatech engineers did on a project with MasterControl. That second model is a form of team extension, and it changes what you assess.

What your quality unit checks depends on that model:

• The partner works under its own SDLC. You assess the partner’s quality system and development process.
• The partner’s engineers join your teams. You mainly assess their skills, training, system access, and any subcontractors, and the agreement states whose procedures apply.

The second point comes from our reading of Annex 11, which asks that agreements state each side’s responsibilities.

If your company sells software to drug or device makers, your customers may see your engineering partner as your subcontractor. ISPE authors expect responsibilities for subcontracted work that affects quality to be defined, and EU GMP says the contract should let the outsourcing company audit agreed subcontractors too. In our reading, you should qualify your partner with this chain in mind, so your own customers’ audits find no gaps.

Once you know which kind of partner you have and which model it works in, you can decide what to ask it before the project starts.

Supplier Qualification Questionnaire: What Your Quality Unit Will Ask a Software Engineering Partner

Your quality unit will ask a software engineering partner about how it builds software, who does the work, how it protects your data, and how you keep control until the work ends. You can turn the questions below into your own supplier qualification questionnaire or checklist. When the partner gets them before the project starts, it has time to prepare evidence, and your quality unit spends less time chasing answers.

The questions fall into four areas:

• Quality system and development process. How the partner plans, builds, and tests software.
• People and subcontractors. Who does the work and how the partner trains them.
• Data integrity, security and changes. How the partner protects your records and tells you about changes.
• Oversight and exit. How you check the partner’s work and what happens when it ends.

The table lists 14 questions across these areas. For each one, you see what your quality unit asks, which evidence to request, and where the expectation comes from. Use the Basis column when you need to explain to the partner or an auditor why a question is on your list.

Questions and evidence are our selection. The Basis column shows where each expectation comes from. EMA rows come from clinical trial guidance, rows from the UK Medicines and Healthcare products Regulatory Agency (MHRA) come from UK guidance, and the exit row comes from a 2025 EU draft. ISPE rows come from an article on quality agreements for SaaS, applied here to a development partner by analogy, and the Austrian regulator row comes from Austrian guidance.

We recommend sending these questions as a vendor qualification questionnaire before the document review or audit. The answers help your quality unit set the audit scope and become your supplier qualification criteria for approval. Keep them with the approval record from Step 4 so you can later show why you approved the partner.

A SOC report or ISO certificate answers only part of question 9 on security practices. For questions 7 and 12 on data integrity and access, our guide to Part 11 audit trail requirements explains how software keeps a secure history of every change to a record.

Where Supplier Qualification Fails: Lessons from FDA Warning Letters

Recent FDA warning letters show that supplier qualification can fail in basic ways, such as missing records or contractors nobody checked. A warning letter is the formal notice FDA sends a company after an inspection finds serious violations, and FDA publishes these letters on its website for anyone to read. They are useful for you because they show the gaps an inspector looks for, so you can check your own process against them.

Below are three recent examples from letters FDA has published, each with the process step it relates to.

1. A company forgot to add its software supplier to the approved list

In a September 2025 warning letter, FDA noted that a software supplier the company had used since 2023 was not on its approved supplier list. This gap relates to Step 4, and you close it by adding every supplier to the list with its approved scope.

2. A company did not check the skills of its contract staff

In an October 2026 warning letter, a company had hired a contractor to clear a backlog of complaint investigations. FDA found that the company did not evaluate the contractor’s ability to provide qualified staff for quality assurance work and could not show that the contract staff had product training.

This gap relates to Step 2 and to question 5 about the partner’s people. The contractor handled complaints, and the same gap applies to a software team. The inspections took place from October to December 2025 under the older Quality System regulation, so the letter cites 21 CFR 820.50.

3. A company did not decide how much control its suppliers’ work needed

In a June 2023 warning letter, FDA found that a company did not define the type and extent of control over services from its suppliers. This gap relates to Step 4, and in the QMSR final rule, FDA says manufacturers must document this control.

These three letters are examples, and they do not show how often such gaps occur. All three come from inspections held before the QMSR took effect.

In each case, the missing piece was a record or a check that this guide covers. When your quality unit completes Steps 2 and 4 and asks the partner about its people, you close these gaps before an inspector finds them.

So far, this guide has shown the check from your quality unit’s side. The next section shows what the same practices look like from the partner’s side.

Case Study: What Supplier Qualification Looks Like from the Partner’s Side

From the partner’s side, supplier qualification means having practices that answer your quality unit’s questions with evidence. When you know what these practices look like in a working team, it is easier for you to judge the answers a partner gives you. Here is an example from our own work.

MasterControl builds quality, manufacturing, and compliance software for life sciences and other regulated industries. On one project, Zoolatech engineers joined MasterControl’s product teams and worked as part of its development process. This is the model where the partner’s engineers join your teams, and the MasterControl team extension case study shows how it worked.

As the work grew, the team grew with it, and our article on how the MasterControl team grew describes that process.

Across our MasterControl projects, the work included practices that answer several questions from the table above:

Approval steps and traceability (questions 1 and 2, on the development process and traceability). Our engineers added verification and approval steps, feedback loops, and governance to a delivery workflow that uses artificial intelligence (AI). They also improved end-to-end traceability, which is what question 2 asks a partner to show.

Automated validation reports (questions 3 and 4, on testing and reusable records). A team of 3 Zoolatech engineers built Validation on Demand with MasterControl. This framework executes validation from start to finish and creates a report every time it is used, and the automated validation case study tells the full story.

Tests owned by developers (question 3, on testing). In our test automation work for MasterControl, we moved test ownership to the development teams. This removed delays from waiting on separate test engineers, known as software development engineers in test (SDETs). Test automation is part of our quality assurance services.

In every engagement, we provide a dedicated Delivery Manager, a live risk register, and a formal quality assurance checkpoint, and our teams work in the client’s time zone.

These examples show how we worked on one client’s projects. They say nothing about how MasterControl qualified Zoolatech, and they show the kind of evidence you can ask any partner to share.

Final Word

Qualifying a software partner takes time, and it often happens while your engineering team is waiting to start. From the inside, it can feel like paperwork standing between you and the project.

This effort pays off. Supplier qualification is your chance to find gaps in a partner’s process before they turn into wrong records in a system that FDA inspects. At this stage, you fix a gap with a conversation, and after an inspection, the same gap can cost you a warning letter and months of corrective work.

Send the question bank to your partner early and ask for evidence behind each answer. When the answers come back complete, your quality unit can approve the partner with confidence, and the project can start on time.

If you are looking for an engineering partner for GxP software work, Zoolatech is ready to answer your quality unit’s questions and show how our teams work inside regulated product development.