Computerized System Validation Deviations and Release

Computerized-system release is the controlled decision that a system is suitable for its intended GxP use and may enter production operation. It is not simply the approval of the final test protocol or confirmation that software has been installed.

The release decision should consider the complete body of validation evidence, including requirements coverage, test results, deviations, defects, migration results, interfaces, security access, procedures, training, backup and recovery, support readiness, and remaining risk.

Release should occur only after authorized personnel determine that the system can support the regulated business process reliably and that any unresolved items have been evaluated and formally accepted.

Purpose of the Release Process

The release process provides a documented transition from project or validation activities into controlled production use. It should confirm that:

• the approved intended use remains accurate;
• the production system matches the evaluated configuration;
• required validation activities are complete;
• requirements and risk controls have adequate evidence;
• deviations and defects have approved dispositions;
• migration and interfaces are accepted;
• users and support personnel are prepared;
• procedures are effective;
• security access is approved;
• records can be protected and recovered;
• operational responsibilities are assigned; and
• remaining risks are understood and accepted.

The release criteria should be established during Computerized System Validation Planning and Strategy, not invented at the end of the project.

The release package should present the evidence clearly enough for an independent approver to understand what was completed, what remains open, and why the system is considered suitable for use.

Validation Deviations, Discrepancies, and Defects

Unexpected results can occur during configuration, migration, testing, training, or release preparation. These results should be recorded and evaluated rather than informally corrected and removed from the validation record.

Organizations may use terms such as deviation, discrepancy, incident, anomaly, or defect differently. The governing procedure should define each term and apply it consistently.

A practical distinction is:

• A validation deviation or discrepancy is an unexpected result or departure from an approved instruction, specification, test step, or expected result.
• A defect is a confirmed problem in the system, configuration, design, interface, calculation, migration logic, or supporting component.

Not every deviation indicates a product defect. For example, a tester may use the wrong data set or omit a required screenshot. Conversely, a failed test may reveal that the application performs a calculation incorrectly or permits an unauthorized action.

The original result should remain visible in the validation record. Successful correction and retesting do not erase the failure that led to the investigation.

Recording Test Deviations

A validation deviation record should provide enough information to reconstruct what occurred. It should normally identify:

• the affected protocol and test step;
• the requirement, function, or control being evaluated;
• the expected result;
• the actual result;
• the date, environment, and system version;
• the tester and relevant user role;
• the data or records involved;
• available screenshots, logs, reports, or audit-trail evidence;
• immediate actions taken;
• preliminary impact;
• investigation or defect reference;
• correction and retesting requirements;
• final disposition; and
• required approvals.

Evidence should be retained before the environment, data, or configuration is changed. Relevant logs and audit trails may otherwise be overwritten or become difficult to interpret.

Discrepancy Classification

Classification helps determine the urgency, investigation depth, correction, retesting, escalation, and effect on release. It should be based on impact rather than only on the type of error. Classification should consider whether the discrepancy affects:

• patient safety;
• product quality;
• material or product status;
• a critical calculation;
• data integrity;
• record completeness;
• security or segregation of duties;
• audit trails or electronic signatures;
• interface accuracy;
• migration completeness;
• backup or restoration;
• regulatory compliance;
• a critical requirement; or
• the ability to perform the intended business process.

A useful classification model may include critical, major, and minor discrepancies, but the terms should be defined in the validation procedure.

A critical discrepancy may prevent release because it compromises a required control or creates an unacceptable risk. A minor documentation error may be corrected without extensive investigation when the error does not affect the execution, evidence, or conclusion.

Numerical scoring may support consistency, but it should not replace a written evaluation of the actual failure and its consequences.

Determining the Nature of the Problem

The investigation should determine whether the unexpected result arose from:

• an unclear or incorrect requirement;
• an incorrect specification;
• a software defect;
• incorrect configuration;
• custom code or calculation logic;
• interface mapping or transmission;
• migration logic or source-data quality;
• infrastructure or environment failure;
• incorrect test data;
• an inaccurate expected result;
• a test-script error;
• tester execution error;
• missing training;
• a procedural weakness;
• supplier documentation; or
• a combination of causes.

The conclusion should be supported by evidence. Labeling every unexpected result as “tester error” without examining the instructions, training, usability, system behavior, and available controls can conceal a recurring problem.

Root-Cause Analysis

The depth of root-cause analysis should reflect the significance and recurrence of the discrepancy.

A simple transcription error in a test record may require correction and documented verification. A failed security control, incorrect calculation, missing audit-trail event, or loss of migrated data requires a more detailed technical and process investigation.

Root-cause analysis should consider:

• why the failure occurred;
• why existing controls did not prevent it;
• whether the problem affects other functions or records;
• whether the problem exists in other environments;
• whether similar configurations are affected;
• whether the requirement or test strategy was inadequate;
• whether supplier action is required; and
• whether corrective or preventive action is appropriate.

Where the supplier owns the affected software or service, the supplier’s investigation may be used as supporting evidence. The regulated organization should still evaluate the supplier’s conclusion and its effect on the site-specific configuration and intended use.

Correction, Retesting, and Regression Testing

A correction should be implemented under appropriate configuration or change control. The correction may involve:

• revising a requirement or specification;
• changing configuration;
• correcting custom code;
• modifying an interface;
• correcting migration logic;
• revising a report or calculation;
• updating a procedure;
• improving training;
• correcting test data; or
• revising a test script or expected result.

Retesting should demonstrate that the corrected item now meets the approved requirement. It should use controlled test conditions and produce objective evidence.

Regression testing should determine whether the correction affected other functions, configurations, interfaces, calculations, reports, records, or controls. The regression scope should be based on the nature of the change and the affected system dependencies.

A test should not simply be repeated until it passes. The reason for the original failure should be understood, and the correction should be approved before retesting begins.

Unresolved and Deferred Items

Not every discrepancy must be corrected before release. However, every unresolved item should have a documented disposition. The assessment should identify:

• the affected requirement or process;
• the known or potential impact;
• the reason correction is being deferred;
• available workarounds;
• compensating controls;
• user or procedural restrictions;
• monitoring requirements;
• the owner of the open item;
• the target resolution date;
• the required corrective change; and
• the person authorized to accept the residual risk.

An unresolved item should not be accepted merely because the project schedule or planned launch date would otherwise be missed.

Deferral may be acceptable when the system remains capable of compliant operation and the risk is controlled. Missing critical data-integrity, security, product-quality, patient-safety, or recovery controls would normally prevent release.

Requirements Coverage and Traceability

Before release, the organization should confirm that approved requirements have adequate evidence.

Requirements Traceability and Validation Evidence should connect, as applicable:

• intended use;
• requirements;
• risk controls;
• functional and configuration specifications;
• supplier evidence;
• configuration records;
• test cases;
• test results;
• deviations;
• defects;
• migration evidence;
• procedures;
• training; and
• release conclusions.

The release review should identify requirements that are:

• fully verified;
• partially verified;
• covered through combined testing;
• supported by acceptable supplier evidence;
• not applicable;
• removed through approved change;
• deferred; or
• failed.

Missing traceability should be resolved or evaluated before release. A high percentage of completed tests does not demonstrate readiness if an untested requirement controls a critical calculation, security permission, interface, audit trail, or regulated record.

Supplier Documentation and Evidence

Supplier documentation can contribute to the release package when it has been assessed and found suitable. Relevant evidence may include:

• development and testing records;
• release notes;
• known-defect lists;
• installation or deployment records;
• architecture and security documentation;
• configuration guidance;
• service qualification evidence;
• certificate or compliance reports;
• backup and recovery information;
• disaster-recovery evidence; and
• supplier acceptance-test results.

Supplier evidence should be used according to the approach defined in Computerized System Supplier Assessment and Evidence Leverage.

Supplier documentation does not replace confirmation of the organization’s intended use, selected configuration, interfaces, migrated data, security roles, procedures, or production environment.

Known supplier defects should be reviewed for applicability. The release assessment should document whether each relevant defect has been corrected, mitigated, accepted, or determined not to affect the implemented system.

Data-Migration Acceptance

Where data are migrated, the release decision should include formal migration acceptance. The evidence should confirm that:

• the approved migration scope was completed;
• inclusion and exclusion rules were followed;
• required records and metadata were transferred;
• transformations and mappings were verified;
• counts and control totals were reconciled;
• sampled records passed content comparison;
• rejected and failed records were resolved;
• attachments and relationships remain associated correctly;
• required audit trails and signatures were addressed;
• source-system retention is defined; and
• migration exceptions have approved dispositions.

Migration acceptance should be based on the strategy described in Computerized System Data Migration Validation.

Completion of a migration tool run is not evidence that the migrated data are complete, accurate, readable, and suitable for regulated use.

Interface Readiness

Connected systems and interfaces should be ready before the production process depends on them. The release review should confirm:

• source and destination systems are available;
• approved mappings are implemented;
• service accounts and certificates are active;
• field formats, units, precision, and status values are correct;
• acknowledgments and error handling operate as intended;
• rejected, delayed, and duplicate transactions can be managed;
• reconciliation is available;
• interface monitoring is active;
• support ownership is assigned; and
• recovery procedures have been tested where appropriate.

Temporary manual transfers may support conditional release only when they are formally controlled, verified, reconciled, and limited to an approved period.

Interface controls are addressed further in Computerized System Interfaces and Data-Transfer Controls.

Access and Security Approval

Production access should be approved before users begin regulated work.

The release package should confirm that:

• user roles match approved responsibilities;
• least-privilege principles have been applied;
• segregation of duties is effective;
• administrator and privileged access is restricted;
• service accounts are controlled;
• authentication settings are approved;
• default and temporary accounts have been removed or secured;
• electronic-signature permissions are appropriate;
• remote access is controlled; and
• access-review responsibilities are established.

Development or testing accounts should not be carried into production without formal assessment and approval.

Where electronic records or signatures are used, the release evaluation should consider applicable controls under 21 CFR Part 11 and particularly the closed-system controls described in 21 CFR 11.10.

Procedures and Training

Procedures should be approved and effective when the system enters production use.

Depending on the system, procedures may address:

• routine operation;
• record creation and review;
• data correction;
• audit-trail review;
• electronic signatures;
• access administration;
• configuration management;
• incident management;
• backup and restoration;
• business continuity;
• interface failures;
• change control;
• periodic review; and
• system retirement.

Users, administrators, support personnel, and reviewers should complete the training required for their assigned roles. Training should cover not only how to operate the software but also how to recognize and respond to errors, incomplete transactions, security concerns, and data-integrity events.

Successful Computerized System End-to-End and User Acceptance Testing may provide evidence of operational readiness, but it does not replace required procedural training.

Backup, Restoration, and Business Continuity

A system should not be released without a defined method for protecting and recovering required records and configurations. Release readiness should confirm:

• what data, metadata, audit trails, and configuration are protected;
• the backup frequency and retention period;
• responsibility for monitoring backup completion;
• response to failed backups;
• availability of protected backup copies;
• restoration procedures;
• evidence that restoration works;
• recovery-time and recovery-point objectives;
• responsibilities during an outage;
• temporary business processes;
• delayed-transaction controls; and
• reconciliation after service restoration.

For cloud services, the supplier’s backup commitments should be distinguished from the organization’s restoration and business-continuity responsibilities.

These controls are discussed further in Backup, Restoration, Disaster Recovery, and Business Continuity.

Support Readiness

The operational support model should be active before release. Support readiness should include:

• named business and technical owners;
• service-desk or incident-reporting routes;
• escalation procedures;
• supplier contacts;
• severity definitions;
• support hours;
• response expectations;
• monitoring and alerting;
• known-error information;
• change-management responsibilities;
• cybersecurity incident escalation;
• license and certificate monitoring;
• capacity monitoring; and
• arrangements for emergency access.

Support personnel should understand which incidents may affect product quality, patient safety, data integrity, or regulated records and therefore require Quality involvement.

Controlled Configuration Baseline

The production configuration approved for release should be documented as the controlled baseline. The baseline may include:

• application and component versions;
• enabled modules;
• configuration settings;
• workflows and business rules;
• calculations;
• reports;
• interfaces;
• roles and permissions;
• audit-trail settings;
• electronic-signature settings;
• code tables and master data;
• custom code and scripts;
• infrastructure dependencies;
• certificates;
• deployment records; and
• approved configuration deviations.

The baseline provides the reference for future incident investigation, change assessment, regression testing, periodic review, and retirement.

The configuration actually deployed to production should match the configuration represented by the validation evidence. Differences should be reconciled before authorization.

Release-Readiness Review

The release-readiness review should bring together validation evidence and operational readiness. At minimum, the review should confirm:

Residual-Risk Acceptance

Residual risk is the risk remaining after corrections, technical controls, procedures, training, monitoring, and other mitigations have been applied.

The release record should explain:

• what risk remains;
• which process, requirement, or record is affected;
• why the risk is considered acceptable;
• which controls reduce the risk;
• how the controls will be monitored;
• who owns the remaining risk;
• when the decision will be reviewed; and
• who approved the acceptance.

Residual-risk acceptance should be made by personnel with authority for the affected business process and appropriate Quality oversight.

A statement such as “risk accepted” without the supporting rationale, controls, and ownership does not provide an adequate release decision.

Conditional Release

Conditional release permits limited production use while specified noncritical items remain open. It may be appropriate when:

• the system can perform the authorized intended use safely and compliantly;
• open items do not affect critical controls;
• restrictions are clearly defined;
• compensating controls are practical and effective;
• affected users are informed and trained;
• enhanced monitoring is active;
• open items have owners and deadlines; and
• withdrawal criteria are established.

Conditions may restrict:

• business processes;
• user groups;
• sites;
• products;
• modules;
• interfaces;
• transaction volumes;
• reports; or
• operating periods.

Conditional release should have a defined expiry or review date. It should not become an indefinite substitute for completing validation or correcting significant defects.

Quality Approval and Production Authorization

Quality approval and production authorization may be separate decisions. Quality approval confirms that:

• validation activities are complete or appropriately dispositioned;
• deviations and defects have been evaluated;
• requirements have adequate coverage;
• residual risks are acceptable;
• procedures and training are ready; and
• the system is suitable for its intended GxP use.

Production authorization permits the system to begin operational use. It may include:

• activating production access;
• enabling interfaces;
• scheduling the production deployment;
• switching from a legacy process;
• confirming business-owner acceptance;
• approving the migration cutover; and
• communicating the effective date.

The organization should define who can approve GxP suitability and who can authorize technical and business activation. The system should not be placed into production before all required approvals are complete.

FDA regulations assign the Quality Control Unit responsibility and authority to approve or reject procedures and records affecting drug quality under 21 CFR 211.22. Applicable written procedures and departures from them should also be controlled in accordance with 21 CFR 211.100.

Release Record

The approved release record should identify:

• the system and production environment;
• the released version and configuration;
• the intended use;
• the validation package;
• the release criteria;
• the status of each criterion;
• unresolved deviations and defects;
• applicable restrictions;
• accepted residual risks;
• required post-release actions;
• the effective release date;
• Quality approval;
• process-owner acceptance; and
• production authorization.

A short release memorandum may be sufficient for a simple, low-complexity system when it clearly references the supporting evidence. A complex or critical system may require a detailed validation summary report and formal readiness review.

Post-Release Monitoring

The first period of production use may receive enhanced monitoring, sometimes called stabilization or hypercare. Post-release monitoring may include:

• incidents and user-reported problems;
• failed or delayed interface transactions;
• security and access events;
• audit-trail exceptions;
• backup failures;
• calculation or reporting concerns;
• unexpected workflow behavior;
• data-quality problems;
• performance and capacity;
• supplier notifications;
• open-defect status; and
• effectiveness of temporary controls.

The monitoring period, responsible personnel, review frequency, and exit criteria should be defined before release.

Significant post-release findings should be evaluated through incident, deviation, and change-control processes. They may require correction, regression testing, revalidation, additional training, or temporary suspension of affected functions.

After stabilization, the system should enter normal lifecycle control, including Computerized System Change Control, Patching, and Revalidation and periodic review.

Practical Release Outcome

A complete release process demonstrates more than successful testing. It shows that the organization understands the system’s remaining limitations and is operationally prepared to control it. The final decision should establish:

• what system and configuration are authorized;
• which intended uses are approved;
• what validation evidence supports the decision;
• how deviations and defects were resolved;
• which items remain open;
• what restrictions or compensating controls apply;
• who accepted the residual risk;
• who approved GxP suitability;
• who authorized production use; and
• how the system will be monitored after release.

A computerized system is ready for release when both its validation evidence and its operating arrangements demonstrate that it can support the intended GxP process reliably, securely, and under continued control.