Title: Change Approval Procedure Document ID: [PROC-CHANGE-001] Version: 0.1 Draft Status: Draft Owner: CISO (Paul Jenkins) Approver: CISO (Paul Jenkins) Classification: Internal Effective date: [DD Month YYYY] Review date: [DD Month YYYY] # Change Approval Procedure ## Purpose This procedure defines how BlackDice should assess, review, approve, and record changes that may affect security, service integrity, or compliance. ## Scope This procedure applies to production changes, infrastructure changes, configuration changes, security tooling changes, CI/CD workflow changes, and other in-scope changes requiring formal approval. ## Trigger / When Used Use this procedure when: - a planned change may affect security or service operation - a high-risk or production change requires approval - an emergency change requires retrospective review ## Procedure Steps 1. Create a change record with a description of the planned change, scope, systems affected, timing, and owner. 2. Assess the change for security, operational, customer, resilience, and rollback impact. 3. Identify testing, evidence, implementation steps, and backout arrangements. 4. Determine the approval level required based on risk, environment, and criticality. 5. Obtain approval from the appropriate reviewer or authority before implementation, unless emergency conditions require immediate action. 6. Ensure pre-implementation conditions are satisfied, including communication and deployment readiness where relevant. 7. Record the decision and retain approval evidence. 8. For emergency changes, ensure retrospective review and confirmation of residual risk. ## Inputs - change request - impact assessment - test or validation evidence - implementation and rollback plan ## Outputs / Records - approved or rejected change record - approval evidence - implementation conditions and notes - retrospective review record where applicable ## Roles and Responsibilities - Change owners must submit complete and accurate change information. - [Role] or designated approvers must review and approve changes according to risk. - Technical reviewers must provide impact input where needed. ## Escalation / Exceptions Escalate where: - the change has production, customer, or regulatory impact - risk is not understood or testing is incomplete - there is disagreement on approval or readiness - emergency implementation is proposed without enough context Exceptions must be documented and approved through the defined process. ## Related Documents - Change Management Policy - Production Deployment Procedure - Secure Development Policy - Risk Assessment Procedure ## Version Control | Version | Date | Description of Change | Author | | --- | --- | --- | --- | | 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |