Change Model

Change model is a repeatable, agreed approach for managing a particular category of change to an IT service or its supporting technology. Within IT service management and the ITIL change enablement practice, a change model defines the conditions under which a change follows a particular route, the activities and controls involved, who makes the relevant decisions, and what evidence is retained. A model can be simple or complex, manual or automated, depending on the risk, predictability, and dependencies of the changes it governs.

In plain terms, a change model is the agreed way to handle this kind of change whenever it arises. It translates an organization's broader change rules into a repeatable operating pattern. The model may identify an approved implementation route, but its existence does not automatically authorize every individual change. Whether separate authorization is necessary depends on the model's scope, the applicable change authority, and the conditions of the particular request.

A change model is often confused with a standard change. The two are related but different: a standard change is a low-risk, pre-authorized class of change, whereas a model is the method used to manage a defined change category. Models can also govern normal changes that need case-by-case decisions and emergency changes that need expedited handling.

This entry uses change model in its IT service management sense. Models for leading organizational transformation, such as Kotter's 8-Step Change Model, address a different problem: how people and organizations move from one way of working to another.

Purpose and scope

A change model makes recurring decisions and control requirements predictable. When the same kind of service change arises repeatedly, requiring every team to reconstruct its risk assessment, review path, test expectations, and recovery arrangements can waste time and produce inconsistent outcomes. A defined model establishes the common route in advance while preserving safeguards for situations that do not fit.

The model should be specific enough to distinguish eligible changes from superficially similar changes with different consequences. For example, an established procedure for rotating a certificate on an isolated test service should not automatically cover changes to the certificate used by the organization's shared production identity service. The technical operation may look similar, but the blast radius, authorization requirements, rollback options, and stakeholder impact may differ.

Change models sit beneath the overarching change enablement practice and its governing policy. They describe how particular change categories are handled, rather than replacing the organization's overall accountability, security requirements, or independent approval rights. The IRS's documented IT change-management process is one example of an operating model that uses defined change models with risk-based authorization and execution controls.

How a change model works

A model defines a repeatable route, but each proposed change must first be checked against the route's eligibility conditions. A typical application has five connected decisions:

1. Identify the applicable model. Confirm that the requested change, affected service, environment, and implementation method fit its approved scope.
2. Check the required evidence. Supply the service context, risk information, prerequisites, test results, planned timing, and other inputs specified by the model.
3. Apply the authorization rule. Determine whether the change is already authorized within defined limits, requires an individual decision, or must be escalated.
4. Execute and verify. Follow the prescribed implementation and recovery approach, monitor the result, and respond to deviations or failure conditions.
5. Record the result and learn. Preserve the relevant approval, execution, outcome, and exception evidence so that the model can be evaluated and improved.

These are explanatory functions, not a mandatory five-step ITIL sequence. An organization may combine steps, automate decisions, or use different workflows for different change categories. What matters is that the chosen model answers the relevant questions and has an explicit route when a prerequisite, test, approval, or implementation condition fails.

A model's boundaries are as important as its normal path. If a change exceeds a risk limit, affects a newly critical dependency, uses an untested method, or lacks the required recovery capability, it should leave the pre-established route and obtain the assessment or authorization appropriate to the new circumstances. Reusing a model is defensible only while its assumptions remain true.

What a change model specifies

There is no universal document layout or fixed number of fields. A useful model normally makes the following elements clear enough for both operators and reviewers to apply them consistently.

Element	Question addressed	Typical content
Identity and ownership	Which model is being applied, and who maintains it?	A unique name or identifier, version, accountable owner, and approval status
Eligibility and trigger	What situations qualify for this route?	Change category, affected services, environments, prerequisites, and exclusions
Required inputs	What information must be available before work proceeds?	Change request or equivalent trigger, scope, dependencies, test evidence, and business context
Risk and impact criteria	How are materially different cases recognized?	Service criticality, risk thresholds, security conditions, and escalation triggers
Decision rights	Who may authorize which action?	Delegated change authority, pre-authorization conditions, and exceptions requiring individual review
Execution path	How is the change carried out?	Sequence of tasks, responsible teams, automation gates, and dependency checks
Timing and communication	When may it proceed, and who must know?	Scheduling constraints, blackout periods, notifications, and coordination requirements
Verification and recovery	What indicates success or requires intervention?	Acceptance tests, monitoring, stop conditions, rollback or alternate recovery steps
Evidence and closure	What proves that the route was followed and the result assessed?	Authorization record, deployment trace, outcome evidence, exceptions, and review rules

The level of detail should match the operating context. A short, low-risk procedure may fit on a controlled checklist. A high-consequence deployment route may require linked engineering runbooks, automated quality gates, several approvers, a tested recovery procedure, and an auditable history of changes to the model itself. Stanford University's change-management role definitions provide an example of separately identified change owners, approvers, implementers, and authorities responsible for approving process models or templates.

Relationship to standard, normal, and emergency changes

A change type describes the authorization or urgency characteristics of an individual change. A change model describes the repeatable handling approach associated with a defined category. Consequently, a single organization can maintain several models within the same change type, and different models can require different levels of authorization.

Change type	How a model may be used	Authorization distinction
Standard Change	A tested model specifies the eligible, low-risk action and its approved procedure	The qualifying pattern is pre-authorized; each occurrence must still meet its established conditions
Normal Change	A model guides recurring assessment, testing, stakeholder review, and implementation of similar proposals	Individual changes still require the applicable decision, even though the route is repeatable
Emergency Change	A model can predefine an accelerated response, available decision-makers, minimum evidence, and post-change review	Urgency changes the route and timing; it does not automatically remove accountability

For example, a normal database deployment can follow a mature, reusable model without becoming a standard change. The model might prescribe compatibility checks, backups, application-owner consultation, a maintenance window, and a designated approval. The actual migration still requires its own authorization when the predefined rights or circumstances demand it.

Likewise, a model for emergency security remediation may specify who can authorize urgent action, which tests can be performed immediately, and what records must be completed afterward. Having such a model does not make an emergency routine or eliminate the need to judge the particular threat and operational risk. Atlassian distinguishes change categories according to their approval and urgency characteristics while encouraging an approach proportionate to risk and organizational circumstances.

Approval of the model versus approval of a change

Two separate decisions can be involved. First, the organization approves a model as an acceptable route for a particular category of change. That approval establishes the model's owner, scope, controls, eligible users, and authority boundaries. Second, each actual change is handled under the model, with any additional decision required by the route.

Approval of the model does not mean that an implementer can broaden its scope at will. For example, a model authorized for a non-production environment cannot be used to justify an unreviewed deployment to a production service merely because the execution steps are identical.

A Change Advisory Board can help review a model's cross-functional risks, while a designated change authority makes the approval decision when delegated to do so. A change manager may coordinate the workflow without personally holding every technical, security, or business approval right. For urgent decisions, an Emergency Change Advisory Board may be consulted where the organization's emergency arrangements require it. These governance mechanisms should not be treated as interchangeable.

For automated models, authorization may be expressed through formally approved policy conditions and enforced workflow controls rather than repeated manual approvals. The key requirement is to know who approved the rules, which changes they cover, and what happens when automation cannot establish that all conditions are satisfied. AWS recommends qualifying automated change models or deployment pipelines against change-control requirements before allowing them to operate under those permissions.

Automation and continuous delivery

A change model can be represented as human-readable instructions, a workflow in an IT service management platform, a deployment pipeline, or a combination. Automation is particularly useful where the same checks and tasks recur and the necessary evidence can be produced reliably by systems.

In a software delivery pipeline, the model may require source-code review, automated functional and security tests, deployment to a controlled environment, health checks, approval where necessary, and automatic rollback on specified failure signals. The resulting logs and records can provide evidence that a particular implementation followed the model. AWS describes this as an integration of change enablement, release management, and deployment management within an automated delivery flow.

Automation introduces its own boundaries. A successful pipeline run shows that configured controls passed; it does not guarantee that the controls cover every service dependency or business consequence. A model should therefore identify the conditions under which automation must stop, seek human review, or hand off to Incident Management or recovery arrangements.

An unchanged deployment pipeline can also become an unsuitable model if the underlying application, infrastructure, regulatory obligations, or risk exposure changes. Model ownership and requalification are needed even when execution is fully automated.

Illustrative applications

Routine certificate replacement

Consider a hypothetical model for replacing short-lived certificates on an isolated internal service. Its eligibility rules specify which services and certificate types qualify. It requires a tested replacement procedure, an expiry check, application-owner notification, a validation step, and a recovery method. If an approved service meets those conditions and the model has appropriate pre-authorization, the replacement can be treated as a standard change.

Now consider the same technical activity on a shared identity gateway used by critical customer applications. The model's assumptions may no longer hold. The change could need broader dependency analysis, an implementation window, and individual authorization. The original model has not failed; the proposed work simply falls outside the conditions for which it was approved.

Application release through an automated pipeline

An enterprise might maintain a model for repeated releases of one application using a fixed pipeline. It defines test gates, eligible deployment environments, code-review obligations, observability thresholds, owner responsibility, automatic recovery conditions, and the events that require a pause for manual approval.

A small release that satisfies those conditions follows the established route. A release introducing a new external payment integration could trigger a different decision because the change extends beyond the model's known dependency and risk profile. A correctly governed model therefore supports both rapid execution of qualifying work and escalation of exceptional work.

Both examples are illustrative; they are not documented organizational deployments or universal ITIL requirements.

Governance, review, and maintenance

Models need explicit ownership because their content determines how future changes will be handled. Common responsibilities include:

• The change enablement practice owner sets consistency requirements, reviews the model portfolio, and decides when a model should be retired or redesigned.
• The model owner maintains its scope, approved version, procedure, control evidence, and exceptions.
• A designated change authority approves the model and, where required, individual changes using it.
• Technical and service owners establish implementation feasibility, dependencies, test expectations, and operational support.
• Independent assurance or compliance functions may review whether required approvals and evidence are preserved, particularly for consequential or regulated changes.

A model should be reconsidered when a change causes an outage, repeated exceptions occur, the target service or dependency structure changes, a control is no longer effective, or a new automation alters the risk profile. The review may broaden or narrow eligibility, add safeguards, change decision rights, or withdraw pre-authorization. This is an operating recommendation rather than a prescribed ITIL review interval.

A useful distinction is between model revision and change execution. Updating the model changes the permitted route for future work; executing under an approved model creates a record for a specific event. Separating the two makes it possible to establish which model version and authority applied when an earlier change occurred. The IRS change process illustrates lifecycle records and controlled authorization as part of maintaining traceable changes.

Evidence and performance

The usefulness of a model is assessed through the changes actually managed under it. Model-specific measures can include the share of qualifying changes completed without avoidable escalation, approval lead time, departures from required steps, change-related incidents, failed changes requiring rollback, and the completeness of execution records. None is meaningful without an agreed denominator and the relevant risk context.

A high volume of automated changes is not proof that a model is safe. Equally, a model that frequently routes work for individual approval may be performing correctly if the requests are genuinely outside its approved limits. Review should distinguish failures of the model's design, failures to follow a sound model, and changes in the environment that invalidate its original assumptions.

The strongest evidence usually connects the model version and decision authority to the actual change record, required tests, implementation trace, outcome verification, exceptions, and follow-up actions. This helps demonstrate whether repeatability is producing consistent control rather than simply reducing paperwork.

Related and distinct concepts

A change model is narrower than the overall Change Enablement practice: the practice governs service changes across the organization, while a model defines the route for a specific category. A Request for Change proposes a particular change; a Change Record captures information and decisions about a particular change; neither is itself the reusable model. A Change Plan sets out the intended execution of a change and may apply the model to a particular service or deployment.

Release Management coordinates making new or changed services and features available, and Deployment Management addresses the movement of changed components into environments. A model may embed activities associated with both, while retaining the distinction between authorization and execution. Configuration management helps maintain information about the affected assets and their dependencies.

Finally, an organizational change model such as Kotter's 8-Step Change Model deals primarily with the human and organizational transition to a different way of working. That use of the phrase change model is separate from the ITSM change-control meaning explained here.

ITIL terminology and version context

The ITIL 4 Change Enablement Practice Guide defines the concept as a repeatable approach for managing a type of change, as quoted in AWS Well-Architected guidance. PeopleCert has introduced ITIL (Version 5) through a phased release and states that Change Enablement remains among its management practices. Terminology and individual practice guidance should be checked against the version formally adopted by an organization; model design and approval rules remain locally governed.

See also

• Change Enablement
• Standard Change
• Normal Change
• Emergency Change
• Change Authority
• Change Advisory Board
• Request for Change
• Change Record
• Release Management
• Kotter's 8-Step Change Model