Actions

Difference between revisions of "Standard Change"

(Created page with "'''Change authority''' is a person or group with delegated responsibility for authorizing a proposed change to an IT service. Within Change Enablement, a change authority...")
 
m
Line 1: Line 1:
−
'''Change authority''' is a person or group with delegated responsibility for authorizing a proposed change to an IT service. Within [[Change Enablement]], a change authority determines whether a change may proceed within its assigned decision-making limits, using the relevant risk, impact, readiness, and business information. The authority may be an individual, a management role, a technical group, or a formally constituted board; its identity and powers depend on the organization's change model and governance arrangements.<ref name="itil4">AXELOS (2020), ''ITIL 4 Practice Guide: Change Enablement'', sections 2.2 and 4.1.2, [https://s3.amazonaws.com/thinkific/file_uploads/381835/attachments/491/75a/635/Change-enablement.pdf practice guide] (accessed 6 November 2026).</ref>
+
'''Standard change''' is a pre-authorized, low-risk change to an IT service or its supporting technology that is performed using a documented, proven, and repeatable procedure. Within [[Change Enablement]], a standard change can proceed without obtaining a new approval for every occurrence, provided it remains within the scope and conditions of the authorization granted in advance.<ref name="atlassian">Atlassian (n.d.), ''Types of change management for ITSM teams'', [https://www.atlassian.com/itsm/change-management/types Atlassian ITSM guidance] (accessed 6 November 2026).</ref><ref name="service-now">ServiceNow (2025), ''Change types'', updated 30 January 2025, [https://www.servicenow.com/docs/r/it-service-management/change-management/change-types.html product documentation] (accessed 6 November 2026).</ref>
  
−
In practical terms, a change authority answers a specific question: ''Who is empowered to permit this change, and on what conditions?'' This decision right is distinct from coordinating the review, advising on risk, carrying out the implementation, or accepting the resulting service. A [[Change Advisory Board]] (CAB), for example, can provide advice to the change authority; it becomes the approving authority only when the organization has expressly assigned that responsibility to it.
+
In plain terms, the organization approves a ''kind of change'' and the safeguards for carrying it out, rather than asking an approver to reconsider the same controlled activity each time it occurs. A standard change is therefore distinguished by its established authorization and execution conditions, not merely by being common, small, or technically simple. The change must still be performed correctly and its outcome must remain observable.
  
−
Change authority is a role or mandate rather than necessarily a permanent job title. A service owner may authorize one class of changes, while a technical lead, designated manager, automated approval rule, or emergency decision group handles others. An individual can hold several roles, but the approval record should make clear which authority was exercised and whether the decision was within its limits.
+
Standard changes are one of the commonly recognized service-change types in [[IT Service Management (ITSM)|IT service management]] and [[ITIL]], alongside [[Normal Change|normal changes]] and [[Emergency Change|emergency changes]]. The classification applies to technical or service changes; it should not be confused with the people-focused discipline of organizational change management. The definitions and detailed controls used by a particular organization depend on its service criticality, risk tolerance, and adopted change governance arrangements.<ref name="peoplecert">PeopleCert (n.d.), ''ITIL 4 Practitioner: Change Enablement'', [https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-practitioner-change-enablement-3794 official practice overview] (accessed 6 November 2026).</ref>
  
−
== Purpose and decision rights ==
+
== Defining characteristics ==
  
−
The purpose of a change authority is to make authorization proportionate to the potential effects of a change while keeping responsibility for the decision identifiable. The authority sits at the decision point between evaluation and permitted implementation; it does not, by itself, replace the broader assessment, scheduling, release, deployment, or verification activities of [[IT Service Management (ITSM)|IT service management]].
+
A change qualifies as standard when its risk is sufficiently understood and controlled for advance authorization to be meaningful. Frequency alone is not enough: repeating an unassessed or poorly documented action does not establish that it is safe.
−
 
 
−
Depending on the change model, an authorized decision may be to approve the change, approve it subject to conditions, defer it pending further evidence, reject it, or escalate it to another authority. The scope of this mandate should be explicit. For example, permission to approve a routine service update does not necessarily permit the same person to accept a material security exception, waive regulatory controls, or authorize an enterprise-wide outage.
 
−
 
 
−
A well-defined decision right identifies both its holder and its boundary. Where separate business, security, financial, or regulatory approvals are required, change authorization must respect those requirements rather than silently replace them.
 
−
 
 
−
== How change authority is assigned ==
 
−
 
 
−
Organizations commonly define change authorities through a [[Change Model|change model]], a change policy, or a documented delegation of authority. These arrangements establish which changes require which form of authorization and what evidence or escalation is necessary. ITIL 4 describes distributing authority to an appropriate level, including service or product owners, technical experts, and development teams, rather than assuming every change must be approved by a central board.<ref name="itil4" />
 
−
 
 
−
Typical assignment considerations include the affected service, business criticality, technical and security risk, potential customer impact, reversibility, urgency, and whether a change is already covered by an approved procedure. The authority should have sufficient knowledge to judge the proposed change or access to competent advice, and should be able to escalate decisions outside its mandate.
 
  
 
{| class="wikitable"
 
{| class="wikitable"
−
! Aspect
+
! Characteristic
−
! Question that delegation must settle
+
! Meaning for a standard change
 
|-
 
|-
−
| Scope
+
| Low and understood risk
−
| Which services, environments, change categories, and impact levels can this authority approve?
+
| Potential service, security, and business effects are within agreed limits; the risk assessment is relevant to the actual environment.
 
|-
 
|-
−
| Decision criteria
+
| Defined scope
−
| What risk, technical, business, and readiness evidence must be considered?
+
| The permitted systems, services, tasks, roles, and conditions are known. A materially different action is not covered merely because it looks similar.
 
|-
 
|-
−
| Limits and escalation
+
| Repeatable method
−
| Which changes require a higher authority, additional sign-off, or an emergency route?
+
| Approved implementation, validation, and recovery steps are documented and can be followed consistently.
 
|-
 
|-
−
| Accountability
+
| Evidence of reliability
−
| Who owns the authorization decision, and how is it recorded and reviewed?
+
| Testing, prior successful execution, or other credible evidence supports the expected outcome. The required evidence depends on the change and organization.
 
|-
 
|-
−
| Substitution
+
| Advance authorization
−
| Who may act when the usual authority is unavailable or has a conflict of interest?
+
| A designated [[Change Authority|change authority]] has approved the change pattern and its boundaries before individual occurrences are carried out.
 +
|-
 +
| Controlled execution
 +
| Individual instances can be scheduled, recorded, monitored, and reviewed according to the applicable policy without repeated case-by-case approval.
 
|}
 
|}
  
−
''Role names are not uniform across organizations.'' For example, the US Internal Revenue Service distinguishes a role called "Change Authority," which defines authorization levels and escalation criteria, from a "Change Approver," who makes particular approval decisions. This illustrates why the actual delegation and responsibility matter more than the label on an organizational chart.<ref name="irs">US Internal Revenue Service, ''Internal Revenue Manual, section 2.125.2'', [https://www.irs.gov/irm/part2/irm_02-125-002 role descriptions and responsibilities] (accessed 6 November 2026).</ref>
+
These characteristics explain why a low-risk one-off change may still be a normal change: without an approved, reusable procedure and prior authorization, there is no standard authorization for the implementer to rely on.<ref name="ncsu">North Carolina State University, Office of Information Technology (2025), ''Standard Change Templates'', knowledge article updated 5 December 2025, [https://ncsu.service-now.com/sp?id=kb_article_view&amp;sysparm_article=KB0016939 university operating guidance] (accessed 6 November 2026).</ref>
  
−
== Authorization for different change types ==
+
== How pre-authorization works ==
  
−
The authority arrangement depends on the type and risk of the change. In the ITIL change enablement model, [[Standard Change|standard changes]], [[Normal Change|normal changes]], and [[Emergency Change|emergency changes]] follow different authorization patterns. The following examples describe common arrangements rather than a universal approval matrix.<ref name="atlassian">Atlassian, ''Types of changes'', [https://www.atlassian.com/itsm/change-management/types IT service management guidance] (accessed 6 November 2026).</ref>
+
Pre-authorization applies to an approved change pattern, often represented by a [[Standard Change Template|standard change template]] in an IT service management system. The template defines what can be performed, who may perform it, which prerequisites must hold, and how completion or failure is recognized. For example, a permitted routine maintenance operation may specify a particular service class, tested procedure, maintenance window, and recovery method.
  
−
{| class="wikitable"
+
A candidate normally needs to be evaluated before it becomes standard. The [[Change Authority|change authority]] or another formally delegated approver examines its operational risk, scope, instructions, evidence of successful execution, and safeguards. Once the pattern is approved, subsequent qualifying occurrences use that authorization. Organizations such as Stanford University explicitly review standard-change template proposals and require supporting examples of earlier changes before approving the template.<ref name="stanford">Stanford University, University IT (2025), ''Propose a New Standard Change template'', updated 4 April 2025, [https://uit.stanford.edu/service/changemgt/std University IT guidance] (accessed 6 November 2026).</ref>
−
! Change type
+
 
−
! Typical authority arrangement
+
The essential distinction is between ''approval of the standard change pattern'' and ''execution of an instance''. The former establishes the decision right and safeguards; the latter must demonstrate that it is actually the approved activity and meets those safeguards. An expired, suspended, or materially altered template cannot safely substitute for renewed assessment.
−
! Key distinction
+
 
−
|-
+
Pre-authorization does not necessarily remove every other control. An approved change might still need a deployment window, coordination with another team, segregation-of-duties checks, or an independent security permission. The original authorization cannot override other mandatory approvals that lie outside its scope.
−
| [[Standard Change]]
 
−
| An appropriate authority approves the change model or procedure in advance; qualifying individual executions normally do not need another case-by-case approval.
 
−
| Pre-authorization applies only while the approved conditions are met.
 
−
|-
 
−
| [[Normal Change]]
 
−
| The change is evaluated and authorized at a level proportionate to its risk and impact, for example by a technical lead, service owner, change manager, or designated group.
 
−
| The approver and evidence requirements can vary substantially between normal changes.
 
−
|-
 
−
| [[Emergency Change]]
 
−
| A specifically delegated authority uses an expedited route, potentially involving an [[Emergency Change Advisory Board]] or designated on-call decision-maker.
 
−
| Urgency changes the decision route; it does not automatically eliminate accountability or the need to record the decision.
 
−
|}
 
  
−
A central CAB is therefore one possible authorization arrangement, not the defining characteristic of change authority. Modern change enablement may use distributed and automated approval routes where an approved policy supports them.<ref name="itil4" />
+
== Typical execution and control ==
  
−
== What the authority considers ==
+
An individual standard change commonly follows a shorter route than a normal change. Its precise workflow varies, but the governing logic is consistent:
  
−
A proposed change is usually represented by a [[Change Request|change request]] or equivalent tracked record. Before authorization, the responsible authority considers enough information to make the decision appropriate to the change's risk and scope. Relevant information may include the reason for the change, expected benefit, affected services and dependencies, testing evidence, security and compliance implications, implementation readiness, scheduling conflicts, rollback or recovery arrangements, and relevant stakeholder approvals.
+
# '''Confirm applicability.''' Identify the approved template or rule and verify that the affected service, intended action, implementer, timing, and environmental conditions are within scope.
 +
# '''Record or initiate the occurrence.''' Create the required change record or automated trace, including the template identity and the person or system responsible for execution.
 +
# '''Check readiness.''' Confirm prerequisites such as backups, test results, monitoring, service dependencies, and available recovery steps when applicable.
 +
# '''Implement the documented procedure.''' Follow the approved instructions; do not silently broaden scope or substitute untested steps.
 +
# '''Verify and close.''' Record the observed result, relevant evidence, unexpected effects, and any follow-up or recovery action. Escalate deviations or failures under the organization's rules.
  
−
Not every change requires every item in the same depth. A repeatable, low-risk standard change can rely on evidence already assessed when the model was approved. A high-impact normal change may need specialist analysis or several distinct approvals. An emergency change often has less time for assessment, which makes clearly delegated decision rights and later review particularly important.
+
This sequence is illustrative rather than a universally prescribed ITIL workflow. For example, North Carolina State University's operating procedure distinguishes approving a standard change template from executing a change under that template, and permits the latter to proceed without new approval.<ref name="ncsu" />
  
−
The resulting authorization should specify what was permitted and any conditions that must be satisfied before implementation. A recommendation, attendance at a CAB meeting, or absence of an objection should not be mistaken for affirmative approval unless the approved decision rules explicitly give it that meaning.
+
=== When the standard route no longer applies ===
  
−
== Relationship to other roles ==
+
A change should leave the standard route when an essential assumption no longer holds. Examples include a different production target, a newly identified shared dependency, an untested procedure revision, a materially altered security exposure, or a failed readiness check. Depending on urgency and risk, the activity may be deferred, reassessed as a normal change, or handled through a genuinely applicable emergency procedure. A normal or emergency label should not be used merely to conceal a missing control.
  
−
Change authority operates alongside several roles that may overlap in a small organization but perform different functions.
+
== Standard, normal, and emergency changes ==
  
 
{| class="wikitable"
 
{| class="wikitable"
−
! Role or body
+
! Change type
−
! Principal relationship to change authorization
+
! Defining condition
 +
! Authorization pattern
 +
! Principal distinction
 
|-
 
|-
−
| Change authority
+
| '''Standard change'''
−
| Holds the delegated decision right for a defined set of changes.
+
| Well-understood, low-risk, documented, repeatable activity
 +
| Authorization is granted to the defined change pattern in advance
 +
| Individual qualifying occurrences do not require a fresh discretionary approval
 
|-
 
|-
−
| [[Change Manager|Change manager]]
+
| [[Normal Change|Normal change]]
−
| Coordinates the change enablement practice, records, reviews, and workflow; may also approve changes if separately delegated that power.
+
| A non-emergency change that is not covered by an approved standard route
 +
| Assessment and authorization appropriate to the particular change
 +
| A decision is needed for the specific proposal, even if the risk is relatively low
 
|-
 
|-
−
| [[Change Advisory Board]] (CAB)
+
| [[Emergency Change|Emergency change]]
−
| Brings relevant parties together to assess and advise; may act as change authority when its mandate includes approval.
+
| Urgent change needed to address a significant incident, threat, or comparable need
 +
| Expedited assessment and authorization under the relevant emergency policy
 +
| Time pressure changes the decision route; it does not automatically make the change low risk
 +
|}
 +
 
 +
The categories describe the authorization context, not simply the technical operation. A routine software patch may qualify as standard when its exact method and environment have been approved in advance. A critical patch during active exploitation may require emergency handling; a novel application or database migration may need individual normal-change review. Vendor and practitioner guidance emphasizes that classifications and thresholds should reflect actual context rather than rigid lists of technologies.<ref name="atlassian" /><ref name="service-now" />
 +
 
 +
== Examples and scope limitations ==
 +
 
 +
Potential candidates include replacing an approved device with an identical unit in a non-critical configuration, expanding storage by a predefined amount in a controlled environment, or applying a tested recurring update to a known set of systems. These are examples of ''possible'' standard changes, not automatically approved activities in every organization.
 +
 
 +
{| class="wikitable"
 +
! Illustrative change
 +
! When it may be standard
 +
! When fresh assessment is needed
 
|-
 
|-
−
| [[Service Owner|Service owner]] or product owner
+
| Add capacity to an isolated service
−
| Provides accountability and service knowledge; may be the delegated authority for changes affecting that service or product.
+
| A known limit, approved method, and automated checks keep the work within an assessed risk envelope
 +
| The change affects a shared dependency, exceeds the approved limit, or requires a different deployment method
 
|-
 
|-
−
| [[Emergency Change Advisory Board]] (ECAB)
+
| Replace a failed component with an identical spare
−
| Supports urgent change decisions and may approve them when the emergency procedure grants that authority.
+
| The target, spare, failover, and verification process are documented and previously tested
 +
| The hardware variant, service criticality, or recovery assumptions have changed
 
|-
 
|-
−
| [[Change Implementer|Change implementer]]
+
| Apply a recurring maintenance update
−
| Executes the authorized work and reports the outcome; implementation responsibility alone does not establish approval rights.
+
| The permitted versions, affected systems, tests, and fallback steps are established
 +
| The update introduces new functionality, a novel dependency, or an urgent security exception
 
|}
 
|}
  
−
A useful distinction is between ''advice'', ''authorization'', and ''execution''. Advice informs whether a change is acceptable. Authorization permits the change under defined conditions. Execution makes the change. These responsibilities may be combined in one person when permitted by policy, but the decision record should not blur them.
+
''Illustrative examples only.'' The deciding factor is the approved pattern and its real-world conditions, not the activity's name. This is particularly important for services in which apparently minor actions can affect availability, identity, data integrity, or regulatory obligations.
 +
 
 +
== Responsibilities and governance ==
 +
 
 +
The [[Change Enablement|change enablement]] practice defines the controls and records within which a standard change is executed. A [[Change Authority|change authority]] approves the reusable pattern within delegated decision rights; technical implementers carry out instances; and service or product owners help identify acceptable impact and dependencies. A [[Change Advisory Board]] may review a proposed standard-change pattern when policy requires it, but its attendance is not inherently required for each occurrence.
 +
 
 +
The organization should be able to establish who authorized the pattern, what the authorization covers, who maintains the procedure, which roles may use it, and who can suspend or retire it. For material risks, the person implementing a change should not be able to redefine the authorization boundary without the required independent scrutiny.
 +
 
 +
Approval of a standard pattern is therefore a continuing governance decision. Recurring failures, unplanned incidents, changes in service architecture, or changed security requirements can invalidate the evidence on which approval originally depended. A standard change should be reviewed or withdrawn if its risk assumptions no longer hold. This is different from treating a previously approved template as permanently safe.
  
−
== Delegated and automated authorization ==
+
== Standard change and related concepts ==
  
−
Change authorization does not always require a meeting or a manual signature. A predefined rule can authorize qualifying routine changes, and an approved workflow can route riskier changes to the appropriate decision-maker. In these cases the organization remains responsible for the policy, thresholds, exceptions, and oversight behind the automated result. Automation applies an authorization rule; it does not independently establish who has governance accountability.<ref name="itil4" /><ref name="atlassian" />
+
A '''[[Change Model|change model]]''' is a repeatable way of managing a particular type of change. It may describe approval levels, responsibilities, workflows, and controls for changes with varying risks. A standard change is a ''classification and authorization arrangement'' for a low-risk change pattern. A change model can support a standard change, but the two terms are not interchangeable. AWS explicitly notes this distinction in its ITIL-related cloud guidance.<ref name="aws">Amazon Web Services (n.d.), ''Change enablement in the cloud'', section ''Automation of change models'', [https://docs.aws.amazon.com/wellarchitected/latest/change-enablement-in-the-cloud/change-enablement-cloud.html AWS Well-Architected guidance] (accessed 6 November 2026).</ref>
  
−
Delegation improves timeliness only when the decision boundary is credible. If authority is assigned too broadly, a local decision may expose services or stakeholders outside the approver's remit. If authority is too centralized, routine changes can be delayed without a corresponding improvement in risk control. Appropriate delegation therefore depends on risk, expertise, affected parties, and the organization's capacity to maintain consistent decisions.
+
A '''[[Standard Change Template|standard change template]]''' is the reusable record or work instruction that makes the authorized pattern available to qualified implementers. Its existence in a tool does not by itself prove that its risk assessment or authorization is current.
  
−
== Accountability and decision records ==
+
A '''[[Service Request|service request]]''' asks for a predefined service action, such as access or a service item, under the organization's fulfillment arrangements. Some requests may trigger an approved standard change, but the request and the service change remain distinct records or activities. A request catalog entry should not silently authorize changes that exceed the service's pre-approved scope.
  
−
An authorization is most useful when another person can establish what was decided and on what basis. Depending on local controls, a decision record may identify the change, the applicable model or policy, the individual or rule that authorized it, the evidence reviewed, the outcome, approval conditions, timing, and any escalation or exception. These are practical control considerations, not a fixed list universally mandated by ITIL.
+
'''[[Deployment Management|Deployment management]]''' concerns moving new or changed components into environments, while '''[[Release Management|release management]]''' concerns making new or changed services available for use. A standard change can involve a deployment or release, but neither execution mechanism automatically provides authorization for the change itself.
  
−
Common weaknesses include unclear authority limits, a CAB recommendation being treated as a formal approval, emergency approvals with no review trail, routine changes submitted repeatedly for unnecessary approval, and authorization granted before a necessary independent sign-off is obtained. In audit or incident review, these problems make it difficult to distinguish a poor change decision from an unauthorized or incorrectly executed change.
+
== Automation, evidence, and improvement ==
  
−
A [[Post Implementation Review|post-implementation review]] can examine whether a change achieved its intended result and whether the approval assumptions held. It does not retrospectively replace an authorization that was required before implementation.
+
Standard changes are often good candidates for [[Workflow Automation|workflow automation]] and [[DevOps|delivery pipelines]] because the allowed action, checks, and expected outcomes are known in advance. Automated implementations can verify identity, assess constraints, execute a version-controlled procedure, test results, log evidence, and halt when guardrails fail. AWS describes how cloud automation and repeatable change models can reduce manual approval overhead while preserving traceable risk controls.<ref name="aws" />
  
−
== Example ==
+
Automation should enforce an authorization already established by accountable governance. It cannot make a risky or poorly understood activity a standard change simply by running it repeatedly. Nor does a successful pipeline demonstrate that a new business impact or dependency is within the original approval.
  
−
Consider a proposed modification to a shared authentication service. The change team documents the affected applications, expected benefit, testing evidence, deployment timing, and recovery plan. Security specialists identify a dependency that the team has not resolved. A CAB discusses that risk and recommends a condition for proceeding, while the service owner has formally delegated approval rights for changes of this impact level.
+
Useful measures include the number of standard-change instances, failed or rolled-back executions, change-related incidents, unplanned deviations, elapsed implementation time, and the age or frequency of review of approved patterns. Measures should be interpreted by change type and service criticality. For example, a higher percentage of standard changes may reflect better risk reduction and documentation, but it can also reflect overly permissive classification; the count alone does not establish better governance.
  
−
In this illustrative case, the CAB's recommendation is advice. The service owner makes and records the authorization decision, including the condition. The implementation team can proceed only when the specified condition and other required approvals have been satisfied. If the change exceeds the service owner's delegated risk threshold, the decision must be escalated instead. The example illustrates how several participants can contribute to one change without all becoming its change authority.
+
A [[Post Implementation Review|post-implementation review]] or other appropriate outcome review may identify revisions to the template, tests, recovery steps, monitoring, or approval boundary. Routine successful execution supplies evidence for continued use, but a change that repeatedly fails should not remain pre-authorized merely because it is familiar.
  
 
== ITIL context ==
 
== ITIL context ==
  
−
The definition and delegated-authority arrangements described here are grounded in the ITIL 4 ''Change Enablement'' practice guidance. PeopleCert's subsequent ITIL (Version 5) qualification structure continues to identify Change Enablement within its Plan, Implement and Control practices. The precise approval roles, thresholds, and records in any enterprise remain matters for its adopted change management system and governing policies.<ref name="peoplecert">PeopleCert, ''ITIL Frequently Asked Questions'', [https://www.peoplecert.org/help-and-support/faq-itil official guidance on ITIL Version 5 and practice groupings] (accessed 6 November 2026).</ref>
+
The concept of a standard change is covered in the ITIL 4 ''Change Enablement'' practice, alongside change models, emergency changes, and change authority. PeopleCert's ITIL (Version 5) continues to organize Change Enablement within the Plan, Implement and Control practice group. Organizations may retain ITIL 4 materials while introducing Version 5 guidance; local policies and documented controls determine how the classification is implemented.<ref name="itil4syllabus">AXELOS (2023), ''ITIL 4 Change Enablement Practice Syllabus'', learning outcome 1.3, [https://eu-assets.contentstack.com/v3/assets/blt637b065823946b12/blt37b6f9281b6c3a17/64b7c925f823f127514f5e85/EN_ITIL4_Change_enablement_prct_CandidateSyll_v1.0.pdf official syllabus] (accessed 6 November 2026).</ref><ref name="itil5">PeopleCert (2026), ''ITIL FAQ: What has changed in the ITIL management practices?'', [https://www.peoplecert.org/help-and-support/faq-itil official ITIL (Version 5) guidance] (accessed 6 November 2026).</ref>
  
 
== See also ==
 
== See also ==
 
* [[Change Enablement]]
 
* [[Change Enablement]]
 +
* [[Change Authority]]
 
* [[Change Advisory Board]]
 
* [[Change Advisory Board]]
 +
* [[Normal Change]]
 +
* [[Emergency Change]]
 
* [[Change Model]]
 
* [[Change Model]]
−
* [[Change Request]]
+
* [[Standard Change Template]]
−
* [[Emergency Change Advisory Board]]
 
−
* [[Standard Change]]
 
 
* [[Post Implementation Review]]
 
* [[Post Implementation Review]]
 
* [[IT Governance]]
 
* [[IT Governance]]

Revision as of 02:40, 7 November 2026

Standard change is a pre-authorized, low-risk change to an IT service or its supporting technology that is performed using a documented, proven, and repeatable procedure. Within Change Enablement, a standard change can proceed without obtaining a new approval for every occurrence, provided it remains within the scope and conditions of the authorization granted in advance.[1][2]

In plain terms, the organization approves a kind of change and the safeguards for carrying it out, rather than asking an approver to reconsider the same controlled activity each time it occurs. A standard change is therefore distinguished by its established authorization and execution conditions, not merely by being common, small, or technically simple. The change must still be performed correctly and its outcome must remain observable.

Standard changes are one of the commonly recognized service-change types in IT service management and ITIL, alongside normal changes and emergency changes. The classification applies to technical or service changes; it should not be confused with the people-focused discipline of organizational change management. The definitions and detailed controls used by a particular organization depend on its service criticality, risk tolerance, and adopted change governance arrangements.[3]

Defining characteristics

A change qualifies as standard when its risk is sufficiently understood and controlled for advance authorization to be meaningful. Frequency alone is not enough: repeating an unassessed or poorly documented action does not establish that it is safe.

Characteristic Meaning for a standard change
Low and understood risk Potential service, security, and business effects are within agreed limits; the risk assessment is relevant to the actual environment.
Defined scope The permitted systems, services, tasks, roles, and conditions are known. A materially different action is not covered merely because it looks similar.
Repeatable method Approved implementation, validation, and recovery steps are documented and can be followed consistently.
Evidence of reliability Testing, prior successful execution, or other credible evidence supports the expected outcome. The required evidence depends on the change and organization.
Advance authorization A designated change authority has approved the change pattern and its boundaries before individual occurrences are carried out.
Controlled execution Individual instances can be scheduled, recorded, monitored, and reviewed according to the applicable policy without repeated case-by-case approval.

These characteristics explain why a low-risk one-off change may still be a normal change: without an approved, reusable procedure and prior authorization, there is no standard authorization for the implementer to rely on.[4]

How pre-authorization works

Pre-authorization applies to an approved change pattern, often represented by a standard change template in an IT service management system. The template defines what can be performed, who may perform it, which prerequisites must hold, and how completion or failure is recognized. For example, a permitted routine maintenance operation may specify a particular service class, tested procedure, maintenance window, and recovery method.

A candidate normally needs to be evaluated before it becomes standard. The change authority or another formally delegated approver examines its operational risk, scope, instructions, evidence of successful execution, and safeguards. Once the pattern is approved, subsequent qualifying occurrences use that authorization. Organizations such as Stanford University explicitly review standard-change template proposals and require supporting examples of earlier changes before approving the template.[5]

The essential distinction is between approval of the standard change pattern and execution of an instance. The former establishes the decision right and safeguards; the latter must demonstrate that it is actually the approved activity and meets those safeguards. An expired, suspended, or materially altered template cannot safely substitute for renewed assessment.

Pre-authorization does not necessarily remove every other control. An approved change might still need a deployment window, coordination with another team, segregation-of-duties checks, or an independent security permission. The original authorization cannot override other mandatory approvals that lie outside its scope.

Typical execution and control

An individual standard change commonly follows a shorter route than a normal change. Its precise workflow varies, but the governing logic is consistent:

  1. Confirm applicability. Identify the approved template or rule and verify that the affected service, intended action, implementer, timing, and environmental conditions are within scope.
  2. Record or initiate the occurrence. Create the required change record or automated trace, including the template identity and the person or system responsible for execution.
  3. Check readiness. Confirm prerequisites such as backups, test results, monitoring, service dependencies, and available recovery steps when applicable.
  4. Implement the documented procedure. Follow the approved instructions; do not silently broaden scope or substitute untested steps.
  5. Verify and close. Record the observed result, relevant evidence, unexpected effects, and any follow-up or recovery action. Escalate deviations or failures under the organization's rules.

This sequence is illustrative rather than a universally prescribed ITIL workflow. For example, North Carolina State University's operating procedure distinguishes approving a standard change template from executing a change under that template, and permits the latter to proceed without new approval.[4]

When the standard route no longer applies

A change should leave the standard route when an essential assumption no longer holds. Examples include a different production target, a newly identified shared dependency, an untested procedure revision, a materially altered security exposure, or a failed readiness check. Depending on urgency and risk, the activity may be deferred, reassessed as a normal change, or handled through a genuinely applicable emergency procedure. A normal or emergency label should not be used merely to conceal a missing control.

Standard, normal, and emergency changes

Change type Defining condition Authorization pattern Principal distinction
Standard change Well-understood, low-risk, documented, repeatable activity Authorization is granted to the defined change pattern in advance Individual qualifying occurrences do not require a fresh discretionary approval
Normal change A non-emergency change that is not covered by an approved standard route Assessment and authorization appropriate to the particular change A decision is needed for the specific proposal, even if the risk is relatively low
Emergency change Urgent change needed to address a significant incident, threat, or comparable need Expedited assessment and authorization under the relevant emergency policy Time pressure changes the decision route; it does not automatically make the change low risk

The categories describe the authorization context, not simply the technical operation. A routine software patch may qualify as standard when its exact method and environment have been approved in advance. A critical patch during active exploitation may require emergency handling; a novel application or database migration may need individual normal-change review. Vendor and practitioner guidance emphasizes that classifications and thresholds should reflect actual context rather than rigid lists of technologies.[1][2]

Examples and scope limitations

Potential candidates include replacing an approved device with an identical unit in a non-critical configuration, expanding storage by a predefined amount in a controlled environment, or applying a tested recurring update to a known set of systems. These are examples of possible standard changes, not automatically approved activities in every organization.

Illustrative change When it may be standard When fresh assessment is needed
Add capacity to an isolated service A known limit, approved method, and automated checks keep the work within an assessed risk envelope The change affects a shared dependency, exceeds the approved limit, or requires a different deployment method
Replace a failed component with an identical spare The target, spare, failover, and verification process are documented and previously tested The hardware variant, service criticality, or recovery assumptions have changed
Apply a recurring maintenance update The permitted versions, affected systems, tests, and fallback steps are established The update introduces new functionality, a novel dependency, or an urgent security exception

Illustrative examples only. The deciding factor is the approved pattern and its real-world conditions, not the activity's name. This is particularly important for services in which apparently minor actions can affect availability, identity, data integrity, or regulatory obligations.

Responsibilities and governance

The change enablement practice defines the controls and records within which a standard change is executed. A change authority approves the reusable pattern within delegated decision rights; technical implementers carry out instances; and service or product owners help identify acceptable impact and dependencies. A Change Advisory Board may review a proposed standard-change pattern when policy requires it, but its attendance is not inherently required for each occurrence.

The organization should be able to establish who authorized the pattern, what the authorization covers, who maintains the procedure, which roles may use it, and who can suspend or retire it. For material risks, the person implementing a change should not be able to redefine the authorization boundary without the required independent scrutiny.

Approval of a standard pattern is therefore a continuing governance decision. Recurring failures, unplanned incidents, changes in service architecture, or changed security requirements can invalidate the evidence on which approval originally depended. A standard change should be reviewed or withdrawn if its risk assumptions no longer hold. This is different from treating a previously approved template as permanently safe.

Standard change and related concepts

A change model is a repeatable way of managing a particular type of change. It may describe approval levels, responsibilities, workflows, and controls for changes with varying risks. A standard change is a classification and authorization arrangement for a low-risk change pattern. A change model can support a standard change, but the two terms are not interchangeable. AWS explicitly notes this distinction in its ITIL-related cloud guidance.[6]

A standard change template is the reusable record or work instruction that makes the authorized pattern available to qualified implementers. Its existence in a tool does not by itself prove that its risk assessment or authorization is current.

A service request asks for a predefined service action, such as access or a service item, under the organization's fulfillment arrangements. Some requests may trigger an approved standard change, but the request and the service change remain distinct records or activities. A request catalog entry should not silently authorize changes that exceed the service's pre-approved scope.

Deployment management concerns moving new or changed components into environments, while release management concerns making new or changed services available for use. A standard change can involve a deployment or release, but neither execution mechanism automatically provides authorization for the change itself.

Automation, evidence, and improvement

Standard changes are often good candidates for workflow automation and delivery pipelines because the allowed action, checks, and expected outcomes are known in advance. Automated implementations can verify identity, assess constraints, execute a version-controlled procedure, test results, log evidence, and halt when guardrails fail. AWS describes how cloud automation and repeatable change models can reduce manual approval overhead while preserving traceable risk controls.[6]

Automation should enforce an authorization already established by accountable governance. It cannot make a risky or poorly understood activity a standard change simply by running it repeatedly. Nor does a successful pipeline demonstrate that a new business impact or dependency is within the original approval.

Useful measures include the number of standard-change instances, failed or rolled-back executions, change-related incidents, unplanned deviations, elapsed implementation time, and the age or frequency of review of approved patterns. Measures should be interpreted by change type and service criticality. For example, a higher percentage of standard changes may reflect better risk reduction and documentation, but it can also reflect overly permissive classification; the count alone does not establish better governance.

A post-implementation review or other appropriate outcome review may identify revisions to the template, tests, recovery steps, monitoring, or approval boundary. Routine successful execution supplies evidence for continued use, but a change that repeatedly fails should not remain pre-authorized merely because it is familiar.

ITIL context

The concept of a standard change is covered in the ITIL 4 Change Enablement practice, alongside change models, emergency changes, and change authority. PeopleCert's ITIL (Version 5) continues to organize Change Enablement within the Plan, Implement and Control practice group. Organizations may retain ITIL 4 materials while introducing Version 5 guidance; local policies and documented controls determine how the classification is implemented.[7][8]

See also

References

  1. ↑ 1.0 1.1 Atlassian (n.d.), Types of change management for ITSM teams, Atlassian ITSM guidance (accessed 6 November 2026).
  2. ↑ 2.0 2.1 ServiceNow (2025), Change types, updated 30 January 2025, product documentation (accessed 6 November 2026).
  3. ↑ PeopleCert (n.d.), ITIL 4 Practitioner: Change Enablement, official practice overview (accessed 6 November 2026).
  4. ↑ 4.0 4.1 North Carolina State University, Office of Information Technology (2025), Standard Change Templates, knowledge article updated 5 December 2025, university operating guidance (accessed 6 November 2026).
  5. ↑ Stanford University, University IT (2025), Propose a New Standard Change template, updated 4 April 2025, University IT guidance (accessed 6 November 2026).
  6. ↑ 6.0 6.1 Amazon Web Services (n.d.), Change enablement in the cloud, section Automation of change models, AWS Well-Architected guidance (accessed 6 November 2026).
  7. ↑ AXELOS (2023), ITIL 4 Change Enablement Practice Syllabus, learning outcome 1.3, official syllabus (accessed 6 November 2026).
  8. ↑ PeopleCert (2026), ITIL FAQ: What has changed in the ITIL management practices?, official ITIL (Version 5) guidance (accessed 6 November 2026).
Retrieved from "https://cio-wiki.org//index.php?title=Standard_Change&oldid=19564"