Asset, change, and configuration management

To meet the C2M2 asset, change, and configuration management requirement, you must maintain an accurate asset lifecycle inventory and enforce secure configuration baselines where every material change is authorized, tested, implemented, and recorded. Operationalize it by defining scope, establishing “gold” baselines, running a controlled change workflow, and producing audit-ready evidence that systems match approved configurations. ¹

Key takeaways:

• You need a scoped, lifecycle-managed asset inventory that supports security decisions and assessments. ¹
• You need configuration baselines plus controlled change management that prevents drift from approved states. ¹
• Your “pass/fail” in reviews often depends on evidence: tickets, approvals, baselines, scans, and exception records.

“Asset, change, and configuration management” is one of those requirements that sounds generic until you are in an assessment, incident, or customer diligence call and realize nobody can answer basic questions: What assets are in scope? Who owns them? What configuration is approved? What changed last week, and was it authorized?

C2M2 frames the requirement plainly: maintain asset lifecycle and secure configuration management discipline. ¹ For a Compliance Officer, CCO, or GRC lead, the fast path is to translate that into a small set of non-negotiables: a complete-enough inventory for the scoped environment, defined configuration standards for key technologies, and a change process that produces traceable records from request through implementation and verification.

This page is written to help you operationalize the requirement quickly: who must participate, what to implement first, what evidence to retain, where audits bog down, and how to avoid the most common failure modes (like “we have a CMDB” that is not tied to actual discovery, or “we have change tickets” that do not map to baseline configuration changes). The goal is audit-ready discipline that also works in real operations. ¹

Regulatory text

C2M2 requirement (C2M2-02): “Maintain asset lifecycle and secure configuration management discipline.” ¹

What the operator must do (plain reading)

You must be able to:

1. Identify and manage assets through their lifecycle (from acquisition/onboarding through change, maintenance, and retirement) within the scope of your C2M2 assessment. ¹
2. Define and maintain secure configuration expectations (approved baselines) for those assets. ¹
3. Control and document changes so assets do not drift from approved states without visibility and authorization. ¹

Plain-English interpretation (what “good” looks like)

A practical interpretation that holds up in an assessment:

• You maintain an inventory that is “decision-grade,” meaning it can support patching, vulnerability management, incident response, access reviews, and control testing for the in-scope environment.
• You publish configuration baselines for the technologies that matter most (servers, endpoints, network devices, cloud accounts, OT systems, critical applications). A baseline can be a hardening standard, a template, or a desired-state configuration.
• You run a change process where changes are requested, risk-reviewed, approved, tested as appropriate, implemented by authorized personnel, and then verified. The record connects the change to the affected assets and the baseline it modified.
• You track exceptions explicitly (what is out of baseline, why, who approved it, how long it is allowed).

Who it applies to

Entities

This requirement is relevant to organizations using C2M2, particularly critical infrastructure operators and energy sector organizations, or any organization adopting C2M2 for a defined environment. ¹

Operational context (scope is everything)

Applies when your organization has adopted C2M2 for a scoped business unit, function, or operational technology environment and is assessing maturity within that defined scope. ¹

In practice, scope typically includes a defined set of:

• Networks and zones (corporate IT, OT, DMZ, cloud landing zones)
• Systems supporting critical functions
• Third-party managed infrastructure where you retain configuration responsibility or shared responsibility

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

The sequence below is designed for fast operationalization without boiling the ocean.

1) Define “in-scope assets” and ownership

• Write a one-page scope statement: environments, locations, business services, and exclusions.
• Define asset classes you will track (examples: servers, endpoints, network devices, cloud resources, OT controllers, applications, databases).
• Assign asset owner (business) and custodian (IT/OT) fields. If ownership is unclear, your inventory will decay fast.

Output: Asset management standard + scope statement.

2) Build or fix the asset inventory so it reflects reality

Minimum viable inventory fields that auditors and operators ask for:

• Unique identifier, hostname/asset tag, environment/zone, system role/criticality
• Owner/custodian, location, platform (OS/firmware), network identifiers
• Source of truth and last-seen timestamp (so you can prove it is maintained)

Collection approach:

• Prefer automated discovery (endpoint management, network discovery, cloud inventory) plus a reconciliation process to remove duplicates and investigate unknowns.
• Include third-party operated assets where your security posture depends on them (for example managed hosting or managed OT), even if the third party holds the keyboard. Track them with clear responsibility notes.

Control objective: inventory supports lifecycle and security decisions. ¹

3) Establish secure configuration baselines (“gold standards”)

Start where configuration risk is highest:

• Identity and access (core settings, MFA policies, privileged access workstations)
• Server and endpoint hardening (logging, encryption, local admin controls)
• Network device configuration (management access, SNMP, NTP, AAA, segmentation rules)
• Cloud account guardrails (logging, storage policies, IAM constraints)

Baseline mechanics that work:

• Store baselines in a controlled repository (policy library, configuration-as-code repo, or configuration management tool).
• Version each baseline and define who can approve changes to it.
• Define what “compliance to baseline” means (for example: desired state checks, config drift detection, periodic reviews).

Output: Baseline standards + version history + approval workflow. ¹

4) Run change management that is tied to assets and baselines

Your change process must answer: what changed, why, who approved, what was tested, what asset was impacted, and how you verified success.

Implement:

• A single intake path for changes (ticketing system) with required fields:
  • assets/CI impacted (must link to inventory)
  • risk rating and backout plan
  • testing/validation steps
  • security review trigger conditions (see below)
• A change approval model:
  • Standard changes (pre-approved, low risk, repeatable)
  • Normal changes (CAB or delegated approvers)
  • Emergency changes (expedited approval + after-the-fact review)
• A baseline-change linkage rule: changes that modify secure settings must reference the baseline (or update it) so drift is not institutionalized.

Security review triggers (examples you can operationalize):

• Changes affecting authentication, authorization, logging, encryption, network segmentation, remote access, or externally exposed services
• Changes to critical systems or high-impact OT environments
• Changes initiated by third parties

Output: Change policy + SOP + configured ticket workflow + CAB/approval roster.

5) Detect and manage configuration drift

This is where programs fail in audits: “we have a baseline” but no evidence that assets match it.

Implement drift controls:

• Scheduled configuration checks (agent-based, network-based, or cloud policy checks)
• Exception workflow: record deviation, risk acceptance, compensating controls, and expiration date
• Remediation tracking that ties back to the asset record and the baseline requirement

Output: Drift reports, exception register, remediation tickets.

6) Tie lifecycle events to controls (onboard, change, retire)

Define required actions for:

• Onboarding: inventory entry, baseline applied, logging enabled, owner assigned
• Significant change: change record, baseline validation, update inventory attributes
• Retirement: remove access, decommission securely, update inventory status, retain evidence

Output: Lifecycle checklists + decommission records.

7) Make it audit-ready (without creating busywork)

What assessors want is consistency and traceability, not extra documents. A small set of well-maintained records beats a large set of stale records.

If you use Daydream, map each asset class to: required baseline, evidence source (tool/report), and change record type. Then generate an evidence register per assessment scope so the review becomes a controlled export instead of a scavenger hunt.

Required evidence and artifacts to retain

Use this as your evidence checklist for C2M2-02. ¹

Governance artifacts

• Asset management standard (scope, ownership, minimum fields, lifecycle expectations)
• Configuration management standard (baseline definition, versioning, exception handling)
• Change management policy/SOP (approval, emergency change, testing, validation)

Operational records (sample-based is fine if consistent)

• Current asset inventory export for the scoped environment (with owner and status)
• Baseline documents/templates and version history, with approvals
• Change tickets showing:
  • request and business justification
  • security review evidence (when triggered)
  • approval
  • implementation notes
  • validation/verification and closure
• Drift/compliance reports and exception register with approvals and expiration
• Decommission records and access removal evidence for retired assets

Common exam/audit questions and hangups

Questions you should be ready to answer

• “Show me your in-scope asset inventory and explain how you keep it current.” ¹
• “What are your approved configuration baselines for critical technologies?” ¹
• “Pick a recent change. Prove it was approved, tested, implemented, and verified.” ¹
• “How do you detect configuration drift? What happens when you find it?”
• “How do you handle emergency changes and document after-the-fact review?”
• “How do third parties make changes, and how do you approve and record them?”

Hangups that slow assessments

• Inventory is manually maintained and out of sync with discovery.
• Assets exist in multiple tools with no reconciliation rules.
• Change tickets exist, but they don’t identify impacted assets or baseline controls.
• “Exceptions” are informal (Slack/email) and expire without reevaluation.

Frequent implementation mistakes (and how to avoid them)

1. Treating the CMDB as the control. The control is the lifecycle process that keeps inventory accurate. Fix by tying inventory updates to onboarding/offboarding and automated discovery.
2. Baselines that are PDFs nobody enforces. Fix by implementing technical checks (drift detection) and requiring baseline references in change tickets.
3. Change management that ignores security-impacting changes. Fix by embedding security triggers in the ticket workflow so reviews happen by rule, not by memory.
4. Emergency changes with no governance. Fix by requiring a post-implementation review record and baseline validation.
5. Third-party changes outside your process. Fix by contractually requiring change notifications/approvals for in-scope systems and capturing third-party change records as part of your evidence set.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this C2M2 requirement, so this page does not cite specific enforcement outcomes.

Operational risk still maps cleanly to what assessors look for: inaccurate or outdated asset, change, and configuration management leads to drift from approved baselines, and your security decisions may rely on incomplete asset information during internal control testing, audits, customer diligence, or regulator review. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and minimum controls)

• Freeze and publish the in-scope definition for the C2M2 assessment. ¹
• Identify systems of record for inventory, change tickets, and baseline documents.
• Produce a “minimum viable” asset inventory for in-scope assets; assign owners for the highest-criticality assets first.
• Define baseline approach for the top technologies in scope; publish initial versions with approvers.
• Update the change ticket template to require impacted assets and security trigger questions.

Days 31–60 (make it measurable)

• Implement automated discovery where feasible; set reconciliation rules between discovery and inventory.
• Start drift detection for at least one major asset class (endpoints, servers, network, or cloud).
• Stand up the exception register with approvals and expiry expectations.
• Run a sample audit on a handful of recent changes; fix missing fields and unclear approvals.

Days 61–90 (make it durable and audit-friendly)

• Expand baselines and drift checks across remaining critical asset classes.
• Formalize emergency change retrospective review and metrics (counts and common failure causes, reported internally).
• Integrate third-party changes: add contractual notice/approval requirements for in-scope managed services and capture their change evidence.
• Build an evidence pack template in Daydream (or your GRC tool): inventory export, baseline versions, change samples, drift reports, exception register.

Frequently Asked Questions

Do we need a “perfect” asset inventory to satisfy the asset, change, and configuration management requirement?

No. You need an inventory that is accurate enough to manage the lifecycle of in-scope assets and support configuration control decisions. Document scope, sources of truth, and how you reconcile discovery with records. ¹

What counts as a configuration baseline in practice?

A baseline is an approved definition of secure settings for a technology or system, with version control and an owner who approves changes. It can be a hardening standard, a template, or configuration-as-code, as long as you can show what is approved and what is deployed. ¹

How do we handle emergency changes without failing audits?

Allow emergency changes, but require documentation, approval logic, and a post-change review that includes validation against the baseline or updated baseline approval. Keep the emergency record tied to the impacted assets and evidence of verification. ¹

Our third party manages key infrastructure. Are we still responsible for change and configuration discipline?

If the systems are in your C2M2 scope and your risk depends on them, you need visibility and governance. Contract for notice/approval where needed, require change records, and capture evidence that configurations remain aligned with approved baselines. ¹

What evidence is most persuasive for assessors?

Traceability. An inventory export linked to actual assets, baseline versions with approvals, a set of change tickets that show request-to-verification, and drift/exception reports that show you detect and resolve deviations. ¹

How do we keep this from becoming a paperwork exercise?

Make tools produce the evidence as a byproduct of operations: required ticket fields, automated discovery feeds, baseline versioning, and scheduled drift checks. Then use Daydream to assemble an evidence register by scope instead of chasing screenshots. ¹

What you actually need to do

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

Footnotes

1. DOE C2M2

2. DOE C2M2 program