Change Authority

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.

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.

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.

Purpose and decision rights

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.

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, 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.

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.

Aspect	Question that delegation must settle
Scope	Which services, environments, change categories, and impact levels can this authority approve?
Decision criteria	What risk, technical, business, and readiness evidence must be considered?
Limits and escalation	Which changes require a higher authority, additional sign-off, or an emergency route?
Accountability	Who owns the authorization decision, and how is it recorded and reviewed?
Substitution	Who may act when the usual authority is unavailable or has a conflict of interest?

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.

Authorization for different change types

The authority arrangement depends on the type and risk of the change. In the ITIL change enablement model, standard changes, normal changes, and emergency changes follow different authorization patterns. The following examples describe common arrangements rather than a universal approval matrix.

Change type	Typical authority arrangement	Key distinction
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.

What the authority considers

A proposed change is usually represented by a 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.

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.

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.

Relationship to other roles

Change authority operates alongside several roles that may overlap in a small organization but perform different functions.

Role or body	Principal relationship to change authorization
Change authority	Holds the delegated decision right for a defined set of changes.
Change manager	Coordinates the change enablement practice, records, reviews, and workflow; may also approve changes if separately delegated that power.
Change Advisory Board (CAB)	Brings relevant parties together to assess and advise; may act as change authority when its mandate includes approval.
Service owner or product owner	Provides accountability and service knowledge; may be the delegated authority for changes affecting that service or product.
Emergency Change Advisory Board (ECAB)	Supports urgent change decisions and may approve them when the emergency procedure grants that authority.
Change implementer	Executes the authorized work and reports the outcome; implementation responsibility alone does not establish approval rights.

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.

Delegated and automated authorization

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.

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.

Accountability and decision records

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.

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.

A 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.

Example

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.

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.

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.

See also

• Change Enablement
• Change Advisory Board
• Change Model
• Change Request
• Emergency Change Advisory Board
• Standard Change
• Post Implementation Review
• IT Governance