Essential steps for pharma software compliance in the operational phase

Concept and project phase 

Initially, during the concept phase, the need for a computerized system is identified, and user requirements are defined. Next, in the project phase, the system is developed, validated, and deployed in line with pharma regulatory standards and best practices. 

Figure 1: computerized system lifecycle. 

Operational phase 

Upon entering the operational phase, the system actively supports business processes. This phase involves ongoing maintenance, monitoring, and periodic reviews to ensure the system’s continued performance and compliance with regulatory requirements. Activities here include periodic reviews, audit trail review, data integrity assessments, and software change management. 

Throughout the operational phase, the system is continuously monitored for performance, security, and compliance. Regular backups and disaster recovery plans safeguard data integrity and ensure business continuity.  

Additionally, any system changes—whether software updates or modifications to business processes—are validated to confirm they do not compromise system functionality or regulatory compliance. 

Retirement phase 

As the system reaches the end of its operational lifespan, the retirement phase begins, involving orderly decommissioning through data migration, archiving, and disposal as per regulatory requirements. Documentation of the lifecycle, including validation records and retirement plans, is maintained for regulatory purposes. 

Handover and project closure activities  

Handover and project closure activities are essential in transitioning from the project phase to the operational phase of a system's lifecycle. During handover, project teams transfer responsibility for the system to operational teams, including documentation, training, and support to equip operational staff with the knowledge and resources needed to manage the system effectively.  

Project closure activities involve completing final documentation, post-implementation reviews, and obtaining stakeholder sign-off to officially close out the project. Managing the handover and closure process carefully ensures a smooth transition to the operational phase and sets the stage for successful long-term system management. 

Rollout activities  

Rollout activities in the operational phase involve systematically deploying the computerized system across the organization. This process includes user training, data migration, system configuration, and support readiness to ensure a seamless transition from testing environments to full production.  

Rollout activities also cover communication strategies to inform stakeholders about system availability, features, and support channels, as well as monitoring and feedback mechanisms to track system performance, user satisfaction, and any issues. By planning and executing rollout activities carefully, organizations can minimize disruptions, maximize user adoption, and integrate the system into daily operations successfully. 

Operational change control 

Operational change control involves managing and implementing changes to computerized systems in a controlled manner to minimize risks and disruptions. Change control procedures include assessing proposed changes' impact, obtaining stakeholder approval, and documenting changes and their outcomes. This ensures system changes are implemented smoothly without negatively impacting system functionality or compliance. 

Pharma software is likely to undergo changes, such as configuration adjustments, version updates, or new module installations. These changes must be evaluated for their impact on data integrity, patient safety, or product quality to determine if revalidation is needed. Risk assessments may need updating to reflect changes. If revalidation is required, regression testing based on risk is important. 

SaaS release evaluation 

Software as a Service (SaaS) refers to a cloud-based software delivery model where applications are hosted and maintained by a third-party provider and accessed remotely by users over the internet. 

When a SaaS provider pushes a new release, users may relinquish control over update timing and content. Unlike on-premises software, where users can schedule and customize updates to suit their needs, SaaS updates are often deployed automatically by the provider (typically with a 1- to 2-month notice). 

 This lack of control can lead to potential disruptions, as users may encounter unfamiliar features, changes in functionality, or unexpected bugs. While SaaS providers aim to enhance user experience and address security vulnerabilities, the lack of control over updates can challenge users' ability to adapt seamlessly. 

Therefore, SaaS release evaluation is a critical process for organizations utilizing SaaS solutions. When a new release or update is introduced, it’s essential to evaluate (via change control) its impact on operations, data integrity, and security. This evaluation includes assessing the new release's functionality, testing compatibility with existing configurations, and verifying compliance with regulatory requirements. 

A new release does not necessarily require revalidation. For example, if the update introduces a new module that the user does not intend to use, it does not impact the solution’s intended use, and no additional validation is required. 

Backup and restore testing 

Backing up data/records and their restoration ensures data integrity and availability in case of data loss (e.g., system failure, power loss, or data corruption). Implementing a backup and restore process—and regularly testing its effectiveness—is essential.  

This process involves verifying that data backups can be restored, read, and used, and checking backup integrity (without restoration). Systems with similar technologies can simplify testing: testing one system may allow extending results to others with shared technology. 

Testing frequency is based on risk assessments of the data produced. For software and configuration backups, frequency may differ from data records. Backups support system restoration in cases of disaster and rollout issues during change implementation. 

Business continuity management 

Business continuity planning involves developing strategies to ensure critical business operations can continue in emergencies. This includes identifying key processes, resources, and dependencies, implementing redundant systems, and conducting drills to test response capabilities. Regularly reviewing and testing business continuity processes help organizations adapt to evolving threats and changes, ensuring resilience. 

Testing these processes through drills helps identify areas for improvement and builds stakeholder confidence, preparing employees to respond effectively to disruptions and maintain critical operations. 

Audit trail review 

Audit trail review is crucial for maintaining data integrity and traceability within computerized systems. It involves regularly reviewing audit trails to detect any unauthorized or suspicious activities, ensuring the accuracy and reliability of electronic records. A robust audit trail review process strengthens data integrity controls and mitigates data manipulation risks. 

Audit trail review frequency should align with risk assessment. Non-critical data may be reviewed annually, while critical data requires more frequent review. High-risk data may even need continuous review. 

Periodic review 

Periodic Review ensures computerized systems remain in a validated status throughout the operational phase. This includes verifying that processes, documentation, user access, system administration, and backup/restore records remain up-to-date and compliant. 

Periodic review helps identify validation weaknesses by analyzing incident records, confirming that validation efforts are appropriate to system changes. The review frequency is based on system complexity, history, and understanding. It is common to perform periodic reviews annually after the initial handover.