The Handoff Problem: One Record, Three Custodians

Ask a clinical operations leader who owns data quality and you will usually get a confident answer: the sponsor does. Ask the same leader who is accountable for a specific wrong value in a specific dataset, discovered eleven days before database lock, and the answer takes longer. The value was measured by a central laboratory. It was transferred under a specification written by a contract research organization. It was mapped into study data tabulation model domains by a third team. It failed a range check nobody had updated since the protocol amendment. Four organizations are involved and each of them did what their contract said.

This is not a failure of goodwill. It is a structural feature of how modern development and manufacturing are organized. Sponsors outsource because outsourcing gives them access to capability they do not have and capacity they do not want to carry. The German Association of Research-Based Pharmaceutical Companies surveyed its members on contract research organization oversight and found that the majority used a full-outsourcing model with preferred providers, working with roughly three contract research organizations each.1 Three providers is the median case, not the extreme one. Add a central laboratory, an interactive response technology vendor, an electronic clinical outcome assessment platform, and a safety database provider, and a mid-size study routinely has six or seven organizations with hands on trial data.

The manufacturing chain looks similar. A contract development and manufacturing organization runs the process and generates the batch record. A contract analytical laboratory performs release testing. A packaging and labeling contractor adds another set of records. The sponsor’s quality unit consolidates all of it and makes the release decision. FDA’s regulations recognize this arrangement directly, and the agency’s position is unambiguous: contractors are treated as an extension of the manufacturer’s own facility.2

Why blame diffuses at the boundary

Three things happen at every organizational boundary that do not happen inside one company.

First, context is lost. The person who entered a value knows why it looked odd. The person who transformed it three weeks later does not. A comment field, a repeat sample note, or a site’s local practice does not always survive a transfer specification written before anyone knew that nuance existed.

First-line detection also moves. Inside one company, the person who creates a record and the person who uses it often work in the same quality system and can talk. Across a boundary, detection typically happens at the receiving end, days or weeks downstream, by someone with no ability to inspect the source. That gap between where a defect is created and where it is found is the single biggest driver of slow resolution.

Second, each party optimizes what it is measured on. A laboratory is measured on turnaround time and analytical accuracy. A data management vendor is measured on query resolution and lock readiness. Neither is measured on the joint outcome, which is a clean, complete, analyzable dataset. Reconciliation work falls between the two scorecards.

Third, the contract usually describes activities, not failures. A statement of work says the vendor will perform electrocardiogram overreads and deliver files on an agreed schedule. It does not say what happens when the overread is right, the file is right, and the subject identifier in the file does not match any subject in the sponsor’s database because the site enrolled under a screening number and the vendor keyed the randomization number. Somebody has to own that. If the agreement is silent, the party with the least leverage usually ends up doing the work, which is rarely the party best placed to fix the cause.

The reframe this article proposes: stop asking “who owns data quality” and start asking “who owns this class of defect.” Ownership assigned by activity leaves gaps at every boundary. Ownership assigned by defect class closes them, because a defect class is defined by its cause, and a cause always belongs to somebody.

Six Defect Classes, and Why Each Needs Its Own Owner

Almost every cross-organization data failure we see in pharma falls into one of six classes. They are worth separating because they have different causes, different detection points, different remediation work, and different correct owners. Treating them as one category called “data issues” is what produces the finger-pointing.

CLASS 1

Capture errors

The value was wrong when it was created. A vial was mislabeled, an operator read the wrong instrument, a site recorded a weight in the wrong field, a sensor was out of calibration. No downstream process can recover the true value.

CLASS 2

Transcription errors

The value was correct at the source and became wrong when a human or a manual step moved it. Paper laboratory reports keyed into a case report form, batch data retyped into a summary, a result copied from an instrument printout.

CLASS 3

Transformation and mapping errors

The value was correct on arrival and became wrong through a program: a unit conversion, a controlled terminology mapping, a derivation, a join on the wrong key, a rounding rule applied at the wrong step.

CLASS 4

Reference data and version mismatches

Every value is individually correct, but the parties are using different versions of the reference data that gives them meaning: laboratory reference ranges, dictionary versions, specification limits, material codes, or a protocol amendment implemented on different dates.

CLASS 5

Timeliness failures

The data is accurate and arrives too late to be used for the decision it was meant to support. A deviation reported after batch disposition, a safety signal that reaches the sponsor after the data monitoring committee met, a transfer that misses the lock window.

CLASS 6

Reconciliation gaps

Two systems each hold internally consistent records that do not agree with each other, or one holds records the other does not: subject counts, sample counts, event counts, batch quantities, serious adverse events in the clinical database versus the safety database.

Why the classes cannot share an owner

Capture errors can only be owned where capture happens. If a site records the wrong value, no contract term makes the sponsor’s data management vendor capable of fixing it. What the vendor can own is detection: an edit check that flags the implausible value fast enough for the site to correct it against source. ICH E6(R3) makes this distinction directly. It says corrections to data errors should be attributed, justified, and “supported by source records around the time of original entry.”3 That is a statement about who can legitimately correct a capture error, and the answer is the party with access to source.

Transcription errors have a structural answer that most parties skip past. The guideline is blunt about it: unnecessary transcription steps between the source record and the data acquisition tool should be avoided.3 If your architecture requires a human to retype a value that already exists electronically, you have accepted a defect rate, and the owner of that defect rate is whoever chose the architecture, not whoever does the typing.

Transformation and mapping errors belong to whoever wrote and validated the program, but detection almost always belongs to somebody else. This is the class where the ownership gap does the most damage, because the party that created the defect has no natural trigger to look for it and the party that finds it cannot see the code.

Reference data mismatches are the class most often left unassigned. Laboratory reference ranges are a clear example. The Society for Clinical Data Management’s guidance notes that each local laboratory must supply a set of reference ranges to the sponsor or contract research organization, which increases the work required for every aspect of laboratory data collection, and that variability in reference ranges and units between laboratories is a defining disadvantage of local laboratory use.4 The same guidance recommends a conversion factor table to standardize conventional units to the International System of Units, precisely because unit handling cannot be left to each party’s local convention.4

The class most often missing from agreements: in the vendor agreements we review, capture and transcription are usually addressed, transformation is sometimes addressed through validation language, and reference data version control is almost never addressed by name. Yet a dictionary upversion or a mid-study reference range change can invalidate a whole family of derived values without triggering a single edit check, because every individual value is correct.

Timeliness deserves its own class because it is the one failure mode where the data is not wrong. Treating a late deviation report as a quality event rather than a data event is how it stays invisible in data quality metrics while doing more damage than most inaccuracies. FDA’s quality agreements guidance addresses this directly for manufacturing: the agreement should explain how the contractor will report manufacturing deviations to the owner, as well as how deviations will be investigated, documented, and resolved.5 Reporting mechanics and timing are part of the quality obligation, not an administrative afterthought.

Reconciliation gaps are structurally different from the other five. They cannot be owned by one party at all, because by definition they exist between two parties’ records. What can be owned is the reconciliation itself: who runs it, on what cadence, against which fields, and who adjudicates when the two records disagree and both parties believe they are right.

What the Regulations Actually Assign

Before designing your own allocation, it helps to know what is already assigned by regulation and cannot be negotiated. The pattern across clinical and manufacturing is consistent: activities can be transferred, accountability cannot, and anything not explicitly transferred stays where it started.

Clinical: ICH E6(R3)

ICH E6(R3) reached Step 4 in January 2025 and reorganizes sponsor oversight around this principle. Section 3.6.6 states that a sponsor may transfer any or all trial-related activities to a service provider, but the ultimate responsibility for those activities, including the reliability of the trial data, resides with the sponsor.3 Section 3.6.4 supplies the default rule that closes the gap: “The sponsor’s trial-related activities that are not specifically transferred to and assumed by a service provider are retained by the sponsor.”3

Read that as a drafting instruction. If your agreement does not name a defect class, that defect class is yours. Silence is not a shared burden. Silence means the sponsor owns it.

Two further provisions matter for multi-party chains. Section 3.6.9 requires the sponsor to maintain oversight of important trial-related activities transferred to service providers, including activities further subcontracted by the service provider.3 A contract research organization that subcontracts imaging does not put that activity outside sponsor oversight. And section 4.2.5 speaks directly to the transfer problem this article is about: validated processes, or other appropriate processes such as reconciliation, should be in place to ensure that electronic data transferred between computerized systems retains its integrity, the transfer process should be documented to ensure traceability, and reconciliation should be implemented as appropriate to avoid data loss and unintended modifications.3

Clinical systems: the EMA computerized systems guideline

The EMA guideline on computerized systems and electronic data in clinical trials, effective September 2023, is more explicit than E6(R3) on the vendor question because that is its whole subject. It states in its glossary that all references to sponsors and investigators in the guideline also apply to their service providers, irrespective of the services provided.6 Its Annex 1 on agreements says responsible parties can delegate tasks to a service provider, but the full responsibility for data integrity, security, and confidentiality resides with them, and that agreements should specify subcontracting conditions and the responsible party’s oversight of subcontracted activities.6

The same annex contains a line worth putting in front of any procurement team: if appropriate agreements cannot be put in place because a service provider will not allow access to important documentation, or is unwilling to support pre-qualification audits or regulatory inspections, systems from that service provider should not be used in clinical trials.6 That is not a preference. It is a disqualification criterion.

Manufacturing: ICH Q10, EU GMP Chapter 7, and 21 CFR

ICH Q10 section 2.7 extends the pharmaceutical quality system, including management responsibilities, to the control and review of outsourced activities and the quality of purchased materials, and places ultimate responsibility for having those control processes on the pharmaceutical company.7 EU GMP Chapter 7 was revised in light of Q10 and carries the same logic into European inspection expectations. Clause 7.4 states that the contract giver is “ultimately responsible to ensure processes are in place to assure the control of outsourced activities.”8 Clause 7.15 is the operational one: the contract “should describe clearly who undertakes each step of the outsourced activity,” and the chapter then lists steps including knowledge management, technology transfer, subcontracting, testing and releasing materials, and in-process controls.8 Clause 7.16 requires that all records related to outsourced activities be kept by, or be available to, the contract giver.8

In the United States, 21 CFR 200.10 records FDA’s position that extramural contract facilities are regarded as an extension of the manufacturer’s own facility,2 and 21 CFR 211.22(a) makes the quality control unit responsible for approving or rejecting drug products manufactured, processed, packed, or held under contract by another company.9 FDA’s 2016 quality agreements guidance draws the conclusion explicitly: “No party to a quality agreement may delegate any of its responsibilities to comply with CGMP through the quality agreement or any other means.”5

The agency repeats the point in enforcement. A December 2025 warning letter to a contract facility carried the standard formulation: “You are responsible for the quality of drugs you produce as a contract facility regardless of agreements in place with product owners.”10 Both ends of the relationship are responsible. The contract allocates work and evidence, not liability.

The common rule across all four frameworks

Clinical and manufacturing regulators converge on the same three statements, and every ownership design should start from them:

  • Activities transfer, accountability does not. The sponsor or owner remains answerable for the reliability of the record regardless of who produced it.
  • Unassigned means retained. Anything the agreement does not specifically transfer stays with the sponsor or contract giver.
  • Subcontractors are in scope. Oversight follows the activity down the chain, not just to the first counterparty.

The Defect-Class Ownership Matrix

Here is the allocation we recommend as a starting point. It separates four roles that agreements usually collapse into one word, “responsible,” and that separation is most of the value. Detection, correction, root cause, and evidence are four different obligations, and they frequently belong to different parties.

Defect classOwns detectionOwns correctionOwns root cause and CAPAEvidence required
Capture errors Receiving party, through edit checks and plausibility rules agreed before first transfer Originating party only, against source records Originating party, with sponsor oversight of repeat patterns Source record, audit trail entry, query and response with reason for change
Transcription errors Receiving party, through source data verification sampling and cross-field checks Originating party, against the source it transcribed from Whoever designed the process step that required transcription Both the source and the transcribed record, plus the verification method used
Transformation and mapping errors Receiving party, through acceptance tests on every transfer, not just the first Party that owns the program or mapping specification Same party, plus the party that approved the specification Version-controlled specification, validation record, before-and-after comparison of affected records
Reference data and version mismatches Named reference data steward, on a defined review cadence Party that holds the authoritative copy of the reference data Sponsor, because the defect is a governance gap, not a vendor error Effective-dated reference data register, impact assessment, list of records revalued
Timeliness failures Receiving party, through automated monitoring of expected versus actual delivery Sending party, through recovery delivery Sending party, escalating to joint governance after a second occurrence Transfer log with timestamps, notification record, impact assessment on decisions already made
Reconciliation gaps Named reconciliation owner, on the schedule in the agreement Adjudicated case by case against a pre-agreed tiebreak rule Joint, reviewed at the governance meeting Reconciliation output, adjudication decision with rationale, corrected records in both systems

Three design choices inside the matrix

Detection is almost always downstream of creation. That is not a flaw, it is physics. Design for it. The receiving party should be contractually obliged to run detection and contractually protected from owning the correction, so nobody is tempted to fix a value they cannot verify against source. A downstream party that “corrects” an upstream value without source access has not fixed a data quality problem, it has created a data integrity problem.

Root cause can belong to a party that did not create the defect. Reference data mismatches are the clearest case. If two vendors used different dictionary versions, neither did anything wrong. The sponsor failed to specify which version was authoritative and when it changed. Assigning root cause to a vendor there produces a corrective action that cannot work.

Evidence is a separate obligation from correction. A vendor can correct a record and still leave you unable to demonstrate to an inspector what changed and why. EU GMP Chapter 7 requires that records related to outsourced activities be kept by or available to the contract giver,8 and E6(R3) requires that corrections be attributable and justified.3 Name the evidence artifact in the agreement, not just the fix.

A Worked Example: One Lab Result Through Three Parties

Consider a serum potassium result in a phase 2 study. The study uses a central laboratory, a contract research organization that performs data management, and a sponsor platform where the clinical data reviewers work. The value in the final dataset is 5.9 mmol/L and it is flagged as a clinically significant abnormality that would exclude the subject from the per-protocol analysis set. It should have been 3.9.

1

The site draws the sample and completes the requisition

The site enters the subject’s screening number on the requisition rather than the randomization number, because the sample was drawn during an unscheduled visit and the coordinator used the screening-visit kit. The value measured is correct. The identifier is not. Class 1 defect, created at the site, invisible to everyone at this point.

2

The central laboratory analyzes and transfers

The laboratory analyzes the sample, produces 3.9 mmol/L, and includes it in the weekly transfer file under the identifier on the requisition. The laboratory has met its obligation exactly. It has no way to know the identifier is wrong, because it holds no enrollment data. Detection here would require the sponsor to have supplied the laboratory with a subject listing for independent reconciliation, which the Society for Clinical Data Management recommends doing during study conduct or before database lock.11 In this study, that listing was never provided.

3

The data management vendor loads the file

The load program does not find a matching visit for that identifier. Rather than rejecting the record, the program assigns it to the nearest visit by date, a behavior that was in the load specification and was approved two years earlier for a different study. The record now belongs to the wrong visit for the right subject. Class 3 defect, created in the transformation, and the specification was approved by the sponsor.

4

The reference range check fires on the wrong baseline

The flagging program compares the value to the reference range effective at the assigned visit date. The laboratory revised its potassium reference range four months into the study. The program uses a single range for the whole study because the transfer specification did not carry an effective date on the range fields. The value is now compared against the wrong range. Class 4 defect, and neither the laboratory nor the vendor caused it.

5

A duplicate arrives and wins

The site, realizing the identifier problem, asks the laboratory to reissue under the correct number. The laboratory reissues. Both records now exist. The load program applies a last-in-wins rule at subject and visit level and retains a different subject’s value, 5.9, because the reassignment in step 3 put two subjects’ records in the same visit slot. Class 6 defect: two systems, both internally consistent, that no longer agree.

6

Detection, eleven days before lock

A medical reviewer notices that a subject with no history of renal impairment has a single isolated hyperkalemia value with no repeat. She raises it. Now three organizations investigate the same record for nine days, each confirming that their own step performed as specified. All three are correct.

What the ownership matrix would have changed

Notice that no party in this chain broke its contract. The laboratory reported accurately. The vendor ran an approved load specification. The site corrected its own error as soon as it found it. Every activity-based obligation was met and the dataset was still wrong.

Under a defect-class allocation, four things happen earlier. The subject listing reconciliation in step 2 is a named obligation with an owner and a cadence, so the identifier mismatch surfaces within one transfer cycle instead of six months later. The load specification’s fallback behavior is an acceptance test case, so assigning an unmatched record to a nearest visit fails the test rather than passing through unremarked. Reference ranges carry effective dates as mandatory fields in the transfer specification, and a named reference data steward owns the register. And the duplicate resolution rule is adjudicated by a person against a pre-agreed tiebreak, not by a program applying last-in-wins to a case nobody anticipated.

The manufacturing version of the same story

The manufacturing chain produces the same shape of failure with different vocabulary. A contract development and manufacturing organization runs a batch and records an in-process pH reading. A contract analytical laboratory performs release testing against a specification revision the sponsor issued but the laboratory’s system had not yet adopted. The sponsor’s quality unit consolidates the batch record package and finds a result that meets the old limit and fails the new one. Three parties, one class 4 reference data defect, and a batch disposition decision waiting on it. FDA’s quality agreements guidance anticipates exactly this and recommends the agreement designate responsibility for investigating deviations, discrepancies, failures, out-of-specification results, and out-of-trend results in the laboratory, and for sharing the reports of those investigations.5 The sharing clause matters as much as the investigation clause, because a root cause investigation whose report never reaches the owner has not closed anything.

The Machinery: Agreements, RACI, and Transfer Specifications

The matrix is the design. Four artifacts carry it into operation. We have written separately about how to draft data quality service level language that holds up, so this section deliberately covers the allocation machinery rather than the drafting of performance commitments.

1. Quality agreement and contract language by defect class

Both FDA and the EU expect the written agreement to be specific about who does what. FDA’s guidance notes that quality agreements may use charts, matrices, or narratives, and that regardless of format the agreement should clearly document which party is responsible for specific activities.5 EU GMP Chapter 7 requires that the contract describe clearly who undertakes each step.8 Neither says the allocation has to be organized by activity, which means you are free to add a defect-class annex, and that is what we recommend.

Two structural points. Keep the defect-class annex in the quality agreement or technical agreement rather than the commercial contract. FDA recommends that quality agreements be separate from, or at least severable from, commercial contracts,5 and defect ownership is a quality matter that should survive a pricing renegotiation. Second, write the annex so that unassigned classes fail visibly. A line that reads “any defect class not listed in this annex is retained by the sponsor” makes E6(R3) 3.6.4 explicit and gives your own team a reason to complete the table.3

2. A RACI that covers defect classes, not just deliverables

RACI matrices are already the most common oversight instrument in the industry. In the vfa member survey, RACI matrices were named by 95 percent of respondents among the instruments used to implement contract research organization oversight, ahead of standard operating procedure validation matrices and communication plans.1 The instrument is not the gap. What it covers is.

95% of surveyed sponsors named RACI matrices among their oversight instruments [1]
90% had established formal escalation procedures for provider issues [1]
~3 contract research organizations per sponsor among full-outsourcing companies [1]

Most vendor RACI matrices list deliverables down the left side: the data management plan, the edit check specification, the transfer specification, the lock checklist. Add six rows for the six defect classes and four columns for detection, correction, root cause, and evidence. The exercise takes an afternoon and it consistently exposes two or three cells where both parties assumed the other had it.

One discipline makes the RACI useful rather than decorative: every “A” must be a named role at a named organization, and no cell may contain two accountable parties. Joint accountability for a defect class is the same as no accountability, with a longer meeting attached.

3. Data transfer specifications that carry the reference data

The data transfer specification is where most of this becomes real, because it is the only document both technical teams actually read. The Society for Clinical Data Management’s guidance on external data transfers sets out what belongs in it: agreement in advance on key variables and mandatory fields, written specification of record and file formats, clarification of numeric versus character fields, decimal granularity, handling of characters such as greater-than and less-than signs, and explicit treatment of null or missing data.11 It also states that the vendor should provide a complete list of reference values and their effective dates at the onset of the study, with procedures to minimize changes during the study.11

That effective-date requirement is the single most under-implemented line in external data management, and it is the direct control for class 4 defects. If your transfer specification carries reference ranges without effective dates, you have no way to revalue historical records correctly when a range changes, and no way to prove which range applied when.

What a defect-aware transfer specification adds: beyond format and field definitions, name (a) the key variables used to match records and what happens when a match fails, (b) reference data fields with effective dates and the authoritative holder of each, (c) the acceptance tests that must pass before a transfer is accepted, (d) the recovery path and notification timing when a transfer is late or partial, and (e) the reconciliation the receiving party will run and the fields it will run on.

4. Acceptance tests on every transfer, not just the first

Most programs test the first transfer thoroughly and then accept the rest on the strength of that test. That is the wrong shape of assurance, because transfer defects usually arrive with a change: a new site, a protocol amendment, a laboratory instrument replacement, a vendor software release. EMA’s guideline is specific here. It says all transfers needed during the conduct of a trial need to be pre-specified, that validation of transfer should include appropriate challenging test sets, and that the process should be available and functioning at trial start.6 Challenging test sets means records designed to fail: unmatched identifiers, out-of-range values, missing mandatory fields, duplicate submissions, boundary values on every conversion.

The practical rule is to run a small standing acceptance suite on every transfer, automatically, with results visible to both parties, and to add a test case every time a defect is found. A defect that escapes twice is a governance failure, not a data failure.

Reconciliation Points, Escalation, and Metrics

Reconciliation is the control that catches what individual checks cannot, because it compares two independent representations of the same reality. It only works if the points are defined in advance, owned, and scheduled early enough to matter.

Where to put the reconciliation points

Reconciliation pointWhat is comparedOwnerTiming
Subject and sample listing Sponsor or contract research organization enrollment listing against external vendor’s subject and sample inventory Data management, with vendor participation Every transfer cycle from first subject, not only before lock
Serious adverse event reconciliation Clinical database events against safety database cases Pharmacovigilance, jointly with data management Monthly during enrollment, then before each analysis milestone
External data completeness Expected versus received records by visit, site, and test Receiving party Automated per transfer, reviewed weekly
Reference data register Version and effective date of ranges, dictionaries, and specifications held by each party Named reference data steward at the sponsor Quarterly, and on any notified change
Batch record package completeness Contract manufacturer’s executed records and analytical results against the owner’s release checklist Owner’s quality unit Before disposition, with a defined interim review during long campaigns
Deviation and investigation status Open deviations, out-of-specification investigations, and CAPA at each party Joint quality governance Monthly, with a hard gate before batch release or database lock

The recurring failure is scheduling reconciliation only before lock or release. At that point the reconciliation is a discovery exercise under time pressure, and any defect it finds is expensive to correct because downstream work has already been done on the bad data. Running the same reconciliations from the first transfer converts them from a gate into a control.

Escalation that produces a decision

Formal escalation is common. In the vfa survey, 90 percent of responding companies had established escalation procedures.1 The weakness is usually not the existence of a path but the trigger. Escalation procedures typically trigger on severity, which requires someone to make a judgment call in the moment, under pressure, about a defect whose full impact is not yet known.

Better triggers are objective and defect-class specific:

  • Repeat rule. Any defect class that recurs after a closed corrective action escalates automatically, regardless of severity. Recurrence is evidence the corrective action did not address the cause.
  • Cross-boundary rule. Any defect where detection and creation sit at different organizations escalates to joint governance, because neither party alone can close it.
  • Aging rule. Any defect open past an agreed number of business days without an agreed owner escalates. The absence of an owner is the escalation trigger, not the absence of a fix.
  • Decision-impact rule. Any defect affecting data already used for a decision, a batch disposition, a dose adjustment, an interim analysis, escalates immediately with a documented impact assessment.

E6(R3) supports this design. Section 3.9.6 requires the sponsor to ensure appropriate and timely escalation and follow-up of issues so that appropriate actions can be implemented in a timely manner,3 and section 3.12.3 goes further: where significant noncompliance by a service provider persists despite remediation, the sponsor should consider terminating that provider’s participation in the trial.3 Termination is the end of an escalation ladder, and the ladder needs rungs before it.

Metrics that hold each party to its own class

Measure by defect class and by owner, not by total defect count. A single “data quality score” tells you nothing about where to intervene, and it lets a party with excellent performance in one class hide poor performance in another.

Defect classPrimary metricWhat it tells you
CaptureQuery rate per hundred records by site, and repeat query rate on the same fieldWhether the problem is training, form design, or a single site
TranscriptionDiscrepancy rate found during source verification samplingWhether manual steps in the architecture are producing an accepted defect rate
TransformationAcceptance test pass rate per transfer, and defects found after acceptanceWhether your test suite covers the failure modes actually occurring
Reference dataNumber of version mismatches found at register review, and records revaluedWhether the reference data governance is real or nominal
TimelinessOn-time transfer rate, and median delay when lateWhether lateness is systemic or incidental
ReconciliationOpen discrepancy count and aging by reconciliation pointWhether reconciliation is a control or a backlog

Two rules keep these metrics honest. Report them to joint governance with both parties present, so the numbers are discussed rather than filed. And separate detection performance from creation performance in the reporting. A vendor that finds many defects is doing its job well, and a metric that punishes discovery will produce silence rather than quality.

When One Party Is a Software Platform, Not a Service Provider

Everything above assumes the third party performs work. Increasingly one of the parties in the chain supplies a system rather than a service: an electronic data capture platform, a laboratory information management system delivered as software as a service, a manufacturing execution system, a cloud analytics environment. The ownership question changes shape, and most agreements do not adjust for it.

What is genuinely different

A service provider performs a defined activity on your data and can be held to the outcome of that activity. A platform vendor provides a capability that you configure, and the defects divide into three groups with different owners:

GROUP A

Product defects

The software does not do what its specification says. A calculation is wrong, an audit trail entry is not written, a permission is not enforced. The vendor owns the correction and the root cause. You own detecting it in your environment and assessing which of your records are affected.

GROUP B

Configuration defects

The software works as designed and was configured to do the wrong thing for your process. An edit check threshold, a workflow step, a role definition, a derived field. You own this entirely, even when the vendor’s professional services team performed the configuration.

GROUP C

Release and change defects

The vendor updated a multi-tenant environment and the change altered behavior you depended on. Ownership is genuinely shared and has to be settled in advance: notification lead time, your regression testing window, and the right to defer.

GROUP D

Evidence gaps

The system behaved correctly but you cannot demonstrate it, because the validation documentation, the audit trail export, or the configuration history belongs to the vendor and is not available to you on inspection timelines.

Group C is where most programs get hurt

A single-tenant deployment lets you control when a change reaches your validated environment. A multi-tenant platform generally does not. If the vendor releases quarterly and you require four weeks of regression testing, that arithmetic has to be in the agreement, not discovered at the first release. Specify the notification lead time in business days, the content of the release notification (what changed, what was tested by the vendor, what regression evidence they will supply), your testing window, and what happens if your testing finds a defect after the release is already live for you.

What the regulators say about platform vendors specifically

The EMA guideline addresses the software supplier case directly and does not soften it. It states that the responsible party should adopt and take full ownership of the user requirements, whether those requirements were documented by the responsible party, by a vendor, or by a service provider, and should review and approve them to verify that they describe the functionality users need in their trials.6 It also says that where a vendor’s validation activities and documentation are insufficient, or the responsible party cannot rely on the vendor to provide documentation, the responsible party should validate the system itself.6 And it requires contractual arrangements ensuring continued access to validation documentation for the full retention period even if you stop using the system or the vendor stops supporting it or ceases activity.6

Read those three requirements together and the practical conclusion is that a platform vendor’s documentation is a deliverable, not a courtesy. Group D evidence gaps are the ones that surface during an inspection rather than during operations, which is the worst possible time to discover that your escrow arrangement does not cover configuration history.

The clause people forget: continued access to validation and configuration documentation after the relationship ends. Retention obligations for clinical and manufacturing records outlast most software contracts. If the agreement does not address what happens to your evidence when you migrate off the platform or the vendor exits the market, you have an obligation with no mechanism behind it.

Adjusting the matrix for a platform vendor

Three changes to the defect-class matrix cover the platform case. First, split transformation and mapping defects into product defects and configuration defects, because the owners are different and the evidence is different. Second, add release and change management as an explicit reference data and version concern, since a platform version is reference data in every meaningful sense. Third, make documentation access an evidence obligation with named artifacts and a retention period, rather than a general audit right.

A well-built matrix allocates a great deal. It cannot allocate everything, and pretending otherwise is where programs get into trouble. Five obligations stay with the sponsor or the contract giver no matter how the paper reads.

The reliability of the record. E6(R3) places ultimate responsibility for the reliability of trial data with the sponsor.3 ICH Q10 places ultimate responsibility for having control processes over outsourced activities with the pharmaceutical company.7 EU GMP Chapter 7 uses the same phrase for the contract giver.8 There is no contractual structure that moves this.

Selection and continued qualification of the party. E6(R3) 3.6.7 makes the sponsor responsible for assessing suitability and selecting the service provider,3 and Chapter 7.5 makes the contract giver responsible for assessing the legality, suitability, and competence of the contract acceptor before outsourcing.8 Qualification is not a one-time gate. Chapter 7.7 requires the contract giver to monitor and review the acceptor’s performance and to identify and implement needed improvement.8

Oversight that reaches subcontractors. E6(R3) 3.6.9 extends sponsor oversight to activities further subcontracted by the service provider.3 Chapter 7.11 prohibits the contract acceptor from subcontracting without the contract giver’s prior evaluation and approval, and requires that the arrangements pass information and knowledge along in the same way as the original relationship.8 A tier-two vendor you have never met is inside your oversight scope.

The release or lock decision. Under 21 CFR 211.22(a) the owner’s quality control unit is responsible for approving or rejecting products manufactured under contract by another company.9 The clinical analogue is data set finalization before analysis, which E6(R3) requires to be confirmed and documented against pre-specified procedures.3 Those decisions cannot be outsourced to the party whose work is being judged.

Every defect class the agreement failed to name. This is the one people miss. E6(R3) 3.6.4 makes it explicit for clinical work: what is not specifically transferred is retained.3 The practical effect is that an incomplete matrix is not a neutral document. It is a document that assigns everything it omits to you.

A useful test before signing: take the six defect classes and ask, for each one, “if this happens in month seven, who runs the investigation, who corrects the record, who pays for the rework, and what does the inspector see?” If any of those four questions produces a pause, that class is not allocated. It is retained.

Conclusion

The reason three parties can each be blameless while the record is wrong is that agreements allocate activities and defects do not respect activity boundaries. A capture error created at a site is detected by a vendor, corrected by the site, and caused by a form design decision the sponsor approved. An activity-based contract has no row for that. A defect-class allocation does, and it does not require renegotiating the commercial relationship: it requires one annex, one expanded RACI, and a transfer specification that carries effective dates on its reference data.

What we consistently see is that the organizations handling this well are not the ones with the most detailed contracts. They are the ones that decided, before the first transfer, which failures they expected and who would own each of them, then ran the reconciliations from month one instead of month eleven. The regulatory frameworks already point in this direction. ICH E6(R3), ICH Q10, EU GMP Chapter 7, and FDA’s quality agreements guidance all say the same thing in different vocabulary: transfer the work, keep the accountability, and write down exactly which is which.

Sakara Digital works with pharma and biotech organizations building data quality and oversight structures across multi-vendor chains. If you are mapping who owns what across your CRO, CDMO, laboratory, and platform relationships and want an independent perspective on where the gaps are, we are happy to have that conversation.

For Further Reading