Normal Change

Normal change is a non-emergency change to an IT service, product, or supporting technology that requires assessment and authorization for the specific proposal because it is not covered by a pre-authorized standard change procedure. In Change Enablement, a normal change follows a risk-appropriate path for evaluating its consequences, deciding whether it may proceed, coordinating implementation, and reviewing the result.

A normal change is not necessarily ordinary, low-risk, or small. It may range from an isolated configuration adjustment to a major data-centre migration. What these proposals have in common is that the organization must make an authorization decision about this particular change, taking account of its actual scope, risk, timing, dependencies, and evidence. A low-risk change can remain normal when no approved standard-change pattern covers it; a high-risk change can be normal when it is planned rather than urgent.

Normal change is one of three commonly used service-change classes, alongside standard change and emergency change. The categories guide how IT service management applies control, but the precise risk thresholds, approval levels, and records are established by each organization's policy. A Change Advisory Board (CAB) may review consequential normal changes, while a suitably delegated change authority can authorize lower-risk proposals without a standing committee meeting.

What makes a change normal?

A normal change is the appropriate classification when an intended service change is neither a qualifying emergency nor an instance of a previously authorized standard-change procedure. The word normal identifies the authorization route, not the familiarity of the technical activity. It is therefore possible for two similar-looking deployments to follow different routes if one is within an approved standard-change model and the other introduces an unassessed dependency.

A normal change typically has the following characteristics:

• Individual assessment. The specific proposal is evaluated for service impact, likelihood and severity of failure, dependencies, and readiness.
• Explicit authorization. The designated authority approves, defers, rejects, or conditionally approves the proposal within its delegated limits.
• Planned implementation. The team identifies suitable timing, resources, technical steps, communication needs, validation, and recovery measures.
• Recorded outcome. The organization retains a change record showing the decision, execution, result, and significant deviations.

These characteristics do not imply that every normal change requires the same paperwork or the same committee. For example, Virginia Tech's operational standard specifies lighter approval requirements for lower-risk normal changes and additional Change Advisory Board review for high-risk or broadly coordinated work. That is a concrete organizational design, not a universal approval rule prescribed for every enterprise.

Assessment and authorization

The defining decision in a normal change is whether the expected benefit justifies the remaining risk under the proposed implementation conditions. Assessment supplies the evidence for that judgment; authorization grants permission to proceed. Neither is equivalent to the technical team merely declaring that a deployment is ready.

A useful assessment considers both the chance of failure and the consequence if something goes wrong. Service criticality, sensitive data, customer-facing effects, security exposure, system dependencies, the implementation window, monitoring coverage, and the ability to reverse the change can all alter the decision. A small modification to a shared authentication rule, for example, may have greater consequences than a much larger update to a non-critical internal application. The relevant question is the potential service and business effect, rather than the number of configuration lines changed.

Assessment dimension	Question for the proposed normal change	Evidence typically considered
Purpose and scope	What is being changed, and what outcome is expected?	Affected service, proposed difference, reason, business owner, and intended result
Service and business impact	Which users, business processes, or service commitments could be affected?	Service criticality, customer exposure, dependencies, and operational impact
Technical and security risk	What could fail, and how serious would the result be?	Peer review, test findings, vulnerabilities, design constraints, and failure scenarios
Implementation readiness	Can the work be executed and supported as proposed?	Deployment plan, staff availability, acceptance checks, monitoring, and communication plan
Recovery feasibility	What happens if implementation or validation fails?	Back-out or forward-recovery approach, decision triggers, backups, and restoration evidence
Scheduling and coordination	Does the planned window conflict with other work or important business activity?	Maintenance calendar, freeze periods, release dependencies, and stakeholder consultation

The change authority may impose conditions, require more evidence, request a different window, or escalate the decision. Approval should be traceable to the authorized role and relevant risk limits. Where security, privacy, finance, or business continuity obligations require a separate decision, normal-change approval does not automatically waive those controls.

How approval levels vary

A practical change model can delegate different levels of normal-change authorization according to risk and impact. The following table illustrates common governance patterns rather than prescribing a fixed ITIL hierarchy.

Risk or coordination profile	Possible authority arrangement	Main governance concern
Low risk; limited service effect	Delegated service owner, qualified technical reviewer, or policy-governed approval mechanism	Confirm that the assessment is credible and any independence requirement is met
Moderate risk; multiple teams or dependencies	Accountable service or change owner, with specialist consultation and any additional required approvals	Resolve cross-team dependencies and define conditions for proceeding
High risk; critical service or substantial uncertainty	Senior delegated authority, potentially supported by CAB review and business or security approval	Ensure that risk acceptance, recovery readiness, and consequences are understood by legitimate decision-makers

Some organizations require CAB authorization for all normal changes; others use risk-based routing and consult the CAB selectively. ServiceNow's documented product workflow uses CAB authorization for its normal-change type, while Virginia Tech's published standard varies the approval route according to risk and multi-unit impact. These describe different valid operating choices rather than conflicting definitions of normal change.

Typical lifecycle and control points

A normal change generally proceeds through a series of connected decisions and activities. Organizations may combine stages or automate evidence collection, but the meaning of the control points remains recognizable:

1. Record and classify. A requester or change owner identifies the proposed alteration, affected services, reason, and why the standard or emergency route does not apply. The change request establishes the proposed scope.
2. Assess and plan. Relevant teams review business and technical risk, test evidence, implementation steps, dependencies, communications, and recovery options. Important gaps are returned for resolution.
3. Authorize. The assigned change authority records the decision and any conditions. A proposal can be deferred or rejected; completion of technical planning does not itself grant permission to implement.
4. Schedule and coordinate. Authorized work is placed into a suitable implementation window, taking account of other changes, release dependencies, and service commitments.
5. Implement and verify. Qualified implementers execute the approved plan, observe agreed checks, and activate recovery or escalation if the outcomes depart from expectations.
6. Review and close. The responsible role confirms the result, records incidents and deviations, and determines whether a post-implementation review or further corrective work is needed.

This is a reference description of the lifecycle, not a single mandatory sequence or approval chain. Atlassian's workflow guidance includes review, planning, approval, implementation, and closure, while North Carolina State University's operating guide distinguishes assessment, authorization, scheduling, implementation, review, and closure states for normal changes.

An authorized change can still be stopped before implementation when a material condition changes, such as a newly discovered dependency or a failed readiness test. Similarly, a successful deployment is not automatically a successful change: the intended service outcome and any unintended effects may need to be verified after the work is completed.

People, responsibilities, and records

The normal-change route separates preparation, advice, authorization, execution, and outcome verification. Roles may be combined in smaller organizations, but their decision rights and any requirements for independent review should remain clear.

Role	Contribution to a normal change	Responsibility boundary
Change requester or request owner	Explains the need, desired result, affected scope, and proposed timing	Requesting work does not automatically confer approval authority
Change owner	Coordinates assessment, planning, evidence, dependencies, and closure of the specific change	Coordinates the proposal but may need a separate or higher-level approver
Change manager	Oversees the change practice, classification, workflow integrity, scheduling, and reporting as locally assigned	Does not necessarily authorize every normal change
Change authority	Makes or records the permitted decision within delegated limits	Cannot waive other required permissions or exceed its mandate
Change Advisory Board	Brings together relevant technical, operational, security, and business perspectives for consequential changes	Advises unless the organization explicitly delegates authorization to the board
Implementers, service owners, and specialist reviewers	Assess feasibility and impacts, perform approved work, verify service condition, and support recovery	Technical execution and expert advice are different from risk acceptance

The change record or equivalent audit trail connects these responsibilities. It should establish what was proposed and authorized, by whom, under what conditions, when it was implemented, what tests and recovery arrangements supported it, and what actually happened. Change records can draw evidence from service-management tools, version control, automated tests, deployment pipelines, and operational monitoring rather than requiring every item to be copied manually into a form.

Examples

A normal change may be technically modest or enterprise-wide. These scenarios are illustrative; their classification depends on the organization's actual pre-authorizations, urgency, and risk policy.

New integration between business applications

A team proposes a new production integration that will exchange customer records between two existing systems. Although both applications are well established, the proposed integration introduces a new dependency and potentially new failure and security effects. The proposal is assessed as a normal change, with attention to data access, test results, downstream consumers, rollback feasibility, and the approval rights of affected service owners.

Major infrastructure migration

An organization plans to move an important application and its database to a different hosting environment. The work is scheduled rather than an immediate response to an outage, but it has substantial availability, performance, data-integrity, and recovery implications. It would normally need an individual risk decision, coordinated window, and explicit verification. The change remains a normal change despite its potential severity because normal does not mean minor.

One-off low-risk configuration change

A team needs a small configuration update to an internal service. The change appears low risk, but there is no pre-approved standard procedure covering its exact scope. It therefore receives a proportionate normal-change assessment and delegated authorization. If the organization later validates and pre-authorizes a repeatable pattern, subsequent qualifying instances may move to a standard-change route. That future transition should follow evidence and governance rather than happen automatically because the task has been repeated.

Normal, standard, and emergency changes

Service-change class	Defining condition	Authorization approach	What distinguishes it
Normal change	Planned or otherwise non-emergency proposal not covered by a pre-approved standard-change pattern	Assessment and authorization for the individual proposal, scaled to risk	Each proposal needs its own permission to proceed
Standard change	Pre-authorized, sufficiently low-risk and repeatable activity within an approved procedure	The approved pattern provides prior authorization for qualifying instances	The particular instance does not normally need a fresh discretionary approval
Emergency change	Urgent alteration needed to address an incident, serious threat, or comparable exposure that cannot wait for normal scheduling	Expedited assessment and authorization under emergency rules	Genuine urgency changes the route and timing, but does not remove accountability

A normal change may require swift action, but a business preference for speed or a missed deadline does not by itself make the change an emergency. Conversely, a genuinely urgent correction can require emergency handling even when the technical steps are familiar. The classification should be based on the situation and the governing policy, not selected to avoid review.

Relationship to ITIL, releases, and automation

In ITIL, the relevant management practice is Change Enablement. The standard, normal, and emergency labels are used to describe how service changes are controlled according to their authorization context. PeopleCert identifies Change Enablement among the Plan, Implement and Control practices in the current ITIL (Version 5) qualification structure. Detailed organization-specific thresholds and workflows still have to be defined locally; a product's default workflow is not a universal requirement of the framework.

Release management addresses making new or changed services and features available for use. Deployment management addresses movement of new or changed components into environments. A normal change may involve a release or deployment, but performing those activities does not itself establish change authorization. The normal-change decision is about permission to proceed with an understood operational and business risk, regardless of whether the work is carried out manually or through a CI/CD pipeline.

Automation can help gather evidence, calculate an initial risk profile, check policy constraints, route a request to the designated authority, detect conflicting change windows, and attach implementation results to the change record. Appropriate low-risk approvals may be automated where the governing policy expressly allows them. However, an automated workflow does not transform an individually assessed normal change into a pre-authorized standard change merely by removing a manual click.

Common control weaknesses

Several recurring problems can make the normal-change route slow without improving risk control, or fast at the expense of accountability:

• Committee review for every proposal. Requiring the same multi-person meeting for a trivial isolated change and a high-impact migration can consume specialist time without adding proportionate value.
• Approval without meaningful evidence. A recorded approval is weak assurance when the affected service, failure impact, test results, or recovery assumptions are unclear.
• Risk assessments based only on technical size. Small changes to shared, critical services may create outsized business consequences.
• Schedule conflicts and hidden dependencies. Two individually acceptable changes can interact badly when executed in the same window.
• Scope changes after authorization. Expanding the production targets, method, or dependencies can invalidate the original assessment and require renewed authorization.
• Closure treated as proof of success. A completed ticket may hide incidents, incomplete verification, unmet business outcomes, or unresolved corrective work.

These weaknesses point to an important boundary: a normal-change procedure provides a decision framework and evidence trail. It does not guarantee that a proposed change is safe, that its plan is effective, or that its implementation will succeed.

Measurement and improvement

Measures of normal-change performance should distinguish delivery efficiency from decision quality and actual service outcomes. Useful measures include elapsed time from proposal to decision, time spent waiting for additional information, change-related incidents, unsuccessful implementations, recovery effectiveness, and the proportion of changes requiring rework or unplanned escalation.

Comparisons should be segmented by risk, service criticality, and type of change. A low-risk configuration adjustment and a high-risk application migration have different review burdens. An apparent reduction in average approval time can reflect a shift in the mix of proposals rather than better governance; a higher approval rate does not necessarily indicate safer changes.

Review findings may support better risk rules, clearer delegation, stronger test evidence, more reliable implementation patterns, or the formal creation of approved standard-change procedures. A recurring change should be promoted to standard status only when its risk and execution conditions are sufficiently understood and the new authorization has actually been granted.

See also

• Change Enablement
• Standard Change
• Emergency Change
• Change Authority
• Change Advisory Board
• Change Request
• Change Model
• Change Record
• Post Implementation Review
• IT Service Management (ITSM)