Change Management Scope: Non-Code Changes
Change management covers non-code changes too, and the scope is decided by assessing the risk, impact, and reversibility of each change, not by whether it involves code. You define scope by categorizing changes (e.g., configuration, data, infrastructure, process) and applying a risk-based filter to determine which need formal approval, testing, and communication. This article explains how to build that filter and apply it consistently.
Why Non-Code Changes Matter
Many organizations focus change management on software deployments, but non-code changes often carry equal or greater risk. A database parameter tweak, a firewall rule update, a cloud instance resize, or a change to a business workflow can cause outages, data corruption, or compliance violations just as easily as a bad code release. For example, changing a connection pool size in an application server configuration can exhaust database connections and take down the entire application, even though no code was touched.
Regulatory frameworks like ITIL and ISO 20000 explicitly include infrastructure, configuration, and process changes in their change management definitions. In practice, this means any modification to a production environment or to the documented way of working is a candidate for change management, regardless of whether it involves a source code repository.
How to Decide Scope: A Risk-Based Approach
The core principle is to match the level of process to the level of risk. A low-risk change (e.g., updating a non-production log level) should not require the same approval chain as a high-risk change (e.g., modifying a production database schema). Here is a practical framework:
- Identify the change type: Configuration, data, infrastructure, security, process, or documentation.
- Assess impact: How many users, systems, or business processes are affected? Is it internal or customer-facing?
- Assess likelihood of failure: Has this type of change been done before? Is there a rollback plan?
- Assess reversibility: Can you undo the change quickly and safely? A reversible change is lower risk.
- Assess detectability: If something goes wrong, will monitoring catch it immediately?
Combine these factors into a simple scoring matrix (e.g., 1-5 for each) and define thresholds. For example, a total score below 8 could be a “standard� change with pre-approved steps; 8-15 could be “normal� requiring a change request; above 15 could be “major� requiring a CAB (Change Advisory Board) review. This approach is objective and repeatable.
Categories of Non-Code Changes
To make scope decisions easier, break non-code changes into distinct categories, each with its own typical risk profile:
- Configuration changes: Modifying settings in applications, servers, network devices, or cloud services. Examples: changing a timeout value, enabling a feature flag, updating a load balancer rule.
- Data changes: Direct updates to databases or files. Examples: correcting a customer record, bulk updating prices, running a data migration script.
- Infrastructure changes: Adding, removing, or modifying hardware or virtual resources. Examples: resizing a VM, adding a disk, changing network routing.
- Security changes: Modifying firewall rules, access controls, or encryption settings. These often have compliance implications.
- Process changes: Altering how work is done, such as a new approval workflow, a revised incident response procedure, or a changed vendor management process.
- Documentation changes: Updating runbooks, user guides, or policy documents. Usually low risk, but can be high impact if they contain critical instructions.
Each category can have its own default scope. For instance, documentation changes might only require peer review, while security changes always require CAB approval.
Common Mistakes in Scoping
Several recurring errors cause scope decisions to fail:
- Treating “no code� as “no risk�: A config change can be more impactful than a minor code fix.
- Ignoring dependencies: A change that seems isolated may affect other systems. For example, changing a shared authentication service’s timeout affects all connected apps.
- Not considering the rollback: If you cannot revert a change, it is automatically higher risk, even if the change itself is small.
- Over-standardizing: Requiring CAB approval for every tiny change creates bottlenecks and encourages people to bypass the process.
- Under-documenting: Even if a change is approved, failing to record what was changed makes future troubleshooting much harder.
A common misconception is that “standard changes� require no approval. In reality, standard changes are pre-approved because they are low-risk and repeatable, but they still need to be logged and tracked. The approval is built into the pre-defined procedure, not skipped.
How to Implement a Scoping Policy
To turn this framework into practice, follow these steps:
- Inventory change types: List all the non-code changes your team routinely makes.
- Assign risk scores: Use the impact/likelihood/reversibility criteria to score each type.
- Define approval levels: Map scores to approval paths (standard, normal, major).
- Create checklists: For each change type, provide a checklist of required steps (e.g., backup, test, rollback plan).
- Automate where possible: Use ticketing tools or CI/CD pipelines to enforce the policy, so a change request cannot be closed without the required approvals.
- Review and adjust: After major incidents, revisit the scoring to see if a change was misclassified.
For example, a company might decide that any change to a production database schema is automatically “major� because it is high impact and hard to reverse, while a change to a development environment’s log level is “standard� and can be done by the developer directly.
Costs and Benefits of a Formal Scope
Implementing a scoping policy has costs: time spent on approvals, documentation overhead, and potential delays. But the benefits usually outweigh these:
- Reduced incidents: Fewer unplanned outages because changes are reviewed and tested.
- Faster recovery: Documented rollback plans mean quicker restoration.
- Compliance: Auditors look for evidence that changes are controlled.
- Team clarity: Everyone knows what they can do without asking and what needs approval.
The key is to calibrate the process so that the cost of the process is lower than the cost of the failures it prevents. A startup with a small team and no external customers might accept a lighter process than a bank handling millions of transactions.
Frequently Asked Questions
What is the difference between a standard change and a normal change?
A standard change is pre-approved, low-risk, and follows a documented procedure (e.g., restarting a service, adding a user). A normal change requires a change request and approval from a manager or CAB because it has higher risk or is not fully routine.
Should a documentation change go through change management?
It depends on the impact. If the documentation is for internal developers and is easily corrected, peer review may be enough. If it is user-facing or contains safety-critical instructions, it should go through the same approval as a code change.
How do I handle emergency changes that cannot wait for approval?
Emergency changes (e.g., restoring service after an outage) should still be logged and reviewed, but the approval can be obtained after the fact. The key is to have a pre-defined emergency process that includes a post-incident review to prevent recurrence.
Who should be on the Change Advisory Board (CAB)?
The CAB should include representatives from operations, development, security, and business stakeholders who can assess impact from different angles. It does not need to be large; for a small team, two or three people may suffice.
Can a non-code change be more risky than a code change?
Yes. For example, changing a database connection string in a production config file can take down the entire application, while a well-tested code deployment might be completely safe. Risk depends on the change itself, not on whether it is code.
Related
Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.