Release starts the operational part of assurance
A released system changes through supplier updates, configuration changes, user access, interfaces, data growth, incidents, and business use. Assign owners who can recognize when the original evidence no longer supports the current use.
Change control
Describe what changes and what it could affect. Consider shared components and indirect effects. A new field may appear cosmetic until it becomes an input to routing. Use the assessment to select evidence, training, deployment controls, and rollback or recovery arrangements.
Example: Adding a mandatory CAPA product-family field changes existing records, imports, and routing. Check old records, bulk upload behavior, blank values, and the transition process. Testing only a newly created CAPA leaves gaps.
Emergency changes
An urgent production problem may require an accelerated process. Keep the change authorized and traceable. Identify immediate evidence, temporary controls, retrospective activities allowed by the approved procedure, responsible owners, and completion dates.
Example: An interface outage requires a temporary manual transfer. Define which records are transferred, who verifies them, how duplicate entry is prevented, and how reconciliation occurs when the interface returns. A general instruction to “work manually” leaves significant ambiguity.
Access review
Check whether people still need their permissions and whether roles reflect current responsibilities. Include privileged and service accounts, inactive identities, external support, and combinations of permissions that undermine separation of duties.
Example: A former quality reviewer moves to IT support but retains approval access. The account is active and the person is employed, yet the permission may no longer be appropriate. An employment-only check misses this issue.
Backup and restoration
Define recovery needs with the process owner. Test that restored information is usable, complete for its purpose, and connected to the necessary configuration and relationships. A successful backup job is evidence that a job ran; recovery evidence establishes something different.
Example: Restore a CAPA with attachments, linked changes, approvals, and history into an authorized test environment. Confirm retrieval and interpretation, not just file counts. Protect sensitive data during recovery testing.
Periodic review
Use a review interval justified by the system and applicable procedures. Examine changes, incidents, overdue actions, access, supplier status, performance, restore evidence, emerging uses, and whether controls still work. Avoid declaring “validated state maintained” without explaining the basis.
Completed review conclusion — fictional: “The approved uses remain unchanged. Two supplier releases were assessed; the updated report engine required additional export checks, completed without unresolved findings. One access-review action remains and has a temporary restriction. Recovery evidence supports the defined archive retrieval use. The next review will also assess the planned identity-provider change.”
Decommissioning
Identify what must remain available, how long, who owns retrieval, and how meaning and relationships will be preserved. Resolve integrations and access before retirement. Test retrieval without depending on a service that will be terminated.
Exercise: All PDFs have been exported. Is the legacy system ready to shut down?
Answer: Not necessarily. Check record completeness, relevant metadata and history, signature meaning and linkage, relationships, retention, search, retrieval, and the ability to interpret records after the old service disappears.