This is a ready-to-use form for the specific moment a computerized system validation keeps running into: an already-approved requirement needs to change before the system goes live. Replace every <<FILL: ...>> placeholder with your own specifics, set your document and reference numbers, and route it through your normal change and document control. This form is not the same as a post-go-live change control record for a validated production system; it governs a change to a specification, still inside the validation project, before or shortly after the requirement was baselined. A worked filled specimen follows. Confirm each cited regulation against the current source before you rely on it.
Document control header
| Field | Entry |
|---|---|
| Form title | Requirement Change and Retraceability Impact Assessment |
| Form number | <<FILL: FORM-ID, e.g. FORM-CSV-009>> |
| Version | <<FILL: version, e.g. 1.0>> |
| Effective date | <<FILL: effective date>> |
| Controlling procedure | <<FILL: SOP-ID for requirements management or change control>> |
| Retention | Per records retention schedule, not less than <<FILL: retention period>> |
Section A. Change identification (completed by requestor)
| Field | Entry |
|---|---|
| Change reference | <<FILL: e.g. RCH-2026-0031>> |
| Date raised | <<FILL: date>> |
| Requestor (name, role) | <<FILL>> |
| Requirement(s) affected | <<FILL: URS/FS/DS ID(s), e.g. URS-021>> |
| Current approved wording | <<FILL: quote the wording exactly as baselined>> |
| Proposed wording | <<FILL: quote the proposed wording exactly>> |
| Reason for change | <<FILL: gap found in testing / regulatory clarification / vendor behavior differs from assumption / user need missed at elicitation>> |
| Project phase at time of request | <<FILL: pre-baseline / post-baseline, pre-test / mid-test / post-test, pre-go-live>> |
Do not edit the approved URS, FS, or DS document until this section is logged. A wording change made directly in the approved file with no reference number is the single most common finding this form exists to prevent.
Section B. RTM lookup (completed by Validation / CSV)
Pull every row linked to the affected requirement ID(s) directly from the current Requirements Traceability Matrix. Do not rely on memory or on what the requestor believes is downstream; the RTM is the source of truth for this section.
| Linked item | Item type | Current status |
|---|---|---|
<<FILL: e.g. FS-050>> | FS | <<FILL: drafted / approved>> |
<<FILL: e.g. DS-CAL-05>> | DS | <<FILL: drafted / approved>> |
<<FILL: e.g. OQ-141>> | Test case | <<FILL: not yet run / executed, Pass / executed, Fail>> |
<<FILL: add rows as needed>> |
If the RTM shows no linked items, record “no downstream items exist” and proceed directly to Section D; there is nothing to reassess for impact beyond the requirement document itself.
Section C. Impact assessment (completed by Validation / CSV, reviewed by QA)
Assess every row from Section B individually. Do not apply one blanket judgment to the whole requirement; a functional spec item and a database configuration item linked to the same requirement can carry different impact.
| Linked item | Impact of the proposed change | Action required | Basis for the decision |
|---|---|---|---|
<<FILL>> | None / Revise wording only / Revise behavior | No action / Revise, no retest / Revise and retest | <<FILL: why this action is sufficient>> |
<<FILL>> |
| Field | Entry |
|---|---|
| Overall impact conclusion | No impact / Low, revision only / High, retest required |
| GxP / data integrity requirement affected | Yes / No |
| Any item excluded from retest despite a prior link | <<FILL: item ID and the documented reason, or "none">> |
| Assessor (name, role, date) | <<FILL>> |
Section D. Re-approval
| Role | Name | Signature | Date | Required when |
|---|---|---|---|---|
| Requestor | <<FILL>> | Always | ||
| System / Process Owner | <<FILL>> | Wording or intent changes | ||
| Subject Matter Expert | <<FILL>> | Behavior changes | ||
| Quality Assurance | <<FILL>> | GxP-relevant requirement, or any retest required |
A wording clarification that does not change what the system must do may be approved by the original signatories alone; a change to what the system must do is re-approved with the same rigor as the original requirement, QA included.
Section E. Retest execution (complete only where Section C requires it)
| Field | Entry |
|---|---|
| Test case(s) revised or newly written | <<FILL: ID(s)>> |
| Prior result disposition | <<FILL: superseded, reference this change, or "not applicable, no prior execution">> |
| Retest protocol ID and execution date | <<FILL>> |
| Result | Pass / Pass with handled deviation / Fail |
| Independent reviewer (name, date) | <<FILL>> |
Section F. RTM update and closure
| Field | Entry |
|---|---|
| RTM updated to new baseline | Yes / No |
| Rows updated (item IDs) | <<FILL>> |
| Old test result(s) marked superseded, with this change reference | Yes / No / Not applicable |
| Forward and backward tracing re-checked after update | Yes / No |
| Related deviation, if any | <<FILL: number or N/A>> |
| QA closure (name, signature, date) | <<FILL>> |
This change is not closed until the RTM itself reflects it. A requirement, FS, or DS document that carries a new version number while the RTM still cites the old test as proof is an open change, not a closed one, whatever the file dates say.
Acceptance criteria
This record is complete and defensible when all of the following are true:
- The change was logged with a reference before the approved wording was altered anywhere.
- Section B was built from the live RTM, not from what the requestor remembered being downstream.
- Every linked item in Section C has an individually stated impact and action, with a documented basis, including anything excluded from retest.
- Re-approval in Section D matches the scope of the change and includes QA wherever the requirement is GxP-relevant.
- Where retest was required, Section E shows an independent review of the result, not a self-confirmed pass.
- The RTM is updated and re-checked for forward and backward tracing before Section F is signed closed.
References
EU GMP Annex 11, clause 4.4 (user requirements traceable through the life of the system) and section 10 (change and configuration management). GAMP 5, Second Edition (ISPE, 2022), on scaling verification effort to risk and maintaining traceability through change. 21 CFR Part 11; ICH Q9 and Q10.
Confirm the current version and clause numbers of each reference before issue.
Filled specimen
The following shows the form completed for an example potency-calculation requirement change discovered during OQ, so you can see the level of detail an inspector expects. The company, system, and numbers are illustrative; replace them with your own.
Section A
| Field | Entry |
|---|---|
| Change reference | RCH-2026-0031 |
| Requestor | J. Alvarez, QC Validation |
| Requirement affected | URS-021, “The system shall calculate and display the potency result to 2 decimal places.” |
| Proposed wording | ”The system shall calculate the potency result to 3 decimal places internally and display 2 decimal places, applying rounding only at display and reporting, never before the specification comparison.” |
| Reason for change | OQ testing found a result of 98.996 percent rounded to 99.00 before the specification check, masking a value that was, at full precision, below the 99.00 lower limit. |
| Project phase | Post-baseline, mid-test |
Section B
| Linked item | Item type | Current status |
|---|---|---|
| FS-050 | FS | Approved |
| DS-CAL-05 | DS | Approved |
| OQ-141 | Test case | Executed, Pass (against old wording) |
Section C
| Linked item | Impact | Action required | Basis |
|---|---|---|---|
| FS-050 | Revise behavior: rounding point moves from pre-comparison to display-only | Revise and retest | Calculation logic description changes, not just display formatting |
| DS-CAL-05 | Revise behavior: stored precision changes from 2 to 3 decimal places | Revise and retest | Underlying data element changes, affects downstream reports referencing this field |
| OQ-141 | Prior pass no longer proves current behavior | Revise and retest | The original test never exercised a borderline value at 3-decimal precision |
Overall impact conclusion: High, retest required. GxP requirement affected: Yes, this is a specification-comparison and release-decision calculation. No items excluded from retest.
Section D Requestor J. Alvarez 14 Sep; System Owner T. Okafor 15 Sep; SME (QC Manager) L. Brandt 15 Sep; QA R. Gomez 17 Sep 2026.
Section E OQ-141R written and executed 19 September 2026 against three challenge values, including a value at 98.996 that would have passed under the old 2-decimal rounding and correctly failed at full precision. Result: Pass. Reviewed by P. Rao, 19 September 2026.
Section F RTM updated: URS-021 v2, FS-050 v2, DS-CAL-05 v2, OQ-141 marked superseded referencing RCH-2026-0031, OQ-141R recorded as the current evidence. Forward and backward tracing re-checked, confirmed intact. No related deviation; the gap was caught in testing before go-live, not in production. QA closed by R. Gomez, 20 September 2026.
In this example, a rounding behavior that looked like a display detail turned out to be a release decision hiding an out-of-specification result. The impact assessment is what caught that it was not a cosmetic change, and the retest with a deliberately chosen borderline value is what proved the fix actually worked, rather than merely proved the system still ran.
Common inspection findings this form prevents
- An approved requirement edited in place with no change reference, so nothing shows a change ever happened.
- A requirement change treated as “small” and never checked against the RTM, missing a test case that had already passed against the old wording.
- A passed test kept on file as evidence for a requirement whose wording has since changed underneath it.
- Retesting applied inconsistently, either skipped on a change that needed it or applied blanket to items the impact assessment never actually touched.
- An RTM that still shows the pre-change baseline weeks after the requirement, FS, and DS documents were all reissued.
- Re-approval obtained from the original signatories only, for a change that altered system behavior rather than wording.
How to adapt this form
- Set your form number and controlling procedure in the header.
- If your organization maintains the RTM in a dedicated tool rather than a document, replace Section B with an exported extract or a direct link, but keep the requirement that it comes from the live matrix, not from memory.
- Align the re-approval roles in Section D with your own signatory matrix for specification documents.
- Where a change is discovered during PQ/UAT rather than OQ, route the retest reference in Section E to the relevant qualification stage instead.
- Confirm every regulation in the references against the current published version before issue.