Navata
← All Library

Validation & Evidence

When Can a GxP System Be Released with Open Defects?

AI-assisted research and drafting · Practitioner reviewed by Rohith Karanam Sreedhar · 16 September 2026

ⓘ Library content is researched and drafted with AI assistance and reviewed by a Navata practitioner before publication. For original analysis and long-form practitioner perspectives, visit Navata Insights →

A zero-defect release is not always realistic, but "known issue" is not a regulatory category that makes a defect harmless. The release decision must show which intended-use claims remain supportable despite the unresolved condition.

Start from consequence, not severity label

Defect labels differ across organisations. A "medium" defect in a vendor tool can still be release-blocking if it affects a critical local requirement. Assess the actual consequence for the regulated process.

Ask whether the defect can affect data integrity, identity, calculation, required approval, access control, interface completeness, audit evidence, record retention or another relied-upon control. Identify the affected users, records, time window and operating conditions.

Separate critical failures from tolerable limitations

EMA's guideline on computerised systems and electronic data in clinical trials states that failures to meet requirements predefined as critical should be solved or have mitigating actions implemented before deployment. It also says open deviations and known issues at release should be assessed and the resulting decisions documented in the validation report and, where applicable, release notes.

That is a useful release-decision pattern within the guideline's clinical-trial scope. It does not mean every open issue is acceptable once it appears in a report.

A defect should block release where it leaves a critical claim unsupported and no effective mitigation can contain the consequence. Examples include an uncontrolled permission path, unreliable calculation, missing required audit evidence or loss of regulated records.

Test the mitigation as a control

If the release depends on a workaround, manual check, restricted role, disabled feature or monitoring step, treat that mitigation as part of the operating control. Show that it can be performed reliably, that the responsible people know when to use it and that it detects or prevents the relevant failure.

A mitigation that exists only in a meeting note is not an effective control. If a manual review is required for every affected record, capacity and detectability matter. If a feature is disabled, prove it cannot be used inadvertently.

Record residual risk and authority

The release record should identify the defect, affected requirement or claim, evidence reviewed, mitigation, residual risk, named owner, target closure and the person or role authorised to accept the residual condition.

ICH Q9(R1) distinguishes risk assessment, control, acceptance, communication and review. Using that structure for a system-release defect decision is practitioner application of Q9 principles, not a Q9 software-validation procedure.

Preserve the defect after go-live

Do not let release acceptance close the issue administratively unless the technical or procedural condition is actually resolved. Keep the defect traceable to the change, validation evidence, mitigation and eventual fix.

Define triggers for re-evaluation: increased frequency, a related incident, evidence the workaround is not effective, a new population exposed to the issue, a platform change or a delayed closure that changes the risk picture.

Distinguish release from validated-state maintenance

Release is a point-in-time decision. The accepted condition becomes part of the system's operating risk profile and should remain visible to change control, periodic review and incident assessment.

EU GMP Annex 11 requires a risk-based lifecycle for computerised systems. It does not provide a numeric threshold of permissible open defects. The organisation has to justify the current state against intended use and applicable controls.

Important boundaries

The detailed open-deviation language cited here comes from EMA's clinical-trial computerised-systems guideline. Annex 11 and ICH Q9 provide broader GMP and quality-risk principles but do not prescribe a universal defect-severity matrix. Local quality procedures may be stricter.

Sources