Change Logging

“Change logging” sounds basic until you scope it across OT, where changes happen through vendor laptops, engineering workstations, and controller configuration tools that were not built for audit trails. C2M2 v2.1 ASSET-3.B sets a clear expectation: changes to IT and OT assets are logged and records are maintained ¹. In practice, that means you need an operating definition of “asset change,” technical sources of truth that actually capture those changes, and a retention approach that lets you reconstruct events during an incident, internal control testing, customer diligence, or a regulator inquiry.

For a Compliance Officer, CCO, or GRC lead, the fastest route to operationalizing this requirement is to treat change logging as an evidence system, not a policy statement. You need: (1) scope and ownership, (2) minimum required log fields, (3) a workflow that binds approvals to logged changes, and (4) periodic review so you can show the control operates, not just that it exists.

If you already run an IT change management process (ITSM), the gap is usually OT coverage and evidence quality. If you already have OT MOC (management of change), the gap is often centralized retention and traceability to the asset inventory.

Regulatory text

Requirement (C2M2 v2.1 ASSET-3.B): “Changes to IT and OT assets are logged and records are maintained.” ¹

What this requires operationally

• You can’t rely on informal tickets, email threads, or tribal knowledge. You need a repeatable logging mechanism for changes affecting in-scope IT assets and OT assets, and you must retain records so you can produce them later ¹.
• “Records are maintained” is an evidence requirement. If you cannot produce change records that show the full story of a change, you will struggle to demonstrate maturity against ASSET-3.B in an assessment aligned to the DOE program’s C2M2 approach ².

Plain-English interpretation

Log every meaningful change to your IT and OT assets, and keep those logs long enough to support investigations, audits, and accountability. “Meaningful” should be explicitly defined by you and applied consistently across teams, including engineering and third parties who touch OT.

A practical definition most operators can implement quickly:

• A change is any action that alters an asset’s configuration, firmware/software version, security controls, network connectivity, identity/access posture, or operational logic.
• A log is a record that captures, at minimum: asset, change description, timestamp, actor, method/source, approval reference (or emergency rationale), and outcome (success/failure).

Who it applies to

Entity types and context

• Energy sector organizations and critical infrastructure operators using C2M2 to assess cybersecurity capability for a defined scope ¹.
• Applies to the business unit, site, or OT environment you have placed “in scope” for your C2M2 assessment ¹.

Operationally, you should include

• IT assets: servers, endpoints, network devices, identity systems, cloud resources, security tooling.
• OT assets: PLCs/RTUs, HMIs, historians, engineering workstations, safety systems interfaces, OT network gear, remote access appliances, and supporting Windows/Linux hosts.

Third-party impact Any third party performing maintenance, remote support, patching, configuration changes, or firmware updates can create changes that must be logged. You need contractual and technical mechanisms so their activity produces records you can retain.

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

1) Set scope and define “change” (make it auditable)

1. Declare in-scope asset classes (IT + OT) aligned to your C2M2 assessment boundary ¹.
2. Write a one-page “Change Logging Standard” that defines:
   • what constitutes a change (include examples),
   • required log fields (minimum dataset),
   • systems of record (where logs live),
   • retention expectation (state a rule, even if you later refine),
   • who owns review and exception approval.
3. Map change types to sources:
   • IT: ITSM tickets + endpoint management + network config backups + IAM audit logs.
   • OT: MOC records + engineering workstation logs + controller change exports + remote access logs.

Deliverable: a scope statement and change taxonomy that lets an auditor test completeness.

2) Implement a logging mechanism per asset class (don’t force one tool)

1. Pick a primary change record per environment:
   • IT: your ITSM change record (ServiceNow/Jira/etc.) plus system logs for verification.
   • OT: an OT change record (could be ITSM with OT-specific fields) plus engineering evidence.
2. Ensure each change event produces two things:
   • a workflow record (request/approval/implementation/closeout),
   • a technical trace (device log, config diff, backup snapshot, commit record, or exported audit log).

If you only have workflow records without technical trace, the change logging story collapses during incident reconstruction.

3) Bind approvals to changes (closed loop)

C2M2 ASSET-3.B is about logging and maintaining records, but in practice assessors will look for accountability: who authorized and who executed ¹.

Implement:

1. Approval criteria: what requires pre-approval vs standard change vs emergency change.
2. Provisioning steps for who can execute changes (especially in OT, where local admin and shared accounts are common).
3. Revocation triggers: when a contractor leaves, when an engagement ends, when a site transitions to a new integrator (aligns to the “approval criteria…revocation triggers” control intent in your provided best-practice set) ¹.
4. Periodic review cadence: a scheduled review of change records for completeness and policy compliance ¹.

4) Protect and retain the records (tamper resistance and retrievability)

1. Centralize change records in a system with role-based access and reliable export/search.
2. Restrict who can edit/erase logs. If deletion is possible, require a privileged workflow and keep an audit trail of the deletion action.
3. Back up the change logging repository and validate restore.
4. Document retention: define how long you keep records and how you handle legal holds. Use a rule you can execute consistently; inconsistency is what auditors flag.

5) Validate completeness (the exam-style test)

Run a monthly (or similarly regular) control check:

• Pick a sample of assets and ask: “Show me all changes to this asset for the period.”
• Cross-check against independent signals: vulnerability scanning “last seen patch,” endpoint config baselines, network config diffs, remote access session logs, OT engineer activity logs.
• Track exceptions (missing logs, shared accounts, undocumented emergency work) and drive remediation.

6) Operationalize for third parties (the usual failure point)

For any third party touching OT/IT in scope:

• Contractually require change records (tickets, work orders, maintenance logs) and timely delivery.
• Require named accounts (no shared accounts) where feasible, or compensating controls that preserve attribution.
• Route remote access through managed solutions that produce session logs you can retain.

Daydream note: if you need a defensible evidence pack quickly, Daydream is typically introduced here to standardize control narratives, map evidence to requirements like C2M2 ASSET-3.B, and track exceptions with approval and expiry so you can produce a clean audit trail without rebuilding your tooling stack.

Required evidence and artifacts to retain

Use this as an evidence checklist for ASSET-3.B:

Policy/standard

• Change Logging Standard (scope, definitions, minimum fields, retention, roles) ¹

Operational records

• Change tickets / work orders (approved, implemented, closed)
• Emergency change records with after-the-fact approval and rationale
• OT MOC records where applicable
• Access requests/approvals tied to change execution permissions (aligns to the provided best-practice evidence expectations) ¹

Technical proof

• Config backups and diffs for network devices and OT network gear
• System audit logs (IAM, endpoint management, EDR change events)
• Engineering workstation logs or exported controller audit trails
• Remote access session logs for internal admins and third parties

Oversight

• Review reports showing periodic validation results, exceptions, and remediation tracking ¹
• Exception register with business justification, approver, compensating controls, and expiry date

Common exam/audit questions and hangups

Auditors and assessors tend to test these points:

1. Completeness: “How do you know all changes are logged, including OT?”
   Hangup: You only show tickets, not device-side evidence.

2. Attribution: “Can you tie the change to a specific person or approved third party?”
   Hangup: Shared accounts on engineering workstations or controllers.

3. Traceability: “Show the approval, implementation steps, and verification for this change.”
   Hangup: Approvals live in email; implementation proof lives nowhere.

4. Retention and retrieval: “Can you produce last quarter’s OT changes quickly?”
   Hangup: Logs exist but are scattered across laptops, contractor portals, or individual file shares.

5. Exception handling: “What happens when logging isn’t possible?”
   Hangup: No documented compensating control or expiry, so exceptions become permanent.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Treating ITSM change tickets as the entire control	Tickets can be fiction if they don’t match what changed	Require technical trace (diff, export, audit log) for defined change classes
Ignoring “minor” OT changes	Small logic or setpoint changes can have large safety/availability impact	Define OT change categories; include configuration/logic changes explicitly
Shared/admin accounts for OT work	Breaks attribution and accountability	Move to named accounts or add session recording + strict check-in/out controls
No exception lifecycle	“Temporary” becomes permanent	Use an exception register with approval and expiry, then review regularly
Logs that can be edited/deleted without trace	Undermines integrity	Restrict permissions, audit admin actions, and back up logs

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should avoid tying ASSET-3.B directly to specific penalties or outcomes. The practical risk is still concrete: weak change logging makes it hard to justify access and change decisions during audits, customer diligence, or regulator review, and it slows incident investigation because you cannot reconstruct what changed ¹.

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Confirm in-scope IT/OT boundaries for your C2M2 assessment ¹.
• Publish the Change Logging Standard (definitions, minimum fields, systems of record, roles).
• Identify top change sources (ITSM, IAM, remote access, engineering workstations).
• Start an exception register immediately for known gaps (shared accounts, unloggable devices).

Days 31–60 (connect logging to reality)

• Require technical trace attachments for high-risk change categories (network, identity, OT logic/config).
• Implement a basic monthly completeness review with sampling and cross-checks.
• Update third-party requirements: named accounts, remote access logging, record delivery expectations.
• Train OT engineering leads on “what must be logged” and “what evidence must be saved.”

Days 61–90 (prove operation and tighten controls)

• Produce a packaged evidence set: standard, sample change records, technical traces, review reports, exception lifecycle.
• Reduce exception volume by remediating the easiest gaps (centralize logs, remove shared accounts where feasible).
• Add monitoring or automation where it improves coverage (config backup cadence, audit log exports).
• Decide how you will keep the control healthy: ownership, review schedule, metrics (qualitative is fine if you can’t defend numbers).

Frequently Asked Questions

What counts as a “change” for change logging in OT?

Any modification to configuration, logic, firmware/software version, network connectivity, or security settings for an in-scope OT asset should be treated as a change and logged. Define this explicitly in your Change Logging Standard so engineering teams apply it consistently ¹.

Do we need one centralized tool for all IT and OT change logs?

No, but you need a defensible system of record and a way to retrieve records across sources. Many organizations keep IT changes in ITSM and OT changes in MOC or OT-specific records, then centralize evidence retention and reporting.

How do we handle emergency changes where pre-approval isn’t practical?

Require an emergency change record with who executed, what changed, and why, plus after-the-fact approval and verification. Track emergency changes in your periodic review and require remediation if they become routine.

What’s the minimum evidence an auditor will accept?

Expect to show a change record (request/approval/implementation/closeout) plus technical proof that the asset actually changed. If you can’t produce both, document a compensating control and an exception with an expiry.

Our OT devices can’t generate audit logs. Can we still meet the requirement?

Yes, if you implement compensating records such as engineering workstation logs, configuration exports saved to a controlled repository, and strict change workflows that require evidence attachments. Document the limitation and manage it through an exception process ¹.

How should we address third parties who perform maintenance and changes?

Make change logging a contractual and operational requirement: named access, remote session logging where feasible, and delivery of work records tied to your asset inventory. Validate their records during periodic reviews, the same way you validate internal teams.

Footnotes

1. Cybersecurity Capability Maturity Model v2.1

2. DOE C2M2 program; DOE C2M2 Program (U.S. DOE CESER)