Untangles Fiduciary vs. Processor roles across a diagnostic lab's franchise counters, LIS vendors, and hospital referrals — and what a valid Section 8(2) processor contract must actually contain.
A single blood test at a diagnostic lab chain rarely touches just one system. It starts at a franchise collection counter, moves into the lab's LIS for processing, gets routed through a report-delivery app, and often ends up back in a referring hospital's records. Four or five parties, one patient's data — and under the DPDP Act, each of those parties sits in a specific legal role that determines who's accountable for what. Get the role wrong, and the compliance structure built on top of it doesn't hold up.
This is where diagnostic labs run into more nuance than most businesses handling personal data, because the chain isn't uniform. The same lab can be a Data Fiduciary in one relationship and a Data Processor in another — sometimes within the same patient's test.
The Test Isn't Who Pays — It's Who Decides
Under the DPDP Act, the roles are defined by function, not by commercial arrangement. A Data Fiduciary is the party that determines the purpose and means of processing. A Data Processor processes personal data on the Fiduciary's instructions, for the Fiduciary's purpose. Section 8(1) makes this distinction consequential: the Data Fiduciary carries primary accountability for the Act's compliance across the entire processing chain — including what its processors do — and that responsibility can't be contracted away, regardless of what any agreement says.
That single principle resolves most of the confusion in a lab's franchise and referral network — once you map it out:
| Arrangement | Who Determines the Purpose | Lab's Role | Counterparty's Role |
|---|---|---|---|
| Franchise collection centre operating under the lab's brand | The lab | Data Fiduciary | Data Processor |
| LIS vendor, cloud host, courier, report-delivery app | The lab | Data Fiduciary | Data Processor |
| Hospital sends samples for testing under its own patient consent | The hospital | Data Processor (for that instruction) | Data Fiduciary |
| Lab sends the report back to the referring hospital or doctor | Each party, for its own use | Data Fiduciary | Data Fiduciary |
| Lab uses hospital-referred patient data for its own health-package marketing | The lab | Data Fiduciary (fresh purpose) | — |
The last two rows are where labs most often get tripped up. Sending a report back to a referring doctor isn't a processor handoff — it's a disclosure between two independent Fiduciaries, each accountable for their own use of that data. And if a hospital instructs a lab to run a specific panel, the lab is acting as a processor for that instruction alone. The moment that same patient data gets pulled into the lab's own marketing list for a health-package promotion, the purpose has changed — and so has the lab's role. The hospital's original consent doesn't travel with it. That reuse needs its own notice and its own consent, in the lab's own right.
What a Processor Contract Actually Needs to Say
Section 8(2) permits a Data Fiduciary to engage a processor only under a valid contract — but the Act doesn't hand you a clause-by-clause template. The substance of what that contract needs to cover comes from the obligations the Fiduciary still carries regardless of who's doing the processing: reasonable security safeguards under Section 8(5) (the provision carrying the Act's steepest penalty tier, up to ₹250 crore), breach notification under Section 8(6), and the underlying duty to ensure erasure and support rights requests.
In practice, a processor agreement — whether it's a standalone contract or an addendum to an existing franchise or LIS agreement — needs to address:
| Clause | What It Should Cover |
|---|---|
| Scope of instructions | The specific fields and purposes involved — not a generic reference to "patient data" |
| Reuse restrictions | No independent use, analytics, or model training on the data without the Fiduciary's written instruction |
| Sub-processor visibility | Named sub-processors, with advance notice before any change |
| Security commitments | Encryption, access controls, and log retention consistent with the lab's own Section 8(5) obligations |
| Incident notification timeline | A vendor-to-lab reporting window short enough for the lab to still meet its own regulatory deadlines |
| Erasure and exit terms | Confirmed deletion on consent withdrawal or contract termination, with no residual copies left behind |
| Audit rights | The lab's ability to request access logs and evidence of compliance, not just assurances |
The most practical starting point for most labs isn't renegotiating every individual franchise and vendor agreement from scratch — it's issuing a single data-processing addendum that attaches to existing contracts, supported by a short field-scoping annexure per vendor so the scope is concrete rather than generic.
Reporting Timelines Run on Two Separate Clocks
Labs handling a breach need to track two distinct regulatory timelines, not one. Under the DPDP Rules, a detailed breach report goes to the Data Protection Board within 72 hours. Separately, under CERT-In's 2022 directions — a cybersecurity requirement that predates and sits alongside the DPDP framework — specified categories of cyber incidents must be reported within 6 hours. These aren't alternatives; they're parallel obligations, and any vendor contract's incident-notification clause needs to be tight enough to let the lab meet the shorter of the two.
Referral Reports Are Disclosures, Not Transfers of Responsibility
When a lab sends a result to a referring doctor or hospital, that recipient becomes an independent Data Fiduciary for their own use of the data — the lab's job isn't done just because the file left its system. The Act's expectations around accuracy and appropriate scope still apply to what gets disclosed. In practice, that means naming the recipient category clearly in the patient notice (a specific "shared with your referring doctor" rather than a vague "shared with partners"), sending only the fields the recipient actually needs for their purpose, and keeping a log of what was shared, when, and under what consent state — the same record that becomes essential if a breach inquiry ever asks where a patient's data actually went.
Most Labs Aren't Significant Data Fiduciaries — But Section 8 Still Applies in Full
It's worth being precise here: the heavier obligations under the DPDP Rules — mandatory audits, algorithmic assessments, a dedicated Data Protection Officer — apply specifically to organizations notified as Significant Data Fiduciaries, based on factors like data volume and sensitivity. Most diagnostic labs won't fall into that category. But that doesn't create a lighter compliance bar overall — every lab, regardless of size, owes the full set of Section 8 obligations, and it's precisely those obligations that a poorly governed processor chain puts at risk.
Where TheDPDPAct.com Fits In
Mapping which counterparty in a lab's network is a Fiduciary and which is a Processor — franchise centres, LIS vendors, referring hospitals — is detailed, unglamorous work, and it's easy to get at least one relationship wrong without a structured process. TheDPDPAct.com's assessment platform is built to walk through exactly this kind of chain, flagging where a processor contract is missing, where roles are misclassified, and where a lab's compliance depends on evidence it currently can't produce.