design-a-change-control-process

# design-a-change-control-process Match control depth to risk without making low-risk improvement impossible. ## When to use - Use for project, technology, policy, vendor, facility, product, or operating changes. - Do not let emergency classification become a permanent bypass. ## Procedure 1. Define change classes, risk factors, standard changes, emergency changes, prohibited actions, and decision authority. 2. Require a request with purpose, scope, affected items, dependencies, risk, timing, implementation, test, rollback, and owner. 3. Assess user, operational, financial, security, privacy, safety, legal, accessibility, data, and vendor impact. 4. Route approval by class and conflict; separate requester, implementer, and approver where risk requires. 5. Schedule against freezes, dependencies, capacity, communications, and support readiness. 6. Record exact version, baseline, authorization, execution, evidence, deviations, and incidents. 7. Verify intended outcomes and unintended effects; roll back or correct under defined criteria. 8. Review emergency use, failed changes, exceptions, lead time, and recurring low-value control. ## Done - A change-control process document and request template record classes, impact, evidence, authority, plans, schedules, outcomes, and review - Classification, conflict, approval, freeze, implementation, verification, rollback, emergency, and audit checks verify control