Change management is a core Practice within the Compliance Framework and ECC‑2:2024 Control 1‑6‑1 requires standardized templates, clearly defined roles, and auditable approval workflows to ensure changes to systems and services are controlled, tested, and documented; this post walks through a practical, repeatable approach small organizations can implement now.
Why Control 1‑6‑1 matters for the Compliance Framework
The Compliance Framework defines practice‑level expectations; Control 1‑6‑1 translates those expectations into concrete evidence you can produce during an assessment: consistent change request templates, role assignments (requestor, approver, security reviewer, CAB), and approval workflows that produce tamper‑evident audit trails. Without these elements, organizations can't demonstrate that changes were evaluated for security impact, tested, or safely rolled back, which increases the likelihood of outages or breaches and makes compliance attestation difficult.
Core components to include in your policy
At a minimum your change management policy (Practice level) should mandate: a standardized change request template, a matrix of roles/approvals mapped to risk thresholds, defined emergency change procedures, approval workflow steps (including automated pre‑deployment checks), and logging/retention rules for audit evidence. For Compliance Framework alignment, explicitly map each policy clause to ECC‑2:2024 control language and retain examples of completed templates as evidence.
Templates: required fields and examples
Design templates to capture everything an assessor expects: change ID, change title, requestor, business justification, affected assets (asset IDs from your CMDB), scope, planned start/end, change window, rollback/backout plan (commands and procedures), test plan and acceptance criteria, risk score (use a numeric matrix), dependencies, impacted users, and monitoring/validation checks post‑deployment. Example (small business): a SaaS startup using GitHub can use a Pull Request template that includes "Security Impact", "Risk Score (1–10)", "Rollback Steps (git reset --hard
Roles: who signs off and when
Define roles with exact responsibilities and make them enforceable in your tooling. Typical roles: Change Requestor (creates request), Change Owner (coordinates implementation), Technical Approver (team lead), Security Reviewer (infosec or delegated SME), CAB Chair (for high‑risk), and Emergency Change Coordinator. In small businesses, roles can be mapped to named individuals or functions (e.g., "CTO or delegated engineer") but avoid single points of failure by assigning alternates. Use RBAC in your ticketing/CI system to ensure only authorized roles can move a request to “Approved” or “Implementing.”
Approval workflows: gates, automation, and evidence
Build approval workflows that combine manual sign‑offs with automated gates. Example workflow: Request created → automated static code analysis and IaC linting (tools: SonarQube, tfsec) → Technical Approver review → automated integration tests pass in CI → Security Reviewer sign‑off if risk ≥7 → CAB review for cross‑team impact → scheduled deployment window. Enforce branch protection rules and require one or more approvals for production releases. All approvals should be logged with timestamps, approver identity, and approver comments preserved for audit (e.g., Jira issue history, GitHub review logs, or ServiceNow approvals). Retain artifacts (test results, vulnerability scan outputs) for your retention period defined in the policy.
Implementation steps for a small business
Start by drafting a short policy mapped to the Compliance Framework and tag clauses to ECC‑2:2024 Control 1‑6‑1. Create two practical templates: (1) Pull Request/Change Request for code/config changes and (2) Infrastructure change request for manual server or network changes. Configure your ticketing/CI system: add required fields, add approval gates, and integrate automated scanners. Hold a weekly lightweight CAB (15–30 minutes) for Normal changes; handle Standard changes via pre‑approved templates and Emergency changes via an expedited but logged path. Example: a 15‑person e‑commerce shop uses GitHub Actions for CI; configure a "production" workflow that blocks deployment unless a "prod‑approval" Jira ticket is approved by the CTO and Security reviewer, and ensure the workflow uploads test artifacts to an S3 bucket with restricted access for auditors.
Technical controls, metrics, and auditability
Implement technical controls that make the policy self‑enforcing: branch protection, mandatory code reviews, pipeline gates (SAST, DAST, secret scanning), feature flags for gradual rollouts, and automatically generated rollback playbooks. Track KPIs required by Compliance Framework assessments: change success rate, mean time to recover (MTTR) after a failed change, percentage of emergency changes, and percent of changes with complete evidence. Store change artifacts and logs in an immutable, access‑controlled location (WORM S3, SIEM) for the retention period stated in your policy and include retention references in the policy document.
Risks of not implementing this requirement
Failing to implement Control 1‑6‑1 leaves you exposed to unauthorized or poorly tested changes that can cause service outages, introduce vulnerabilities, or leak sensitive data. From a compliance perspective, auditors will flag absence of templates, undefined responsibilities, or missing approval trails as major gaps — potentially leading to corrective actions, failed audits, or regulatory penalties. Operationally, the lack of rollback plans and validation checks increases MTTR and can damage customer trust.
Compliance tips and best practices
Keep the policy concise and actionable: use appendices for templates and mapping to ECC‑2:2024. Automate as much evidence collection as possible (scan outputs, CI logs, approval timestamps). For small teams, define a pragmatic CAB cadence and allow pre‑approved "Standard" changes for low‑risk, repetitive tasks to avoid bottlenecks. Regularly review and test emergency change procedures via tabletop exercises. Finally, train staff on the policy and build change management into onboarding so the process becomes habitual, not an afterthought.
In summary, align your change management policy to ECC‑2:2024 Control 1‑6‑1 by creating standardized templates, defining clear roles with RBAC enforcement, and implementing approval workflows that combine manual sign‑offs with automated technical gates; automate evidence collection, maintain an auditable trail, and regularly measure and test the process so you can both reduce operational risk and demonstrate compliance to auditors.
