Change Record

Change record is a documented account of an individual change to an IT service or its supporting technology, maintained to preserve the change's scope, assessment, authorization, implementation, and outcome. In IT service management, it provides a traceable record of what was proposed, what decisions were made, what work was performed, and what happened as a result.

In plain English, the record is the history and evidence of one controlled change. It begins with enough information to identify the change and evolves as people assess risk, make decisions, perform the work, check results, and complete any required review. It may be a ticket in an ITSM system, a linked set of digital records, or another approved record structure. It is more than an initial form or an approval stamp.

A Request for Change (RFC) is the proposal asking for a change to be considered; the change record preserves the resulting lifecycle and decision history. Older ITIL terminology distinguishes them explicitly. In contemporary systems, a record called a change request may perform both functions: the same ticket starts as a proposal and accumulates approvals, implementation evidence, and closure information. The conceptual distinction remains useful even when the software does not create two separate objects.

Purpose within change enablement

The change enablement practice uses change records to make decisions and outcomes visible across teams and over time. A change may involve software, infrastructure, configuration, a cloud service, a security control, or another item whose modification could affect service delivery. The record connects the business or operational reason for making the change with the assessment, authority, work performed, and observed result.

A useful record answers several different questions. What was the intended change, and why? Which services and dependencies were affected? What did the responsible people know before authorization? Who or what authorized the change, under which conditions? Did execution follow the approved plan? What actually happened, including any incidents, recovery actions, or remaining follow-up work? These questions may be answered by information stored directly in the record or by evidence that can be reliably retrieved through its links.

The record serves three related purposes. It supports operational coordination while work is underway; it supports accountability by preserving the basis and limits of decisions; and it supports learning and audit after the outcome is known. Recording an approval alone does not establish that the change was safe or successful. The IRS and Virginia Tech both distinguish lifecycle evidence from the initial description of a change and require information to be updated as the work progresses in their respective environments.

What a change record contains

There is no single universal set of mandatory fields for every organization. The information needed depends on change risk, classification, service criticality, regulatory obligations, and the organization's approved change model. Virginia Tech, for example, specifies a common record identifier and lifecycle fields, then varies other requirements for routine, normal, and emergency changes. Its standard also allows required information to be held in linked or distributed records, provided it remains retrievable.

The following elements explain the common information functions of a change record rather than prescribe one fixed form.

Information area	Typical contents	Function in the record
Identity and status	Unique reference, change title, classification, creation date, current state, owner, and relevant timestamps	Establishes which individual change is being tracked and where it stands
Purpose and scope	Reason for change, intended result, affected services, environments, and configuration items	Connects the change to its operational need and potential dependencies
Assessment	Service impact, risk assessment, security implications, technical dependencies, feasibility, and mitigation measures	Preserves the evidence considered before deciding whether to proceed
Authorization	authorizing role or policy, decision, conditions, approver identity where applicable, and decision time	Shows who or what permitted the change and the boundaries of that permission
Preparation and schedule	Implementation plan, test evidence, resources, planned window, communications, and scheduling constraints	Shows how the authorized work was prepared and coordinated
Recovery arrangements	Back-out or remediation approach, trigger conditions, recovery owner, and relevant test results	Makes the response to an unsuccessful change identifiable
Execution evidence	Actual start and finish times, performed actions, deployment or configuration references, deviations, and implementation notes	Distinguishes planned activity from what occurred in the environment
Results and closure	Verification outcomes, service effects, related incidents, review findings, close code or disposition, and closure date	Establishes the outcome and why the record was completed, rejected, cancelled, or otherwise closed

Some fields are created early and others become meaningful only later. A record should make that progression clear. For example, a planned maintenance window and an actual implementation time are different facts; replacing one with the other can obscure whether the change occurred as authorized. Similarly, an assessor's recommendation is not the same as the authorization decision, and implementation completion is not necessarily proof that the service outcome was achieved.

How the record develops through its lifecycle

The change record normally evolves with the change. Its lifecycle may follow different paths for pre-authorized, individually assessed, and urgent changes; the following stages describe information that commonly becomes part of the record, without imposing a universal state machine.

Lifecycle point	Evidence the record gains	Decision or status question
Registration	Proposal origin, identifying details, service or item links, initial classification	Has this change been identified and routed correctly?
Assessment	Risk, impact, dependencies, feasibility, tests, and recommendations	Is there sufficient evidence for an authorization decision?
Authorization and planning	Approval or rejection, conditions, responsible authority, approved scope, and schedule	What exactly is permitted, and under which conditions?
Implementation	Actual actions, time stamps, verification checks, deviations, and any recovery activity	Did execution remain within the authorized scope, and what happened?
Outcome review	Actual service result, incidents, unresolved defects, and post-implementation review where required	Did the change achieve its objective, and what requires follow-up?
Closure	Final disposition, review responsibility, completion time, and evidence links	Is the record sufficiently complete to close under the applicable rules?

A rejected change may have a valid, complete record despite never being implemented. A cancelled change may preserve the decision to stop and the reasons for doing so. These outcomes matter because an audit or later reviewer should be able to distinguish a deliberate decision from missing data. Historic ITIL terminology expressly describes retaining a record for received RFCs even when the proposal is rejected.

Where a proposal changes materially after authorization, the record should identify the new scope and whether re-evaluation or renewed authorization was required. A single approved decision should not be made to appear to cover work that exceeded its stated boundaries. Exact amendment and versioning rules depend on the organization's policy and system design.

Records for different change types

The same record purpose applies across standard, normal, and emergency change classifications, although the required review and authorization evidence differs. Classification controls the route, not whether the organization benefits from traceability.

For a standard change, the authorization may apply to an approved repeatable procedure rather than to each instance. A record or equivalent execution evidence can identify the specific occurrence, approved procedure, responsible team, and outcome. The absence of a new case-by-case approval does not mean that the implementation was unrecorded.

For a normal change, the record commonly contains an individual risk assessment, authorization decision, planned implementation and recovery measures, execution evidence, and closure details. Greater business or technical consequences may justify more extensive supporting documents and review.

For an emergency change, action may have to proceed on an expedited path. Records should preserve the urgency, the decision-maker or emergency authorization route, the actions taken, their consequences, and any retrospective evidence or approval required by policy. Virginia Tech explicitly distinguishes post-event acknowledgement for certain emergency records from advance authorization; the IRS requires emergency change records to be created as soon as practicable in its own process.

These are different control paths within one record-keeping concept. A change should not be labelled an emergency simply to avoid documenting a difficult approval, and a standard-change record should not imply that every possible variation was pre-authorized.

Roles, responsibility, and evidence ownership

Different actors contribute different parts of a change record. The precise role names and approval rules vary; the important distinction is between supplying information, making a decision, executing the work, and reviewing the result.

Role	Typical record contribution	Boundary
Requester or initiator	Describes the original change need and proposed scope	Initiation alone does not confer authorization
Change owner or coordinator	Maintains classification, completeness, assignments, dependencies, and status	Coordination does not automatically confer every technical or business approval right
Service, technical, and security reviewers	Provide impact assessments, implementation readiness evidence, and specialist findings	Advice and technical sign-off may be distinct from final authorization
Change authority	Records authorization, conditions, rejection, or deferral within delegated powers	Must act within the organization's assigned limits
Implementation team	Records actual work, timings, checks, deviations, and recovery activity	Completion of tasks does not by itself establish success of the service outcome
Reviewer or change practice owner	Verifies required evidence, outcomes, exceptions, and closure conditions	The review role may be separate from the implementer, particularly for consequential changes

A Change Advisory Board may supply cross-functional recommendations or hold approval rights when formally delegated. The record should distinguish the board's advice from the decision that actually authorized a change. For controls requiring segregation of duties, information about reviewer, approver, and implementer identities helps demonstrate whether those responsibilities were handled appropriately. The IRS policy explicitly addresses accountable closure and segregation-of-duties evidence in its change management controls.

Relationship to other ITSM records

A change record often links to other managed information, but these objects are not interchangeable.

Related entity	Relationship to a change record
Request for Change	Supplies the original proposal; may become the initial state of the same electronic record
Change Model	Defines the agreed handling procedure or authorization path for this class of change
Change Schedule	Places authorized or planned changes in a shared timing view and reveals scheduling conflicts
Configuration Management Database (CMDB)	Holds information about the affected configuration items and their relationships; the change record documents the change event and its decisions
Incident Record	Documents a service interruption that may have triggered a change or resulted from one
Post Implementation Review	Records deeper assessment of the outcome where required and can be attached or linked
Release record	Tracks a coordinated release that may involve multiple related service changes

The relationship between a change record and a configuration item is especially important. A record says what happened to a controlled service or component; configuration information describes relevant components and their current or managed states. The change record can reference both the affected item and the corresponding configuration updates. This allows a later reviewer to understand the transition without treating the change record as the sole authoritative description of the environment.

Illustrative change record

Consider a hypothetical enterprise planning an adjustment to authentication settings for a shared customer sign-in service. This is a normal change because the specific settings and potential service effects require individual assessment. The example is illustrative; it does not describe an actual enterprise event.

The initial record identifies the proposed configuration adjustment, expected security benefit, affected applications, change owner, and intended maintenance window. Assessment finds that one older application relies on an authentication method scheduled for removal. The team updates the implementation plan, adds a compatibility check and a fallback configuration, and presents the revised evidence for authorization. The assigned authority approves the narrower scope with a condition that the application test must pass before production execution.

During the authorized window, engineers apply the change and record the deployment reference and actual start time. Monitoring detects increased sign-in failures for one integration even though the main test passes. The team activates the approved recovery action and documents the time of restoration, the affected integration, and a linked incident record. The change is not recorded simply as "completed"; its outcome reflects that the intended state was not sustained and recovery was necessary.

At review, the service owner and change coordinator identify the missed dependency, the decision to recover, and the follow-up testing required before a revised attempt. The record links to the associated review and closes with the appropriate disposition under local policy. Its value lies in preserving the difference between the approved plan, the actual execution, and the observed result. A reader examining the record later can reconstruct the decision and its consequences without relying on memory or informal messages.

Digital records, automation, and auditability

A change record does not have to duplicate every technical artifact. ITSM systems can retain identifiers and links to version-controlled plans, code changes, testing reports, deployment runs, automated policy checks, service monitoring, approval workflows, and incident records. Virginia Tech's standard expressly allows information to be maintained outside one record-like object when the complete required record can still be produced; its requirements also address linked-document retention and exportability.

Automation can improve fidelity when a pipeline captures what was deployed and when, rather than depending on a person to retype it. It can also preserve evidence that a predefined approval policy applied to the change. The record should still identify a meaningful decision route and the scope of that policy; successful automated execution is not evidence that a change satisfied every business or regulatory condition.

Records used for accountability need controlled access, accurate timestamps, retained supporting evidence, and a way to distinguish later edits from original decisions. The applicable retention schedule, privacy protections, and access requirements depend on the organization and its legal obligations. Credentials, secrets, and unnecessary sensitive data should not be copied into broadly accessible change tickets; access-controlled links to appropriate systems are preferable when evidence is sensitive.

An audit trail is only as useful as its completeness and meaning. A record containing many mandatory fields but no reliable authorization or actual outcome evidence is weak, even if the ITSM form appears filled in. Conversely, a concise record with traceable approvals, deployment evidence, and verifiable results may support stronger assurance than a lengthy narrative reconstructed after the event.

Quality, reporting, and common weaknesses

Change records can support analysis of control performance and service risk when fields and outcomes are consistently defined. Examples include missing authorization evidence, changes implemented outside their approved windows, incomplete records awaiting closure, unsuccessful or backed-out changes, repeat emergency changes, and incident links following deployments. Such measures should be segmented by change class, risk, and service criticality; otherwise differences in workload and classification can be mistaken for differences in control quality.

Common weaknesses include treating a draft request as approval, recording the planned outcome as though it occurred, failing to update the actual implementation time, leaving emergency actions undocumented, losing access to linked test reports, and closing records without identifying deviations or required follow-up. A second weakness is over-documentation: copying the same data manually across several tools can introduce discrepancies and encourage superficial completion.

Record integrity improves when each field has a clear purpose, evidence is captured close to the actual event, identity and status changes are traceable, and closure is tied to the appropriate result. The objective is to establish a reliable account of the change rather than to produce paperwork for its own sake. The IRS's 2026 process connects change logging, assessment, authorization, implementation, review, and closure; Northern Arizona University likewise describes retaining the full request-to-review history for audit and analysis.

Terminology and scope

This page concerns a change record as an operational ITSM lifecycle and evidence object. The concept is separate from the RFC proposal, the procedure governing a category of change, a shared change calendar, and a configuration database. A change record is also different from a request to correct an existing data record or an organizational change management log of employee-adoption actions.

Historical ITIL sources sometimes describe a distinct change record created for each RFC. Current service-management software may instead call the full lifecycle object a change request or change ticket. Local naming is less important than preserving the distinction between what was proposed, what was authorized, what happened, and the verified outcome.

See also

• Request for Change
• Change Enablement
• Change Authority
• Change Advisory Board
• Change Model
• Change Schedule
• Standard Change
• Normal Change
• Emergency Change
• Configuration Management Database (CMDB)
• Post Implementation Review
• Release Management