Five questions
- What changed?
- Why?
- What validated functions are affected?
- What testing is required?
- What documentation or training must change?
Common changes
| Change | Start the assessment here |
|---|---|
| Configuration change | Rules, permissions, workflows and open records |
| Software upgrade | Changed functions, shared components and known issues |
| Interface change | Mapping, data meaning, sequence, exceptions and recovery |
| Infrastructure change | Availability, performance, access and recovery |
| SaaS release | Release notes, configuration impact and supplier evidence |
| Security patch | Affected components, identity, interfaces and operational continuity |
Keep the decision proportionate
Trace the change to affected functions and dependencies. Use existing evidence where suitable, record the local checks needed and define release conditions. Update procedures or training when the way people use or control the system changes.
Detailed practice, examples and references
Start with the affected use
A change label such as minor, major, standard, or emergency helps route the record, but it does not determine testing by itself. Describe the change and its reason, then identify the approved intended use, affected GxP functions, records, interfaces, data, roles, security controls, procedures, and open transactions.
Minimum change-impact record
| Assessment field | What to document |
|---|---|
| Change description and reason | Current behavior, proposed behavior, components, configuration items, supplier release, defect, or urgent condition |
| GxP impact | Regulated process, decision, calculation, control, or record that can be affected |
| Functional risk assessment | Failure scenario, process effect, consequence, existing controls, detectability, and remaining risk |
| Configuration, interface, and data impact | Changed rules, integrations, mappings, transformations, open records, migrations, or reports |
| Electronic records and signatures | Record meaning, audit trail, signature manifestation, record linking, retention, and accurate copy |
| Security and access | Roles, privileged access, identity, segregation of duties, and service accounts |
| Evidence and regression scope | Supplier evidence accepted, local tests, exploratory charters, automated checks, and exclusions |
| Readiness | Documentation, procedure, training, deployment, rollback, monitoring, approval, and post-implementation review |
Four completed fictional examples
| Change | Affected function and risk | Proportionate validation approach | Release conclusion |
|---|---|---|---|
| Minor configuration: add a non-GxP dashboard column | Presentation only; no calculation, status, workflow, record, or export change | Configuration review, display check with representative roles, accessibility confirmation | Approved after expected display and permissions are confirmed; no broad regression |
| Major workflow: revise CAPA closure routing | A required Quality approval could be bypassed for legacy blank site values | Script every material branch and unauthorized transition; explore interruption, concurrent review, API path, and open-record transition | Restricted until the legacy condition is corrected and targeted regression passes |
| Supplier SaaS release | Routing engine and signed-record export changed; dashboard color also changed | Use release notes and supplier regression for standard behavior; locally test configured routing and signature meaning; perform usability check for color | Approve only the supported functions after deviations close; do not apply one regression package to all three changes |
| Emergency security change | Identity provider certificate expires and can block access; urgent production change is required | Record emergency rationale and temporary controls; verify authorized login, privileged access, signature reauthentication, service accounts, and recovery; complete retrospective review | Time-limited approval with monitoring and post-implementation Quality review |
Selecting regression scope
Trace each changed component to affected GxP functions and shared dependencies. Include unchanged functions only when the change can influence them through shared workflow engines, identity services, data models, interfaces, libraries, infrastructure, or open-state transitions. Record why excluded tests do not answer a remaining risk question.
Release and post-implementation review
Release approval should identify the implemented version, completed evidence, deviations, residual risk, restrictions, rollback or recovery readiness, required training, monitoring window, and accountable approvers. A post-implementation review is useful when production-only conditions, data volume, integrations, or emergency timing leave uncertainty that cannot be reproduced safely before release.
Reassessment criteria
Reassess when intended use, workflow, configuration, interface, data model, record or signature behavior, identity service, supplier version, known issue, operating environment, or monitoring result changes.
Regulatory and procedural context
Primary sources. FDA CSA guidance ↗ describes risk-based assurance for production and quality-management-system software. 21 CFR Part 11 ↗ addresses change control over systems documentation and controls for relevant electronic records and signatures.
Company procedure. The organization’s approved validation, change-control, supplier-management, information-security, data-integrity, records-retention, and Quality approval procedures determine the required records, roles, and approval route.
CSVtoCSA practitioner interpretation. Testing depth should follow the affected function and credible failure, not the administrative change category. This is a recommended validation approach, not a statement that every listed activity is a direct regulatory requirement.
Practitioner guidance by Sandip Thorat · Simplified 17 September 2026. Apply the requirements and approved procedures relevant to your system. Report a correction.
Questions and discussion
Ask a question or share a perspective. Contributions are reviewed before publication.
Loading contribution options…