Change Management Process

To meet the change management process requirement, you must route changes to in-scope IT and OT assets through a documented workflow where the change is evaluated for risk and impact, approved by an authorized approver, then implemented with traceable records. Your goal is simple: no production change without prior review, approval, and evidence. ¹

Key takeaways:

• You need a single, repeatable workflow for evaluating and approving IT and OT asset changes before implementation. ¹
• Evidence matters as much as process: keep change tickets, approvals, testing, backout plans, and post-implementation validation. ¹
• The highest-risk failure mode is “silent drift” from approved baselines, especially in OT where changes are often informal. ¹

“Change management process requirement” usually sounds like a generic IT control, but C2M2 ASSET-3.A is blunt and operational: changes to IT and OT assets must be evaluated and approved before implementation. ¹ If you run critical infrastructure or support industrial operations, the control is not optional ceremony. It is the mechanism that prevents unauthorized configuration changes, untracked software installs, unsafe OT modifications, and security exceptions that become permanent.

For a CCO, GRC lead, or compliance officer, the fast path is to translate this requirement into: (1) scope, (2) a change workflow with clear approval authority, (3) minimum required change record fields, and (4) retention-ready evidence. You are not trying to perfect ITIL. You are trying to prove that your organization consistently stops changes from reaching production (or the plant floor) until someone evaluates risk and signs off.

This page gives you requirement-level implementation guidance aligned to C2M2 v2.1, with practical steps you can run in a mixed IT/OT environment and defend during audits, customer due diligence, or internal control testing. ¹

Regulatory text

Requirement (C2M2 v2.1 ASSET-3.A, MIL1): “Changes to IT and OT assets are evaluated and approved before being implemented.” ¹

What the operator must do:
You must implement a process (people + workflow + records) that forces pre-implementation evaluation and approval for changes affecting in-scope IT and OT assets. “Evaluated” means you assess impact and risk; “approved” means an authorized person (not the requestor acting alone) authorizes the change; “before being implemented” means approvals occur prior to execution, not after-the-fact clean-up. ¹

Plain-English interpretation (what auditors expect you to mean)

• You know what counts as a “change” for your environment (configuration, patching, firmware, logic changes, network rule updates, onboarding/removal of assets, and exceptions).
• You have a consistent method to request, review, approve, implement, and validate changes.
• You can show records that link: request → evaluation → approval → implementation evidence → post-change validation.
• The same expectation applies to OT, even if OT has different safety constraints, outage windows, and vendor involvement. ¹

Who it applies to (entity and operational context)

Entity types in scope: energy sector organizations and other critical infrastructure operators using C2M2 to assess maturity for a defined scope. ¹

Operational contexts where this control is tested hard:

• Hybrid IT/OT environments: changes may happen through different tools (ITSM vs. maintenance logs), with different owners (IT vs. engineering).
• Third-party supported OT systems: OEMs/integrators frequently make “quick fixes” that bypass your normal governance unless you explicitly route them through your process.
• Remote access and emergency work: urgent changes are common, but “urgent” cannot mean “unapproved.” You need an emergency path with tight documentation. ¹

What you actually need to do (step-by-step)

Step 1: Define scope and change triggers

1. List in-scope asset classes (minimum): servers, network devices, endpoints, cloud workloads, OT controllers, HMIs, historians, safety systems, and supporting infrastructure.
2. Define what constitutes a change using a short, enforceable definition: any modification that affects availability, integrity, security, safety, monitoring, or asset inventory/baseline.
3. Map change triggers to real activities:
   • Patch/firmware upgrades
   • Configuration changes (including firewall rules and routing)
   • Software installs/uninstalls
   • OT logic changes and setpoint changes (where applicable)
   • Asset install/removal and network re-segmentation
   • Security exceptions (temporary admin access, disabled controls) ¹

Step 2: Stand up a single workflow with tiers (standard / normal / emergency)

Build a simple classification that drives approval and evidence requirements:

Change type	Typical examples	Minimum pre-implementation approvals	Required evaluation
Standard (pre-approved)	Routine, low-risk with proven procedure	Process owner approval of the standard template; per-change record still required	Confirm matches template; verify prerequisites
Normal	Most production changes	Technical owner + system/asset owner; add security review when risk impacts security controls	Impact, risk, testing plan, rollback/backout
Emergency	Safety, outage, active incident containment	Verbal/rapid approval allowed but must be recorded; require post-implementation review	Document reason, risk acceptance, and validation steps

Keep this lightweight, but enforce it. If every change is treated like a major release, teams route around you.

Step 3: Define minimum required fields for every change record

Whether you use ServiceNow/Jira, an OT maintenance system, or Daydream as the evidence layer, each change record should contain:

• Unique change ID
• Requestor and implementer (separate when possible)
• Assets affected (hostnames, device IDs, OT tags, location, environment)
• Change description (what will change)
• Business/operational reason
• Risk and impact assessment (security, availability, safety where relevant)
• Test/validation plan and success criteria
• Backout/rollback plan (or “not feasible” with documented rationale for OT)
• Planned window and communications
• Approver(s) and timestamps (pre-implementation)
• Implementation notes (what actually happened)
• Post-implementation validation evidence (monitoring checks, functional tests) ¹

Step 4: Establish approval authority and segregation rules

Document who can approve which changes:

• Asset owner approval: required for changes that alter production behavior, uptime, or safety constraints.
• Security approval: required when changes modify security controls, access paths, segmentation, logging, monitoring, or introduce exceptions.
• OT engineering approval: required for OT control logic, firmware, and plant-floor network changes.
  Also document what is prohibited: self-approval for high-impact changes; “rubber stamp” approvals without review notes.

Step 5: Connect change management to asset inventory/baselines

C2M2’s asset focus means you must keep records current during installs/removals/exceptions. Two controls are consistently expected in practice:

• Define how your change management process updates records during changes, installations, removals, or exceptions so the underlying records stay current. ¹
• Retain change records, reconciliations, and periodic review evidence showing the inventory or baseline is accurate and maintained. ¹

Practical implementation:

• Require the change ticket to include “inventory/baseline update required: yes/no.”
• Add a closure step: “inventory updated” with a link or screenshot.
• Run periodic reconciliations between discovered assets and approved inventory; log discrepancies as tickets.

Step 6: Operationalize emergency changes without losing control

Emergency changes are where auditors find process failure. Set rules your operators can follow:

• Minimum required fields still apply (reason, asset, approver, timestamp, validation).
• If you allow rapid verbal approval, require documented confirmation in the ticket as part of closure.
• Perform a post-implementation review to decide if the emergency fix becomes permanent, needs follow-up hardening, or requires a formal risk acceptance record.

Step 7: Build a compliance-ready evidence package

For audits or customer diligence, prepare a “change management evidence binder” (folder or GRC collection) with:

• Change management policy/procedure (IT + OT coverage)
• Roles and approval matrix
• Standard change templates
• Sample of completed change records across IT and OT
• Evidence of reconciliations/periodic reviews tied to baselines/inventory ¹

Daydream fit (earned mention): if your teams run changes in multiple systems (ITSM for IT, maintenance logs for OT, spreadsheets for site work), Daydream can serve as the control evidence layer by standardizing required fields, collecting approvals, and packaging artifacts consistently across tools for audits.

Required evidence and artifacts to retain

Retain artifacts that prove pre-implementation evaluation and approval plus what actually changed:

1. Change request/ticket with required fields completed
2. Risk/impact review notes (including security and operational impact)
3. Approval evidence (name, role, timestamp; meeting minutes if CAB used)
4. Test plan + results (or validation steps for OT where testing is constrained)
5. Backout/rollback plan or documented rationale if infeasible
6. Implementation evidence (configuration diffs, deployment logs, command logs, screenshots where necessary)
7. Post-implementation validation (monitoring checks, functional verification)
8. Inventory/baseline update evidence and reconciliation logs ¹

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me three recent OT changes and prove they were approved before implementation.”
• “How do you prevent a third party (integrator/OEM) from making untracked changes?”
• “What qualifies as an emergency change, and who can approve it?”
• “How do you ensure the asset inventory/baseline stays accurate after installs/removals?” ¹
• “Pick one change: show end-to-end evidence from request through validation.”
  Hangup pattern: teams can produce a policy but cannot produce a clean sample set of records with timestamps and approvals.

Frequent implementation mistakes (and how to avoid them)

1. Approvals happen after the change.
   Fix: configure tooling so implementation fields cannot be completed/closed until approvals are recorded; train operators that after-the-fact approval is noncompliant for this requirement. ¹

2. OT is excluded “because it’s different.”
   Fix: maintain OT-specific pathways (longer windows, safety review, vendor coordination), but keep the same requirement: evaluate and approve before execution. ¹

3. No linkage to assets.
   Fix: require asset identifiers in every ticket; make “unknown asset” a rejected change request.

4. Inventory and baseline drift.
   Fix: add a closure checklist for inventory updates and keep reconciliation evidence. ¹

5. Change templates exist but aren’t used.
   Fix: define a small catalog of standard changes (routine patching, cert renewal, endpoint agent update) and enforce template-only execution.

Enforcement context and risk implications

No public enforcement cases are provided for this specific C2M2 requirement in the supplied sources. Operationally, the risk is still concrete: if change management records are inaccurate or outdated, systems drift from approved baselines and security decisions get made using incomplete asset information during internal control testing, audits, customer diligence, or regulator review. ¹

Practical 30/60/90-day execution plan

Use this as an operator’s rollout plan; adapt to your tooling and OT realities.

First 30 days: establish minimum viable control

• Confirm in-scope IT and OT asset classes and owners.
• Publish a one-page change definition and change types (standard/normal/emergency).
• Implement minimum required fields and an approval matrix.
• Identify where change records live today (ITSM, OT logs, spreadsheets) and define the system of record for evidence packaging.
• Start collecting exemplar change records (you will need these for audits).

Days 31–60: enforce and close the biggest gaps

• Configure workflow gates so approvals must exist before implementation status can be set.
• Add OT-specific change pathways (engineering/safety approval) while keeping the same evidence requirements.
• Implement the inventory/baseline update step on ticket closure and begin reconciliations. ¹
• Train third parties and internal teams: “no ticket, no change,” including integrator work.

Days 61–90: harden and make it auditable

• Build a repeatable evidence pack: policy, roles, templates, and a clean sample set of IT and OT change records.
• Review emergency changes and confirm post-implementation reviews are documented.
• Trend recurring change failures (missing asset IDs, missing approvals) and fix root causes.
• If data is fragmented, implement Daydream (or an equivalent evidence layer) to normalize records and approvals across IT and OT workflows.

Frequently Asked Questions

Do we need a formal Change Advisory Board (CAB) to meet this requirement?

No. You need evaluated and approved changes before implementation, with evidence. ¹ A CAB is one way to do approvals, but a documented approver matrix and ticketed workflow can also satisfy the requirement.

What counts as an “OT asset change” in practice?

Treat firmware updates, control logic changes, configuration changes, and network/remote access changes as changes that require pre-approval. ¹ If the action can alter performance, safety constraints, or security posture, route it through change control.

How do we handle emergency changes during outages or safety events?

Allow an emergency pathway, but still capture who approved, why it was necessary, what changed, and how you validated it afterward. ¹ Require a post-implementation review to prevent “temporary” exceptions from becoming permanent.

Our OEM/integrator performs changes remotely. How do we control that?

Contractually require tickets and approvals before work starts, and require the third party to attach implementation notes and evidence to the record. Tie remote access enablement to an approved change window so access is not open-ended.

Is patching considered a “change” that needs approval every time?

Yes, patching is a change. Many teams pre-approve routine patching as a “standard change” with a proven procedure, but still retain per-event records and validation. ¹

What evidence is most persuasive to an auditor?

Time-stamped approvals that occur before implementation, plus validation evidence after implementation, all tied to the specific assets affected. ¹ Inventory/baseline update proof is also high value because it shows the process stays current. ¹

What you actually need to do

Use the cited implementation guidance when translating the requirement into day-to-day operating steps. ²

Footnotes

1. Cybersecurity Capability Maturity Model v2.1

2. DOE C2M2 program