Why Control Practices Matter
Uncontrolled change is the leading cause of service incidents. Without systematic change management, changes are made ad-hoc, impacts are not assessed, and unintended consequences occur. Without configuration management, organizations have no accurate picture of the environment they are operating—when a service fails, they cannot quickly determine which components are affected. The control practices form the foundational infrastructure on which reliable service delivery is built. ISO 20000 Clause 8.5 (change management), Clause 8.6 (release and deployment management), and Clause 8.1 (the Configuration Management Database) are interdependent. CMDB provides the data for change impact assessment. Change management ensures that all changes are recorded and controlled. Release management ensures that changes are bundled, tested, and deployed safely.
Implementing Change Management
Define Change Types
ISO 20000 distinguishes three types of changes, each with different approval and implementation procedures.
Standard changes are pre-authorized, low-risk, repeatable changes. They do not require full change management workflow for each instance. Examples: scheduled patching (apply OS patches on the second Tuesday of each month), password reset procedure updates, applying a previously tested security configuration to additional servers. Standard changes still must be documented and tracked, but they bypass the CAB approval step. Standard change procedure is documented once, and each execution is logged but not individually approved.
Normal changes require assessment and approval before implementation. They are the majority of changes. Examples: applying a new application version, reconfiguring a network device, expanding storage capacity. Normal changes require: change record creation, risk assessment, impact analysis, CAB approval, implementation window scheduling, post-implementation review.
Emergency changes require expedited handling. They are initiated in response to an operational emergency (a critical system is down and must be brought back online immediately; a security vulnerability must be patched immediately). Emergency changes follow a streamlined approval process (may be approved verbally by incident manager or service manager rather than waiting for full CAB meeting), but they must have post-implementation review within 48 hours to formally document what was changed and why.
Change Record Required Fields
A change record must contain all fields necessary for traceability and audit. Required fields: change ID (unique identifier), requester (who initiated the change), detailed description of what is being changed, reason or business justification for the change, affected configuration items (CIs) and services, risk assessment (likelihood × impact, scoring matrix), implementation plan (step-by-step procedure), rollback/back-out plan (how to undo the change if problems occur), test plan (how the change will be verified before going to production), scheduled implementation window (date/time), approval authority and CAB decision (approved/rejected/deferred), actual implementation status (completed/rolled back/failed), and post-implementation review outcome (successful/issues identified). These fields form the complete record that auditors examine.
Risk Assessment for Changes
Risk assessment categorizes change risk in terms of: service impact (number of users affected, criticality of affected service), security impact (does the change expose security vulnerabilities?), compliance impact (does the change affect compliance posture?), and implementation complexity (how difficult is the change to implement, what is the probability of implementation error?). A risk scoring matrix translates these factors into a risk level (low/medium/high). Risk level determines approval authority: low-risk changes may be approved by the service manager; high-risk changes require CAB approval; critical infrastructure changes may require executive approval.
The Change Advisory Board (CAB)
The CAB is a body composed of representatives from key stakeholder areas: service manager (who owns service continuity and customer satisfaction), technical leads (who represent the technology teams that implement changes), a customer representative (especially for major changes affecting customer-facing services), and a security representative (for changes with security implications). The CAB meets on a regular cadence (weekly or fortnightly, depending on change volume). The CAB reviews normal and high-risk changes, assesses impact and risk, and makes an approval decision (approved, rejected, deferred pending additional information). The CAB must maintain meeting minutes documenting who attended, which changes were reviewed, the risks identified, and the decisions made. CAB minutes are required documented information for audit evidence.
For urgent changes that cannot wait for the next scheduled CAB meeting, an emergency CAB (eCAB) may be convened—typically a call with incident manager, service manager, and technical leads, without waiting for the full CAB roster. The eCAB follows the same decision process as the full CAB but operates on an accelerated timeline.
Change Freeze Periods
Change freeze periods are windows when normal changes are not approved or implemented. Change freezes are typically declared before major business events (financial period close, major product launch) or during high-risk operational periods (major sporting events when the service must be completely stable). During a change freeze, only emergency changes (to fix operational failures) are allowed. The change freeze must be communicated to all stakeholders. Change freeze procedures must define who has authority to declare a freeze, how long freezes last, and how emergency changes are handled during freeze.
Post-Implementation Review (PIR)
After a change is implemented, a PIR is conducted to verify that the change achieved its objective and did not cause unintended impacts. PIR answers these questions: Did the change accomplish what was intended? Are there any unexpected side effects? Did the implementation proceed according to plan? What was actually different from the implementation plan? The PIR must be documented in the change record. PIR must be conducted before the change record is closed. Skipping PIR is a common pitfall; PIR is where implementation problems are identified and corrected.
Change Success Metrics
Track: change success rate (percentage of changes that closed without incident), emergency change rate (is the emergency change volume high or low—high volume suggests normal change process is not working), change-related incident rate (what percentage of incidents are caused by changes?), and overdue change count (changes that missed their scheduled implementation window). These metrics show whether change management is maintaining service stability or if changes are becoming a source of instability.
Implementing Release Management
Defining What Constitutes a Release
A release is typically a bundled set of changes that are designed, tested, and deployed together through a full pipeline from development through testing to production. Releases are usually application-version-based (e.g., "version 2.5.1 of the payroll system") or maintenance-release-based (e.g., "Q1 2026 OS patch bundle"). Releases are larger units of change than individual changes; while an individual change might be approved by the service manager, a release requires full change management and testing procedures.
Release Record Content
A release record must include: release ID and version number, list of changes included in the release (linked to individual change records), test plan with test cases to be executed, test results (which test cases passed, which failed), deployment plan (step-by-step deployment procedure), acceptance criteria (how you will know the deployment was successful), and deployment authorization (who approved deployment to production). The release record becomes the documented proof that the release was properly tested and approved before being deployed.
Release Testing Requirements
Testing must cover: functional testing (does the application function as designed?), regression testing (do existing features still work after changes?), performance testing (is the performance acceptable?), and security testing (are there new security vulnerabilities?). All test plans and test results must be documented. Testing must be completed and signed off by the testing team before release authorization is given.
Deployment Authorization
Deployment authorization confirms that the release is ready for production. The person who authorizes deployment should be independent of the development team (separation of duties). Deployment authorization should be based on test sign-off and should be documented in the release record as approval evidence.
Linking Releases to Changes
Every release must reference its constituent change records, and vice versa. This traceability is essential for audit. When auditors trace a service incident back to a change, they need to understand what release that change was part of, what other changes were in that release, and what testing was done on the release.
Implementing Configuration Management
Defining CI Scope
Configuration Items (CIs) are anything that must be tracked to manage services effectively. Scope decisions must be made on: What hardware gets CIs? (typically servers, network devices, storage—yes; cables and power supplies—no), What software gets CIs? (applications, middleware, operating systems—yes; utility tools—maybe), What documentation gets CIs? (Service Level Agreements, configuration documentation—yes; email—no), What services get CIs? (customer-facing services, support services—yes). The CI scope decision is documented in a CI scope statement, approved by service management, and communicated to all staff. The scope decision prevents unlimited CMDB growth while ensuring all critical items are tracked.
CMDB Tool Selection
CMDB implementation choices: (1) Purpose-built CMDB tool (e.g., BMC CMDB, ServiceNow CMDB)—most comprehensive but expensive; (2) ITSM platform CMDB (ServiceNow, Atlassian, others include CMDB as part of the suite)—good if you are already using the ITSM tool for incident/change management; (3) Spreadsheet-based CMDB—suitable for small organizations (<50 CIs) but difficult to maintain as the organization grows. Tool selection depends on organizational size, budget, and existing tool investments.
Initial CMDB Population
CMDB population can be done: (1) discovery-based (use automated discovery tools to scan the network and populate the CMDB automatically), (2) manual (staff manually create CI records in the CMDB)—time-consuming but ensures accuracy, (3) hybrid (use discovery to get initial population, then manual refinement). Prioritize population by service criticality—populate critical service infrastructure first. Develop a CMDB population plan with timeline and assign responsibility. CMDB population is typically a 4–8 week project depending on environment size.
CI Attributes to Capture
Each CI record must contain: CI ID (unique identifier), name (human-readable name), type (server, network device, application, SLA, document), category (software, hardware, service, documentation), status (live/in production, decommissioned, in development, being retired), owner (person responsible for the CI), location (physical location if applicable), version (software version, firmware version), support group (which team supports this CI?), and relationships to other CIs (parent-child relationships like "application A runs on server B," peer relationships like "server A is in a cluster with server B"). CI relationships are crucial for impact assessment—when you change one CI, the CMDB can show you what other CIs and services depend on it.
CMDB Accuracy Verification
CMDB accuracy decays over time as systems change but the CMDB is not updated. Scheduled verification cycles (quarterly recommended) identify discrepancies. Verification process: sample CIs from the CMDB (200–300 CIs), physically verify or query the actual environment to confirm the CMDB matches reality, record discrepancies, reconcile (update CMDB or investigate why systems changed). When discrepancies are found, analyze the root cause (was the system changed without a change record? Was the CMDB update forgotten after a change?). CMDB accuracy should be tracked as a KPI. Target: >95% accuracy in verification sample.
Using the CMDB Operationally
CMDB value is realized when it is actively used in incident, change, and problem management. In incident management: when a service fails, look up the service in the CMDB, identify the CIs that compose it, and determine which ones are affected by the incident. In change management: when assessing a proposed change to a CI, use the CMDB relationships to identify all dependent services and ensure impact assessment is complete. In problem management: analyze incident data by CI to identify whether a particular CI is a recurring source of problems.
Configuration Management Governance
Define: Who owns the CMDB (usually the service manager or configuration manager)? Who can create new CI records (usually configuration manager or service manager)? Who can update CI attributes (usually the support team for that CI, or centrally by configuration manager)? Who can retire CI records (usually configuration manager, with approval from the CI owner)? How is audit trail of CI changes maintained? Answer these questions in a configuration management procedure.
Common Implementation Pitfalls
Pitfall 1: Implementing change management without CMDB means impact assessment is based on knowledge ("I think this change affects these services") rather than data ("the CMDB relationship map shows this change affects these services"). Impact assessment becomes unreliable.
Pitfall 2: CMDB populated once and then abandoned. CIs in the CMDB become stale. When a change is made, the CMDB is not updated. Over time, the CMDB represents the infrastructure as it was 6 months ago, not as it is today. The CMDB becomes a liability rather than an asset.
Pitfall 3: Emergency changes that bypass all controls. In a crisis, the pressure is to fix the problem now. Controls are bypassed. But uncontrolled changes create more problems (unintended impacts, undocumented state). Emergency changes must still be documented; they just have expedited approval.
Pitfall 4: CAB meetings held but no minutes kept. Without CAB minutes, there is no evidence of the approval decision, no record of risks discussed, no accountability. CAB minutes are required documented information.
Pitfall 5: Change records closed without PIR. The change is implemented, the record is marked closed, but no one verifies that the change actually achieved its objective. Problems are not identified until the next incident.
| KEY CONCEPT | The CMDB is not a static asset register—it is a living relationship map. Its value comes from the CI relationship data (which CIs support which services, which CIs depend on which other CIs). The CMDB enables accurate impact assessment for both changes (what services will be affected?) and incidents (which CIs are affected, and therefore which services are impacted?). A CMDB with accurate relationships is worth the investment; a CMDB with inaccurate relationships is a liability. |
Change Type Comparison
| Change Type | Authorization Requirement | Approval Authority | Timeline | PIR Required | Examples |
|---|---|---|---|---|---|
| Standard | Pre-authorized one-time, logged per execution | Service manager (pre-approval) | 2 hours to 1 business day | No, but execution logged | OS patching, password procedure updates, approved security config |
| Normal | Full assessment and approval required | Service manager (low-risk), CAB (medium/high-risk) | 2–5 business days | Yes, within 48 hours | App version upgrade, network reconfiguration, storage expansion |
| Emergency | Expedited approval, may be verbal | Incident manager or service manager | Immediate to 4 hours | Yes, within 48 hours | Critical system down and needs immediate fix, urgent security patch |
CMDB Implementation Checklist
| Phase | Activity | Output | Completion Criteria | |
|---|---|---|---|---|
| Planning | Define CI scope, select CMDB tool, develop population plan, assign ownership | CI scope statement, tool selection decision, population plan with timeline, configuration manager assigned | Scope approved by service management, tool procurement authorized, plan reviewed and agreed | |
| Population | Conduct discovery scan or manual population, create initial CI records, establish CI relationships | CMDB with all in-scope CIs populated, relationships documented, CI verification report | All critical service CIs populated, sample verification audit showing >90% accuracy | |
| Integration | Integrate CMDB with incident, change, and problem management tools, train staff on CMDB usage | Integration complete, incident/change procedures updated to require CMDB lookup, staff training completed | Incident resolvers using CMDB for impact analysis, change CAB using CMDB for impact assessment | |
| Governance | Establish CMDB change control, define update procedures, conduct quarterly verification cycles, monitor accuracy KPI | Configuration management procedure, quarterly verification schedule, CMDB accuracy report | Quarterly verification cycles completed, accuracy >95%, CI changes tracked and documented, CMDB treated as controlled document | |
| IMPORTANT | CMDB inaccuracy discovered during a change or incident is a direct threat to service stability. If the CMDB states that Server A supports Service X, but Server A actually also supports Service Y (which the CMDB does not know about), a change to Server A could cause an unplanned Service Y outage. Auditors will test CMDB accuracy by sampling CIs, checking them against the live environment, and identifying discrepancies. If accuracy falls below 85%, auditors will flag this as a significant finding and recommend CMDB reconstruction. | |||
| BITLION INSIGHT | Bitlion GRC change management workflow and CMDB integration capabilities enable organizations to manage changes safely while maintaining an accurate configuration record. Change records are linked to CMDB CIs, so impact assessment is data-driven. PIR workflow ensures post-implementation verification is completed. CMDB relationships can be visualized to show service dependencies. Change history is tracked against the CMDB, enabling full traceability. |