Form: Periodic Review Evidence Collection Worksheet

This is a ready-to-use worksheet. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route the completed worksheet with the review record through your normal document control and retention. A worked filled specimen follows the template so you can see how a completed version reads. Verify each cited regulation against the current source before you rely on it. This template is an educational reference for you to adapt to your own quality system, products, and regulatory context; it is not legal, regulatory, or professional advice. This worksheet is the working paper behind a periodic review, not the review itself. It exists because the failure mode of periodic review is almost never bad judgment. It is evidence that was requested late, or requested from the wrong function, or never received at all, with the gap invisible by the time the report is drafted because an empty section looks the same as a section with nothing to report. Recording the request date and the receipt date for every input makes a missing input show up as a missing input.

The governing procedure is SOP: Periodic Review of GxP Computerized Systems. The report this worksheet feeds is Periodic Review Report (Validated System).

Document control header

Review identification

Purpose of this form

To record, for one periodic review of one system or one approved group, every evidence input required by the governing procedure: what was requested, from whom, when it was requested, when it arrived, what record satisfies it, and how the reviewer assessed it. The completed worksheet is the audit trail of the review itself. It answers the question an inspector asks when a review section looks thin: did you look and find nothing, or did you not look.

Field definitions

Assessment values

“Not received” and “Not applicable” are different states and are never merged. That distinction is the whole point of the worksheet.

Completion instructions

1. Open the worksheet before you request anything. Fill the review identification block first, including the review period start date taken from the previous review’s period end. If those two dates do not meet, you have found a coverage gap before you have collected a single record; note it now.
2. Send every request in writing, on the same day where possible. Requests dribbled out over six weeks produce a review that stalls waiting on the last one. Record the request date as the date you sent it, not the date you meant to.
3. Name the system of record in every request. “Send me the access list” gets you a spreadsheet somebody typed. “Export the active user list for MES-PROD-01 from the identity management system, with role and last-login date, generated on or after the period end date” gets you evidence.
4. Record the record reference exactly as it appears on the evidence, including the generation date of any export. An export with no generation date cannot be tied to the review period later.
5. Do not assess a row until you have examined the underlying record. A summary email from the owning function saying “no issues” is a communication, not evidence, and is recorded as “not received” until the record arrives.
6. Chase anything outstanding at the interval set in the governing procedure, and record each chase in the comment field with its date. Two recorded chases and no evidence is a much stronger position than a blank row.
7. Assess every row. No row is left empty. If the input does not apply, mark it Not applicable and say why.
8. Record counts, not adjectives. “14 changes, all closed, all with validation impact assessments” is evidence of a review. “Change control looks fine” is not.
9. Escalate a Non-conformance when you find it, not when the worksheet is finished. The governing procedure sets the notification time. Waiting until the report is drafted wastes the days that matter most.
10. Do not erase or overwrite. If an assessment changes because further evidence arrived, add the revision in the comment with the date and your initials, and state what changed it. This worksheet follows the same documentation practice as any other GxP record.
11. Attach or index every piece of evidence to the review record so the report can cite it by reference rather than paraphrase it.

Retention

The worksheet

One row per evidence input. Rows 1 to 14 are the standard input set from the governing procedure; add system-specific rows at the end where the system warrants them.

Collection status summary

Complete this block before drafting the report. The report cannot conclude that the validated state is confirmed while any applicable input is outstanding.

References

EU GMP Annex 11, Computerised Systems, section 11 (periodic evaluation), which contemplates evaluation of matters including current functionality, deviation records, incidents, problems, upgrade history, performance, reliability, security, and validation status reports. EU GMP Annex 15, Qualification and Validation. 21 CFR Part 11 (electronic records and electronic signatures); 21 CFR 211.68, 211.180, 211.194. ICH Q9(R1), Quality Risk Management, for the risk-based depth applied to evidence collection. ISPE GAMP 5, Second Edition (2022), A Risk-Based Approach to Compliant GxP Computerized Systems. MHRA, ‘GxP’ Data Integrity Guidance and Definitions (2018). PIC/S PI 041, Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments.

Confirm the current version and clause numbers of each reference before issue.

Filled specimen

The following shows the worksheet completed for an example laboratory information management system, so you can see the level of detail an inspector expects. The company, system, and numbers are illustrative; replace them with your own.

In this example the worksheet did three things the report alone could not. It made the two leaver accounts visible on 09 April, five weeks before the report was due, so the accounts were disabled that day rather than after the paperwork finished. It recorded that the security evidence was requested, chased twice, and never produced, which turns an empty report section into a documented organizational gap with a name attached. And it separated “not applicable” from “not received”, so nobody reading the review later can mistake an unexamined input for a clean one.

Common inspection findings this form prevents

• A periodic review section is blank or reads “no issues”, with no way to tell whether the reviewer looked and found nothing or never looked at all.
• Evidence was requested so late that the review concluded on partial information, and the gap is invisible in the final report.
• The review cites “backups running” because the restore record was never actually requested from infrastructure.
• Access reconciliation is claimed but no access list export exists, so the claim rests on an administrator’s recollection.
• A configuration extract is cited with no generation date, so it cannot be tied to the review period.
• The report states data integrity is intact while the audit trail review records for part of the period were never produced.
• A finding was discovered early in evidence collection but not escalated until the report was issued weeks later.
• Prior-review actions were never requested from the CAPA system, so they were not carried forward.
• A supplier’s support status is asserted rather than evidenced, and the system turns out to be running an unsupported version.
• The reviewer’s assessment of each input is missing, so the conclusion cannot be traced to the evidence that produced it.

How to adapt this form

1. Set your form number, version, and governing procedure reference in the header, and align the input list to whatever your own periodic review SOP requires. The 14 rows here match the standard set; add or remove rows so the worksheet and the SOP never disagree.
2. Name the actual systems of record in the “evidence requested” column for your organization: your change management system, your identity management platform, your service desk, your CAPA system. A reviewer should not have to work out where evidence lives.
3. Name the owning function to a team, not to a department. “IT Infrastructure, storage and backup team” gets an answer. “IT” gets forwarded three times.
4. Set your own chase intervals in completion instruction 6 to match the lead time your SOP allows, and make the escalation path explicit.
5. Add system-specific rows where the system needs them: interface reconciliation reports, instrument connectivity checks, hosted service level reports for a SaaS system, chain of identity checks for a cell and gene therapy system, batch record reconciliation for a manufacturing execution system.
6. For a grouped review, run one worksheet per group for the common controls and one abbreviated worksheet per sampled member for the system-specific inputs, and reference the approved grouping rationale in the header.
7. Keep the worksheet with the review record for the same retention period. It is the working paper that proves the review had coverage, and it is the first thing worth producing when an inspector asks how a conclusion was reached.