Form: Validation Project Scope and Requirement Change Log

This is a ready-to-use log for capturing a scope or requirement change requested during an active validation project, before the system is released and post-release change control (governed separately, see change control for validated systems) takes over. Its purpose is to stop verbal, undocumented scope changes from entering a project quietly and shipping untested. Replace every <<FILL: ...>> placeholder, log every request the day it is made, and route each through impact assessment before deciding. A worked filled specimen follows the template.

Document control header

1. Purpose

Any addition, removal, or modification of scope after the validation plan, URS, and risk assessment are baselined carries two risks: it consumes schedule and effort that were not planned, and it may introduce a requirement, and therefore a function, that is never risk-assessed or never tested. This log makes every such request visible, assessed, and decided in writing, so the project’s baselined documents and the system that actually ships stay in agreement.

2. Change request log

3. Impact assessment (complete for each request before a decision is made)

For every request, answer before deciding:

1. Which deliverables change (URS, functional/configuration spec, risk assessment, test cases, traceability matrix)?
2. What is the effort and schedule impact, stated in real days, not “small”?
3. Does the change introduce risk that was not covered by the existing risk assessment? If yes, the risk assessment must be updated, not just the requirement.
4. Does the change affect any test case already executed? If yes, that test case is invalidated and must be re-executed against the updated baseline.
5. Is there a safe way to defer the change to a controlled post-go-live item instead of absorbing it now?

4. Decision rule

Scope tradeoffs (schedule, cost, resourcing) are a sponsor decision. Quality tradeoffs are a QA decision, and most quality tradeoffs are simply not available: a change that would ship untested function is not something the sponsor can approve around QA.

5. Acceptance criteria

• Every scope or requirement change raised during the project appears in this log; none are handled by email or verbal agreement alone.
• Every accepted change has its affected documents updated and re-baselined before further testing proceeds against it.
• Every test case invalidated by an accepted change is re-executed, and the traceability matrix is updated to reflect the current baseline.
• No change is silently absorbed into the build without a logged decision, regardless of how small it appears.
• Deferred changes are documented as a controlled backlog item, not simply dropped.

6. References

GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems, Second Edition (ISPE), for the expectation that requirements, risk, and test evidence remain aligned throughout the lifecycle. ICH Q9, Quality Risk Management, for reassessing risk when scope changes.

Confirm the current version of each reference before issue.

7. Revision history

Filled specimen

The following shows two example entries from a configured LIMS project, so you can see the level of detail expected. The system and names are illustrative; replace them with your own.

SC-004 was accepted because it affects a data integrity control point, so the risk assessment, an OQ test case, and the requirement were all updated together and the new case was executed before OQ was declared complete. SC-005 was deferred because it is cosmetic, does not affect fitness for intended use, and was logged as backlog item BL-2026-009 for the next release rather than consuming project schedule.

Common inspection findings this log prevents

• Function found in production that was never in the URS or the risk assessment because it was added mid-project with no re-baseline.
• A requirement changed after the risk assessment or traceability matrix was completed, so the change was never risk-assessed or tested.
• A “quick” scope addition accepted verbally that later cannot be traced to any approval or impact assessment.
• Test cases executed against a superseded requirement because the baseline moved after the test was designed and nobody re-executed it.

How to adapt this log

1. Set the project and log owner in the header.
2. Log every request the day it is raised, including ones you expect to reject; a rejected request with a documented rationale is itself useful evidence that scope was controlled.
3. Route every accepted change back through section 3’s impact assessment before touching the build or the documents.
4. Keep this log open for the life of the project and close it out (or roll unresolved items into post-go-live change control) at the same time the validation summary report is finalized.