Navata
← All Library

Validation & Evidence

How to Define GxP Regression Testing Scope After a System Change

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 →

Regression testing should answer one question: which assurance claims might no longer be trustworthy because this change occurred? A large test pack is not automatically safer if it repeats unaffected checks while missing the changed dependency.

Start with the actual change

Describe what changed at a level that can be traced. A label correction, lifecycle-state change, permission update, interface mapping, Java or low-code rule, platform release and data-model change do not create the same regression surface.

Record the changed component, old and new behaviour, affected environment, intended release and any assumptions used in the impact assessment. If the team cannot identify the technical or process delta, it cannot justify the regression boundary.

Trace consequences before selecting tests

Follow the change outward through the system and process. Check whether it can affect:

  • intended uses and critical requirements;
  • upstream inputs and downstream outputs;
  • calculations, reports or decision-support information;
  • role permissions and segregation boundaries;
  • interfaces and background automation;
  • exception, rejection and recovery paths;
  • regulated records, metadata and audit evidence.

This is dependency analysis, not a request to retest every nearby feature. The objective is to identify claims whose validity depends on something that changed.

Decide what evidence must be re-established

For each potentially affected claim, choose the evidence that would show the claim still holds. That may be a targeted scripted test, an automated regression case, a focused scenario, a configuration comparison, an interface reconciliation or another justified verification activity.

EMA's guideline on computerised systems and electronic data in clinical trials states that where previously passed scripts are not rerun alongside testing of fixes, this should be risk assessed and the rationale documented. That statement is specific to the guideline's clinical-trial scope, but it illustrates a useful evidence principle: omission from regression should itself be a reasoned decision, not an accident.

EU GMP Annex 11 requires a risk-based lifecycle approach to validation and control of computerised systems. It does not prescribe a universal regression percentage or mandatory test-pack size.

Reuse evidence only when its supporting conditions still hold

A previously passed test remains useful only if the conditions that made it representative still apply. Ask whether the relevant configuration, data, interface contract, role model, platform behaviour and operating procedure are unchanged in ways material to the claim.

Do not treat a historical PASS as permanent evidence. Equally, do not rerun a test merely because it exists. The decision is whether the old result still supports the current state.

Include indirect and negative effects

Regression gaps often appear at joins. A field change may affect a report filter. A permission change may alter who can perform a downstream action. A workflow change may alter an integration trigger. A fix may remove one failure while creating another at a boundary condition.

Include negative tests where the change could weaken a prohibition or exception control. A test pack that proves the happy path still works can miss the more important question of whether an action that should be blocked has become possible.

Keep a regression decision record

The retained record should identify the change, impact analysis, affected assurance claims, tests selected, tests deliberately not rerun and the rationale for each material exclusion. Link the record to failures, retests and final change acceptance.

ICH Q9(R1) supports proportionate, documented quality-risk decisions and ongoing risk review. Applying that principle to regression scope is practitioner interpretation; ICH Q9 does not prescribe a software regression method.

Important boundaries

The EMA source cited here is a clinical-trial computerised-systems guideline and should not be represented as a universal GMP software-testing rule. Annex 11 provides the GMP lifecycle and risk-management baseline, while local procedures and applicable regulations determine the required formality.

Sources