Many small and academic teams keep their trial master file on a shared drive. Sometimes that is a defensible choice, sometimes it is the first thing an auditor questions. This page compares the two on the controls that matter, gives a decision rule, and says plainly that Capture is an EDC, not an eTMF.
Free sandbox · No credit card · 21 CFR Part 11 aligned
| Plain shared drive | Configured shared drive | Dedicated eTMF | |
|---|---|---|---|
| Folder structure from an index | |||
| Version history | |||
| Restricted, reviewed access | |||
| Audit trail of who filed or changed what | |||
| Completeness and timeliness reports | |||
| Qualified e-signature and review workflow |
The short answer
The two options
The trial master file is the sponsor's set of essential documents: the records that, individually and together, let someone reconstruct how the trial was run and whether the data can be trusted. An eTMF is software built to hold that set electronically, with a structure based on a reference model, metadata for each document, controlled access, an audit trail and tools to check that the file is complete and current. A shared drive (a network folder, SharePoint, Google Drive or similar) is general file storage that you configure to behave like a TMF.
The comparison matters because the content is identical. The protocol, approvals, contracts, delegation logs, training records and monitoring reports are the same whether they sit in a purpose-built system or in a folder tree. What differs is how much of the control work the system does for you and how much is done by people and SOPs. For the difference between the TMF and the data system, see EDC vs eTMF. To build the file itself, see how to set up a trial master file. This page is about where to keep it.
Each site keeps its own investigator site file. Many sites run on paper binders or the hospital's own folders, and the sponsor does not choose that. The decision here is about the sponsor-side master file. For the site set, see the investigator site file index template.
ICH E6(R2) section 8 asks that sponsor and investigator keep a record of where their essential documents are stored, and that the storage system supports identification, version history, search and retrieval. It also allows the list of documents to be supplemented or reduced in advance, based on how important and relevant each is to the trial. ICH E6(R3), adopted in January 2025, uses "essential records" and an essentiality test, and says its table is not a rigid checklist. Check the current text that your regulator and sponsor apply; this page paraphrases and is not legal advice.
Control by control
Read the middle column as "what you must add to the drive" rather than "what it can never do". Every item can be addressed with configuration and procedure; the cost is the effort and the proof.
| Control an inspector looks for | On a shared drive | In a dedicated eTMF |
|---|---|---|
| Document index and structure | Folder tree copied from a model or your own index. Easy to start; drifts when people add folders. | Index built in, usually from a reference model, with an expected-documents list per country and site. |
| Naming, version and metadata | File names carry the rules, and only if everyone follows them. Version history exists in many drives but is not tied to document status. | Metadata fields (type, version, date, country, site) captured at upload; superseded versions tracked. |
| Access control | Folder permissions you set and must review. Link sharing and inherited permissions are common gaps. | Role-based access, restricted areas for unblinded material, and user lists reportable for review. |
| Audit trail | Depends on the product and the licence. Often a log of file events, not a trail of what changed and why. | Filing, change and deletion history kept as part of the system. |
| Review and approval of filed documents | Done by email or a separate form, then filed. The link between review and file is manual. | Workflow for quality check and approval, recorded in the system. |
| Signatures | Wet-ink scans or a separate signing tool. Evidence sits outside the drive. | Often built in; whether it meets your signature requirements depends on validation. |
| Completeness and timeliness | A spreadsheet tracker someone maintains by hand. | Reports on expected versus filed documents and time to file. |
| Deletion and recovery | Users can delete or overwrite; recycle bins are time-limited. | Controlled deletion, retained history, designed for retention rules. |
| Validation and change control | Vendor builds it for general use. Your evidence that it is fit for GCP records is yours to produce. | Vendors often supply validation packs; you still own the fitness decision. |
| Inspector access | Screen share or read-only account you create for the day. | Read-only inspector roles and export tools. |
This table describes typical behaviour of the two categories and says nothing about any specific product. Check any product against its own documentation and your own validation.
Decision rule
Rather than argue the two options in the abstract, answer five questions about your trial. The more answers fall to the right, the harder it is to defend a drive.
A single-site or two-site study with three people filing is controllable by habit. Ten sites across several countries, with a CRO and several vendors filing, is not. Volume is what turns "we follow the naming rule" into "we cannot prove it".
If the data will support a regulatory submission, expect the file to be examined by inspectors who see many TMFs. A file that looks improvised invites a deeper look. For an investigator-led study with publication as the aim, the bar is different, though GCP still applies.
Randomization lists and unblinding records need tight access. Folder permissions can do this, and so can an eTMF, but the review of who has access has to be a recurring task, not a start-up setting. See blinded and unblinded role management for the data-side equivalent.
Inspectors often look at whether documents were filed when generated, not assembled before the visit. A drive with file-modified dates is weak evidence, because dates change when files are moved or re-saved. If your drive cannot give you a trustworthy filing date, you need another record of it.
A drive costs little to start and a lot of someone's time to keep controlled. An eTMF costs more to buy and configure, and removes part of that time. The honest comparison is licence plus validation against the hours of a TMF owner over the life of the trial.
Sites filing
3
Contributors
5
Overdue filings
7
Open access reviews
2
4 outstanding
Hand-tracked
Folder permissions
Build your eCRFs, consent and randomization in the free sandbox and see the exports you would file. Your eTMF decision can wait. Free sandbox, every feature, no credit card.
If you choose a shared drive
None of this makes a drive an eTMF. It makes the choice documented, controlled and explainable.
State the system, the index it follows, the owner, who may file, and why a drive is proportionate to this trial's risk. A reasoned decision on file is better than an unexplained one.
Create folders once from your index and remove the right to add top-level folders. Record the index version.
One rule for type, version, date and site code. Keep a register (a controlled spreadsheet) with the filing date you can defend, since file dates are not reliable.
Give people the least access they need, switch off open link sharing, hold randomization and unblinding material in a separate restricted area, and review the user list on a schedule with a signed record.
Keep file activity logs, version history and deletion protection, and export the logs to a controlled location at agreed intervals.
Maintain an expected-documents tracker per site and run a monthly quality check, recording findings and closure. This is the work an eTMF automates.
Decide how you will export the file with its metadata at close-out, how you will archive it, and how you would migrate if the trial grows. See data archiving and retention.
Worked scenarios
These are invented examples for reasoning, not recommendations for your trial.
| Scenario | Features | Likely fit |
|---|---|---|
| Investigator-led pilot, one site, 40 participants, approved product used in label | Three staff file; no regulatory submission planned; sponsor is the hospital | A configured, access-reviewed drive with a TMF plan and a hand tracker is usually proportionate. Agree it with your sponsor and QA. |
| Phase 2, five sites in two countries, CRO involved, open-label | Eight contributors; submission to regulators possible later | Borderline. A drive needs heavy procedure. Price an eTMF, or ask whether the CRO provides one as part of the contract. |
| Phase 3, twelve sites, four countries, blinded, regulatory submission | Many contributors and vendors; restricted unblinding records; inspection likely | A dedicated eTMF is the safer default. The volume and the evidence expectations outgrow hand control. |
Phase and size are signals, not rules. The risk to participants and to data reliability is what decides how much control you need.
Where Capture fits
Capture is an all-in-one clinical trial platform: EDC, eCRF builder, ePRO, eConsent and randomization with one audit trail. It is not an eTMF and it does not store your regulatory binder, contracts or delegation logs. What it does is produce records that belong in the master file, whichever way you keep it, so they come from a system with its own controls instead of being rebuilt by hand.
Blank eCRF PDF, approved form versions
From platform export
User list and access review
Audit trail export at database lock
Signed consent examples (redacted)
How to evaluate
Use these with any vendor. They avoid feature lists and test the evidence you will need.
Which structure is built in, and can you adapt it for a smaller trial without losing the audit trail?
Does it record filing, change and deletion with user and time, and can you export it?
Can you create restricted areas, and report who has access on a given date?
What evidence does the vendor provide, and what must you do yourself?
Can you see expected versus filed documents by site and by time to file?
Can you export the whole file with metadata at close-out, in a readable format, without extra fees?
Licence, set-up, validation, training and per-study charges, against the hours of a TMF owner.
Is an eTMF already part of your CRO contract or your institution's tools?
What goes wrong
The recurring problems are not exotic. Documents are filed in batches before a monitoring visit, so the file shows a tidy state that was not real at the time. Superseded protocol versions sit next to current ones with no mark. A departed team member still has access. A restricted randomization file is reachable through an old shared link. A tracker spreadsheet is correct on the day it is updated and wrong a week later.
Each has the same remedy: make the rule visible, record the check, and keep the evidence. A monthly quality check that is minuted and signed does more for inspection readiness than a better folder tree. The monitoring visit report template shows how a monitor writes up such findings, and the delegation log template is the record that tells you who should have had access in the first place. For the wider move to risk-proportionate quality, read the ICH E6(R3) guide.
It can be, for a small, lower-risk trial, if you configure it with a locked structure, restricted and reviewed access, version history, logs and a quality-check routine, and document why it is proportionate. There is no rule that requires a product called an eTMF, but you must be able to evidence the controls. Agree the approach with your sponsor and QA first.
You can use them as the storage for a TMF, and many teams do. Whether they behave like an eTMF depends on how you configure and validate them. Plain folder sharing does not give you an audit trail of filing, completeness reporting or access reports without additional work.
Typically a built-in index, document metadata, an audit trail of filing and changes, controlled access, review workflows, and reports on completeness and timeliness. You can reproduce some of this on a drive by procedure, at a cost in time and with weaker evidence.
GCP sets expectations for the content and control of the file, not the product. It asks that essential documents are identifiable, versioned, searchable and retrievable, and that they are protected and retained. Check the current text of the guidance that applies to your trial.
No. Capture is an EDC, eCRF, ePRO, eConsent and randomization platform. It does not store your regulatory documents. It exports records that belong in a trial master file, such as the blank eCRF PDF, signed consent PDFs and the audit trail.
When the number of sites, countries and contributors makes hand control unreliable, when the data will support a regulatory submission, or when you cannot show timely filing and access review from your current setup. Moving mid-trial is possible but costs migration effort, so decide early.
Many CROs run trials in their own eTMF. If you use one, ask in the contract what you receive at the end, in what format, and how you get access during the trial.
Keep exploring
EDC vs eTMF
What the data system and the document system each do.
How to set up a trial master file
Structure, ownership and quality checks.
Investigator site file index template
The site-side file.
Data archiving and retention
What happens at close-out.
EDC vs CTMS
The other category question.
ICH E6(R3) guide
Essential records and proportionality.
Free sandbox with every feature. No credit card, and you pay only when you go live with real participants.