manage-change-control
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseManage Change Control
变更控制管理
Evaluate, approve, implement, and verify changes to validated computerized systems while maintaining their validated state.
评估、审批、实施并核验已验证计算机化系统的变更，同时维持系统的已验证状态。
When to Use
适用场景
- A validated system requires a software upgrade, patch, or configuration change
- Infrastructure changes (server migration, OS upgrade, network change) affect validated systems
- A CAPA or audit finding requires system modification
- Business process changes require system reconfiguration
- Emergency changes need expedited approval and retrospective documentation
- 已验证系统需要进行软件升级、打补丁或配置变更
- 基础架构变更（服务器迁移、OS升级、网络变更）影响已验证系统
- CAPA或审计发现要求对系统进行修改
- 业务流程变更需要对系统重新配置
- 紧急变更需要加急审批和事后补录文档
Inputs
输入材料
- Required: Change description (what is changing and why)
- Required: System(s) affected and their current validated state
- Required: Change requestor and business justification
- Optional: Vendor release notes or technical documentation
- Optional: Related CAPA or audit finding references
- Optional: Existing validation documentation for affected system(s)
- 必填：变更描述（变更内容及原因）
- 必填：受影响的系统及其当前已验证状态
- 必填：变更请求人及业务合理性说明
- 可选：供应商发行说明或技术文档
- 可选：相关CAPA或审计发现参考
- 可选：受影响系统的现有验证文档
Procedure
操作流程
Step 1: Create and Classify the Change Request
步骤1：创建并分类变更请求
markdown
undefinedmarkdown
undefinedChange Request
Change Request
Document ID: CR-[SYS]-[YYYY]-[NNN]
Document ID: CR-[SYS]-[YYYY]-[NNN]
1. Change Description
1. Change Description
Requestor: [Name, Department]
Date: [YYYY-MM-DD]
System: [System name and version]
Current State: [Current configuration/version]
Proposed State: [Target configuration/version]
Requestor: [Name, Department]
Date: [YYYY-MM-DD]
System: [System name and version]
Current State: [Current configuration/version]
Proposed State: [Target configuration/version]
2. Justification
2. Justification
[Business, regulatory, or technical reason for the change]
[Business, regulatory, or technical reason for the change]
3. Classification
3. Classification
| Type | Definition | Approval Path | Timeline |
|---|---|---|---|
| Emergency | Urgent fix for safety, data integrity, or regulatory compliance | System owner + QA (retrospective CCB) | Implement immediately, document within 5 days |
| Standard | Planned change with potential impact on validated state | CCB approval before implementation | Per CCB schedule |
| Minor | Low-risk change with no impact on validated state | System owner approval | Documented before implementation |
This change is classified as: [Emergency / Standard / Minor]
Rationale: [Why this classification]
**Expected:** Change request has a unique ID, clear description, and justified classification.
**On failure:** If classification is disputed, default to Standard and let the CCB adjudicate.| Type | Definition | Approval Path | Timeline |
|---|---|---|---|
| Emergency | Urgent fix for safety, data integrity, or regulatory compliance | System owner + QA (retrospective CCB) | Implement immediately, document within 5 days |
| Standard | Planned change with potential impact on validated state | CCB approval before implementation | Per CCB schedule |
| Minor | Low-risk change with no impact on validated state | System owner approval | Documented before implementation |
This change is classified as: [Emergency / Standard / Minor]
Rationale: [Why this classification]
**预期结果**：变更请求具备唯一ID、清晰的描述以及合理的分类。
**失败处理**：如果分类存在争议，默认归为标准变更，交由CCB裁定。Step 2: Perform Impact Assessment
步骤2：开展影响评估
Evaluate the change against all dimensions of the validated state:
markdown
undefined对照已验证状态的所有维度评估变更影响：
markdown
undefinedImpact Assessment
Impact Assessment
Change Request: CR-[SYS]-[YYYY]-[NNN]
Change Request: CR-[SYS]-[YYYY]-[NNN]
Impact Matrix
Impact Matrix
| Dimension | Affected? | Details | Risk |
|---|---|---|---|
| Software configuration | Yes/No | [Specific parameters changing] | [H/M/L] |
| Source code | Yes/No | [Modules, functions, or scripts affected] | [H/M/L] |
| Database schema | Yes/No | [Tables, fields, constraints changing] | [H/M/L] |
| Infrastructure | Yes/No | [Servers, network, storage affected] | [H/M/L] |
| Interfaces | Yes/No | [Upstream/downstream system connections] | [H/M/L] |
| User access/roles | Yes/No | [Role changes, new access requirements] | [H/M/L] |
| SOPs/work instructions | Yes/No | [Procedures requiring update] | [H/M/L] |
| Training | Yes/No | [Users requiring retraining] | [H/M/L] |
| Data migration | Yes/No | [Data transformation or migration needed] | [H/M/L] |
| Audit trail | Yes/No | [Impact on audit trail continuity] | [H/M/L] |
| Dimension | Affected? | Details | Risk |
|---|---|---|---|
| Software configuration | Yes/No | [Specific parameters changing] | [H/M/L] |
| Source code | Yes/No | [Modules, functions, or scripts affected] | [H/M/L] |
| Database schema | Yes/No | [Tables, fields, constraints changing] | [H/M/L] |
| Infrastructure | Yes/No | [Servers, network, storage affected] | [H/M/L] |
| Interfaces | Yes/No | [Upstream/downstream system connections] | [H/M/L] |
| User access/roles | Yes/No | [Role changes, new access requirements] | [H/M/L] |
| SOPs/work instructions | Yes/No | [Procedures requiring update] | [H/M/L] |
| Training | Yes/No | [Users requiring retraining] | [H/M/L] |
| Data migration | Yes/No | [Data transformation or migration needed] | [H/M/L] |
| Audit trail | Yes/No | [Impact on audit trail continuity] | [H/M/L] |
Regulatory Impact
Regulatory Impact
- Change affects 21 CFR Part 11 controls
- Change affects EU Annex 11 controls
- Change affects data integrity (ALCOA+)
- Change requires regulatory notification
**Expected:** Every dimension is assessed with a clear yes/no and rationale.
**On failure:** If impact cannot be determined without testing, classify the dimension as "Unknown — requires investigation" and mandate a sandbox evaluation before production change.- Change affects 21 CFR Part 11 controls
- Change affects EU Annex 11 controls
- Change affects data integrity (ALCOA+)
- Change requires regulatory notification
**预期结果**：每个维度都已完成评估，给出明确的是/否结论及理由。
**失败处理**：如果不经过测试就无法确定影响，将该维度标记为「未知——需要调研」，要求在生产环境变更前先在沙箱环境完成评估。Step 3: Determine Revalidation Scope
步骤3：确定再验证范围
Based on the impact assessment, define what validation activities are needed:
markdown
undefined基于影响评估结果，明确需要开展的验证活动：
markdown
undefinedRevalidation Determination
Revalidation Determination
| Revalidation Level | Criteria | Activities Required |
|---|---|---|
| Full revalidation | Core functionality changed, new GAMP category, or major version upgrade | URS review, RA update, IQ, OQ, PQ, TM update, VSR |
| Partial revalidation | Specific functions affected, configuration changes | Targeted OQ for affected functions, TM update |
| Documentation only | No functional impact, administrative changes | Update validation documents, change log entry |
| None | No impact on validated state (e.g., cosmetic change) | Change log entry only |
| Revalidation Level | Criteria | Activities Required |
|---|---|---|
| Full revalidation | Core functionality changed, new GAMP category, or major version upgrade | URS review, RA update, IQ, OQ, PQ, TM update, VSR |
| Partial revalidation | Specific functions affected, configuration changes | Targeted OQ for affected functions, TM update |
| Documentation only | No functional impact, administrative changes | Update validation documents, change log entry |
| None | No impact on validated state (e.g., cosmetic change) | Change log entry only |
Determination for CR-[SYS]-[YYYY]-[NNN]
Determination for CR-[SYS]-[YYYY]-[NNN]
Revalidation level: [Full / Partial / Documentation only / None]
Rationale: [Specific reasoning based on impact assessment]
Revalidation level: [Full / Partial / Documentation only / None]
Rationale: [Specific reasoning based on impact assessment]
Required Activities
Required Activities
| Activity | Owner | Deadline |
|---|---|---|
| [e.g., Execute OQ test cases TC-OQ-015 through TC-OQ-022] | [Name] | [Date] |
| [e.g., Update traceability matrix for URS-007] | [Name] | [Date] |
| [e.g., Update SOP-LIMS-003 section 4.2] | [Name] | [Date] |
**Expected:** Revalidation scope is proportional to the change impact — no more, no less.
**On failure:** If revalidation scope is contested, err on the side of more testing. Under-validation is a regulatory risk; over-validation is only a resource cost.| Activity | Owner | Deadline |
|---|---|---|
| [e.g., Execute OQ test cases TC-OQ-015 through TC-OQ-022] | [Name] | [Date] |
| [e.g., Update traceability matrix for URS-007] | [Name] | [Date] |
| [e.g., Update SOP-LIMS-003 section 4.2] | [Name] | [Date] |
**预期结果**：再验证范围与变更影响相匹配，既不扩大也不缩小。
**失败处理**：如果再验证范围存在争议，优先选择更多测试。验证不足会带来监管风险，验证过度仅会产生资源成本。Step 4: Obtain Approval
步骤4：获取审批
Route the change through the appropriate approval workflow:
markdown
undefined将变更提交到对应审批工作流：
markdown
undefinedChange Approval
Change Approval
Approval for: CR-[SYS]-[YYYY]-[NNN]
Approval for: CR-[SYS]-[YYYY]-[NNN]
| Role | Name | Decision | Signature | Date |
|---|---|---|---|---|
| System Owner | Approve / Reject / Defer | |||
| QA Representative | Approve / Reject / Defer | |||
| IT Representative | Approve / Reject / Defer | |||
| Validation Lead | Approve / Reject / Defer |
| Role | Name | Decision | Signature | Date |
|---|---|---|---|---|
| System Owner | Approve / Reject / Defer | |||
| QA Representative | Approve / Reject / Defer | |||
| IT Representative | Approve / Reject / Defer | |||
| Validation Lead | Approve / Reject / Defer |
Conditions (if any)
Conditions (if any)
[Any conditions attached to the approval]
[Any conditions attached to the approval]
Planned Implementation Window
Planned Implementation Window
- Start: [Date/Time]
- End: [Date/Time]
- Rollback deadline: [Point of no return]
**Expected:** All required approvers have signed before implementation begins (except emergency changes).
**On failure:** For emergency changes, obtain verbal approval from system owner and QA, implement the change, and complete formal documentation within 5 business days.- Start: [Date/Time]
- End: [Date/Time]
- Rollback deadline: [Point of no return]
**预期结果**：实施开始前已获得所有要求的审批人签字（紧急变更除外）。
**失败处理**：对于紧急变更，先获取系统所有者和QA的口头审批，实施变更后在5个工作日内完成正式文档补录。Step 5: Implement and Verify
步骤5：实施与核验
Execute the change and perform post-change verification:
markdown
undefined执行变更并开展变更后核验：
markdown
undefinedImplementation Record
Implementation Record
Pre-Implementation
Pre-Implementation
- Backup of current system state completed
- Rollback procedure documented and tested
- Affected users notified
- Test environment validated (if applicable)
- Backup of current system state completed
- Rollback procedure documented and tested
- Affected users notified
- Test environment validated (if applicable)
Implementation
Implementation
- Implemented by: [Name]
- Date/Time: [YYYY-MM-DD HH:MM]
- Steps performed: [Detailed implementation steps]
- Deviations from plan: [None / Description]
- Implemented by: [Name]
- Date/Time: [YYYY-MM-DD HH:MM]
- Steps performed: [Detailed implementation steps]
- Deviations from plan: [None / Description]
Post-Change Verification
Post-Change Verification
| Verification | Result | Evidence |
|---|---|---|
| System accessible and functional | Pass/Fail | [Screenshot/log reference] |
| Changed functionality works as specified | Pass/Fail | [Test case reference] |
| Unchanged functionality unaffected (regression) | Pass/Fail | [Test case reference] |
| Audit trail continuity maintained | Pass/Fail | [Audit trail screenshot] |
| User access controls intact | Pass/Fail | [Access review reference] |
| Verification | Result | Evidence |
|---|---|---|
| System accessible and functional | Pass/Fail | [Screenshot/log reference] |
| Changed functionality works as specified | Pass/Fail | [Test case reference] |
| Unchanged functionality unaffected (regression) | Pass/Fail | [Test case reference] |
| Audit trail continuity maintained | Pass/Fail | [Audit trail screenshot] |
| User access controls intact | Pass/Fail | [Access review reference] |
Closure
Closure
- All verification activities completed successfully
- Validation documents updated per revalidation determination
- SOPs updated and effective
- Training completed for affected users
- Change record closed in change control system
**Expected:** Implementation matches the approved plan, and all verification activities pass.
**On failure:** If verification fails, execute the rollback procedure immediately and document the failure as a deviation. Do not proceed without QA concurrence.- All verification activities completed successfully
- Validation documents updated per revalidation determination
- SOPs updated and effective
- Training completed for affected users
- Change record closed in change control system
**预期结果**：实施过程符合已审批的计划，所有核验活动全部通过。
**失败处理**：如果核验失败，立即执行回滚流程，将失败记录为偏差。未经QA同意不得继续推进。Validation
验证项
- Change request has unique ID, description, and classification
- Impact assessment covers all dimensions (software, data, infrastructure, SOPs, training)
- Revalidation scope is defined with rationale
- All required approvals obtained before implementation (or within 5 days for emergency)
- Pre-implementation backup and rollback procedure documented
- Post-change verification demonstrates the change works and nothing else broke
- Validation documents updated to reflect the change
- Change record formally closed
- 变更请求具备唯一ID、描述和分类
- 影响评估覆盖所有维度（软件、数据、基础架构、SOP、培训）
- 再验证范围已明确并附合理性说明
- 实施前已获取所有要求的审批（紧急变更需在5天内补全）
- 实施前备份和回滚流程已记录
- 变更后核验证明变更生效且未影响其他功能
- 验证文档已更新以反映变更
- 变更记录已正式关闭
Common Pitfalls
常见误区
- Skipping impact assessment for "small" changes: Even minor changes can have unexpected impacts. A configuration toggle that seems harmless may disable an audit trail or change a calculation.
- Emergency change abuse: If more than 10% of changes are classified as "emergency," the change process is being circumvented. Review and tighten the emergency criteria.
- Incomplete rollback planning: Assuming rollback is "just restore the backup" ignores data created between backup and rollback. Define data disposition for every rollback scenario.
- Approval after implementation: Retrospective approval (except for documented emergencies) is a compliance violation. The CCB must approve before work begins.
- Missing regression testing: Verifying only the changed functionality is insufficient. Regression testing must confirm that existing validated functions remain unaffected.
- 对「小」变更跳过影响评估：即便是次要变更也可能带来意外影响，看似无害的配置开关可能会禁用审计追踪或修改计算逻辑。
- 滥用紧急变更：如果超过10%的变更被归类为「紧急」，说明变更流程正在被规避，需重新审核并收紧紧急变更判定标准。
- 回滚规划不完整：认为回滚「只需恢复备份」忽略了备份到回滚之间产生的数据，需为每个回滚场景定义数据处置规则。
- 实施后补审批：事后补审批（已记录的紧急变更除外）属于合规违规，CCB必须在工作开始前完成审批。
- 缺少回归测试：仅验证变更的功能是不够的，回归测试必须确认现有已验证功能未受影响。
Related Skills
相关技能
- — defines the governance framework including change control board
design-compliance-architecture - — create the revalidation documentation triggered by changes
write-validation-documentation - — full CSV reassessment for major changes requiring full revalidation
perform-csv-assessment - — update SOPs affected by the change
write-standard-operating-procedure - — when changes are triggered by CAPAs
investigate-capa-root-cause
- — defines the governance framework including change control board
design-compliance-architecture - — create the revalidation documentation triggered by changes
write-validation-documentation - — full CSV reassessment for major changes requiring full revalidation
perform-csv-assessment - — update SOPs affected by the change
write-standard-operating-procedure - — when changes are triggered by CAPAs
investigate-capa-root-cause