Developing a Monitoring Plan for Investigator-Initiated Clinical Trials

When an academic investigator holds the Investigational New Drug (IND) or Investigational Device Exemption (IDE) for their own trial, they become a sponsor-investigator under FDA regulation — and inherit every sponsor-side obligation that a pharmaceutical company or CRO would otherwise carry, monitoring included. Building a monitoring plan for an investigator-initiated study (IIS) means designing that sponsor-side oversight function from inside an academic department or clinical research unit, typically without a CRO’s dedicated monitoring staff, travel budget, or commercial monitoring software licenses. This guide covers what a monitoring plan needs to contain, who can actually perform the monitoring, and how to apply risk-based principles to make the plan workable at IIS scale and budget.

Who Takes on the Sponsor’s Monitoring Role in an IIS

Under 21 CFR Part 312, Subpart D, a sponsor is responsible for selecting qualified investigators, ensuring proper monitoring of the investigation, and maintaining oversight throughout conduct (§312.50, §312.53, §312.56). In a commercial trial, a sponsor company assigns this to in-house Clinical Research Associates (CRAs) or contracts it to a CRO. In an IIS, the sponsor-investigator holds this obligation personally — but critically, the sponsor-investigator cannot monitor their own trial. Monitoring is, by definition, an independent check on whether the trial is being conducted per protocol and GCP; a PI reviewing their own site’s compliance is not independent oversight, and most institutional policies and IRBs treat self-monitoring as a conflict-of-interest problem, not just a best-practice gap.

In practice, the monitoring function on an IIS is carried out by one of several arrangements, often blended:

• An institutional Clinical Research Unit (CRU), Office of Clinical Research, or Clinical Trials Office that provides shared monitoring staff across multiple investigators’ trials — the most common academic-medical-center model, since it lets several small IISs share the cost of a monitoring function none of them could staff alone.
• Reciprocal or cross-departmental monitoring, where investigators at different departments or divisions monitor each other’s trials, preserving independence from the study team without hiring additional staff.
• A contracted monitor or Functional Service Provider (FSP) arrangement — engaging a CRO or independent consultant monitor for the monitoring function specifically, rather than a full-service CRO engagement covering the whole trial. This is usually far cheaper than full outsourcing and is common for multi-site IISs that exceed a single institution’s monitoring capacity.
• A multi-site consortium or cooperative group structure, where a lead/coordinating site’s research office runs monitoring for all participating sites under a shared monitoring plan.

Whichever arrangement is used, the monitoring plan should name who performs monitoring, confirm they are independent of routine data collection and study-team decision-making for that trial, and document their qualifications — the same requirement ICH E6(R2) Principle 2.8 applies to anyone conducting trial-related tasks.

The Regulatory Basis: Applying ICH E6 Risk-Based Monitoring to an IIS

ICH E6(R2)’s 2016 addendum formally incorporated risk-based monitoring (RBM) into GCP: Section 5.0 establishes a sponsor quality-management system built around identifying and controlling risks to participant safety and data reliability, and Section 5.18.3 specifically calls for a documented rationale for the monitoring methods chosen, rather than a single fixed on-site cadence and 100% source data verification (SDV) applied uniformly regardless of actual risk. ICH E6(R3), finalized in January 2025, carries this forward with even more explicit emphasis on proportionate, risk-based quality management as a design principle rather than an optional cost-saving measure.

This matters directly for IIS monitoring-plan design for a practical reason: RBM was never written with only large commercial sponsors in mind, but it happens to be the framework that makes monitoring achievable at IIS scale. A monitoring approach that is deliberately scoped to the trial’s actual risk profile — rather than a blanket, maximal-intensity approach borrowed wholesale from a pivotal industry trial — is both the GCP-compliant approach and the only one that is realistically staffable and fundable within an academic budget. A thin monitoring plan that simply reduces visit frequency or SDV sampling to save money, without a documented risk assessment behind it, does not meet the ICH E6(R2)/(R3) bar; a monitoring plan that reduces intensity for well-justified, documented reasons does.

If the IIS is NIH-funded, a separate but related obligation applies: NIH’s 1998 Policy for Data and Safety Monitoring (NOT-98-084) requires every NIH-funded clinical trial to have a data and safety monitoring plan, commensurate with the trial’s size, complexity, and degree of risk — graduated from a study-team-level safety plan for lower-risk trials up to an independent Data Safety Monitoring Board (DSMB) for higher-risk, typically multi-site, Phase III-type trials. This safety-monitoring obligation is distinct from, and additional to, the operational/GCP monitoring plan described in this guide — a DSMB reviews accumulating safety and efficacy data at intervals and can recommend a trial be modified or stopped, while operational monitoring verifies day-to-day protocol adherence, data quality, and regulatory documentation at the site level. A well-run IIS with NIH funding typically needs both, scoped separately and appropriately to the trial’s risk level.

Core Components of an IIS Monitoring Plan

A workable monitoring plan document, whether for a single-site or multi-site IIS, should cover the following, mirroring ICH E6(R2) Section 5.18 expectations at IIS scale rather than skipping them for being “just” an academic trial:

1. Documented risk assessment. What are the trial-critical data and processes — the ones where an error would actually threaten participant safety or the reliability of the trial’s primary results — versus routine data where an error is lower-consequence? Relevant risk factors for an IIS specifically include: whether the investigational product is an already-approved drug/device used off-label (generally lower manufacturing/product risk than a novel investigational agent) or a genuinely novel intervention; the vulnerability of the study population; procedural complexity and invasiveness; and the experience level of the site(s) and study staff, which in an academic setting can vary widely between a well-resourced trials office and a single-coordinator lab.
2. Monitoring methods and their mix. Specify which combination of on-site visits, centralized/remote data review, and statistical monitoring will be used, and for which data/processes each applies. Centralized monitoring — reviewing accumulating data remotely for consistency, protocol deviations, enrollment pace, query resolution timeliness, and adverse-event reporting timeliness — is usually the most cost-effective starting point for an IIS, since it needs no travel budget and can often run through the same EDC or REDCap instance already collecting the trial’s data.
3. Source data verification (SDV) strategy. Specify what proportion and which fields will be source-verified, and why — typically prioritizing informed consent documentation, primary/safety endpoint data, and serious-adverse-event data over routine, lower-risk fields, rather than defaulting to 100% SDV of every field for every subject.
4. Monitoring frequency and intensity, with documented rationale. State the visit schedule (or trigger conditions for a visit, in a more dynamic model) and why that cadence is appropriate given the risk assessment above — this is the specific documentation ICH E6(R2) 5.18.3 calls for, and the piece most often missing when an IIS monitoring plan is just a boilerplate template left unedited.
5. Roles, responsibilities, and independence. Name who monitors, confirm their independence from the study team’s data-collection and analysis functions, and state their qualifications and reporting line (to the sponsor-investigator or, on a multi-site trial, to the coordinating center).
6. Escalation and corrective-action pathway. What happens when a monitoring visit or centralized review finds a finding — a protocol deviation, a data-quality problem, a consent-process issue? The plan should specify how findings are documented, communicated back to the site, tracked to resolution, and, for anything safety-relevant, routed to the IRB and, where one exists, the DSMB.
7. Documentation and filing. Monitoring visit reports (or centralized-review summaries) and any follow-up correspondence are essential documents under ICH E6(R2) Section 8 and belong in the Trial Master File — the same file a regulatory inspector would review if the trial were ever inspected.

The plan should be a living document, not a one-time submission: ICH E6(R2)/(R3) both expect the risk assessment and, correspondingly, the monitoring approach to be revisited as the trial accrues data and any new risk signals emerge, not fixed at study start and left unchanged for the trial’s duration.

Resource-Constrained Approaches That Still Meet the GCP Bar

The practical challenge in IIS monitoring is rarely disagreement about what good monitoring looks like — it is doing it without a CRO-scale budget or staff. A handful of approaches let a modestly resourced IIS meet ICH E6 expectations without pretending to be a commercial trial:

• Lean on centralized/remote monitoring as the default, not the exception. Most modern EDC systems (including REDCap, widely used in academic settings) support built-in edit checks, automated query generation, and data-consistency reports that do a meaningful share of monitoring work without a site visit. A risk-based plan can reserve on-site visits for higher-risk activities — informed consent verification, drug/device accountability, source document review for primary endpoints — and rely on centralized review for the rest.
• Use statistical/trigger-based visit scheduling instead of a fixed calendar cadence. Rather than budgeting for, say, a visit every eight weeks at every site regardless of what’s happening, a plan can specify visit triggers — a protocol deviation rate above a threshold, a data query backlog, a slower-than-expected SAE reporting timeline — so monitoring effort concentrates where risk signals actually appear.
• Share monitoring infrastructure across trials, not just within one. An institutional CRU/trials office monitoring function amortizes training, tools, and travel costs across every IIS it supports, which is usually far more efficient than each individual investigator building monitoring capacity from scratch.
• Budget monitoring into the grant or protocol budget from the start. A monitoring plan that exists only on paper because no funding was allocated to execute it is a common and preventable failure mode; monitoring cost (staff time, any FSP/contracted monitor fees, travel for the on-site portion) should be built into the original funding proposal, not treated as an afterthought once the trial is already enrolling.
• For multi-site IISs, formalize a reciprocal or coordinating-center monitoring agreement early. A consortium or cooperative-group structure where a coordinating center runs monitoring for all sites under one shared plan is usually more efficient, and easier to keep consistent, than each site independently improvising its own arrangement.

Common Pitfalls in IIS Monitoring Plans

• An unedited template. Copying a generic or a prior trial’s monitoring plan without adapting the risk assessment and methods mix to this trial’s actual profile is a frequent audit and inspection finding — the plan needs to reflect this trial’s specific risks, not a boilerplate structure.
• Self-monitoring by the study team. A PI or study coordinator reviewing their own trial’s conduct does not satisfy the independence expectation behind GCP monitoring, however well-intentioned.
• Treating “already-approved product” as automatically low-risk across the board. An off-label use of an approved drug or device can still carry meaningful risk from the trial’s procedures, population, or novel use context — risk assessment should look at the whole trial, not just the regulatory status of the product.
• No plan for revisiting the risk assessment. A monitoring plan finalized at study start and never revisited misses the point of a risk-based approach, which is meant to adapt as real data accumulates.
• Unbudgeted monitoring. A monitoring plan that was never funded is not a monitoring plan an inspector will accept as evidence of actual oversight.

Frequently Asked Questions

Can the principal investigator monitor their own investigator-initiated trial?

No. Because the sponsor-investigator holds both the sponsor and investigator roles under FDA regulation, monitoring — an independent check on trial conduct — cannot be performed by that same person or by the immediate study team. Institutions typically satisfy this through a CRU/trials-office monitor, a reciprocal arrangement with another investigator’s team, or a contracted monitor.

Is risk-based monitoring required, or just an option, for an investigator-initiated trial?

ICH E6(R2)/(R3) apply the same quality-management and monitoring expectations to any trial run under an IND/IDE, regardless of who holds the sponsor role. Risk-based monitoring is not a lesser standard reserved for smaller trials — it is the current GCP-expected approach for all trials, and in practice it is usually the only approach an IIS can realistically execute given typical academic monitoring budgets.

Do NIH-funded investigator-initiated trials need a separate data and safety monitoring plan?

Yes, in addition to the operational/GCP monitoring plan described in this guide. NIH’s 1998 Policy for Data and Safety Monitoring requires every NIH-funded clinical trial to have a data and safety monitoring plan appropriate to its risk level, ranging from a study-team-level plan for lower-risk trials up to an independent DSMB for higher-risk, typically multi-site trials. The two plans serve different functions: safety monitoring reviews accumulating safety/efficacy data and can recommend stopping the trial; operational monitoring verifies day-to-day protocol and data-quality compliance at the site level.

How is monitoring different from an audit or an FDA inspection for an IIS?

Monitoring is the sponsor-investigator’s own ongoing oversight function, carried out throughout the trial. An audit is a periodic, independent, systematic review (often conducted by the institution’s quality-assurance function). An inspection is a regulatory authority’s own review, most commonly triggered by a marketing application or high enrollment at a pivotal site. All three can occur on an IIS, but only monitoring is the sponsor-investigator’s direct, continuous responsibility under 21 CFR Part 312, Subpart D.

What happens if an IIS monitoring plan doesn’t get funded or staffed?

An unfunded or unstaffed monitoring plan is a common and serious compliance gap — institutional research offices and IRBs increasingly ask for evidence of a workable monitoring arrangement, including its funding source, before approving or continuing an IIS. This is a strong reason to budget monitoring costs into the original grant or protocol budget rather than addressing it only after enrollment begins.

For the underlying regulatory concepts referenced throughout this guide, see CASRAI’s dictionary entries on investigator-initiated study (IIS), risk-based monitoring (RBM), and Data Safety Monitoring Board (DSMB).