Requirement
Essential Cybersecurity Controls (ECC – 2 : 2024) - Control - 1-6-2 – The cybersecurity requirements in project and assets (information/technology) change management must include at least the following:
Understanding the Requirement
This control requires that change management for projects and IT/information assets explicitly include defined cybersecurity requirements and objectives so changes do not introduce new vulnerabilities or disrupt security controls. As specified by the framework Essential Cybersecurity Controls (ECC – 2 : 2024), the control references objectives 1-6-2-1 and 1-6-2-2; in practical terms you must capture and enforce security-related steps (for example documentation, risk assessment, approvals, testing, rollback planning and asset updates) as mandatory parts of any change to systems, applications, or asset configurations.
Technical Implementation
-
Change request template that includes security fields — Create a simple, mandatory change request form (in your ticketing system or an editable spreadsheet) that forces submitters to document: affected asset(s) by unique ID, purpose of change, risk assessment summary, required security controls, test plan, rollback plan, and expected outage window. Make these fields required before a request moves to approval.
-
Asset linkage and inventory update — Ensure every change references the canonical asset inventory entry (server, VM, application, database). After a change is approved and implemented, update the inventory immediately with new configuration, owner, version, and security posture notes so risk tracking stays current.
-
Role-based approval workflow with security gate — Define at least two approval roles for non-trivial changes: a technical approver (system owner or engineer) and a security approver (IT security lead or designated reviewer). Automate or enforce this workflow so changes cannot proceed to production without both approvals.
-
Testing and validation in staging — Require that all changes affecting security boundaries or sensitive data be executed first in a staging environment that mirrors production. Document test results (including security tests) on the change ticket and require sign-off before scheduling a production window.
-
Rollback and contingency planning — For every change, document an explicit rollback procedure and a short checklist to verify rollback success. Include criteria that trigger rollback (e.g., failed smoke test, degraded performance, error rate threshold) and assign a rollback owner and timeline.
-
Logging, monitoring and post-change review — Enable logging of change implementation steps and require a 24–72 hour post-change monitoring period with a short review note capturing lessons learned, incidents, or follow-up security tasks. Keep change records for audit and incident investigation.
Example in a Small or Medium Business
Acme HR Solutions, a 40-person company, needs to update its payroll application to support a new tax rule. The engineering lead files a change request in the team's ticketing tool and links the payroll server asset ID from the company inventory. The request includes a risk assessment noting that payroll data is sensitive, a test plan to run payroll calculations in staging, and a rollback plan to restore the previous database snapshot if results differ. The change is routed to the system owner for technical approval and to the security lead for a security gate review; both must approve before scheduling a maintenance window. The team implements the update in staging, runs automated and manual security checks, and documents all test outcomes on the ticket. During the scheduled off-hours window they deploy to production, monitor the system for 48 hours, and run a post-change review to update the asset record and assign remediation tasks for any minor issues found during monitoring.
Summary
By embedding explicit security fields into change requests, linking changes to a maintained asset inventory, enforcing role-based approvals, testing in staging, documenting rollback plans, and performing post-change monitoring and reviews, SMBs can satisfy Control 1-6-2’s requirement that cybersecurity be part of project and asset change management. These policy and technical measures are lightweight enough for small teams yet rigorous enough to reduce the risk of introducing vulnerabilities or service disruptions when changes are made.
