Plan a periodic review of a validated system with checks for use, incidents, changes, access, data integrity, suppliers, and residual risk.
What is a periodic review?
A periodic review is a documented assessment of whether a validated system remains fit for its intended use. It uses operational evidence, not only the original validation package.
The review should consider what changed, what failed, who accessed the system, what the supplier released, and whether the process still matches the approved scope.
Periodic review checklist
| Area | Review evidence |
|---|---|
| Intended use | Current process, users, records, and system boundary |
| Changes | Approved changes, impact assessments, tests, and open actions |
| Incidents | Deviations, defects, complaints, and data-integrity events |
| Access | Role review, privileged access, and leaver removal |
| Supplier | Service changes, performance, incidents, and agreements |
| Continuity | Backup, restore, availability, and recovery evidence |
| Conclusion | Continued use, remediation, revalidation, or retirement |
How often should review happen?
Set the interval using risk, system criticality, change frequency, supplier model, data sensitivity, and operational history. A fixed calendar is useful, but a significant change, incident, or supplier event may trigger an earlier review.
The interval and trigger logic should be documented. A review that is late or never scheduled is itself a lifecycle signal.
What operational data matters?
Review deviations, incidents, service tickets, failed jobs, rejected approvals, audit-trail findings, access exceptions, backup tests, and training records. Look for patterns. Repeated small issues can indicate a control that needs redesign.
How should the conclusion be written?
State whether the system remains fit for intended use, what evidence supports the conclusion, what risks remain, and which actions are required. Possible outcomes include continued operation, targeted remediation, additional testing, a broader revalidation, or retirement planning.
A periodic review is a decision, not a filing exercise. It should tell the business what happens next.
Who should participate?
Include the system owner, process owner, quality, IT, validation, and subject-matter roles appropriate to the risk. Include supplier or security expertise when the service or issue requires it. Keep responsibilities and approvals visible.
What should the working record contain?
Keep the decision, evidence, and ownership together. A reviewer should be able to see the current baseline, the reason for the activity, the people who approved it, and the records that support the conclusion. Use stable identifiers for requirements, risks, tests, actions, and versions so a later review does not depend on one person's memory.
Good lifecycle records explain both the decision and its limits. Record assumptions, exclusions, unresolved questions, and the date when the conclusion should be revisited. This makes the next change or review faster without turning the file into a wall of generic text.
- State the system and process boundary.
- Link the activity to intended use and risk.
- Preserve original results and approved corrections.
- Assign an owner to every open action.
- Record the final decision and residual risk.
How can teams keep the process practical?
Use short decision gates instead of one large end-of-project review. At each gate, ask what is known, what remains open, who owns the next action, and whether the current risk is acceptable. This keeps the work moving while preserving an auditable trail.
Make the record useful to the people who operate the system. Link procedures, training, access decisions, and evidence to the same controlled item. When a future reviewer can understand the context without opening several disconnected folders, the lifecycle is doing its job.
Review the process after the first release. Operational experience often reveals a missing requirement, an unclear role, or a control that looked adequate on paper but is difficult to use. Feed those findings into the next controlled decision.
FAQ
Does a periodic review replace change control?
No. Change control handles individual changes. Periodic review checks the wider state of the system and its operating evidence.
What if nothing changed?
That is still a conclusion that should be supported by review of incidents, access, supplier updates, data integrity, and ongoing process use.
Can the review be risk based?
Yes. The scope and frequency should reflect the system's intended use and risk.
What happens when actions remain open?
Record owners, due dates, impact, interim controls, and the decision about whether continued use is acceptable.
Conclusion
Periodic review keeps the validation decision honest. Use operational evidence, assess change and risk, and record a clear next action.
Keep validation status current
Track periodic reviews, actions, changes, and evidence in one place.
Plan a periodic review →