Anatomy of a lapse: what happens when IRB approval expires

Per ICH E6(R3) Annex 1, Section 1.2.4, the IRB/IEC should conduct continuing review of each ongoing trial at intervals appropriate to the degree of risk to participants. Under U.S. regulations (21 CFR 56.108(a)), that review must occur at least once per year. When that review does not occur before the current approval period expires, the regulatory status of the trial changes fundamentally. The site no longer has IRB authorization to conduct the research. This is not a technicality -- it is a regulatory state change with immediate operational consequences.

The cascade is predictable and, in my experience, remarkably consistent across institutions. It unfolds in stages, each compounding the one before it.

Stage 1: Immediate enrollment freeze. No new participants can be enrolled. Screening visits in progress must be paused. Participants who were scheduled for their first study visit may need to be rescheduled or, depending on the protocol's enrollment window, withdrawn. For a trial actively enrolling, every day of the freeze represents lost participants -- participants who may enroll at a competitor site instead.

Stage 2: Participant visit disruption. Already-enrolled participants present a more complicated question. Most institutions require that study visits be suspended during a lapse, except for interventions necessary to protect participant safety. This means that a participant halfway through a chemotherapy protocol may continue receiving treatment, but protocol-required assessments, blood draws, and imaging studies that exist solely for research purposes cannot proceed. The disruption to data integrity is significant. Protocol deviations accumulate. Windows for time-sensitive assessments are missed.

Stage 3: Sponsor notification and escalation. Per ICH E6(R3) Annex 1, Section 2.5.2, the investigator should comply with the protocol, GCP, and applicable regulatory requirements. A lapse in approval is a compliance failure that the sponsor must be informed of. The clinical research associate will document it. The sponsor's regulatory team will assess whether the lapse constitutes a significant deviation requiring reporting to the FDA. The site's name appears in internal reports -- and not in a favorable light.

Stage 4: Institutional and competitive consequences. The site's research office is notified. Depending on institutional policy, a formal corrective action plan may be required. Other investigators at the institution may face heightened scrutiny. And the sponsor's site selection team, when evaluating sites for the next trial, now has a documented regulatory lapse in your site's history. In a competitive enrollment environment where sponsors can choose from dozens of qualified sites, a lapse is the kind of mark that does not wash off easily.

The portfolio multiplier: why one lapse becomes three

Here is the aspect of continuing review lapses that I find most underappreciated by sites that have not yet experienced one: a lapse does not only affect the study that lapsed. It destabilizes the entire portfolio.

Consider the mechanics. When a continuing review lapse is discovered, the regulatory coordinator must immediately shift from proactive portfolio management to crisis response. The lapsed study demands emergency attention: assembling the overdue package, negotiating expedited IRB review, notifying the sponsor, documenting the lapse, and managing the fallout. Every hour spent on crisis management is an hour not spent on the continuing reviews, amendments, and safety reports for the other 14 studies in the portfolio.

This is how one lapse becomes two. And two becomes three. The RC who is spending 40% of their week managing the consequences of a lapse on Study A does not have the bandwidth to notice that Study B's continuing review is now 45 days out with an incomplete package. By the time the Study A crisis is resolved, Study B is in the same position. The cascade is not hypothetical -- I have seen it happen at sites that were, on paper, adequately staffed and well-organized. The root cause is always the same: the absence of an early-warning system that would have flagged the approaching deadline with enough lead time to prevent the crisis.

Designing the early-warning system: 90, 60, and 30 days

The antidote to a regulatory lapse is not vigilance. Vigilance is a human capacity, and human capacities fail under sustained load. The antidote is infrastructure -- a system that generates alerts at defined intervals regardless of how busy you are, how many other deadlines are competing for your attention, or whether the coordinator who normally tracks that study is on vacation.

The early-warning system I am about to describe is not complex. But it must be implemented with the same rigor you would apply to a safety reporting system, because the consequences of its failure are comparable. It operates on three alert milestones, each triggering a specific set of actions.

The 90-day alert: begin preparation

At 90 days before the current approval expiration date, the tracking system generates the first alert. This is the preparation trigger. At this milestone, the RC takes three actions.

First, verify the expiration date. This sounds redundant, but I have seen sites operate on incorrect expiration dates pulled from outdated approval letters or transposed incorrectly into the tracking system. The 90-day alert is the moment to confirm the date against the most recent IRB approval letter. If the date in your system does not match the letter, fix it now.

Second, identify the data streams that will feed the continuing review package for this study. Which coordinator maintains the enrollment log? Who compiles the adverse event summary? Is the deviation tracker current, or does it need reconciliation before data can be pulled? The goal is not to assemble the package now -- that comes at the 60-day milestone -- but to identify any data collection gaps that would delay assembly later. Per ICH E6(R3) Annex 1, Sections 2.12.1 and 2.12.2, the investigator should ensure the integrity of trial data and maintain adequate source records that are attributable, legible, contemporaneous, original, accurate, and complete. The 90-day check verifies that those records are being maintained continuously, not scrambled together at the last minute.

Third, check for dependencies. Does this study's continuing review require a PI signature? If so, is the PI available during the assembly and submission window, or do you need to plan around a conference, sabbatical, or clinical rotation? Does the IRB require any institutional sign-offs -- pharmacy committee confirmation, radiation safety committee renewal -- that have their own lead times?

The 60-day alert: assembly checkpoint

At 60 days, the system generates the second alert. This is the assembly checkpoint. By this milestone, three conditions must be met.

The data streams identified at the 90-day mark are now locked. The coordinator has provided the enrollment summary current through the data-lock date. The adverse event tally is complete. The deviation log is reconciled. These data elements are in the RC's hands, not still sitting in the coordinator's pending tasks.

The IRB-specific template for this continuing review is populated with the study-level data. Common elements -- study title, protocol number, PI name, approval dates -- are filled. IRB-specific sections -- the format they want for the enrollment summary, the level of detail they expect in the deviation narrative -- are drafted.

And the PI review window is scheduled. Not "we will get the PI to look at it sometime in the next two weeks" -- but a specific date, confirmed with the PI or the PI's assistant, during which the PI will review and sign the package. If the PI is unavailable during the planned review window, the 60-day checkpoint is the last moment at which alternative arrangements can be made without creating timeline risk.

The 30-day alert: submission deadline

At 30 days before expiration, the package must be submitted to the IRB. Not "nearly ready." Not "waiting for one signature." Submitted.

This milestone is non-negotiable because it accounts for the one variable you cannot control: IRB processing time. Most IRBs process continuing reviews in 15 to 25 business days. Some are faster. Some, particularly local institutional IRBs that meet on a monthly committee cycle, may take longer. But 30 calendar days provides the minimum safe buffer for most IRB types. If you are working with an IRB whose processing time routinely exceeds 20 business days, adjust your 30-day standard to 45 days and cascade the 60 and 90-day alerts accordingly.

What happens if you reach the 30-day mark and the package is not ready? This is an escalation event, not a scheduling adjustment. The RC must immediately assess what is preventing submission, escalate to whoever can resolve the block, and explore expedited options. Some IRBs offer expedited or emergency continuing review processing for packages submitted close to expiration. But these expedited pathways are favors, not entitlements. A site that uses them routinely signals a process problem that the IRB will eventually address through more uncomfortable channels.

Integrating early-warning into the tracking system

The early-warning system is not a separate tool. It is a feature of the submission tracking infrastructure you designed in Module 1, Lesson 3. If your tracking system captures each study's current IRB approval expiration date, then the early-warning system is a calculation: expiration date minus 90, 60, and 30 days, with each threshold generating an alert.

The implementation varies by tracking platform. A spreadsheet-based system uses conditional formatting to highlight studies approaching each threshold -- green at 90 days, amber at 60, red at 30. A CTMS module may offer automated email alerts at configured intervals. A shared calendar system uses recurring reminders set backward from the expiration date.

The specific technology matters less than the discipline. The system must generate alerts automatically, without requiring anyone to remember to check. It must be visible to the RC regardless of their current workload or focus. And it must be updated immediately when a continuing review is approved and a new expiration date is established -- because the cycle begins again the moment the current one ends.

Key takeaways

A continuing review lapse is not a paperwork delay -- it is a regulatory state change that immediately halts enrollment, disrupts participant visits, triggers sponsor escalation, and damages the site's competitive position. The consequences cascade across the portfolio because crisis management for the lapsed study consumes the bandwidth needed to prevent lapses on other studies.

The 90/60/30-day early-warning system is the operational infrastructure that prevents lapses. At 90 days, verify the expiration date, identify data collection needs, and check for dependencies. At 60 days, confirm that data is locked, the template is populated, and the PI review window is scheduled. At 30 days, the package must be submitted -- no exceptions. This system integrates with the submission tracking infrastructure from Module 1 and generates alerts automatically, without relying on individual memory.

The cost of building and maintaining this early-warning system is measured in hours per month. The cost of a single lapse is measured in months of recovery, lost enrollment, damaged relationships, and institutional corrective action. The math is not close.

Anatomy of a lapse: what happens when IRB approval expires

Per ICH E6(R3) Annex 1, Section 1.2.4, the IRB/IEC should conduct continuing review of each ongoing trial at intervals appropriate to the degree of risk to participants. Under U.S. regulations (21 CFR 56.108(a)), that review must occur at least once per year. When that review does not occur before the current approval period expires, the regulatory status of the trial changes fundamentally. The site no longer has IRB authorization to conduct the research. This is not a technicality -- it is a regulatory state change with immediate operational consequences.

The cascade is predictable and, in my experience, remarkably consistent across institutions. It unfolds in stages, each compounding the one before it.

Stage 1: Immediate enrollment freeze. No new participants can be enrolled. Screening visits in progress must be paused. Participants who were scheduled for their first study visit may need to be rescheduled or, depending on the protocol's enrollment window, withdrawn. For a trial actively enrolling, every day of the freeze represents lost participants -- participants who may enroll at a competitor site instead.

Stage 2: Participant visit disruption. Already-enrolled participants present a more complicated question. Most institutions require that study visits be suspended during a lapse, except for interventions necessary to protect participant safety. This means that a participant halfway through a chemotherapy protocol may continue receiving treatment, but protocol-required assessments, blood draws, and imaging studies that exist solely for research purposes cannot proceed. The disruption to data integrity is significant. Protocol deviations accumulate. Windows for time-sensitive assessments are missed.

Stage 3: Sponsor notification and escalation. Per ICH E6(R3) Annex 1, Section 2.5.2, the investigator should comply with the protocol, GCP, and applicable regulatory requirements. A lapse in approval is a compliance failure that the sponsor must be informed of. The clinical research associate will document it. The sponsor's regulatory team will assess whether the lapse constitutes a significant deviation requiring reporting to the FDA. The site's name appears in internal reports -- and not in a favorable light.

Stage 4: Institutional and competitive consequences. The site's research office is notified. Depending on institutional policy, a formal corrective action plan may be required. Other investigators at the institution may face heightened scrutiny. And the sponsor's site selection team, when evaluating sites for the next trial, now has a documented regulatory lapse in your site's history. In a competitive enrollment environment where sponsors can choose from dozens of qualified sites, a lapse is the kind of mark that does not wash off easily.

The portfolio multiplier: why one lapse becomes three

Here is the aspect of continuing review lapses that I find most underappreciated by sites that have not yet experienced one: a lapse does not only affect the study that lapsed. It destabilizes the entire portfolio.

Consider the mechanics. When a continuing review lapse is discovered, the regulatory coordinator must immediately shift from proactive portfolio management to crisis response. The lapsed study demands emergency attention: assembling the overdue package, negotiating expedited IRB review, notifying the sponsor, documenting the lapse, and managing the fallout. Every hour spent on crisis management is an hour not spent on the continuing reviews, amendments, and safety reports for the other 14 studies in the portfolio.

This is how one lapse becomes two. And two becomes three. The RC who is spending 40% of their week managing the consequences of a lapse on Study A does not have the bandwidth to notice that Study B's continuing review is now 45 days out with an incomplete package. By the time the Study A crisis is resolved, Study B is in the same position. The cascade is not hypothetical -- I have seen it happen at sites that were, on paper, adequately staffed and well-organized. The root cause is always the same: the absence of an early-warning system that would have flagged the approaching deadline with enough lead time to prevent the crisis.

Designing the early-warning system: 90, 60, and 30 days

The antidote to a regulatory lapse is not vigilance. Vigilance is a human capacity, and human capacities fail under sustained load. The antidote is infrastructure -- a system that generates alerts at defined intervals regardless of how busy you are, how many other deadlines are competing for your attention, or whether the coordinator who normally tracks that study is on vacation.

The early-warning system I am about to describe is not complex. But it must be implemented with the same rigor you would apply to a safety reporting system, because the consequences of its failure are comparable. It operates on three alert milestones, each triggering a specific set of actions.

The 90-day alert: begin preparation

At 90 days before the current approval expiration date, the tracking system generates the first alert. This is the preparation trigger. At this milestone, the RC takes three actions.

First, verify the expiration date. This sounds redundant, but I have seen sites operate on incorrect expiration dates pulled from outdated approval letters or transposed incorrectly into the tracking system. The 90-day alert is the moment to confirm the date against the most recent IRB approval letter. If the date in your system does not match the letter, fix it now.

Second, identify the data streams that will feed the continuing review package for this study. Which coordinator maintains the enrollment log? Who compiles the adverse event summary? Is the deviation tracker current, or does it need reconciliation before data can be pulled? The goal is not to assemble the package now -- that comes at the 60-day milestone -- but to identify any data collection gaps that would delay assembly later. Per ICH E6(R3) Annex 1, Sections 2.12.1 and 2.12.2, the investigator should ensure the integrity of trial data and maintain adequate source records that are attributable, legible, contemporaneous, original, accurate, and complete. The 90-day check verifies that those records are being maintained continuously, not scrambled together at the last minute.

Third, check for dependencies. Does this study's continuing review require a PI signature? If so, is the PI available during the assembly and submission window, or do you need to plan around a conference, sabbatical, or clinical rotation? Does the IRB require any institutional sign-offs -- pharmacy committee confirmation, radiation safety committee renewal -- that have their own lead times?

The 60-day alert: assembly checkpoint

At 60 days, the system generates the second alert. This is the assembly checkpoint. By this milestone, three conditions must be met.

The data streams identified at the 90-day mark are now locked. The coordinator has provided the enrollment summary current through the data-lock date. The adverse event tally is complete. The deviation log is reconciled. These data elements are in the RC's hands, not still sitting in the coordinator's pending tasks.

The IRB-specific template for this continuing review is populated with the study-level data. Common elements -- study title, protocol number, PI name, approval dates -- are filled. IRB-specific sections -- the format they want for the enrollment summary, the level of detail they expect in the deviation narrative -- are drafted.

And the PI review window is scheduled. Not "we will get the PI to look at it sometime in the next two weeks" -- but a specific date, confirmed with the PI or the PI's assistant, during which the PI will review and sign the package. If the PI is unavailable during the planned review window, the 60-day checkpoint is the last moment at which alternative arrangements can be made without creating timeline risk.

The 30-day alert: submission deadline

At 30 days before expiration, the package must be submitted to the IRB. Not "nearly ready." Not "waiting for one signature." Submitted.

This milestone is non-negotiable because it accounts for the one variable you cannot control: IRB processing time. Most IRBs process continuing reviews in 15 to 25 business days. Some are faster. Some, particularly local institutional IRBs that meet on a monthly committee cycle, may take longer. But 30 calendar days provides the minimum safe buffer for most IRB types. If you are working with an IRB whose processing time routinely exceeds 20 business days, adjust your 30-day standard to 45 days and cascade the 60 and 90-day alerts accordingly.

What happens if you reach the 30-day mark and the package is not ready? This is an escalation event, not a scheduling adjustment. The RC must immediately assess what is preventing submission, escalate to whoever can resolve the block, and explore expedited options. Some IRBs offer expedited or emergency continuing review processing for packages submitted close to expiration. But these expedited pathways are favors, not entitlements. A site that uses them routinely signals a process problem that the IRB will eventually address through more uncomfortable channels.

Integrating early-warning into the tracking system

The early-warning system is not a separate tool. It is a feature of the submission tracking infrastructure you designed in Module 1, Lesson 3. If your tracking system captures each study's current IRB approval expiration date, then the early-warning system is a calculation: expiration date minus 90, 60, and 30 days, with each threshold generating an alert.

The implementation varies by tracking platform. A spreadsheet-based system uses conditional formatting to highlight studies approaching each threshold -- green at 90 days, amber at 60, red at 30. A CTMS module may offer automated email alerts at configured intervals. A shared calendar system uses recurring reminders set backward from the expiration date.

The specific technology matters less than the discipline. The system must generate alerts automatically, without requiring anyone to remember to check. It must be visible to the RC regardless of their current workload or focus. And it must be updated immediately when a continuing review is approved and a new expiration date is established -- because the cycle begins again the moment the current one ends.

Key takeaways

A continuing review lapse is not a paperwork delay -- it is a regulatory state change that immediately halts enrollment, disrupts participant visits, triggers sponsor escalation, and damages the site's competitive position. The consequences cascade across the portfolio because crisis management for the lapsed study consumes the bandwidth needed to prevent lapses on other studies.

The 90/60/30-day early-warning system is the operational infrastructure that prevents lapses. At 90 days, verify the expiration date, identify data collection needs, and check for dependencies. At 60 days, confirm that data is locked, the template is populated, and the PI review window is scheduled. At 30 days, the package must be submitted -- no exceptions. This system integrates with the submission tracking infrastructure from Module 1 and generates alerts automatically, without relying on individual memory.

The cost of building and maintaining this early-warning system is measured in hours per month. The cost of a single lapse is measured in months of recovery, lost enrollment, damaged relationships, and institutional corrective action. The math is not close.