IT Service Management is all about controlling and coordinating changes so they don’t break the services people rely on every day. The practices of change enablement, service configuration management, and release management provide the structure to approve modifications, keep track of all the components, and safely roll new versions into production. Understanding these three practices is essential for the ITIL 4 Foundation exam because they form the operational backbone of any IT organisation.
Jump to a section
A simple way to picture Service Management Practices (Part 2): Change Enablement, Service Configuration, and Release Management
A busy suburban kitchen, mid-renovation.
The homeowners want to knock down a wall to open up the space, install new cabinets, and move the sink to a different wall. This is a big change. They don’t just start swinging a sledgehammer—they first submit a change request to the local council for approval. The council reviews the plans, checks if the wall is load-bearing, and schedules an inspection. That’s change enablement: making sure every alteration to the house (or IT service) is properly assessed, approved, and logged before anyone touches a tool.
Meanwhile, the project manager keeps a detailed spreadsheet of everything in the house—every pipe, wire, cabinet, and window. Before the plumber moves the sink, the manager checks the spreadsheet to confirm there’s a hot water supply line at the new location. This is service configuration management: maintaining an accurate, up-to-date record of every component (or configuration item) that makes the house functional.
Finally, when all the parts are ready—the new cabinets are built, the pipes are rerouted, and the wall is safely removed—the team releases the finished kitchen to the family. They do it in a controlled way: they test the water pressure, check the electricals, and let the homeowners do a final walkthrough before moving the fridge back in. That’s release management: bundling approved changes together and deploying them in a way that doesn’t flood the living room or leave the family without dinner for a week.
Let’s break down these three service management practices one at a time. We’ll walk through what each one does, why it exists, and how they work together.
Change Enablement is the practice of making sure every change to an IT service is handled in a controlled way. A “change” could be anything from patching a server to adding a new feature to an app, or even decommissioning an old piece of hardware. The purpose of change enablement is to maximise the number of successful IT changes while minimising risk and disruption. Think of it as a traffic controller for modifications: it decides which changes can go ahead, which need a closer look, and which must be postponed.
Every change goes through a process. First, someone submits a “change request” describing what they want to do and why. Then the change is categorised. There are three types:
Standard changes: low-risk, pre-approved, routine tasks (like resetting a user’s password).
Normal changes: require assessment and approval by a group called the Change Advisory Board (CAB) because they carry some risk.
Emergency changes: urgent fixes for a critical issue (like a security breach). These are assessed by an Emergency Change Advisory Board (ECAB) as quickly as possible, and approval may happen after the change is implemented.
The change enablement process ensures every modification is logged, evaluated, authorised, planned, tested, implemented, and reviewed. This prevents unauthorised changes from causing outages or security issues.
Service Configuration Management is the practice of identifying, controlling, and maintaining information about all the components that make up an IT service. These components are called “configuration items” (CIs). A CI could be a physical server, a software licence, a virtual machine, a network switch, or even a document like a service level agreement (SLA).
The main tool for this is the Configuration Management Database (CMDB) — a central repository that stores details about every CI and the relationships between them. For example, if a company uses an online shopping app, the CMDB would list the web server, the database server, the payment gateway integration, and the firewall, plus how they connect. When a change is proposed (e.g., upgrading the database server), the change enablement team can consult the CMDB to see what other CIs depend on that database. This helps them assess the impact of the change.
Service configuration management also keeps track of CI versions, locations, owners, and status (e.g., “operational” or “under maintenance”). Its purpose is to provide accurate, up-to-date information so that all other practices — especially change enablement and incident management — can work effectively.
Release Management is the practice of making new or changed services and features available for use. A “release” is a collection of one or more approved changes that are deployed together. Releases can be:
Major releases: big, infrequent launches with lots of new features (like a new version of an app).
Minor releases: smaller updates or bug fixes.
Emergency releases: urgent patches to fix critical problems.
Release management controls the entire lifecycle of a release: planning, building, configuring, testing, deploying, and reviewing. It ensures that the release is deployed safely and that users know what to expect. One key concept is the “deployment” — the act of moving the release into the live environment. Release management may use different deployment strategies, like a phased rollout (releasing to a small group first) or a big bang (releasing to everyone at once).
These three practices are interdependent. Change enablement approves what changes will be included in a release. Service configuration management tells you what CIs will be affected. Release management bundles the approved changes, deploys them, and verifies that everything works as expected. Together, they prevent chaos, reduce downtime, and give IT teams control over their evolving services.
Submit a change request
A person or team identifies a need for a modification (e.g., patching a server, adding a feature) and logs a change request describing what, why, and expected impact. This kicks off the change enablement process.
Categorise and assess the change
The change is categorised as standard, normal, or emergency. A risk assessment is performed, often using data from the CMDB to see which CIs will be affected. This determines the level of authorisation needed.
Authorise the change
Based on the category, the change goes to the appropriate body (CAB for normal changes, ECAB for emergency changes, or pre-approved for standard changes). Approval is given, sometimes with conditions like testing requirements.
Plan and build the release
The approved change (and possibly other approved changes) are bundled into a release. The release manager plans the build, configures the components, and writes a deployment plan including rollback steps.
Test the release
The release is deployed to a staging or test environment that mirrors production. Automated and manual tests are run to verify functionality and ensure no side effects. If tests fail, the release may be sent back for fixes.
Deploy the release
The release is moved into the live production environment following the deployment plan. This may be a phased rollout to limit risk. After deployment, monitoring tools check for errors, and the team verifies service continuity.
Review and close
A post-implementation review (PIR) is conducted to evaluate whether the change met its objectives and whether any lessons were learned. The change record and CMDB are updated to reflect the new state, and the release is formally closed.
Imagine you work in the IT department of a mid-sized online retailer. The marketing team wants to add a “guest checkout” feature to the website so customers can buy without creating an account. This is a new feature, so it will require changes to the website code, the payment processing system, and the customer database.
Here’s what an IT professional would actually do with the three practices:
First, a change enablement specialist would log a normal change request. The request describes the new feature, explains why it’s needed (more sales), and lists the systems affected. The specialist categorises it as a normal change because it touches the payment system (high risk). They schedule a meeting of the Change Advisory Board (CAB), which includes the IT manager, the security lead, and a database administrator. The board reviews the request, asks about testing plans and rollback steps, and approves it with a condition: the feature must be tested in a staging environment first.
Second, the service configuration manager checks the CMDB. They pull up the configuration items involved:
The web server (CI-1001) running the e-commerce platform.
The payment gateway integration (CI-2005) connecting to the bank.
The customer database (CI-3007).
The CMDB shows that the payment gateway is also used by the subscription renewal system. This alerts the team that any downtime in the payment gateway could affect renewals, so they schedule the deployment for a low-traffic Tuesday morning.
Third, the release manager takes over. They bundle the approved change with a few other minor fixes into a minor release called “Release 4.2”. They build the updated code, deploy it to the staging environment, and run automated tests. The release manager also writes a deployment plan that details the steps (back up the database, update the web server code, update API keys, test checkout flow, monitor error logs). On Tuesday morning, the team executes the deployment plan. After deployment, they monitor the live site for an hour to confirm no errors. The release manager then formally closes the release and updates the CMDB to show the new version of the web server software.
Throughout this process, the IT professional uses:
A change management tool (like ServiceNow) to track the change request and approvals.
The CMDB to understand dependencies.
A release pipeline tool (like Jenkins or GitLab) to automate builds and deployments.
Monitoring dashboards to watch for incidents.
Without these practices, the same change might be deployed without proper testing, causing the payment system to crash and losing thousands in sales. The three practices work together to prevent that outcome.
The ITIL 4 Foundation exam tests your understanding of the purpose and key activities of each practice, not the detailed procedures. You need to be able to distinguish between them and recall specific definitions.
What to memorise: - The exact purpose statements from the ITIL 4 Foundation syllabus for each practice:
Change enablement: Maximise the number of successful IT changes while ensuring risks are properly assessed and changes are authorised.
Service configuration management: Ensure that accurate and reliable information about the configuration of services, and the CIs that support them, is available when and where it is needed.
Release management: Make new and changed services and features available for use.
The three types of change: standard, normal, emergency.
The names of the authorising bodies: Change Advisory Board (CAB) and Emergency Change Advisory Board (ECAB).
What a Configuration Item (CI) is and what a CMDB contains.
The difference between a release and a deployment (deployment is the act of moving the release into production; a release is the collection of changes that are deployed together).
Common exam traps: - The exam often asks to identify which practice handles a specific activity. For example, a question might describe “planning the rollout of a new version of software” and ask which practice it belongs to. Trainees often confuse release management with change enablement. Remember: change enablement approves the individual changes; release management bundles and deploys them. - Another trap: the exam may list activities and ask you to pick the one that is NOT part of change enablement. Be ready for options like “identifying configuration items” (this belongs to service configuration management) or “conducting post-implementation reviews” (this is part of change enablement). - They also test the difference between standard and normal changes. Remember: standard changes are pre-approved and low-risk; normal changes require individual assessment and approval.
Question types: - Multiple-choice: “Which practice includes the Change Advisory Board?” (Answer: Change enablement). - Multiple-choice: “What is the purpose of service configuration management?” (Answer: To maintain accurate information about CIs and their relationships). - Match-the-term: “Match each term with its description” (e.g., CI, CMDB, release, deployment).
Key definitions to memorise: - Change: The addition, modification, or removal of anything that could have an effect on services. - Configuration Item (CI): Any component that needs to be managed in order to deliver an IT service. - Configuration Management Database (CMDB): A database used to store configuration records throughout their lifecycle. - Release: A collection of one or more changes that are deployed together. - Deployment: The act of moving a release into the production environment.
Focus on these distinctions and definitions, and you’ll navigate the exam questions confidently.
Change enablement maximises successful IT changes by assessing risks and authorising modifications before they happen.
There are three types of change: standard (pre-approved), normal (requires CAB approval), and emergency (fast-track approval by ECAB).
Service configuration management maintains accurate records of configuration items (CIs) and their relationships in a Configuration Management Database (CMDB).
Release management bundles approved changes into releases and controls their deployment to make new services available safely.
A release is the collection of changes, while a deployment is the action of moving that release into the live environment.
The three practices work together: change enablement approves changes, configuration management tracks affected components, and release management deploys them.
Emergency changes require approval too — they aren’t ungoverned even when urgent.
A CI can be a document, a server, a software licence, or any component that needs to be managed to deliver a service.
These come up on the exam all the time. Here's how to tell them apart.
Change Enablement
Focuses on authorising individual changes after risk assessment
Uses CAB or ECAB for approval decisions
Output is an approved change ready for implementation
Release Management
Bundles multiple approved changes into a single release
Controls the build, test, and deployment lifecycle
Output is a deployed, live service feature
Service Configuration Management
Tracks CIs and their relationships for service impact analysis
Focuses on technical and operational data (versions, status, dependencies)
Purpose is to support other ITSM practices like change and incident
Asset Management
Tracks the financial lifecycle of assets (cost, depreciation, disposal)
Focuses on procurement, ownership, and financial value
Purpose is financial control and compliance
Standard Change
Low-risk, pre-approved, routine changes
Does not require individual approval; follows a predefined procedure
Examples: password reset, server patching on a set schedule
Emergency Change
Urgent changes to fix critical incidents or security issues
Requires fast-track approval from ECAB (often after implementation)
Examples: applying a security hotfix, restoring a crashed database
Normal Change
Non-urgent changes with moderate to high risk
Requires full assessment and approval by CAB before implementation
Planned and scheduled with a defined implementation window
Emergency Change
Urgent changes for critical situations (e.g., major outage)
Approved by ECAB, often after deployment to save time
Implemented as quickly as possible, with documentation later
Mistake
Change enablement is only about saying yes or no to changes — it’s just a gatekeeping process.
Correct
Change enablement includes logging, categorising, assessing, authorising, planning, testing, implementing, and reviewing changes. It’s a full lifecycle process, not just a yes/no decision.
People often focus on the approval step because it’s the most visible, but the practice covers much more, including post-implementation review.
Mistake
Service configuration management is just a fancy name for asset management.
Correct
Asset management focuses on financial and lifecycle management of assets (cost, depreciation, disposal). Service configuration management tracks CIs and their relationships to understand how services are composed and how changes affect them.
Both practices deal with inventories, so beginners blur the line. The key difference is purpose: configuration management is about service impact, not financial tracking.
Mistake
A release and a deployment are the same thing.
Correct
A release is the collection of changes that are built and tested together. A deployment is the action of putting that release into the live environment. You can have a release that hasn’t been deployed yet, and you can deploy a release in phases.
ITIL uses these terms precisely, but everyday language often treats them as synonyms, causing confusion in exams.
Mistake
Emergency changes don’t need any approval because they’re urgent.
Correct
Emergency changes still require approval, typically from an Emergency Change Advisory Board (ECAB). The process is faster, but approval is mandatory to prevent further damage.
People assume urgency overrides control, but ITIL emphasises that even urgent changes need oversight to avoid making a problem worse.
Mistake
A configuration item is any piece of hardware or software, but not documents or people.
Correct
A CI can be anything that needs managing to deliver a service, including documents like SLAs, contracts, and even virtual components like cloud resources or network configurations.
The term “configuration item” sounds technical, so beginners limit it to physical devices, but ITIL defines it broadly.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Change enablement focuses on approving and managing individual changes. Release management bundles approved changes together and controls their deployment into the live environment. Changes are “what” we do; releases are “how” we do it safely.
Yes. The exam often asks which group authorises normal changes (CAB) and which handles emergency changes (ECAB). They are distinct bodies, and knowing the names is important.
A CI is any component that needs to be managed to deliver an IT service. It can be hardware (a server), software (an operating system), a document (an SLA), or even a virtual resource (a cloud database).
No, although they can share data. A CMDB tracks CIs and their relationships to understand service dependencies. Asset management tracks financial information (cost, purchase date, depreciation). They serve different purposes.
Standard changes are pre-approved, so they don’t go through individual approval. However, if a standard change doesn’t meet the predefined criteria (e.g., it’s outside the normal scope), it must be treated as a normal change and go through the CAB process.
Release management includes a rollback plan. If the deployment fails, the team follows the rollback steps (e.g., reverting code, restoring the database) to return the service to its previous working state. The failure is then reviewed to prevent recurrence.
No. ITIL is framework-agnostic. You don’t need to know ServiceNow, Jenkins, or any tool by name. Focus on the purposes, processes, and terminology defined in the ITIL 4 syllabus.
You've finished Service Management Practices (Part 2): Change Enablement, Service Configuration, and Release Management. Continue through the ITIL4F study guide to build a complete picture of the exam.
Done with this chapter?