What does third-party software validation (IV&V) involve and cost for FDA/ISO-regulated software?
Independent verification and validation is a team outside your development organization re-deriving the evidence your quality system will be judged on: requirements traced to risk and to system needs, verification that the design and the code match those requirements, and validation that the software does its job in its intended use, in the hands of the people who will actually use it. FDA treats independence as a quality assurance precept rather than a nice-to-have, and in regulated software IV&V usually runs as a standing oversight function rather than a one-time test pass. Cost is not a list price. It is set by six things: the risk class and intended use of the software, how much reviewable requirements and traceability you already have, how many regulatory frameworks are in scope at once, whether you are buying concurrent oversight or a retrospective read on software already fielded, the review cadence and duration, and how much of the evidence falls out of your toolchain rather than being assembled by hand. Scope those six and you can hold a real estimate conversation. Any firm quoting before it has read your requirements is guessing.
What IV&V actually involves for FDA and ISO regulated software
The word doing the work is independent. FDA’s own guidance is unusually direct about why. In General Principles of Software Validation; Final Guidance for Industry and FDA Staff (document issued January 11, 2002, CDRH and CBER), Section 4.9, Independence of Review, reads: “Validation activities should be conducted using the basic quality assurance precept of ‘independence of review.’ Self-validation is extremely difficult. When possible, an independent evaluation is always better, especially for higher risk applications. Some firms contract out for a third-party independent verification and validation, but this solution may not always be feasible. Another approach is to assign internal staff members that are not involved in a particular design or its implementation, but who have sufficient knowledge to evaluate the project and conduct the verification and validation activities.”
That is the buying case in four sentences, and it is worth noticing that FDA offers two routes, not one. Contracting out is the first. Structurally separate internal reviewers are the second. The question to settle before you buy anything is not whether your QA team is good. It is whether it is independent of the people whose work it is judging.
It is also worth being clear about what IV&V does not do. The same guidance states that “regardless of the distribution of tasks, contractual relations, source of components, or the development environment, the device manufacturer or specification developer retains ultimate responsibility for ensuring that the software is validated.” You can buy independence. You cannot buy away accountability, and any firm that implies otherwise is selling you something you will have to retract in front of an assessor.
The regulatory ground under this moved recently, which is the single most common reason a validation package that was fine two years ago is not fine now. 21 CFR part 820 is now titled the Quality Management System Regulation. Under 21 CFR 820.7(b) it incorporates ISO 13485:2016 by reference, and 21 CFR 820.10(a) requires a manufacturer to “Document a quality management system that complies with the applicable requirements of ISO 13485 (incorporated by reference, see 820.7) and other applicable requirements of this part.” FDA states that the revised part 820 is effective February 2, 2026, and that on that date the agency stopped using the Quality System Inspection Technique for device inspections and began using the process described in the updated Inspection of Medical Device Manufacturers Compliance Program: 7382.850. If your last validation package was assembled to survive a QSIT-shaped inspection, that alone is a reason to have someone independent read it again.
Step 1: Independent review of requirements, risk, and traceability
The first pass is not testing at all. It is reading. An IV&V team takes your intended use, your risk analysis, and your software requirements, and asks whether each requirement traces both to a system need and to a risk it controls, and whether each is written so it can actually be verified. FDA’s guidance describes exactly this: “A software requirements traceability analysis should be conducted to trace software requirements to (and from) system requirements and to risk analysis results.”
This is where most of the findings live, and it is by a wide margin the cheapest place to find them. A requirement that cannot be objectively verified will produce a test that proves nothing, and you will not discover that until an assessor asks what the test demonstrates. Two specific failures show up over and over: a requirement with no risk behind it, which usually means the risk analysis is incomplete rather than the requirement being redundant, and a risk with no requirement in front of it, which is the one that costs money. Both are found on paper, in days, by people reading.
Step 2: Independent verification against the design and the code
Verification asks a narrow question: does what was built match what was specified. The IV&V team reviews the design against the requirements, reviews the code against the design, and checks that the test procedures actually exercise what they claim to exercise. This is also where device classification starts driving scope. Under 21 CFR 820.10(c), manufacturers of class II and class III devices, and of class I devices “automated with computer software,” must comply with the requirements in Design and Development, Clause 7.3 and its subclauses in ISO 13485. The design history is not filing; it is the thing being inspected.
If the system creates, modifies, maintains, or transmits electronic records under 21 CFR part 11, there is a second and blunter requirement. 21 CFR 11.10(a) requires “Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.” That last clause is the one teams underestimate. Proving a system can detect an altered record is a different test design from proving it stores records correctly, and it is a common source of late rework because nobody wrote a requirement for it.
Step 3: Independent validation and the evidence package
Validation asks the wider question: in the hands of the people who will actually use it, in the environment it will actually run in, does the software do the job. The output is not a green dashboard. It is an evidence package an assessor can follow without a guide: the traceability matrix, the verification and validation records, the deviations and how each one was dispositioned, and a written statement of what was reviewed, by whom, and against what.
The test of a package is whether a reader who was not in the room can get from a risk to the requirement that controls it, to the design element that implements it, to the test that demonstrates it, and back again, without asking anyone a question. If that walk needs a narrator, the package is not finished, however many test reports sit behind it.
What drives the cost up or down
Nobody scopes this from a price list. Six things move the number, and five of them are inside your control.
- Risk class and intended use. This is the one you do not control, and FDA is explicit that it should drive coverage rather than budget: “Validation coverage should be based on the software’s complexity and safety risk, not on firm size or resource constraints. The selection of validation activities, tasks, and work items should be commensurate with the complexity of the software design and the risk associated with the use of the software for the specified intended use.” Higher risk means more activities, and more activities means more hours. There is no honest way around it.
- The state of what you already have. A reviewable requirements set with real traceability is the single biggest lever on the number. If the IV&V team has to reconstruct requirements from a backlog, a wiki, and a set of screenshots before it can review anything, you are paying independent reviewers to do archaeology at review rates. Fixing this before you buy is the cheapest cost reduction available to you.
- How many frameworks are in scope at once. The QMSR on its own is a single exercise. The QMSR plus part 11 plus a customer-imposed security framework is not triple the work, but neither is it the same work, because each framework wants substantially the same evidence indexed a different way.
- New build versus already fielded. Concurrent oversight of software being built costs more in total and finds problems while they are still cheap to fix. Retrospective validation of software already in the field costs less per month and more per finding, because every gap it turns up has already been built on, tested against, documented, and in some cases shipped. Remediation, not review, is what makes a retrospective engagement expensive.
- Cadence and duration. A retained oversight function priced by the month behaves differently from a bounded readiness review priced by the engagement. Both are legitimate. Choosing the bounded one because it is cheaper, when what you actually need is standing independence, is how programs end up buying both.
- How much evidence is generated rather than assembled by hand. Where traceability and test evidence fall out of the toolchain, the reviewers spend their time on judgment. Where they are assembled by hand into documents at the end, a meaningful share of the engagement is transcription, and it has to be repeated after every change.
How to scope it so you get a number you can defend
Ask for the estimate in named units rather than one total: requirements reviewed, interfaces reviewed, increments covered, frameworks in scope, deliverables signed. A firm that can only price the whole thing has not decomposed the work, and a total with no units behind it cannot be renegotiated when the scope moves, only re-argued.
Then ask three questions of any proposal. Which of the six drivers above has the firm actually confirmed, as opposed to assumed? What specific assumption, if it turns out to be wrong in week two, changes the number, and by roughly how much? And what does the firm hand you at the end, named document by named document, with a signature line on each? A proposal that answers those three is an estimate. One that does not is a placeholder with a number on it.
What we will not do is hand you a per-stage table whose rows add up to a total. Validation scope changes with what the first review finds, and a table that pretends otherwise is a sales artifact rather than an estimate.
When to bring in a partner
Bring in an independent team when the software carries real risk, when the evidence has to survive someone who was not in the room, or when your own QA function reports to the same leader as your development organization. On the last one, FDA’s two routes are worth re-reading before you spend anything: if you can create genuine internal independence, do that. If you cannot, that is what a third party is for.
On our own record, stated plainly and no wider than it goes: i3solutions has performed IV&V on software subject to FDA design-control expectations, including requirements traceability from controls through delivered functionality. We are not going to dress that up into a submission, a clearance, or a certification, and you should be skeptical of any firm that dresses up its own.
The rest of our IV&V record sits in other regulated regimes, and it is worth reading as evidence of how the function is run rather than as FDA work. On a defense program assessed under CMMC, not under FDA or ISO 13485: Across two Program Increments, the IV&V function logged 47 findings (3 critical, 11 high, 33 medium-low), 41 of which closed within the originating sprint. The C3PAO assessment completed without findings against the application, and the contractor extended the engagement. The number that matters there is not 47. It is 41 closed in the sprint that raised them, because a finding closed inside the sprint costs a fraction of the same finding found during an assessment. On a financial services engagement under GLBA, again a different regime from FDA: The IV&V engagement validated requirements traceability from the underlying compliance framework controls through the delivered functionality, identified two control mappings where the vendor’s interpretation of GLBA requirements diverged from the firm’s expectation, surfaced three test cases the vendor’s plan had not included, and produced the board-defensible attestation the audit committee required. Different regulator, same mechanism: read the traceability first, and the expensive gaps show up on paper.
The delivery context behind that: i3solutions has been a Microsoft partner since 1997. i3solutions has completed more than 600 Microsoft platform implementations. The reviewers have built the class of system they are reviewing, which is what separates a useful finding from a checklist observation. Delivery is US-based and senior.
If you want to know where you stand before committing to a cadence, start with a bounded readiness review. If the program is already running and the risk is that defects surface after release, standing oversight is the right shape. Either way, read how IV&V differs from traditional testing first so you are not paying independent-review rates for work your existing QA function already covers, then look at running IV&V inside an Agile delivery cadence if your teams work in sprints, and the IV&V best practices that decide whether findings close cheaply or expensively. Engagement models sit inside our custom Microsoft software consulting practice, and the build side lives in custom application development services.
Schedule a 30-minute scoping call
Frequently asked questions
How much does third-party IV&V cost for FDA or ISO regulated software?
We do not publish a price band for IV&V in an FDA or ISO 13485 context, because the honest answer is that the number is set by scope rather than by a rate card, and a firm that quotes before reading your requirements is guessing. Six things drive it: the risk class and intended use of the software, how much reviewable requirements and traceability already exist, how many regulatory frameworks are in scope at once, whether the software is being built or is already fielded, the review cadence and duration, and how much of the evidence falls out of your toolchain rather than being assembled by hand. Scope those six, ask for the estimate in named units rather than one total, and ask which of the six the firm has actually confirmed. That gets you a number you can defend internally.
Is independent validation actually required, or is our own QA team enough?
FDA’s General Principles of Software Validation does not mandate a third party, but it is direct about the problem: “Validation activities should be conducted using the basic quality assurance precept of ‘independence of review.’ Self-validation is extremely difficult.” The guidance offers two routes, contracting out for third-party independent verification and validation, or assigning internal staff members who were not involved in the design or its implementation but who have sufficient knowledge to evaluate the project. The question is not whether your QA team is good. It is whether it is structurally independent of the people whose work it is judging.
Does hiring an IV&V firm transfer regulatory responsibility to them?
No. FDA’s guidance states that regardless of the distribution of tasks, contractual relations, source of components, or the development environment, the device manufacturer or specification developer retains ultimate responsibility for ensuring that the software is validated. An independent team gives you better evidence and an outside opinion. It does not move your name off the submission, and a firm that suggests it does is one to walk away from.
What does IV&V produce that our existing test reports do not?
Traceability that runs in both directions, and a written record of who reviewed what against which standard. Test reports tell you which tests passed. An IV&V package tells you whether the requirements were the right requirements, whether each traces to a risk and to a system need, which requirements had no test behind them, which risks had no requirement in front of them, and how every deviation was dispositioned. The practical test is whether a reader who was not in the room can walk from a risk to a requirement to a design element to a test and back without asking anyone a question.
When in the project should IV&V start?
Before code, if you have the choice. The first pass reviews requirements, risk analysis, and traceability, and that is where the cheap findings are. A requirement that cannot be objectively verified costs very little to fix on paper and a great deal to fix after it has been built, tested against, and documented. Starting IV&V at the end still produces a defensible package, but you are paying to discover problems at the most expensive point in their life, and the cost of the engagement is then mostly remediation rather than review.
Does the QMSR change what our software validation evidence has to look like?
It changes the frame it is read in. 21 CFR part 820 is now titled the Quality Management System Regulation, it incorporates ISO 13485:2016 by reference under 21 CFR 820.7(b), and 21 CFR 820.10(a) requires a documented quality management system complying with the applicable requirements of that standard. FDA states the revised part is effective February 2, 2026, and that on that date the agency stopped using the Quality System Inspection Technique and began using the updated Inspection of Medical Device Manufacturers Compliance Program: 7382.850. Your underlying verification and validation evidence does not become wrong, but the index into it, and the vocabulary an inspector arrives with, both changed.
