System Change Management

Track, review, approve or disapprove, and log changes to organizational systems.

Quoted verbatim from NIST SP 800-171 Rev. 2 §3.4.3.Source

An assessor determines each objective separately. “Mostly implemented” is not a result — every objective below has to stand on its own.

1. [a]

   changes to the system are tracked;

   1 example covers this

2. [b]

   changes to the system are reviewed;

   1 example covers this

3. [c]

   changes to the system are approved or disapproved; and

   1 example covers this

4. [d]

   changes to the system are logged.

   1 example covers this

Objective text quoted verbatim from NIST SP 800-171A via the CMMC Level 2 assessment guide.

• addresses[a][b][c][d]

  CM.L2-3.4.3 · System Change Management

  Track, review, approve or disapprove, and log changes to organizational systems.

  • [a]

    changes to the system are tracked;

  • [b]

    changes to the system are reviewed;

  • [c]

    changes to the system are approved or disapproved; and

  • [d]

    changes to the system are logged.

  Intended change versus actual change: reconciling tickets against what the tools logged

  CCControlVerdict Corpus@cv-corpusOSCJul 31, 2026

  Community is just starting — add yours. No verdicts yet.

  Implementation

  AO coverage. Addresses all four System Change Management objectives: changes are tracked [a], reviewed [b], approved or disapproved [c], and logged [d].

  Tracking [a]. Every change to an in-scope system has a ticket carrying the target system, the reason, the implementation plan, the rollback plan, and the security impact analysis described in the CM.L2-3.4.4 example. Configuration that lives in code is changed by pull request, and the pull request references the ticket, so the diff and the authorization are linked in both directions.

  Review and decision [b][c]. The review board meets weekly and records an explicit approve or disapprove — disapprovals are kept, because a change record showing only approvals suggests the review is decorative. Each change gets a reviewer who is not the implementer. Emergency changes may proceed with verbal approval from the on-call lead and must be back-filled with a full record within one business day; the emergency path is used a handful of times a year and each use is examined at the next board.

  Logging [d]. The ticket is the authorization record; the tool that made the change is the execution record. Firewall, directory, endpoint management, and cloud configuration changes emit events to the SIEM independently of the ticket system.

  Reconciliation — the part that makes it real. A weekly report lists configuration-change events with no matching ticket in the window. Those are investigated as either an undocumented change or a monitoring gap; the queue is expected to reach zero each week, and the first month of running it found three habitual out-of-process changes that no amount of policy text had fixed.

  Maintenance. Weekly reconciliation review; monthly metric on emergency-change count and back-fill timeliness; annual review of which system classes are in scope for the process as the environment shifts.

  Accepted gap. One appliance emits no configuration-change telemetry, so reconciliation cannot cover it. Compensating control: its administration is only possible from the jump host, and the jump host session recording is compared against tickets monthly by hand.

  What the evidence looks like

  • Change record template showing plan, rollback, reviewer, and decision fields
  • Board minutes including at least one disapproved change
  • Pull request linked to its change ticket
  • Weekly unmatched-change reconciliation report and an investigation outcome
  • Emergency change with its back-filled record and the board's review note

  Environment

  Small infrastructure team that used to edit firewall rules from memory during outages. A weekly review board now exists alongside a defined emergency path.

  Tools

  • Ticketing
  • Git
  • SIEM

  Edit history

  · No edits yet