How to Share Confidential Clinical Trial Data With Partners (2026)

How to Share Confidential Clinical Trial Data With Partners (2026)

Last updated: August 2026

TL;DR: Sharing confidential clinical trial data with a partner is legal and routine when you do three things in order. First, get the artifact and the agreement to match — a CDA/NDA gates evaluation of your topline results, CSR synopsis, and (de-identified) full CSRs and protocols; a DTA/DUA governs any dataset that changes hands; a BAA sits underneath the platform vendor under 45 CFR 164.502(e). Second, de-identify before upload — strip the 18 HIPAA Safe Harbor identifiers (or use Expert Determination) inside your own pipeline, exactly as an imaging team strips DICOM tags before a file reaches the room; remember GDPR treats pseudonymized data as still personal. Third, know where the room stops — a partnering room is not your eTMF, not an EDC, and not a 21 CFR Part 11-validated system. Peony runs this workflow on the $52/admin/month Data Room plan with granular permissions, dynamic watermarking, screenshot protection, audit trails, and AI that never trains on or retains your documents; it is SOC 2 Type II, HIPAA-compliant, and signs a BAA on request.

I'm Deqian Jia, co-founder of Peony, a data room company, and I have spent a lot of time watching biotech and CRO teams run clinical document rooms — the fundraise room, the CDA-gated partnering room per pharma BD team, the sponsor-handover package at trial close. The question that comes up first is almost never "which platform is most secure." It is some version of: we have the clinical study reports and the partner wants to see them — how do we send this without creating a compliance problem? Underneath that sit four narrower questions: what of this is actually protected health information, whether we can legally share it at all, which agreement covers which document, and where a shared room stops versus the regulated systems our quality team runs.

This post answers those in order. It is the process, not a feature list. Peony is where I reach for concrete examples — but the de-identification rules, the agreement mapping, and the Part 11 boundary are platform-agnostic facts, and I have tried to state them the way a regulatory or clinical-operations lead would want to read them: answer-first, with the limits marked. For the ranked buying guides — which provider fits which life-science workflow, and which vendors actually sign a BAA — this post defers to our healthcare and life sciences data rooms guide and our HIPAA-compliant data rooms matrix. Read this one for the how-to.

What counts as confidential clinical data — and which of it is PHI?

Confidential clinical data spans a spectrum from aggregate results that are safe to share early to patient-level records that are the most sensitive files your company holds — and only part of that spectrum is protected health information (PHI). Getting the distinction right is the whole game, because it determines what you can share, when, and after how much de-identification.

The core clinical artifacts, roughly from aggregate to identifiable, are:

• Topline results and TLF summaries — the headline efficacy and safety readout, plus summary tables, listings, and figures (TLFs). The summary layer is pooled statistics about a study population, which is generally not PHI.
• Clinical study reports (CSRs) — the integrated report of a trial's methods and results. The body is aggregate and statistical; the appendices are where identifiable material lives.
• Protocols and amendments — how the trial was designed and run. Not PHI, but competitively sensitive, and often the document a scientific reviewer reads hardest.
• Investigator brochure (IB) — the compiled clinical and nonclinical data on the investigational product. Confidential know-how, not PHI.
• Safety narratives and case-level listings — individual accounts of adverse events, SAEs, and SUSARs. This is where PHI concentrates: a narrative can describe an identifiable individual.
• Patient-level datasets — SDTM and ADaM datasets, the row-per-subject data. The most sensitive artifact, and the one to de-identify most carefully or hold back entirely.

The line that matters: PHI lives at the patient level, not in the aggregate. Pooled efficacy and safety statistics across treatment arms — the substance of a CSR body or a summary table — are not protected health information, because they describe a population, not a person. What carries PHI is anything case-level: a safety narrative that names or describes an individual, a patient listing with dates and identifiers, a raw dataset row. This is the same line our HIPAA data room matrix draws for healthcare M&A — buyers do diligence on de-identified and aggregate data, and identifiable records are handled separately — and it holds here: share the aggregate freely (under a CDA), and treat the patient-level layer as a distinct, higher-sensitivity artifact that gets de-identified before it goes anywhere. If your clinical program includes imaging biomarkers, the imaging equivalent of this rule is covered on our DICOM data room page, where the same de-identify-before-upload discipline applies to DICOM tags.

Can you legally share clinical trial data with a partner?

Yes — sharing clinical trial data with a partner is legal and happens on every licensing, partnering, and co-development deal, as long as you have the right agreement in place and you have handled the identifiable data correctly before it leaves your control. There is no rule against a biotech showing a pharma partner its clinical results; the rules govern how, not whether.

Two conditions make it lawful. First, a signed agreement that binds the partner and defines permitted use — a CDA for evaluation, escalating to a DTA when an actual dataset transfers (the agreement-to-artifact mapping has its own section below). Second, correct handling of PHI and personal data — the aggregate results move once identifiers are stripped, and patient-level data moves only after de-identification, if at all. Clear those two and you are on solid ground.

The limit to check at a high level is consent and secondary use. The informed consent your participants signed, and the study protocol, define what the data can be used for. If participants consented to a specific trial and the original consent did not contemplate a use like out-licensing or a partner's commercial evaluation, then sharing identifiable data for that new purpose may exceed the consent — which is precisely why de-identified or anonymized data is usually the clean path, because de-identified data falls outside the individual-consent question. This is not a judgment call to make alone: your regulatory, legal, or privacy function — and, where the protocol or jurisdiction requires it, an IRB or ethics committee — should confirm the boundary before identifiable data is shared. The safe default is to keep what you share aggregate and de-identified, so the consent-and-secondary-use question rarely becomes load-bearing in the first place.

How do you de-identify clinical data before sharing?

You de-identify clinical data using one of the two methods the HIPAA Privacy Rule provides — Safe Harbor or Expert Determination — and HHS documents both on a single de-identification guidance page. Which you choose is a trade-off between speed and how much analytic detail you preserve, but the operational rule that governs both is the same: de-identify before the data enters a shared room.

Safe Harbor is the checklist route. You remove the 18 categories of identifiers the Privacy Rule enumerates — including names; geographic subdivisions smaller than a state; all date elements more specific than a year (dates of service, and exact ages over 89); telephone and fax numbers; email addresses; medical record, account, and health-plan numbers; device identifiers and serial numbers; biometric identifiers; full-face photographs; and any other unique identifying number, characteristic, or code — and, provided you have no actual knowledge that the remaining data could re-identify an individual, the data is de-identified. It is mechanical and fast, and it is the right tool when you do not need to preserve granular dates or ages.

Expert Determination is the statistical route. A person with appropriate knowledge and experience applies accepted statistical and scientific principles, determines that the risk of re-identification is very small, and documents the analysis. It costs an expert engagement, but it preserves analytic value that Safe Harbor strips — for instance, retaining event dates or precise ages a trialist genuinely needs. For patient-level clinical datasets that must remain analytically useful to a partner, Expert Determination is often the better fit; for a set of narratives or listings you simply need to scrub, Safe Harbor is faster.

A note on where the two methods bite in a clinical context: Safe Harbor's date rule is the one that surprises trial teams most, because a longitudinal dataset loses much of its meaning when every visit date collapses to a year. If the partner's scientific question depends on time-to-event, dosing intervals, or age at onset, Safe Harbor may strip the very variables the analysis needs — which is exactly the case for Expert Determination, where a statistician can retain those fields while documenting that the residual re-identification risk stays very small. Conversely, free-text safety narratives are hard to de-identify by rule alone, because an identifier can be embedded in a sentence rather than a structured field; those often need manual review regardless of which method you nominate. The point is that de-identification is not one switch — it is a per-artifact decision, and picking the wrong method can either leak an identifier or destroy the dataset's usefulness.

Two more points make the difference between doing this right and creating a breach. GDPR is a separate, stricter bar. Its distinction is anonymized versus pseudonymized: pseudonymized data — direct identifiers swapped for a code, but a re-linking key still exists somewhere — remains personal data and stays fully within GDPR's scope; only genuinely anonymized data, not reasonably re-identifiable by anyone, falls outside it. "We replaced patient IDs with subject numbers" is pseudonymization, not anonymization, and if your team or your CRO holds the key, the dataset a partner receives is still personal data. Because clinical partnering is routinely cross-border, assume both regimes apply and clear both. And de-identify before upload, not after — inside your own compliance pipeline, the same way an imaging team strips DICOM tags before a file ever reaches the room (the pattern our DICOM data room page describes per a team's own HIPAA/IRB workflow). A data room is the secure distribution layer; it is not the de-identification tool, and treating it as one puts PHI in the room before it has been cleaned.

Which agreement covers which artifact?

Different clinical artifacts move under different agreements, and matching them correctly is what keeps the transfer clean. Reaching for a single NDA to cover everything is the common mistake — a dataset transfer needs more than a confidentiality promise. Here is the mapping:

The two that get confused are the CDA and the DTA. A CDA (confidential disclosure agreement) — the standard life-science NDA — is an evaluation instrument: it lets a partner read your topline data, CSR synopsis, and, once de-identified, your full CSRs and protocols, under confidentiality, so they can decide whether to proceed. It does not, by itself, authorize handing over a raw dataset. When an actual dataset changes hands — patient-level data especially — you move to a Data Transfer Agreement or Data Use Agreement (DTA/DUA), which spells out exactly what the recipient may do with the data, how long they may keep it, and whether they may share it onward. A Material Transfer Agreement (MTA) is a different animal again: it governs physical materials like biological samples, not data, and comes up when a collaboration involves specimens.

Underneath all of them, if any file in your room could contain PHI, sits the Business Associate Agreement (BAA). A BAA is required whenever a vendor creates, receives, maintains, or transmits protected health information on behalf of a covered entity or another business associate — the requirement is set at 45 CFR 164.502(e). Your data room stores and transmits your files; if any contain PHI, the room's vendor is your business associate, and HIPAA requires a BAA between you. Peony signs a BAA on request. In a real partnering process these stack: the CDA gates the room, a DTA governs any dataset that transfers out of it, an MTA covers any samples, and the BAA sits beneath the platform. For the full picture of which vendors actually commit to a BAA and on which tier, our HIPAA-compliant data rooms matrix is the reference.

What should you actually share at each stage of a partnering or diligence process?

Share in widening rings, and open each ring only when the previous one has earned it. The instinct to send a partner "everything" so they can evaluate quickly is the wrong one for clinical data — it exposes your most sensitive files to the largest audience for the longest time. Staged disclosure does the opposite: minimum exposure, maximum control.

Stage one — before any agreement: topline and TLF summaries. The aggregate efficacy and safety readout, plus summary tables, listings, and figures. This is the layer a partner needs to decide whether to engage at all, and it is the least sensitive — pooled statistics, no patient-level content. It is fine to share this early, and it does the screening work so you are not opening deeper folders for partners who were never serious.

Stage two — under a signed CDA: CSR synopsis, then full CSRs and protocols. Once the partner has signed your confidential disclosure agreement, open the CSR synopsis first, then the full clinical study reports and the study protocols. This is where scientific diligence happens — the reviewer assesses the trial design, the endpoints, and the results in depth. Gate and watermark these; they are competitively sensitive even though the aggregate results are not PHI.

Stage three — later, under a DTA, if the deal warrants it: patient-level data. SDTM/ADaM datasets are the deep end, and they move last, under a Data Transfer Agreement, with de-identification applied. Many programs never share raw patient-level data at all — they provide analysis-ready summaries or expert-determined datasets instead, which answer the partner's scientific questions without handing over the row-level records. Share raw patient-level data only when the transaction genuinely requires it and the DTA is in place.

Throughout every stage, hold back genuine know-how that the current step does not require: proprietary assay methods, manufacturing and CMC detail, unpublished formulation specifics. A partner evaluating clinical results rarely needs your manufacturing trade secrets to form a view, and those are the holdbacks that protect your leverage if the deal moves to terms. The through-line is that each ring opens on justification, not on request — which is exactly the discipline a data room with granular per-group permissions is built to enforce.

How do CRO-to-sponsor and co-development handovers work?

CRO-to-sponsor and co-development handovers work by transferring both the documents and the obligations attached to them — and the key distinction is that the data room is the distribution layer for a curated handover package, not a replacement for the regulated systems of record. A CRO running a trial on a sponsor's behalf, or two co-development partners dividing a program, both hit the same moment: a defined set of clinical deliverables has to move from one party's control to another's, cleanly and with an audit trail.

In a CRO-to-sponsor handover, the substance is a transfer of obligations. Sponsor responsibilities that were delegated to the CRO revert or transfer at defined points, and the documentation that evidences the trial — the trial master file content, study reports, regulatory correspondence — has to be handed over in a state the sponsor can rely on for inspection readiness. The critical thing to keep straight is the layer: the electronic trial master file (eTMF) is the regulated system of record for trial documentation, with its own controls and retention obligations; a data room is where you assemble and share a curated deliverable package — the CSRs, the summary datasets, the regulatory documents a sponsor's diligence or handover team needs to review — under access control. You do not run your eTMF inside a diligence room, and you do not treat a diligence room as your eTMF. You use the room to distribute a defined package, watermarked and permissioned, with every view logged.

Co-development handovers have the same shape with an added wrinkle: ownership of the eTMF and the underlying data has to be explicit. Which partner owns the eTMF, who holds the master datasets, and how each party gets the documents it needs for its own regulatory and commercial work are all terms to nail down in the collaboration agreement, not assumptions to make later. The document-room layer helps here precisely because it is separable — each partner can be given a scoped, audited view of exactly the package it is entitled to, without either party having to hand over control of the system of record. For the transaction-side version of this — a biotech asset changing hands rather than a trial being handed back — our biotech M&A data room walkthrough covers the deal structure, and the biotech data room guide has the folder-by-folder package to assemble.

What security controls matter when clinical data is in the room?

The controls that matter for clinical data are the ones that keep access narrow, tie every view to a named person, and prevent the platform itself from becoming a leak — granular permissions, an NDA gate, dynamic watermarking, screenshot protection, audit trails, and, in 2026, an AI posture that does not turn your documents into training data. Encryption is the floor, not the differentiator: any serious room encrypts at rest and in transit (Peony uses AES-256 at rest and TLS 1.3 in transit), so the real questions are about access and traceability.

The control set, in the order it does work for a clinical package:

• Granular per-group permissions. Scientific diligence sees the clinical package; legal sees only contracts; commercial sees only the commercial folder. A partner never sees a folder they were not licensed to review, and — when several partners evaluate the same asset — one room per partner means no partner learns another is at the table. This is what makes staged disclosure enforceable rather than aspirational.
• NDA / CDA gate. The partner signs your confidential disclosure agreement inline before any folder loads. No signature, no access. On the Data Room plan this is an Advanced NDA with countersigning.
• Dynamic watermarking. Every page — including CSR pages, TLF exhibits, and dataset previews — is stamped with the viewer's name and email, so a photographed or forwarded fragment traces back to a specific person. Watermarking is the deterrent that makes deep review safe; our watermarks feature page covers how it renders.
• Screenshot protection and audit trails. Capture attempts are blocked and logged, and a complete, exportable audit trail records every view and download with timestamp and identity — the records discipline you want if a licensing dispute ever turns on who accessed what.
• AI that does not train or retain. This is the atom that matters most for proprietary clinical data. On Peony, AI document Q&A and extraction call a third-party model at query time only, with no training on your documents and no retention — the room does not become training data for anyone, which is the assurance a team sharing unpublished clinical results and drug IP actually needs before it will use AI features at all.

One tiering note stated plainly: if your workflow requires redacting identifiers out of documents in place — burning out a name inside a PDF rather than removing the file — Advanced Redaction is a Deal Team-tier feature ($64/admin/month). But redacting-in-the-room is the fallback, not the plan. The cleaner discipline, and the one this whole post argues for, is to de-identify before upload so PHI never enters the room and there is nothing to redact.

Where does a data room stop?

A data room stops at the edge of the regulated systems your quality and clinical teams run — it is not your eTMF, not your EDC or CDMS, and not FDA 21 CFR Part 11-validated submission infrastructure, and stating that boundary honestly is the difference between a vendor who understands the space and one selling past it. A diligence or partnering room is a secure place to share reports and datasets for review. It is not the system of record for running a trial or filing with a regulator.

The specific regulation people ask about is 21 CFR Part 11. Part 11 sets the criteria under which the FDA considers electronic records and electronic signatures trustworthy, reliable, and generally equivalent to paper records and handwritten signatures, and it applies to records that are created, modified, maintained, archived, retrieved, or transmitted under FDA records requirements (per FDA's Part 11 guidance). The important part for platform selection: validating a Part 11 system is a process your quality team owns, not a feature a general VDR hands you. A room's audit trail can log every view, download, and e-signature with timestamps and identity — that is genuine records discipline, and it is useful — but that is not the same as a validated Part 11 system, and no general VDR, Peony included, should be represented as satisfying Part 11. The same goes for the electronic trial master file and the EDC: those are regulated systems of record with their own validation and retention obligations. A data room does not run your trial; it distributes a curated slice of its outputs.

The practical split is clean once you hold it: run the regulated system of record where the regulation applies, and use the data room to share curated documents with partners under access control. Share the CSRs, the protocols, and the de-identified datasets for review in the room; keep the eTMF, the EDC, and the Part 11-validated stack in the systems built and validated for them. A team that keeps those layers distinct never over-claims what the room does, and never asks the room to do a job it was not built for.

Which platform fits clinical data sharing?

The platform that fits clinical data sharing is a flat-rate room with the deal-room controls — granular permissions, NDA gate, dynamic watermarking, audit trails — a HIPAA posture with a BAA, and an AI stance that does not train on your files; for founder-led biotech and CRO workflows, Peony fits that shape at $52/admin/month on the Data Room plan. That plan runs unlimited rooms and unlimited storage with viewers free, which is the economics clinical sharing needs: a partnering package heavy with CSRs, TLFs, and datasets would rack up an enormous page count on a legacy per-page VDR, and flat-rate decouples cost from page count entirely — a partner reviewing your clinical package costs nothing to add. Peony is SOC 2 Type II, HIPAA-compliant, and signs a BAA on request; the one limit worth flagging is that it is not ISO 27001 certified, so if that specific certification is a hard procurement requirement, weigh it. Peony serves 6,800+ customers on exactly this kind of gated, multi-room work.

I am not going to rank every provider here — that is what the buying guides are for, and pretending a how-to post is a neutral leaderboard would be dishonest given I run one of the platforms. For the ranked comparison by clinical workflow — biotech fundraise, partnering, medtech — see our healthcare and life sciences data rooms guide, which credits the specialists and the enterprise players where they genuinely win. For the compliance-posture ranking — who actually signs a BAA, on which tier — see the HIPAA-compliant data rooms matrix. And if your program maps to a specific solution surface, our clinical research and biotech pages describe how the room maps to those use cases. The right move is to test a flat-rate room against your own partnering process rather than take a vendor's word for it — pricing is public and you can start immediately.

Frequently asked questions

Can I legally share clinical trial data with a pharma partner?

Yes — sharing clinical trial data with a partner is routine and legal, provided you have the right agreement in place and you have handled the data correctly before it leaves your control. The two things that make it lawful are, first, a signed confidentiality or transfer agreement that defines what the partner may do with the data, and second, de-identification of anything that would otherwise be protected health information (PHI) or personal data. Aggregate results — topline efficacy, safety summaries, tables, listings, and figures — are generally not PHI once patient identifiers are stripped, so they move under a simple confidential disclosure agreement (CDA/NDA). Patient-level datasets are the sensitive end: share those last, if at all, under a data transfer or data use agreement, and only after de-identification. The high-level limit to check is consent and secondary use — the informed consent your participants signed, and the study protocol, govern whether the data can be used for a purpose like out-licensing or a partner's evaluation. If the original consent did not contemplate that use, de-identified or anonymized data is usually the lawful path, and your regulatory or privacy team (and, where relevant, an IRB or ethics committee) should confirm the boundary before you share.

Is a clinical study report (CSR) considered PHI?

A clinical study report is usually not PHI at the aggregate level, but it can contain PHI in specific sections, so the honest answer is "it depends on which part." The body of a CSR reports pooled, statistical results — efficacy and safety across treatment arms — and pooled statistics about a study population are not protected health information. Where PHI hides is in the appendices: individual patient safety narratives, listings, and case-level data can name or describe identifiable individuals, and under HIPAA an identifiable individual's health information is PHI. So the practical rule is to treat the aggregate CSR as shareable under a CDA once obvious identifiers are removed, and to treat the patient-level appendices as a separate, higher-sensitivity artifact — de-identify them under HIPAA Safe Harbor or Expert Determination, or hold them back entirely, before they enter a shared room. The same logic applies to tables, listings, and figures (TLFs): the summary tables are aggregate; the patient listings are where identifiers appear.

How do I de-identify clinical data before sharing it — Safe Harbor or Expert Determination?

HIPAA gives you two routes to de-identify data, and HHS guidance covers both on one page. Safe Harbor is the checklist method: remove the 18 categories of identifiers the Privacy Rule lists — names, geographic subdivisions smaller than a state, all date elements more specific than a year (including dates of service and exact ages over 89), phone and fax numbers, email addresses, medical record, account, and health-plan numbers, device identifiers, biometric identifiers, full-face photos, and any other unique identifying number or code — and, with no actual knowledge that the remainder could re-identify someone, the data is de-identified. Expert Determination is the statistical method: a qualified expert applies accepted principles and documents that the re-identification risk is very small. Safe Harbor is faster and more mechanical; Expert Determination preserves more analytic value (for example, retaining dates or granular ages a trialist needs) at the cost of an expert engagement. The operational rule that matters most: de-identify BEFORE upload, inside your own compliance pipeline, exactly as an imaging team strips DICOM tags before a file reaches the room. The data room is the secure distribution layer, not the de-identification tool.

Is aggregate or pseudonymized clinical data still personal data under GDPR?

Under GDPR the distinction that matters is anonymized versus pseudonymized, and it is stricter than HIPAA de-identification. Pseudonymized data — where direct identifiers are replaced by a code, but a key exists somewhere that could re-link them — is still personal data and stays fully within GDPR's scope. Only truly anonymized data, where re-identification is no longer reasonably possible by anyone, falls outside GDPR. This is why "we replaced the patient IDs with subject numbers" is not the same as "this data is anonymous": if your team (or the CRO) holds the linking key, the dataset a partner receives is still pseudonymized personal data, and the transfer needs a lawful basis and appropriate safeguards. Because clinical partnering is routinely cross-border, assume both HIPAA and GDPR are in play, treat HIPAA Safe Harbor de-identification and GDPR anonymization as separate bars to clear, and involve your privacy function before patient-level data crosses a border.

Which agreement covers which artifact — CDA, DTA/DUA, MTA, or a BAA?

Match the agreement to the artifact. A confidential disclosure agreement (CDA), which is the life-science name for an NDA, covers the evaluation stage — it lets a partner review your topline results, CSR synopsis, and (once de-identified) full CSRs and protocols while binding them to confidentiality. A Data Transfer Agreement or Data Use Agreement (DTA/DUA) governs the actual transfer of a dataset, including patient-level data, and defines permitted use, retention, and onward-sharing limits. A Material Transfer Agreement (MTA) covers physical materials — biological samples, compounds, assays — not data. And a Business Associate Agreement (BAA) is a HIPAA instrument, required under 45 CFR 164.502(e) whenever a vendor creates, receives, maintains, or transmits PHI on your behalf; if your data room could hold PHI, the room's vendor is your business associate and a BAA is required. Peony signs a BAA on request. In practice a single partnering process layers several of these: the CDA gates the room, a DTA governs any dataset that changes hands, and the BAA sits underneath with the platform vendor.

What clinical documents should I share at each stage of a partnering process?

Share in widening rings, gated by trust and agreement. Stage one, before any agreement, is topline results and TLF summaries — the aggregate efficacy and safety readout a partner needs to decide whether to engage; this is the least sensitive layer. Stage two, once a CDA is signed, is the CSR synopsis and then the full CSRs and study protocols, which let scientific diligence assess the program in depth. Stage three, later and only if the deal warrants it, is patient-level data (SDTM/ADaM datasets) under a DTA with de-identification applied — and many programs never share raw patient-level data at all, providing analysis-ready summaries instead. Throughout, hold back genuine know-how: assay methods, manufacturing detail, and unpublished formulation specifics that are not necessary for the current stage. The principle is that each ring opens only when the prior one has justified it, so your crown-jewel data is exposed to the smallest audience for the shortest time.

Is a data room a 21 CFR Part 11 validated system for clinical records?

No — and this is the boundary to state plainly. FDA 21 CFR Part 11 sets the criteria under which the agency considers electronic records and electronic signatures trustworthy, reliable, and generally equivalent to paper, and it applies to records that are created, modified, maintained, archived, retrieved, or transmitted under FDA records requirements. Validating a Part 11 system is a process your quality team owns — it is not a feature a general virtual data room hands you. A diligence or partnering data room is a secure place to share reports and datasets for review; it is not your electronic trial master file (eTMF), not your EDC/CDMS, and not Part 11-validated submission infrastructure. No general VDR, Peony included, should be represented as satisfying Part 11. The right split is to run the regulated system of record where the regulation applies, and use the data room to distribute curated documents to partners under access control.

What security controls do I need when clinical data is in the room?

The controls that matter for clinical data are the ones that keep access narrow and make every view traceable: granular per-group permissions so scientific diligence sees the clinical package while legal sees only contracts, an NDA/CDA gate that a partner must sign before any folder loads, dynamic watermarking that stamps each viewer's name and email on every page, screenshot protection, and a complete, exportable audit trail. Encryption is table stakes — AES-256 at rest and TLS 1.3 in transit. One control is specific to the AI era and matters intensely for proprietary clinical data: how the platform's AI treats your files. On Peony, AI document Q&A and extraction call a third-party model at query time with no training on your documents and no retention — the room does not become training data for anyone. If you also need to redact identifiers out of documents in place, note that Advanced Redaction is a Deal Team-tier feature; the cleaner practice is still to de-identify before upload so PHI never enters the room in the first place.

What does a clinical data room cost?

Pricing depends on the model, not the word "clinical." Flat-rate platforms charge by admin seat regardless of how many gigabytes of imaging or how many pages of CSRs you load: Peony is $52/admin/month on the Data Room plan (annual) — unlimited rooms, unlimited storage, dynamic watermarking, Advanced NDA with countersigning, and granular permissions — with viewers free, so a partner reviewing your data costs nothing. That flat model fits clinical sharing well because a partnering package heavy with CSRs, TLFs, and datasets would run to an enormous page count on a legacy per-page VDR, which meters every page in every room for every month it stays open. For the full provider comparison and the deeper cost breakdown, see our healthcare and life sciences data rooms guide and our HIPAA-compliant data rooms matrix; this post is the how-to, those are the ranked buying guides.

Bottom line

Sharing confidential clinical trial data with a partner is a solved problem when you run it as a process rather than a scramble. Decide what is aggregate and what is patient-level, because only the patient level carries PHI. De-identify before upload — Safe Harbor for a fast scrub, Expert Determination when a partner needs analytic detail preserved — and remember GDPR treats pseudonymized data as still personal. Match the agreement to the artifact: a CDA gates evaluation of your CSRs and protocols, a DTA governs any dataset that transfers, an MTA covers materials, and a BAA sits under the platform vendor per 45 CFR 164.502(e). Share in widening rings so your crown-jewel data reaches the smallest audience for the shortest time. And keep the honest boundary in view — a partnering room distributes curated documents; it is not your eTMF, your EDC, or a 21 CFR Part 11-validated system, and no VDR should claim to be.

For founder-led biotech and CRO workflows, Peony runs this on the Data Room plan at $52/admin/month — unlimited gated rooms, dynamic watermarking, screenshot protection, granular permissions, exportable audit trails, and AI that never trains on or retains your documents — and it is SOC 2 Type II, HIPAA-compliant, and signs a BAA on request. Peony serves 6,800+ customers across exactly this kind of gated, compliance-sensitive work. Test it against your own partnering process, and read the buying guides below to place it against the specialists and the enterprise players.

Related resources

• Healthcare data room guide — the definitional hub: the provider-side document set, the sponsor-CRO-site research workflow, and the deal-type router.
• Best data rooms for healthcare and life sciences — the ranked provider comparison by clinical workflow.
• Best HIPAA-compliant data rooms — the matrix of who actually signs a BAA, and on which tier.
• Biotech data room guide — the nine-folder structure and setup steps for a biotech room.
• Biotech M&A data room — the transaction-side walkthrough when a biotech asset changes hands.
• DICOM data room — de-identified medical-imaging sharing with the same before-upload discipline.
• Clinical research solution — how the room maps to clinical-trial workflows.
• Biotech solution — fundraising, BD licensing, and M&A diligence for life-science teams.
• Watermarks — how dynamic watermarking renders viewer identity on every page.
• Pricing — Peony's public plans, including the $52/admin/month Data Room tier.

Sources

• HHS, Guidance on De-identification of Protected Health Information — https://www.hhs.gov/hipaa/for-professionals/special-topics/de-identification/index.html
• FDA, 21 CFR Part 11 — Electronic Records; Electronic Signatures — https://www.fda.gov/regulatory-information/search-fda-guidance-documents/part-11-electronic-records-electronic-signatures-scope-and-application
• Peony pricing — https://www.peony.ink/pricing
• Peony — https://www.peony.ink/
• Peony, best data rooms for healthcare and life sciences — https://www.peony.ink/blog/best-data-rooms-for-healthcare-and-life-sciences
• Peony, best HIPAA-compliant data rooms — https://www.peony.ink/blog/best-hipaa-compliant-data-rooms
• Peony, biotech data room guide — https://www.peony.ink/blog/biotech-data-room-guide