Change Control Process
Purpose
Define controlled process for software changes: requests, impact analysis, approvals, verification, and configuration management in regulated contexts.
When to Apply
- •Any change to safety-relevant software, requirements, design, tests, or configuration items.
- •Defect fixes, updates, refactors, and dependency/SOUP updates.
Requirements (testable)
- •Change Request: Document change description, rationale, items affected, and trace links (requirements, hazards, tests). Rationale: clarity.
- •Impact Analysis: Assess safety, cybersecurity, interoperability, documentation, and submission impact (FDA/MDR). Rationale: risk-aware decisions.
- •Approval: Obtain appropriate approvals (engineering + QA/RA) before implementation for safety-relevant changes. Rationale: governance.
- •Verification: Define and execute verification/validation scope for the change; include regression tests. Rationale: assurance.
- •Configuration Management: Update baselines, versions, and release notes; ensure traceability of change to artifacts. Rationale: auditability.
- •Submission Considerations: Flag changes that may trigger regulatory submission/update; record decision. Rationale: compliance.
Recommended Practices
- •Use templates for change requests with required fields.
- •Include SBOM updates when dependencies change.
- •Capture change risk level (minor/major) and tailor verification accordingly.
- •Link commits/PRs to change request IDs.
Patterns
Change request (YAML):
yaml
CR-145: description: Fix over-infusion timing edge case rationale: observed jitter at low battery affects: [REQ-62304-102, RISK-CTRL-19, TEST-410] risk: major submission_impact: no (reviewed QA/RA)
Verification entry:
markdown
Tests: TEST-410, TEST-411 rerun; new TEST-415 added for low-batt timing Result: PASS
Anti-Patterns (risks)
- •Implementing changes without impact analysis -> risk: missed verification, submission gaps.
- •Skipping approvals for safety changes -> risk: noncompliance.
- •No linkage to tests/requirements -> risk: lost traceability.
- •Not updating SBOM after dependency changes -> risk: unmanaged vulnerabilities.
Verification Checklist
- • Change request recorded with rationale and affected artifacts.
- • Impact analysis completed (safety, cyber, interoperability, submission).
- • Approvals obtained per policy for safety-relevant changes.
- • Verification/regression defined and executed; results recorded.
- • Baselines/versioning/release notes updated; traceability maintained.
- • Submission impact decision documented.
Traceability
- •Change IDs (
CR-###) linked to requirements, risks, commits/PRs, and test evidence. - •Store decisions and approvals with release artifacts.
References
- •IEC 62304 (configuration management and change control).
- •FDA/MDR expectations for software change impact and documentation.
Changelog
- •1.0.0 (2026-01-04): Initial change control skill with impact analysis and approval process.
Audit History
- •2026-01-04: Audit performed. Verified:
- •IEC 62304 configuration management and change control references accurate
- •FDA/MDR change impact documentation expectations correctly noted