Periodic Review Scheduling That Survives a Staffing Cut

What Annex 11 Clause 11 Actually Requires

The text is two sentences long. Annex 11 of the EU GMP guide, revision 1, came into operation on 30 June 2011 and remains the version in force. Clause 11, headed Periodic evaluation, reads: “Computerised systems should be periodically evaluated to confirm that they remain in a valid state and are compliant with GMP. Such evaluations should include, where appropriate, the current range of functionality, deviation records, incidents, problems, upgrade history, performance, reliability, security and validation status reports.”¹

Read it again and notice what is not there. No interval. No annual requirement. No minimum content that must appear regardless of relevance. The phrase “where appropriate” governs the entire list of nine items, which means each item is included when it tells you something and omitted when it does not. And the word “confirm” sets the purpose: the review exists to reach a conclusion about validated state, not to assemble a file.

That is the whole legal basis for a practice that in many organizations consumes several hundred hours a year and produces documents nobody reads after approval. The gap between the requirement and the practice is where the relief is.

Where the annual habit came from

Nothing in Annex 11 says annual. The habit came from three places, none of which is a requirement to review every computerized system every year.

The first is the Product Quality Review, which is genuinely annual and genuinely mandatory, and which many organizations used as the scheduling model when they first stood up a computerized system review program. The second is Annex 15, which addresses re-qualification of equipment, facilities, utilities and systems and states that they “should be evaluated at an appropriate frequency to confirm that they remain in a state of control.” Annex 15 then adds that where re-qualification is performed at a specific time period, “the period should be justified and the criteria for evaluation defined.”³ That is the same risk-based logic as Annex 11, and it carries the same instruction: justify the period. The third is internal audit scheduling practice, which historically ran on a calendar rather than on risk, a habit the profession has already started to move away from.

Annual review became the default because a default is easier to administer than a justification. That was a reasonable trade when the team was large enough to absorb it. It stops being reasonable the moment the team is not.

What the draft revision adds

On 7 July 2025 the European Commission published a draft revision of Annex 11 for stakeholder consultation, drafted jointly by the EMA GMP/GDP Inspectors Working Group and PIC/S. The draft grows the annex from five pages to nineteen and restructures it into seventeen sections. Section 14 is titled Periodic Reviews.²

As of this writing the 2011 version remains the text in force. The consultation draft has not been adopted, and EudraLex Volume 4 still lists Annex 11 at revision January 2011. Treat the draft as a strong signal of inspector thinking rather than as a live obligation, and do not rewrite procedures against it until a final text exists. It is worth reading closely anyway, because it says out loud what the current annex leaves implicit.

Draft clause 14.1 states that after a system has been initially validated and put into operation, periodic reviews should be conducted, and that the review should verify whether the system remains fit for intended use and in a validated state, or whether changes should be made and re-validation, complete or in parts, is required. Draft clause 14.3 addresses frequency directly: reviews should be conducted, approved and closed according to plan, and “the frequency of reviews should be established and justified based on the risk the system poses to product quality, patient safety and data integrity.” The same clause adds a requirement that many organizations currently miss: a final review should be conducted when the system is taken out of use.²

Two things follow. First, the direction of travel is toward explicit risk-based frequency, not toward a fixed interval. A team that builds a defensible interval model now is building toward the draft, not away from it. Second, the draft’s scope list in clause 14.2 is longer and more specific than the 2011 list, covering changes to hardware, software, configuration, platform, infrastructure and interfaces; changes to system documentation; the combined effect of multiple changes across systems; actions from previous reviews, audits and inspections; conduct of audit trail reviews and access reviews; incidents, problems, deviations and security events; maintenance and service level agreements; vendor contracts and key performance indicators; backup procedures, restore tests and disaster recovery plans; archival adequacy; data integrity assessments; and changes to regulatory requirements.²

That is a demanding list. It is also, read carefully, a list of things that mostly already exist somewhere else in your quality system. The review does not create them. It confirms they happened and asks what they mean together. That distinction is the single largest source of avoidable effort in a periodic review program.

Why the Review Calendar Breaks Before the Team Does

A periodic review program has a fixed annual demand determined by three numbers: how many systems are in scope, how often each is reviewed, and how many hours each review takes. Multiply them and you get the annual hour requirement. Divide by available reviewer hours and you get the answer to whether the program is viable.

Almost nobody does this math. The schedule was set once, the template grew over time, and the system inventory grew faster than either. Then a reorganization removed two validation specialists and a quality systems reviewer, and the arithmetic that was already tight became impossible. Nothing in the procedure changed, so the schedule kept generating due dates that nobody could meet.

The inventory grew and nobody re-baselined the schedule

Annex 11 clause 4.3 requires an up to date listing of all relevant systems and their GMP functionality.¹ That inventory is the input to the review schedule, and when it is wrong the schedule is wrong in both directions: systems that should be reviewed are missing, and systems that no longer exist are still generating due dates.

The MHRA’s published deficiency examples for Annex 11 include exactly this failure mode. One recorded finding describes an inventory that was not a current, accurate list and did not include the GMP functionality of the systems; another describes an access control system defined as not a GMP system and therefore never validated, despite controlling entry to GMP areas.⁶ Both are inventory problems before they are review problems.

If your inventory has not been reconciled in two years, the review schedule built on it is not a schedule. It is a guess with dates attached. Fix the inventory first, because every decision in the rest of this article depends on it.

The template grew and nobody removed anything

Periodic review templates accumulate. An inspector asks a question in 2019 and a section is added. A CAPA in 2021 adds a checklist. A new SOP author in 2023 adds a cross-reference table. Nothing is ever removed, because removing something feels like reducing compliance. The result is a forty-page document where the conclusion about validated state occupies one paragraph and the other thirty-nine pages are transcription.

Transcription is where the hours go. A reviewer copying change records out of the change control system into a review document is not evaluating anything. They are producing a second, less reliable copy of a record that already exists in a validated system. When the team is small, that work is the first thing to eliminate.

Reviewers with no authority produce reviews with no conclusions

The third failure is structural. In many programs the periodic review is assigned to whoever has capacity rather than to someone who can make a determination. A junior reviewer can assemble evidence. They cannot credibly conclude that a system remains in a validated state, and they certainly cannot conclude that it does not, because that conclusion has consequences they are not positioned to own.

The GAMP 5 second edition emphasis on critical thinking by knowledgeable and experienced subject matter experts is directly relevant here. The guide moves away from document-heavy, one-size-fits-all validation toward judgment applied by people qualified to exercise it.⁷ A periodic review program staffed by people who cannot exercise judgment will produce documents that confirm validated state by default, which is worse than no review at all, because it creates a written record of a conclusion nobody actually reached.

Setting Risk-Based Intervals a Regulator Will Accept

The published practitioner consensus is that periodic reviews are typically conducted annually or every two or three years depending on the risk level assigned, driven by an inventory that defines the criticality of each system.⁸ That range is the working space. The question is how you place a given system inside it and what evidence supports the placement.

The three factors that actually justify an interval

Interval justification rests on three inputs. GMP impact, which is the potential effect on product quality and patient safety if the system fails or produces wrong output. Change rate, which is how often the system is modified, upgraded, patched or reconfigured. And control maturity, which is how much independent evidence you already have that the system remains under control between reviews.

The third factor is the one most organizations leave out, and it is the one that earns the longer intervals. A system with continuous audit trail review, quarterly access recertification, automated configuration monitoring and a tested restore is generating evidence of validated state every month. A periodic review of that system is a summary and a conclusion. A system with none of those controls has no evidence between reviews, so the review has to generate it, and that argues for a shorter interval and a longer review.

Stated plainly: strong continuous controls buy you a longer interval. Weak continuous controls do not. If you want to move systems from annual to triennial, invest in the monitoring first and change the interval second. Doing it the other way around is the version an inspector will challenge.

A worked interval model

The table below is a four-tier model that can be adopted directly or used as a starting point. The tier is assigned in the system inventory, reassessed when GMP impact changes, and recorded with a written rationale for each system. The trigger column matters as much as the interval, because it is what makes the model risk-based rather than merely slower.

Two design points are worth naming. First, Tier 4 is not a loophole. It is the single most effective way to reduce program demand, and it depends entirely on the quality of the GMP impact assessment behind it. An inspector will test that assessment before anything else. Second, the trigger column means a Tier 3 system with a three-year interval can still be reviewed twice in eighteen months if events warrant. The interval is a floor for scrutiny, not a ceiling.

What an inspector will ask about a longer interval

A three-year interval is not inherently suspicious. An unjustified three-year interval is. The questions come in a predictable order, and you should be able to answer all four from documents that already exist.

Grouping Reviews by Platform and by Vendor

The second lever is grouping. If forty systems run on one validated platform under one vendor agreement with one set of infrastructure controls, reviewing them forty times means answering the same infrastructure questions forty times. Grouping consolidates the shared layer into one review and leaves a short system-specific supplement for each instance.

This is not a shortcut. Done properly it produces a better review, because the shared analysis is done once by someone who understands the platform rather than forty times by people who understand only their own application.

What can be grouped and what cannot

How a grouped review is structured

The structure is a parent document and a set of short children. The parent covers the platform and vendor layer for the review period and reaches its own conclusion about whether the shared layer remains fit for purpose. Each child covers one system, references the parent by document number and version, and covers only the system-specific content: configuration changes, deviations and incidents for that instance, its access review outcome, its data integrity assessment, and its own validated state conclusion.

Three rules keep this defensible. The parent must be completed and approved before or alongside the children, never after, so the children are not referencing a conclusion that does not yet exist. The parent’s review period must cover each child’s review period, which in practice means the parent is reviewed at the shortest interval of any system in the group. And a finding in the parent must propagate: if the platform review finds that restore testing was not performed, every child in the group inherits that finding rather than concluding validated state on its own.

That last rule is what stops grouping from becoming a way to make problems disappear. It is also the rule that gets forgotten, and it is worth writing into the procedure explicitly.

The cloud and vendor-managed case

Grouping is most valuable and most delicate for cloud and vendor-managed systems, because a substantial part of the platform layer is under someone else’s control. A vendor security attestation evidences the vendor’s operational controls. It does not evidence your tenant configuration, your workflow setup, your access model or your data integrity controls, and it does not discharge the supplier assessment obligation that Annex 11 clause 3 places on the regulated user.¹ ISPE’s work on quality agreements for software-as-a-service in GxP use makes the same division clear: what the provider is responsible for and what the regulated organization remains responsible for has to be written down, or the periodic review has no basis for concluding anything about the shared layer.⁹

The practical test for a grouped cloud review: can you name, for each item in the platform layer, whether you verified it yourself, verified it through a contractual reporting obligation, or accepted it on a vendor attestation? If the answer for every item is the third, the grouped review is a vendor summary rather than a periodic evaluation, and it will not withstand a question about how you know.

The Minimum Viable Periodic Review

A minimum viable periodic review is the shortest document that lets a qualified reviewer reach and defend a conclusion about validated state. It has seven content sections and one conclusion. Everything else is optional and should be justified before it is added.

The seven sections map directly onto the 2011 clause 11 list and onto the more detailed draft clause 14.2 scope, so this is not a reduced-scope review. It is the same scope without the transcription.

The conclusion is the deliverable

The seven sections exist to support one statement, and the statement has to be one of three things. The system remains in a validated state, with no actions. The system remains in a validated state, with defined actions and owners and due dates. Or the system is not in a validated state, with the immediate containment and the remediation path stated. GAMP 5 second edition frames the outcome the same way: a documented determination of validated status confirmed, or a defined remediation or revalidation action.¹⁰

A review that concludes “review complete” has not concluded anything. If your template does not force one of the three statements, add that and remove something else.

What Accreted Into Your Template and Why It Has to Go

Before cutting, be clear about the test. A section stays if a qualified reviewer would reach a different conclusion about validated state without it. A section goes if it is a copy of a record that already exists in a controlled system, if it restates policy rather than evaluating this system, or if it was added to satisfy a question that has since been answered structurally elsewhere.

The usual accretions

• Full transcription of change records. Retyping thirty change control numbers, titles, dates and approvers into the review document duplicates a validated record and introduces transcription error. Attach the query output and analyze it instead.
• Full transcription of the audit trail review. The audit trail review is its own controlled activity with its own records. The periodic review confirms it happened at the required frequency, states the outcome, and evaluates what the outcome means. It does not reproduce the audit trail review.
• Regulatory background sections. A three-page recital of Annex 11, 21 CFR Part 11 and internal policy appears in every review document for every system, and nobody has read it since it was written. It belongs in the procedure, once.
• Duplicated system description. The system description is a controlled document required by Annex 11 clause 4.3 for critical systems.¹ The review confirms it is current and references it. Copying it in creates a second version that will diverge.
• Screenshot appendices. Forty pages of configuration screenshots printed at review time prove what the screen looked like on one day and are not compared against anything. If configuration verification matters, and for most systems it does, run a configuration comparison against the approved baseline and report the differences. That is one page and it is evidence.
• Checklists that only ever get one answer. Any line item that has been answered yes on every system on every review for four years is not testing anything. Either it is genuinely structural and belongs in the procedure, or it is dead weight.
• Sign-off tables with six approvers. Each additional approver adds cycle time and diffuses accountability without adding scrutiny. The review needs a preparer, a system owner or process owner, and a quality approver.

When the Review Finds the System Is Not in a Validated State

This is the outcome the whole exercise exists to detect and the one most programs are least prepared to handle. The finding is usually one of four: configuration has drifted from the approved baseline through changes that were not assessed for validation impact, the validation documentation no longer describes the system that exists, a control that validation relied on has stopped working, or the system’s use has expanded into GMP functionality that was never validated.

The instinct is to soften the conclusion. Resist it. A review that finds a problem and states it plainly is evidence that the control works. A review that finds a problem and records it as an observation for future consideration is evidence that it does not, and if a regulator later finds the same problem, the softened review becomes the more serious finding.

The sequence

What this looks like when it goes wrong

FDA enforcement records show what the same underlying failures look like when nobody caught them. A warning letter issued to Laboratorios Jaloma S.A. de C.V. on 22 May 2026 cites 21 CFR 211.68(b) in a section headed Computer or Related Systems, describing a gas chromatography instrument that was not adequately qualified because the firm failed to validate the control software or enable audit trails, chromatograph data files that could not be located in the storage folders on the instrument computer, and a confirmation from the firm that it did not back up the electronic data on that computer.¹¹

Every one of those is something a minimum viable periodic review would have surfaced. Section 4 asks for restore evidence and would have found no backup. Section 7 asks whether configuration matches the approved baseline and would have found audit trails disabled. Section 1 asks about changes and would have found the software never validated. The regulation that requires computer systems controls is 21 CFR 211.68, and the periodic review is the practical mechanism for demonstrating those controls are still working between inspections.¹²

The Honest Conversation About an Overdue Backlog

If you are reading this with a list of overdue reviews, the question is not how to make the list disappear before the next inspection. It is how to be in a position where the list is not the worst thing an inspector finds.

What to tell an inspector

Inspectors encounter backlogs regularly. What distinguishes an acceptable response from an unacceptable one is not the size of the backlog. It is whether the organization knows the size, understands the risk it carries, and is executing a plan that will close it. Four things need to be true and demonstrable.

A remediation plan that is credible rather than aspirational

The difference between the two is arithmetic. An aspirational plan says the backlog will be cleared within twelve months. A credible plan shows the hours available, the hours required, and the point where the two lines meet.

Build it in this order. Count the backlog and the forward demand together, because clearing eighty overdue reviews while sixty new ones fall due is a different problem from clearing eighty into an empty year. Apply the tier model and the reduced template to both, since the backlog should be cleared using the new approach, not the old one. Calculate required hours from the reduced template, not from historical effort. Compare against genuinely available hours, meaning what the named reviewers can give after their other committed work, not their theoretical capacity. If the lines do not meet inside twelve to eighteen months, the plan needs external resource or a further scope decision, and that is a conversation to have before an inspection rather than during one.

Then sequence the work by risk. Tier 1 systems first, regardless of how overdue they are. Systems with open incidents, recent major changes or known control weaknesses next. Systems whose last review found actions that were never closed after that. Long-overdue Tier 3 systems last, because a stable low-impact system that is fourteen months past due carries less risk than a Tier 1 system that is two months past due, and an inspector will understand that ordering if you can explain it.

Related work that reduces the demand at the source

Three adjacent activities take load off the review program permanently, and each is worth more than any amount of scheduling optimization.

The first is the computerized system inventory. Every system that is correctly assessed as having no GMP impact leaves the program entirely, and every system that has been decommissioned but never removed from the list stops generating due dates. In most estates this is the single largest reduction available, and it is also the Annex 11 clause 4.3 obligation you already have.¹

The second is decommissioning. Systems that are no longer used but have not been formally retired keep consuming review effort and keep carrying record retention obligations nobody is managing. Formal decommissioning removes them from the schedule and settles the retention question at the same time. The draft Annex 11 revision reinforces this by requiring a final review when a system is taken out of use, which is a small addition of effort now in exchange for permanent removal from the recurring schedule.²

The third is consolidation. Every time two systems become one, the review count drops by one permanently. This is one of the less obvious arguments in favor of using an eQMS module rather than a separate best-of-breed tool for a given process: the module is reviewed as part of the platform, while the separate tool is its own system with its own supplier, its own interfaces and its own review. That trade-off is not always decided in favor of consolidation, and it should not be decided on review effort alone, but review effort is a real and usually unquantified part of the comparison.

Where the program has to be governed from

A reduced program only stays reduced if someone owns the arithmetic. That means the periodic review schedule, the tier assignments, the backlog position and the forward demand are reported into management review with the same regularity as deviations and CAPAs, and that a change in headcount triggers a recalculation rather than an accumulation.

The MHRA’s practice of publishing GMP inspection deficiency data exists partly so that organizations can assess themselves against real findings as part of self-inspection and continuous improvement.¹³ Computerized systems have appeared consistently among the most cited deficiency groups across those published years, which is the strongest available argument for keeping the program properly resourced rather than allowing it to erode.¹⁴ The point of a risk-based interval model is not to do less work. It is to spend the available hours where the risk actually is, and to be able to say so.

Conclusion

Periodic review programs fail under staffing pressure because they were built on an unstated assumption about available hours, and nobody revisits the assumption when the hours change. The regulation was never the constraint. Annex 11 clause 11 asks for periodic evaluation confirming a valid state, sets no interval, and qualifies its content list with “where appropriate.” The draft revision goes further and asks explicitly for a frequency justified on risk to product quality, patient safety and data integrity. A program that assigns intervals by tier, groups the platform and vendor layer, and reduces the document to seven sections and a conclusion is not a lighter version of compliance. It is a closer reading of what compliance asks for.

The harder part is the conversation about what is already overdue, and there the only credible position is the accurate one. Know the number, assess what it means, raise it through the quality system, and bring a plan whose arithmetic works. An inspector who finds a backlog you have measured, risk-assessed and are visibly closing is looking at a functioning quality system under strain. An inspector who finds a backlog you had not counted is looking at something else.

Sakara Digital works with pharma and biotech organizations redesigning computerized system oversight to fit the teams they actually have. If you are looking at a review schedule that no longer matches your capacity, and you want an independent view of where the intervals can defensibly move and where they cannot, we are happy to have that conversation.

For Further Reading