18.3 Change Control, Configuration Management, V&V
Key Takeaways
- Change control is the formal process to propose, evaluate, approve, implement, and verify changes so unintended effects do not escape.
- Configuration management identifies, controls, and tracks the baseline of hardware, software, documents, products, processes, and services so the as-built matches the as-designed/as-approved.
- Verification asks “Did we build/do it right against specifications?”; validation asks “Did we build/do the right thing for user needs/intended use?”
- Qualifications (IQ/OQ/PQ or equivalent) provide documented evidence that equipment, systems, and processes are installed, operate, and perform as required in the intended environment.
- Auditors analyze change records for impact assessment, approvals, V&V evidence, training, document updates, and post-change monitoring—not just a signature on a form.
18.3 Change Control, Configuration Management, V&V (CQA BoK V.F–G — Understand/Analyze)
/practice/cqaPractice questions with detailed explanations
Uncontrolled change is a leading root of quality escapes, audit findings, and regulatory action. Domain V.F–G expects you to understand change and configuration concepts and analyze whether evidence shows control—across products, processes, services, hardware, and software.
Change control — the managed decision path
Change control (engineering change, process change, document change, supplier change, software change) is the system that ensures modifications are:
- Requested with clear description and reason
- Impact-assessed (quality, regulatory, safety, cost, validation, customers, labeling, training, inventory)
- Reviewed and approved by authorized roles
- Implemented under controlled conditions
- Verified / validated as needed
- Communicated and documented
- Monitored after release for unintended effects
Scope examples auditors encounter
| Change type | Example | Typical risks if uncontrolled |
|---|---|---|
| Product / design | Material alternate, tolerance change | Fitness for use, reliability, regulatory filing |
| Process | New machine, parameter shift, line transfer | Capability, yield, latent defects |
| Document | Spec revision, SOP rewrite | Training lag, dual procedures |
| Supplier | New source, site move | Incoming quality, CoC integrity |
| Software | Patch, feature release, library update | Cybersecurity, data integrity, regression |
| Service | New delivery method, outsourced step | Customer experience, SLA, privacy |
Analyze-level auditor focus
Do not stop at “there is a form.” Analyze:
- Was impact assessment substantive or checkbox?
- Were affected documents revised and obsolete versions removed?
- Was training completed before effective date?
- Were customer / regulatory notifications required and done?
- Is there objective evidence of verification or validation proportional to risk?
- Were in-process inventory and field product assessed?
- For temporary changes / deviations: time limits, approvals, and closeout?
Scenario — change control failure
A plant “temporarily” increases cure temperature to recover throughput. No change request, no impact on material properties, no update to the validated process range. Field failures appear months later. The CAPA later cites failure to follow change control—a classic system finding, not only an operator error.
Configuration management (CM)
Configuration management maintains integrity of the product/system definition over time. Core activities (classic CM view):
| CM activity | Meaning |
|---|---|
| Configuration identification | Define items, baselines, version/part numbers, BOMs |
| Configuration control | Control changes to baselines (tight link to change control) |
| Configuration status accounting | Know what version is approved, built, installed, released |
| Configuration audit | Verify as-built / as-installed matches baseline (functional & physical) |
Hardware and products
- Part numbers, revision levels, BOMs, drawings, approved manufacturer lists
- Traceability from serial/lot to configuration
- Spare parts and field upgrades matching approved configs
Software (including security)
Software CM is non-negotiable for quality and security:
- Version control, release notes, build provenance
- Controlled promotion (dev → test → production)
- Access control, code review, segregation of duties
- Patch management and vulnerability remediation with regression testing
- Backup/restore and disaster recovery configuration
- Protection of electronic records and audit trails where applicable
Auditors of computerized systems look for unauthorized production changes, missing validation of patches, and configuration drift between documented and actual server/application settings.
Processes and services
Process “configuration” includes controlled parameters, recipes, work instructions, tooling IDs, and service scripts. Service CM may cover rate cards, approved scripts, knowledge-base articles, and third-party tool versions used in delivery.
| Domain | CM artifact examples | Audit question |
|---|---|---|
| Hardware | Drawing rev, BOM, serial config | Does as-built match released BOM? |
| Software | Version, commit hash, config files | Can they prove what runs in production? |
| Process | Recipe ID, parameter set, WI rev | Was the validated recipe the one used? |
| Service | Playbook version, tool build | Are agents using current controlled content? |
Verification vs validation
These terms are exam favorites. Keep them clean.
Verification
Verification confirms that outputs meet specified requirements. Question: “Did we build / implement it right?”
Examples:
- Design verification tests against design inputs/specs
- Inspection and test to drawing tolerances
- Code review and unit tests against software requirements
- IQ/OQ-style checks that equipment meets installation and operational specs
- Document review verifying procedure steps match standard clauses
Validation
Validation confirms that the product, process, or system meets user needs and intended use in the real operating context. Question: “Did we build / implement the right thing?”
Examples:
- Clinical / user validation of a device for intended use
- Process validation that the commercial process consistently produces acceptable product
- Software user-acceptance testing in a realistic environment
- Service validation that the redesigned workflow meets customer outcome metrics
| Dimension | Verification | Validation |
|---|---|---|
| Focus | Specifications / requirements | Intended use / user needs |
| Classic question | Build it right? | Build the right thing? |
| Timing | Often earlier / throughout development | Often later / under real use conditions |
| Example | Dimensional test to drawing | Customer usability / clinical performance |
| Failure mode | Spec wrong but tests pass | Specs met but users still fail to achieve intent |
Scenario — both required
A software update to a quality record system:
- Verification: unit tests, requirements traceability, security scans, IQ/OQ of the installed instance.
- Validation: UAT with real roles (QA, production) confirming the workflow supports intended use and data integrity under production-like load.
Skipping validation after “all tests passed” can still leave a system unusable or unsafe in practice.
Qualifications needed (IQ, OQ, PQ and analogs)
Qualification provides documented evidence that equipment, facilities, utilities, or systems are suitable. Common staged model (life sciences and widely borrowed elsewhere):
| Stage | Name | Core idea |
|---|---|---|
| IQ | Installation Qualification | Installed correctly per specs; utilities, IDs, documentation, calibration hooks |
| OQ | Operational Qualification | Operates across intended ranges; alarms, interlocks, functions work |
| PQ | Performance Qualification | Performs consistently in routine use with real or simulated product/load |
Related concepts:
- Process validation (often IQ/OQ/PQ of process equipment + process performance qualification)
- Computer system validation (CSV) / GAMP-style risk-based validation
- Requalification after major change, move, or defined interval
- Commissioning as engineering readiness feeding formal qualification
Auditor analysis points
- Protocols pre-approved with clear acceptance criteria?
- Deviations to qualification handled and justified?
- Traceability from requirements → tests → results?
- Change after qualification triggers impact assessment and partial/full requal?
- Training and SOPs effective concurrent with go-live?
Integrating change control + CM + V&V
A mature system treats these as one story:
- Identify current configuration baseline.
- Propose change with risk/impact (including security for software).
- Decide verification, validation, and qualification needs.
- Execute testing/qual under approved protocols.
- Update configuration status, documents, training, labels.
- Release only when evidence complete.
- Monitor post-change metrics and complaints.
Mini case for analysis
A contract manufacturer changes sterilization parameters. Change request exists and is signed, but:
- No bioburden/impact scientific rationale
- No update to process validation summary
- Software recipe version in the PLC not updated in CM records
- Training matrix still lists old parameters
Findings analysis: change control incomplete; configuration status accounting broken; validation not demonstrated; training ineffective. Multiple BoK V.F–G issues from one event.
Audit application checklist
- Sample closed changes—high risk first (process, software security, sterile, labeling).
- Read impact assessments for substance.
- Trace configuration: what was approved vs what is installed/running.
- Separate verification evidence from validation evidence in the package.
- Confirm qualifications/requalifications proportional to change.
- Check temporary changes and emergency changes for retrospective control.
- For software: access logs, release tickets, security patches, and segregation of duties.
Common exam traps
- Treating verification and validation as synonyms
- Assuming a signature equals impact assessment
- Forgetting software security as part of configuration/change control
- Believing IQ alone is process validation
- Ignoring document and training updates as part of change
- Thinking configuration management is only for aerospace hardware
Link forward
A team runs tests confirming a redesigned pump meets all dimensional and performance specifications on the drawing. Separately, clinical users confirm the pump supports the intended therapy in real use. Which pairing is correct?
An auditor finds production servers running a software build that does not match the released version list, and a security patch was applied overnight without a change ticket. This most directly indicates weakness in:
Which statement best describes Installation Qualification (IQ)?
When analyzing a process change package, which set of evidence best supports that change control was effective—not merely signed?