Configuration Management Plan

Approach basics §4 sub-section

Tools, baselines, and the change-request flow that everything else hangs off.

Configuration management tool / repository of record * Tool, repo, or system holding your authoritative configuration baselines (e.g., GitHub Enterprise, Ansible Automation Platform, SCCM, Puppet Enterprise, Chef, Salt).

How are baselines documented and stored? Where baseline configurations live and how they're versioned. Example: 'In a Git repository under config/baselines/, tagged at each release. Hardware inventory tracked in ServiceNow CMDB.'

Change-request workflow Workflow from change request through review, approval, implementation, and verification. Mention tooling (Jira, ServiceNow), approval thresholds, and the emergency change pathway.

Configuration Control Board §4 sub-section

Membership, quorum, decision authority, and emergency-change criteria.

CCB chair role Role title (e.g., 'Director of Engineering') rather than a named individual; the role outlasts the person.

CCB meeting cadence — Select — Weekly Bi-weekly Monthly Quarterly Ad hoc / on demand

CCB voting membership

Add item

Roles that hold votes. Example list: System Owner, ISSO, ISSM, Engineering Lead, Network Lead.

Quorum requirement Number or percentage of voting members required to make a binding decision (e.g., '4 of 6', 'simple majority').

Decision thresholds What changes require simple majority vs unanimous? What's the threshold for changes affecting the security posture?

Emergency change criteria + pathway What qualifies as an emergency change? Who can authorize? What's the retroactive review window?

Documentation standards What's recorded for each CCB meeting? Where are minutes stored? Retention?

Configuration Item Identification §3 sub-section

How CIs are named, classified, and related to each other.

CI naming convention How CIs are named, e.g., '<env>-<role>-<serial>' or 'aws/<account>/<region>/<resource_id>'.

CI categories tracked

Hardware Software Firmware Documentation Configuration files Network components Cryptographic keys / certificates Cloud resources

Relationship-mapping approach How dependencies between CIs are documented (e.g., 'CMDB relationship table with hosts → applications → databases'). Critical for impact analysis.

Version-control structure Branch / tag / release strategy used to track CI versions.

Hardening sources §4 sub-section

Authoritative configuration sources cited for CM-6 baseline composition.

Cited hardening sources

Add item

Suggested: + DISA STIGs + CIS Benchmarks + NIST SP 800-70 NCP + Vendor hardening guides + Internal hardening standard

Add each authoritative source. Suggestions auto-populate one click; you can edit or add custom entries.

Configuration Audit Strategy §4 sub-section

Functional vs physical audits, frequency, roles, and reconciliation.

Audit types performed

Functional Configuration Audit (FCA) Physical Configuration Audit (PCA) Software composition audit License audit

Audit frequency How often each audit type runs (e.g., 'FCA quarterly, PCA annually').

Independent assessor role Role responsible for independent verification (e.g., 'Internal Audit', 'Third-party assessor').

System-owner role in audit What the System Owner provides / signs off during the audit.

Reconciliation process How discrepancies between audited configuration and the documented baseline are reconciled, who decides, and how it's tracked.

Exception Management §4 sub-section

Approval workflow, time-bound waivers, POA&M linkage, and revalidation.

Deviation / waiver approval workflow Who can request, who reviews, who approves a deviation from baseline. Reference CCB if relevant.

Maximum waiver duration Hard limit on how long a waiver can stand before it must be revisited (e.g., '90 days', '6 months').

POA&M linkage How active waivers are tracked in the POA&M (e.g., 'Each waiver opens a POA&M item with milestone = waiver expiration').

Revalidation cadence How often open waivers are reviewed for continued applicability.

Backup & Recoverability of Baselines §6 sub-section

Recoverability, versioning, and integrity protection for configuration data (CM-9 / CP overlap).

Recoverability approach How baselines + supporting configuration data can be restored if lost or corrupted. RTO / RPO if defined.

Versioning scheme How successive baseline versions are tracked (Git tags, retention policy on snapshots, etc.).

Integrity protection How baselines are protected from undetected modification (signed Git tags, SHA-256 hashes in CMDB, etc.).

Drift Detection Automation §6 sub-section

Tooling, frequency, alerting, and integration with SIEM / ticketing.

Drift detection tooling What runs the periodic comparison (SCCM compliance baselines, Tenable, Ansible idempotent run, custom scripts, etc.).

Scan frequency How often drift detection runs (e.g., 'continuous', 'daily', 'weekly').

Alert thresholds What level of drift triggers a page vs a daily summary. How false positives are tuned out.

SIEM / ticketing integration Where drift findings flow (SIEM rule, Jira queue, ServiceNow incident). Owner of triage.

CM Metrics & KPIs §6 sub-section

Metrics tracked to demonstrate CM control effectiveness over time.

Tracked metrics

Add item

Suggested: + % assets compliant with baseline + Mean time to remediate drift + Unauthorized changes detected per quarter + % changes routed through CCB (vs emergency / out-of-band) + % emergency changes + Time to detect drift (median) + Open exceptions / waivers (count + age)

Add each metric your program reports on. Suggestions are common picks; customize as needed.

Configuration Documentation Control §4 sub-section

Versioning schema, approval signatures, and retention requirements.

Versioning schema Format used for plan / baseline document versions (e.g., 'MAJOR.MINOR.PATCH', '<year>.<release>').

Required approval signatures

System Owner ISSO ISSM CCB Chair Authorizing Official Privacy Officer

Retention period How long approved baseline documents and supporting records are retained (e.g., '7 years post-decommission', 'per NARA GRS 4.2').

Cross-references to other RMF artifacts §7

Where this plan plugs into the broader RMF package.

SSP section reference Where in the SSP the CM control implementations are summarized (e.g., 'SSP §13.5').

POA&M ID prefix for CM findings Convention used to identify CM-related POA&M items (e.g., 'CM-' or 'POAM-CM-####').

RA-5 scan source feeding CM Vulnerability scanner whose output drives CM remediation (e.g., 'Tenable.sc Container A', 'Nessus Manager').

CA-7 continuous-monitoring strategy reference Pointer to the CA-7 monitoring strategy document that ties CM continuous-monitoring activities to the broader ConMon plan.