Change Management Procedure Example: A Template for IT and Databases

Most documents you find when searching for a "change management procedure example" were written for quality management systems: a material or machine change on a production line. For information technology, and database changes in particular, those templates fall short. This article gives a procedure skeleton IT teams can adapt directly, section by section, with the items specific to databases.

Why a Generic Procedure Falls Short for Databases

A change that comes with application code goes through a build and deployment pipeline; a database change is often a script run by one person. Unless three differences are written into the procedure, they remain gaps in an audit:

• What is approved is text: the ticket says "add a column to the customer table"; what runs is a specific SQL text. The record must show which text the approval was given to.
• Rollback is not automatic: a deleted row or a dropped column does not come back by redeploying the previous version. A rollback script has to be prepared together with the change.
• Reading is an operation too: pulling data from production changes no structure but takes personal data out. These requests are a separate type in the procedure.

The Procedure Template: Ten Sections

1. Purpose: changes to production systems are made in a controlled, traceable and reversible way.
2. Scope: application, infrastructure and database changes; data requests from production; permission changes. What is out of scope is written explicitly.
3. Definitions: standard, normal and emergency change; change window; rollback; personal data.
4. Roles: requester, change manager, technical approver, business approver, implementer (DBA), change advisory board.
5. Segregation of duties: a requester does not approve their own request; where possible the approver and the implementer are different people. Any exception states who may make it and under what condition.
6. Risk classification: the criteria that make a change low, medium or high risk, and the number of approvals each level needs.
7. Process steps: each step from request to closure, its owner and its output (below).
8. Emergency change: who may declare an emergency, how soon it is reviewed afterwards, and how the missing approval is completed.
9. Records: the evidence to keep for each change and how long to keep it.
10. Review: how often the procedure is updated; a periodic analysis of rejected and failed changes.

Change Types

Process Steps

1. Request: the requester enters the reason, the target server and database, the script and the rollback script.
2. Pre-check: the script is checked against coding rules and forbidden patterns (for example UPDATE without WHERE, DROP in production).
3. Risk classification: the affected objects and rules set the risk level; the level sets the required approval steps.
4. Test: the change is tried outside production and the result is attached to the record.
5. Approval: the approver sees the script itself; the approval is given to that text. If the text changes after approval, the approval no longer counts.
6. Scheduling: the change window and dependent changes are set.
7. Implementation: the implementer runs the approved text; start and end times, result and errors are recorded.
8. Verification: the requester confirms the expected result; if needed the rollback is run.
9. Closure: the record is closed; for an emergency change a review date is assigned.

Records to Keep

The questions an auditor asks about a change are well known: who asked for it, who approved it, what was approved, was that what ran, who ran it, what was the result? The records section of the procedure should name the evidence that answers each one: request and justification, script text and its digest, approval steps and approvers, test result, execution time and outcome, rollback decision. Rejected requests are kept too; they are the best proof that the control works.

Keeping the Procedure off Paper

The written procedure is the first document an audit asks for, but on its own it is not enough. The auditor picks a sample and wants to see the procedure applied in those records. If the records are spread across e-mail, the ticketing system, a file folder and the database log, those pieces have to be joined for every sample item; why that is hard is covered in was the SQL that ran the SQL that was approved?

SQL Change Guard is designed to apply the database part of this procedure step by step: request, pre-check, approval by risk level, comparison of the approved text with the text to be executed, controlled execution and an evidence file for every request. It does not change your procedure; it turns it into a flow that produces records.

Frequently Asked Questions

How long should a change management procedure be?

Scope matters, not length. A procedure covering the ten sections above rarely exceeds a few pages in most organisations; details such as risk criteria and the approval matrix can live in annexes.

Can approval be skipped for an emergency change?

It is shortened, not skipped. The procedure should state who may open the emergency path, which approval comes first and how soon the rest is completed. A detailed approach is in the emergency database change article.

Do ITIL and ISO 27001 make this procedure mandatory?

ITIL is a good practice framework and imposes no obligation. ISO 27001 lists change management among its Annex A controls; an organisation seeking certification has to show it with a documented and applied process.

Do database changes need a separate procedure?

Not necessarily; adding database-specific items to the general IT change procedure is enough: keeping the approved text, a rollback script, and defining data requests from production as a separate type.