Configuration Management Procedure

Approval #

Revision History #

Review cycle: Every year, under the Policy and Procedure Management Policy.

1. Purpose #

The people named in this procedure use it to carry out the CM control family policy (POL-CM). It covers every control in the configuration management family. The steps, the people responsible, and the evidence below show how the Organization meets those National Institute of Standards and Technology (NIST) SP 800-53 Rev. 5 controls. They also support the Inspector General (IG) Federal Information Security Modernization Act (FISMA) reporting metrics.

This general procedure covers every control in the CM family. A system that departs from it, or adds to it, has its own system-specific procedure for those controls.

2. Scope #

This procedure applies to every information system that the Organization operates, or that others operate for it, under the high security baseline.

2.1 CSF 2.0 Alignment #

The steps in this procedure support these NIST Cybersecurity Framework (CSF) 2.0 categories:

• ID.AM — Asset Management (Identify function)
• PR.PS — Platform Security (Protect function)
• DE.CM — Continuous Monitoring (Detect function)

3. Controls Covered #

This procedure covers the following 34 controls in the CM family:

3.1 Derived Governance Requirements #

The requirements below come from federal governance sources and apply to the CM control family. They add to the NIST SP 800-53 control requirements that the Procedure section carries out.

CISA BOD 26-04: Prioritizing Security Updates Based on Risk

• The organization must remediate vulnerabilities identified in the CISA Known Exploited Vulnerabilities (KEV) catalog according to risk-based timelines. Vulnerabilities with higher KEV Status, Exploit Automation, Technical Impact, and Asset Exposure scores must be prioritized. Deadline: Risk-based timeline per KEV catalog. (CISA BOD 26-04, §1)

CISA BOD 26-02: Mitigating Risk From End-of-Support Edge Devices

• The organization must identify all end-of-support (EOS) edge devices on the network and plan to replace or mitigate each one, because these devices no longer receive security patches. (CISA BOD 26-02, §1)

CISA BOD 25-01: Implementing Secure Practices for Cloud Services

• The organization must implement secure configuration baselines for cloud computing environments, including monitoring for configuration drift and enforcing baseline compliance through automated tooling. (CISA BOD 25-01, §2)

CISA BOD 23-01: Improving Asset Visibility and Vulnerability Detection

• The organization must maintain continuous and comprehensive asset visibility through active scanning, passive flow monitoring, log queries, or API queries. Asset inventory must be kept current to enable effective vulnerability management. (CISA BOD 23-01, §1)

FedRAMP CR26: FedRAMP Consolidated Rules for 2026 (including 20x Key Security Indicators)

• The organization must review each provider’s Secure Configuration Guide and set the Organization’s security settings in the cloud service to match it. (FedRAMP Consolidated Rules for 2026, AGU-USE-RSG)

OMB M-21-30: Protecting Critical Software Through Enhanced Security Measures

• The organization must identify the EO-critical software the Organization uses or is acquiring, and apply NIST’s security measures for EO-critical software to it. (OMB M-21-30; EO 14028, §4(g)-(i))

CISA/NSA/FBI 2026 Minimum Elements for a Software Bill of Materials (SBOM)

• The organization should incorporate SBOM data into the system component inventory so that software components and their dependencies are traceable, supporting vulnerability correlation (including KEV catalog matching) and change management. (CISA 2026 SBOM Minimum Elements, Discussion)

NIST SP 800-128: Guide for Security-Focused Configuration Management of Information Systems

• The organization should analyze the security impact of each proposed change before approval, and check after the change that controls still work as intended. (NIST SP 800-128, §3.3)

4. Procedure #

4.1 General Implementation Approach #

The Organization implements the CM controls in two ways: as organization-wide common controls that systems inherit, and as system-specific implementations where a system needs them. The control-specific procedures below cover each control in the Configuration Management family.

The Common Control Provider (CCP) implements controls marked inherited for the whole Organization. The CCP and each System Owner share the work for controls marked hybrid. Each System Owner implements controls marked customer-configured for the system.

Responsible party: The Configuration Manager carries out the steps in this procedure unless a control-specific procedure names someone else. The System Owner is accountable for funding and completing the work. The CISO oversees the procedure and receives its performance measures. See the CM policy (POL-CM) for the role definitions.

4.2 Control-Specific Procedures #

CM-01 — Policy and Procedures #

Baselines: Low / Moderate / High / Privacy CSF 2.0: PR.PS (Platform Security)

1. Develop, document, and disseminate to [Assignment: organization-defined personnel or roles — to be defined]:

1. [Selection (one or more): organization-level; mission/business process-level; system-level — to be defined] configuration management policy that:

1. Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
2. Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and

2. Procedures to facilitate the implementation of the configuration management policy and the associated configuration management controls;

2. Designate an [Assignment: organization-defined official — to be defined] to manage the development, documentation, and dissemination of the configuration management policy and procedures; and
3. Review and update the current configuration management:

1. Policy at least annually and following significant changes; and
2. Procedures at least annually and following [Assignment: organization-defined events — to be defined].

Procedure:

The CISO’s office keeps the master copies of POL-CM and PROC-CM as controlled documents on behalf of the designated officials. The CISO’s office tracks the review cycle and opens the review task in the policy library in the document management system every year. The CISO’s office opens an out-of-cycle review the same way after a major incident or a major change to applicable policy.

During a review, the document owner compares the text with current directives, the technology environment, and lessons from incidents and assessments. The document owner then sends the revision to the Authorizing Official, System Owners, Information System Security Officers (ISSOs), and the key stakeholders on the distribution list. The document owner records the approval in the review record, updates the version history, and keeps the superseded version.

The CISO’s office verifies distribution: the distribution record shows who received each revision and when. Evidence: the review records in the document management system with their triggers, the approval records, the version history, and the distribution log for each release of the policy and procedures.

CM-02 — Baseline Configuration #

Baselines: Low / Moderate / High CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security)

1. Develop, document, and maintain under configuration control, a current baseline configuration of the system; and
2. Review and update the baseline configuration of the system:

1. at least annually and when a significant change occurs;
2. When required due to include when directed by the AO; and
3. When system components are installed or upgraded.

Procedure:

The System Owner keeps each system’s baseline configuration under configuration control. The System Owner records the approved component list, the architecture placement, and the required settings, and gives each revision a version number. The System Owner links every revision to a ticketing system change record. Administrators deploy the endpoint baseline through the mobile device management (MDM) tool and enforce the domain baseline through group policy. Administrators build the cloud platform infrastructure from the approved templates for the environment.

Before a new or rebuilt component joins a production network, the administrator applies the approved baseline and the current patches. The administrator confirms both with a compliance scan and records the result on the change ticket. The ISSO records any exception as an approved deviation.

The System Owner and ISSO review each baseline every year against the running system. A significant change to the system boundary or architecture, a directive from applicable policy, or a component installation or upgrade requires an out-of-cycle update through the same change workflow. Configuration compliance scans run against the approved baseline and report drift. Each drift report becomes a remediation ticket in the ticketing system, assigned to the owning administrator.

Evidence: the versioned baseline records, the yearly review sign-offs, the ticketing system change tickets with pre-production scan results, and the scanner compliance reports that show deployed systems match the approved baseline.

CM-02(2) — Automation Support for Accuracy and Currency #

Baselines: Moderate / High

Maintain the currency, completeness, accuracy, and availability of the baseline configuration of the system using [Assignment: organization-defined automated mechanisms — to be defined].

Procedure:

The ticketing system configuration management database (CMDB) holds the authoritative baseline record for each system. The implementer updates the record for every component installation, removal, and upgrade as part of the change ticket, so the record changes with the system. The Organization reconciles vulnerability scan data against the CMDB on a recurring schedule. For each discrepancy, the Organization opens a correction ticket to the System Owner: a component that appears in a scan but not in the record, or a record with no live component behind it. Evidence: the CMDB baseline records with their version history, the reconciliation reports, and the correction tickets that closed each discrepancy.

CM-02(3) — Retention of Previous Configurations #

Baselines: Moderate / High

Retain organization-defined number of previous versions of baseline configurations of the previously approved baseline configuration of IS components of previous versions of baseline configurations of the system to support rollback.

Procedure:

After approval of a baseline revision, the System Owner keeps the superseded record in the CMDB version history. The System Owner also preserves the deployable artifacts behind it. These are the group policy backups, the MDM tool profile versions, and the cloud platform templates for the environment. If a change fails in production, the implementer redeploys the retained version through an emergency change ticket. Evidence: the CMDB version history showing at least one prior baseline per system, the retained artifact copies, and the rollback change records where a previous baseline was restored.

CM-02(7) — Configure Systems and Components for High-risk Areas #

Baselines: Moderate / High

1. Issue [Assignment: organization-defined systems or system components — to be defined] with [Assignment: organization-defined configurations — to be defined] to individuals traveling to locations that the organization deems to be of significant risk; and
2. Apply the following controls to the systems or components when the individuals return from travel: [Assignment: organization-defined controls — to be defined].

Procedure:

A traveler bound for a designated high-risk location requests a travel device through the ticketing system. The issuing team images a hardened laptop or a managed mobile device. The issuing team verifies full-disk encryption and the Agency Mobile Security Standard configuration through the MDM tool and records the issuance on the ticket. On return, the traveler gives the device back to the issuing team and does not connect it to the network. The issuing team inspects the device for signs of tampering and wipes or reimages it before it may connect to any organization system or process sensitive information. Evidence: the travel device tickets, the MDM tool configuration compliance records at issuance, and the inspection and reimage record that closes each loan.

CM-03 — Configuration Change Control #

Baselines: Moderate / High CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security), DE.CM (Continuous Monitoring)

1. Determine and document the types of changes to the system that are configuration-controlled;
2. Review proposed configuration-controlled changes to the system and approve or disapprove such changes with explicit consideration for security and privacy impact analyses;
3. Document configuration change decisions associated with the system;
4. Implement approved configuration-controlled changes to the system;
5. Retain records of configuration-controlled changes to the system for [Assignment: organization-defined time period — to be defined];
6. Monitor and review activities associated with configuration-controlled changes to the system; and
7. Coordinate and provide oversight for configuration change control activities through [Assignment: organization-defined configuration change control element — to be defined] that convenes [Selection (one or more): [organization-defined]; when [organization-defined] — to be defined].

Procedure:

Every configuration-controlled change begins as a ticketing system change request. The requester records the description, the affected components, and the rollback plan. A request for a temporary firewall or boundary rule also records the date the rule ends. The ISSO completes the security and privacy impact analysis before the request reaches the board. The Configuration Control Board meets at least [CM-03 parameter 3 — to be defined] to decide the queue. The board chair convenes the board out of cycle for emergency changes and planned significant changes to system components. The board records its decision on the ticket: approval, disapproval, or conditions.

The implementer makes each approved change in the approved window and closes the ticket with the actual result, including any deviation from the plan. On a temporary rule’s end date, the network team removes the rule and records the removal on the ticket. The ISSO monitors change activity against the approved records. The ISSO handles a change found in production without a matching approval as an unauthorized change.

The Organization keeps change records in the ticketing system for at least [CM-03 parameter 1 — to be defined].

Evidence: the change tickets with their impact analyses, the board minutes and decisions, the implementation records, the temporary rule removals, and the unauthorized-change reviews.

CM-03(1) — Automated Documentation, Notification, and Prohibition of Changes #

Baselines: High

Use [Assignment: organization-defined automated mechanisms — to be defined] to: (a) Document proposed changes to the system; (b) Notify [Assignment: organization-defined approval authorities — to be defined] of proposed changes to the system and request change approval; (c) Highlight proposed changes to the system that have not been approved or disapproved within organization agreed upon time period; (d) Prohibit changes to the system until designated approvals are received; (e) Document all changes to the system; and (f) Notify organization defined configuration management approval authorities when approved changes to the system are completed.

Procedure:

A requester opens a change request in the ticketing system that describes the change, its reason, and its security impact. The ticketing system routes the request to each approver and sends a notice. The ticketing system flags any request that has no decision after the set period and alerts the approvers. The ticketing system holds the implementation tasks until every required approval is in place. The implementer records the completed work in the request, and the ticketing system notifies the designated personnel that the change is closed. Evidence: change requests with approval history, overdue-request flags, and closure notices in the ticketing system.

CM-03(2) — Testing, Validation, and Documentation of Changes #

Baselines: Moderate / High

Test, validate, and document changes to the system before finalizing the implementation of the changes.

Procedure:

When a change request is submitted, the engineer assigned to it stages the change in a non-production environment that mirrors the target. The engineer runs the test plan attached to the ticketing system change request and records the results on the ticket before the Change Control Board finalizes approval. If the change cannot be rehearsed outside production, the engineer schedules a planned maintenance window with rollback ready and validates the change after implementation. The engineer cannot close a change ticket without its testing evidence. Evidence: the test plans and results on each change ticket, the validation sign-offs, and the post-implementation verification notes.

CM-03(4) — Security and Privacy Representatives #

Baselines: Moderate / High

Require [Assignment: organization-defined security and privacy representatives — to be defined] to be members of the Configuration control board (CCB) or similar (as defined in CM-3).

Procedure:

The CCB charter records the board’s membership. The roster names the CISO or a delegated official and the Chief Privacy Officer or a delegated official as standing members. Each ticketing system change request includes its security and privacy impact analysis. The security and privacy members speak to the analysis during the board’s decision, and the meeting minutes record their concurrence or objection. When either representative cannot attend, the delegate attends with full authority. The board holds any decision that requires their review until the representative or the delegate can give it. Evidence: the CCB charter and roster, the meeting minutes showing security and privacy participation, and the change records with their decisions.

CM-03(6) — Cryptography Management #

Baselines: High

Ensure that cryptographic mechanisms used to provide the following controls are under configuration management: All security safeguards that rely on cryptography.

Procedure:

Administrators record each system’s cryptographic settings in its approved baseline, including modules, protocols, cipher suites, and certificates. They enforce the settings through group policy on domain systems, the MDM tool on managed devices, and configuration templates in the cloud platform. Any change to these settings starts as a change request in the ticketing system that the ISSO reviews for security impact. Configuration compliance scans compare live settings with the baseline and report drift. The owning administrator corrects drift through a change request. Evidence: approved baselines, change requests with ISSO review, and scan reports.

CM-04 — Impact Analyses #

Baselines: Low / Moderate / High / Privacy CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security), DE.CM (Continuous Monitoring)

Analyze changes to the system to determine potential security and privacy impacts prior to change implementation.

Procedure:

The ISSO receives the impact analysis task in the ticketing system when a requester opens a change request. The request cannot advance until the ISSO completes the analysis. The ISSO follows the security impact analysis steps in NIST SP 800-128. The ISSO first confirms what the change does. The ISSO then looks up known vulnerabilities in the National Vulnerability Database or scans the affected hosts. Next the ISSO assesses the risk, finds the affected controls in the System Security and Privacy Plan (SSPP), and plans safeguards. The ISSO consults the Privacy Officer when the change touches personal information.

The ISSO also decides whether the change counts as significant. If it does, the Security Control Assessor reviews it, and the Authorizing Official decides on reassessment or reauthorization before the change reaches production. The System Owner signs the completed analysis. The Configuration Control Board considers the analysis, and its conditions become conditions of approval. For an emergency change, the ISSO completes the same analysis before the ticket closes. The Security Impact Analysis and Significant Change section of the Configuration Management procedure gives the full steps.

Evidence: the signed impact analysis on each change ticket, the privacy consultation records, the significant-change decisions, and the board decisions.

CM-04(1) — Separate Test Environments #

Baselines: High

Analyze changes to the system in a separate test environment before implementation in an operational environment, looking for security and privacy impacts due to flaws, weaknesses, incompatibility, or intentional malice.

Procedure:

The implementer deploys each proposed change to the test environment and records the test plan in the ticketing system change request. Testers run functional checks and vulnerability scans against the test build. They note any new vulnerability, failed setting, or conflict with other components. The ISSO reviews the results for security and privacy effects and records a recommendation in the change request. The change moves to production only after that review. Evidence: test plans, scan results, and ISSO review notes in the ticketing system.

CM-04(2) — Verification of Controls #

Baselines: Moderate / High

After system changes, verify that the impacted controls are implemented correctly, operating as intended, and producing the desired outcome with regard to meeting the security and privacy requirements for the system.

Procedure:

Post-implementation verification is a closure gate on the ticketing system change ticket. After deployment, the ISSO re-checks each control the impact analysis flagged. The ISSO compares configuration settings against the approved baseline, runs a targeted vulnerability scan to validate security-relevant settings, and runs functional checks to confirm the control still behaves as designed. The ISSO records the results on the ticket. For a degraded control, the ISSO opens a remediation task or starts a rollback through the emergency change path. Evidence: the verification records on each change ticket, the scan results that support them, and the remediation or rollback records where verification failed.

CM-05 — Access Restrictions for Change #

Baselines: Low / Moderate / High CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security)

Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system.

Procedure:

Each system’s documented access restrictions name the roles authorized to implement configuration-controlled changes and the physical and logical controls that enforce the limit. The identity team implements the logical side. Group policy scopes administrative rights on domain-joined systems, and the cloud platform access policies limit infrastructure changes to the authorized change-implementer roles. Physical access to the spaces that house change interfaces follows the same authorization records.

A person requests change authorization through the ticketing system, tied to role and need, and the System Owner approves or denies it. The System Owner removes the authorization as soon as the person’s duties change, without waiting for a scheduled review. The ISSO reconciles who holds change access against the documented restrictions and opens corrections where they differ.

Evidence: the approved access restriction documentation for each system, the authorization requests and approvals, the enforced group policy and identity and access management (IAM) policy exports, and the reconciliation records.

CM-05(1) — Automated Access Enforcement and Audit Records #

Baselines: Moderate / High

1. Enforce access restrictions using [Assignment: organization-defined automated mechanisms — to be defined]; and
2. Automatically generate audit records of the enforcement actions.

Procedure:

Multi-factor authentication gates the accounts that hold change rights. The privileged access management capability brokers and records each privileged session. Enforcement events flow to the security information and event management tool as they occur. The mechanisms generate audit records of enforcement actions automatically; no one assembles them by hand. The ISSO reviews denied attempts and unusual elevation patterns and opens an unauthorized-change investigation through the ticketing system when the record warrants it. Evidence: the automatically generated enforcement audit records, the session records for privileged change activity, and the review tickets that followed anomalies.

CM-05(5) — Privilege Limitation for Production and Operation #

Baselines: Moderate / High

1. Limit privileges to change system components and system-related information within a production or operational environment; and
2. Review and reevaluate privileges at least quarterly.

Procedure:

The System Owner assigns production change privileges by role and keeps the roster short. The identity team implements the limits through group policy scoping on domain systems and the cloud platform access policies in cloud environments. As a result, a production change requires membership in a group the System Owner explicitly approved. A person requests production change access through a ticketing system ticket with a justification, and the System Owner approves or denies it. On the established review cycle, the System Owner and ISSO reevaluate every production privilege against current duties and withdraw what no longer fits. Evidence: the approved privilege roster, the access request tickets, the policy exports showing the enforced limits, and the review records with the withdrawals made.

CM-06 — Configuration Settings #

Baselines: Low / Moderate / High CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security), DE.CM (Continuous Monitoring)

1. Establish and document configuration settings for components employed within the system that reflect the most restrictive mode consistent with operational requirements using [Assignment: organization-defined common secure configurations — to be defined];
2. Implement the configuration settings;
3. Identify, document, and approve any deviations from established configuration settings for [Assignment: organization-defined system components — to be defined] based on [Assignment: organization-defined operational requirements — to be defined]; and
4. Monitor and control changes to the configuration settings in accordance with organizational policies and procedures.

Procedure:

The configuration management team selects each platform’s baseline under the Secure Configuration Baseline Standard (STD-CFG-001) and builds the enforced settings from it. Administrators apply and maintain endpoint settings through the MDM tool, enforce domain settings through group policy, and configure the cloud platform environments to the approved cloud baseline.

Before a new or rebuilt component joins a production network, the administrator applies the baseline settings and current patches and runs a compliance scan. The administrator connects the component only after the scan shows no unapproved deviation and no missing patch.

A requester opens a deviation request in the ticketing system with its operational justification and risk rationale. The approver listed in the standard for that kind of setting decides it, and the ISSO records each approved deviation. Configuration compliance scans run at the frequency the standard sets, against the baseline plus the approved deviations. Each drift finding becomes a remediation ticket for the owning administrator, due within the standard’s fix time. A rescan verifies closure.

Evidence: the baseline register, the pre-production scan results, the approved deviations, the compliance scan reports, the drift tickets with closure verification, and the change records behind every settings change.

CM-06(1) — Automated Management, Application, and Verification #

Baselines: Moderate / High

Manage, apply, and verify configuration settings for [Assignment: organization-defined system components — to be defined] using [Assignment: organization-defined automated mechanisms — to be defined].

Procedure:

Endpoints enroll in the MDM tool at provisioning and receive the approved settings profiles. Domain-joined systems take their settings from group policy, which reapplies policy on its refresh cycle so local tampering does not persist. Configuration compliance scans provide the independent verification: they compare live settings with the approved configuration and report mismatches. Components that fall out of management, whether unenrolled, unreachable, or blocked from policy, appear on the tooling’s noncompliance reports. The Organization opens a ticketing system ticket for the owning administrator for each such component. Evidence: the enrollment and policy assignment records, the compliance scan results, and the noncompliance tickets with their resolution.

CM-06(2) — Respond to Unauthorized Changes #

Baselines: High

Take the following actions in response to unauthorized changes to [Assignment: organization-defined configuration settings — to be defined]: [Assignment: organization-defined actions — to be defined].

Procedure:

Configuration compliance scans and the MDM tool compliance reports detect settings that differ from the approved baseline. Each detection opens a ticket in the ticketing system assigned to the owning administrator. The administrator notifies the System Owner and ISSO, then investigates who made the change and why. The administrator restores the approved setting, through group policy where it applies, and confirms the fix by rescan. The administrator records the cause and the reason for each action in the ticket. Evidence: scan reports, tickets with notices, and rescan results.

CM-07 — Least Functionality #

Baselines: Low / Moderate / High CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security), DE.CM (Continuous Monitoring)

1. Configure the system to provide only [Assignment: organization-defined mission-essential capabilities — to be defined]; and
2. Prohibit or restrict the use of the following functions, ports, protocols, software, and/or services: [Assignment: organization-defined prohibited or restricted functions, system ports, protocols, software, and/or services — to be defined].

Procedure:

The System Owner documents each system’s authorized functions, ports, protocols, software, and services with the System Security and Privacy Plan (SSPP), and administrators build the enforced configuration from that record. Group policy disables auto-execute and restricts prohibited functions on domain systems. The MDM tool enforces the same restrictions on managed endpoints. The cloud platform network security rules limit cloud workloads to their documented ports and protocols.

Vulnerability scans list what is listening and installed on each system. The ISSO compares the results with the documented authorization. For a service with no documented justification, the ISSO opens a ticketing system ticket to the System Owner for removal. Where the mission requires the service, the CISO authorizes an exception and the System Owner records it against the SSPP. The System Owner removes peer-to-peer file sharing found running without CISO authorization; no one approves it after the fact.

Evidence: the documented port, protocol, and service authorizations, the scan results, the removal and exception tickets, and the updated SSPP records.

CM-07(1) — Periodic Review #

Baselines: Moderate / High

1. Review the system at least annually to identify unnecessary and/or nonsecure functions, ports, protocols, software, and services; and
2. Disable or remove [Assignment: organization-defined functions, ports, protocols, software, and services within the system deemed to be unnecessary and/or nonsecure — to be defined].

Procedure:

Every year, the ISSO pulls the current scanner list of listening services, open ports, and installed software for each system. The ISSO reviews the list with the System Owner against the documented authorization. They decide each unneeded or nonsecure item during the review: the ISSO opens a removal change request in the ticketing system, or the System Owner writes a retention justification when the mission requires the item. A rescan in the following cycle verifies each removal. Evidence: the yearly review records, the scan lists reviewed, the removal change tickets with rescan verification, and the retention justifications for items kept.

CM-07(2) — Prevent Program Execution #

Baselines: Moderate / High

Prevent program execution in accordance with [Selection (one or more): [organization-defined]; rules authorizing the terms and conditions of software program usage — to be defined].

Procedure:

The Organization enforces execution control where programs launch. Group policy applies script execution and software restriction policies to domain systems, and the MDM tool applies application control policies on managed endpoints. Administrators build both sets of policies from the authorized software list. A blocked execution attempt fails closed, and the system logs it. A user who needs software outside the list requests it through the ticketing system. On approval, the administrator updates the authorized list and the enforcement policies together, so the two never differ. Evidence: the enforcement policy exports, the execution block logs, and the software request tickets behind each policy update.

CM-07(5) — Authorized Software — Allow-by-exception #

Baselines: Moderate / High

1. Identify [Assignment: organization-defined software programs — to be defined];
2. Employ a deny-all, permit-by-exception policy to allow the execution of authorized software programs on the system; and
3. Review and update the list of authorized software programs at least quarterly or when there is a change.

Procedure:

The authorized software list is the enforcement source. Administrators generate the MDM tool application control policies and group policy software restriction policies from it, and the policies deny execution outside the list by default. A requester submits a request for new software through the ticketing system with a business justification. After security review and CISO approval, the administrator adds the entry and updates the enforcement policies with it. At least every quarter, the System Owner and ISSO review the list, confirm that each entry is still needed, and remove the rest. The administrator pushes the removals to enforcement in the same cycle. Evidence: the versioned authorized software list, the request and approval tickets, the enforcement policy exports, and the quarterly review record.

CM-08 — System Component Inventory #

Baselines: Low / Moderate / High CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security), DE.CM (Continuous Monitoring)

1. Develop and document an inventory of system components that:

1. Accurately reflects the system;
2. Includes all components within the system;
3. Does not include duplicate accounting of components or components assigned to any other system;
4. Is at the level of granularity deemed necessary for tracking and reporting; and
5. Includes the following information to achieve system component accountability: [Assignment: organization-defined information — to be defined]; and

2. Review and update the system component inventory at least monthly.

Procedure:

The ticketing system CMDB is the authoritative component inventory, with one record per component and each component assigned to a single system. Implementers create and retire records through the change process: the implementer updates the CMDB before closing an installation, removal, or upgrade ticket.

The vulnerability management team runs scanner discovery scans that reconcile what they find against the CMDB. Unmatched discoveries and stale records become correction tickets to the System Owner. Each component record holds the required attributes, and the System Owner attaches SBOM data to software records. The System Owner flags each product that meets NIST’s definition of critical software, with the platform it runs on. The configuration management team applies NIST’s security measures for critical software to each flagged product. The ISSO records any measure not yet in place as a plan of action and milestones (POA&M) item.

At least every month, and after each significant system change, the System Owner certifies that the inventory is accurate. The IT Asset Manager reconciles accountable IT equipment, including devices at telework locations, under the IT Asset Management Procedure (PROC-ITAM-001).

Evidence: the CMDB records with their change history, the critical software flags, the correction tickets, and the monthly certification.

CM-08(1) — Updates During Installation and Removal #

Baselines: Moderate / High

Update the inventory of system components as part of component installations, removals, and system updates.

Procedure:

Inventory maintenance is part of the change workflow. Every ticketing system change ticket that installs, removes, or updates a component includes an inventory task. The implementer records the new component’s attributes, retires the removed record, or updates the version as part of the implementation. The implementer cannot close the ticket while the inventory task is open. Scanner discovery is the backstop: it flags any component whose live state differs from the record. The System Owner corrects the miss and examines the workflow gap that caused it. Evidence: the change tickets with completed inventory tasks, the CMDB change history matched to those tickets, and the reconciliation reports showing how often the backstop found a miss.

CM-08(2) — Automated Maintenance #

Baselines: High

Maintain the currency, completeness, accuracy, and availability of the inventory of system components using [Assignment: organization-defined automated mechanisms — to be defined].

Procedure:

The ticketing system receives component data automatically from the vulnerability scanner agents, the MDM tool, and the cloud platform resource listings. It updates existing records and creates records for newly found components. The System Owner reviews new and changed records and resolves conflicts between sources. The ticketing system flags components that stop reporting, and the System Owner either retires or restores each one. Evidence: discovery integration logs, reconciliation records, and inventory change history in the ticketing system.

CM-08(3) — Automated Unauthorized Component Detection #

Baselines: Moderate / High

1. Detect the presence of unauthorized hardware, software, and firmware components within the system using automated mechanisms with a maximum five-minute delay in detection continuously; and
2. Take the following actions when unauthorized components are detected: [Selection (one or more): disable network access by unauthorized components; isolate unauthorized components; notify [organization-defined] — to be defined].

Procedure:

Continuous scanner discovery compares everything on the network with the authorized inventory in the CMDB. A component with no authorizing record raises an unauthorized-component event. The Organization disables the component’s network access, notifies the Incident Response Team, and records the component, the action taken, and the time in the ticketing system. The Incident Response Team decides each event: it corrects a missed inventory update and traces it to its workflow gap, and it investigates unknown hardware or software as a potential incident. Evidence: the detection events with their disablement timestamps, the Incident Response Team notifications, and the disposition records that separate process misses from true unknowns.

CM-08(4) — Accountability Information #

Baselines: High

Include in the system component inventory information, a means for identifying by position and role, individuals responsible and accountable for administering those components.

Procedure:

When a component enters service, the System Owner names its administrator in the ticketing system inventory record. When staff change jobs or leave, the System Owner updates the record in the same request that ends their access. The ISSO runs a ticketing system report of components with no assigned administrator. The ISSO sends each gap to the System Owner for correction. Evidence: inventory records with assigned administrators, record change history, and the ISSO gap reports.

CM-09 — Configuration Management Plan #

Baselines: Moderate / High CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security)

Develop, document, and implement a configuration management plan for the system that: a. Addresses roles, responsibilities, and configuration management processes and procedures; b. Establishes a process for identifying configuration items throughout the system development life cycle and for managing the configuration of the configuration items; c. Defines the configuration items for the system and places the configuration items under configuration management; d. Is reviewed and approved by [Assignment: organization-defined personnel or roles — to be defined]; and e. Protects the configuration management plan from unauthorized disclosure and modification.

Procedure:

The System Owner develops the configuration management plan during system development or onboarding from the Organization’s template. The plan names its configuration items and maps the change control process to the Configuration Control Board’s operation. It defines baseline and inventory maintenance and names who analyzes each change for security and privacy impact. The plan also describes status accounting: where the System Owner records the current approved version and change history of each configuration item. It describes configuration audits: how the System Owner compares the deployed system with its baseline and change records, and how the System Owner fixes differences. The board chair, CISO, and Authorizing Official (AO) review the plan, and the System Owner records their approval before the system operates under it.

The System Owner stores the plan with access restricted to those who need it. Revisions go through the ticketing system change records like any other controlled document. As the system evolves, the System Owner adds new configuration items and retires those the Organization no longer manages under the plan.

Evidence: the approved plan with its review record, the revision history, the status accounting records, the configuration audit results, and the change tickets, baselines, and inventory that show the plan in use.

CM-10 — Software Usage Restrictions #

Baselines: Low / Moderate / High CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security)

1. Use software and associated documentation in accordance with contract agreements and copyright laws;
2. Track the use of software and associated documentation protected by quantity licenses to control copying and distribution; and
3. Control and document the use of peer-to-peer file sharing technology to ensure that this capability is not used for the unauthorized distribution, display, performance, or reproduction of copyrighted work.

Procedure:

Software enters the environment through the authorized software process, and its license terms enter with it. The administrator records the license type, the entitlement count, and the contract reference in the ticketing system with the software record. The Software Manager compares deployment counts from scanner software inventory data with entitlements in the monthly true-up. For each over-deployment, the Software Manager opens a correction ticket to the System Owner, who removes installations or acquires licenses and documents the resolution.

The Software Manager keeps the license inventory and reports to the Chief Information Officer (CIO) under the IT Asset Management Procedure (PROC-ITAM-001).

The least-functionality controls block peer-to-peer file sharing by default. Where the CISO has authorized a specific use, the authorization documents the purpose and the safeguards against misuse of copyrighted work, and the ISSO reviews usage against it.

Evidence: the license records with entitlements, the correction tickets, and the peer-to-peer authorizations with their reviews.

CM-11 — User-installed Software #

Baselines: Low / Moderate / High CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security)

1. Establish [Assignment: organization-defined policies — to be defined] governing the installation of software by users;
2. Enforce software installation policies through the following methods: [Assignment: organization-defined methods — to be defined]; and
3. Monitor policy compliance Continuously (via CM-7 (5)).

Procedure:

The Organization enforces installation rules at the endpoint. The MDM tool application controls and group policy software restriction policies implement the whitelist and blacklist, so an unauthorized installation fails at the attempt. Users acknowledge the Organization Rules of Behavior, which state what they may install and how to request what is missing. Requests go through the ticketing system to security review.

Continuously, the ISSO runs the compliance review. The ISSO compares scanner software inventory data with the authorized list. The System Owner removes any unauthorized software found installed, and the ISSO opens a ticket and examines how it bypassed enforcement. Trends, such as repeat offenders and repeat software, inform policy and training.

Evidence: the enforcement policy exports, the Rules of Behavior acknowledgments, the continuous compliance reports, and the removal tickets with their root-cause notes.

CM-12 — Information Location #

Baselines: Moderate / High CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security)

1. Identify and document the location of [Assignment: organization-defined information — to be defined] and the specific system components on which the information is processed and stored;
2. Identify and document the users who have access to the system and system components where the information is processed and stored; and
3. Document changes to the location (i.e., system or system components) where the information is processed and stored.

Procedure:

The System Owner records information location with the system’s documentation. For each in-scope information type, the record names the components that process and store it and the user population with access. Controlled Unclassified Information is in scope, including personally identifiable information (PII), Sensitive PII, Business Identifiable Information, Law Enforcement Information, and Increased Sensitive Data. The System Owner maintains the record, and the ISSO verifies it during control assessments and inventory reviews.

A change in where information lives goes through the ticketing system change process. The implementer updates the location record as an implementation task for each migration, new component, or decommissioning, and the impact analysis flags any change that moves sensitive information. The Organization reviews the access lists for the identified components against the documented user population.

Evidence: the information location records for each system, the change tickets that updated them, and the access review results for components that hold sensitive information.

CM-12(1) — Automated Tools to Support Information Location #

Baselines: Moderate / High

Use automated tools to identify Federal data and system data that must be protected at the High or Moderate impact levels on [Assignment: organization-defined system components — to be defined] to ensure controls are in place to protect organizational information and individual privacy.

Procedure:

Automated discovery runs across all system components to locate the in-scope information types where they reside. The System Owner compares the discovery results with the documented location records. A match confirms the record. For a mismatch, meaning sensitive information on an undocumented component, the System Owner opens a ticketing system ticket for correction. The System Owner escalates the ticket for investigation when the location is unauthorized. Discovery output also drives protection decisions: a component confirmed to hold higher-sensitivity information receives the controls its categorization requires. Evidence: the discovery run results, the reconciliation records against the documented locations, and the correction and escalation tickets.

CM-14 — Signed Components #

Baselines: High

Prevent the installation of [Assignment: organization-defined software and firmware components — to be defined] without verification that the component has been digitally signed using a certificate that is recognized and approved by the organization.

Procedure:

The CISO maintains the approved signer list and publishes it to administrators. Administrators deploy signature enforcement through group policy on domain-joined systems and through the MDM tool policies on managed endpoints. These settings allow only software signed by an approved publisher to install or run. In the cloud platform, administrators turn on signature checks for images and extensions where the platform supports them.

Before installing firmware, the administrator checks the vendor signature and records the result in the ticketing system change request. Configuration compliance scans confirm that signature enforcement stays on. Any drift opens a ticket in the ticketing system for the owning administrator. When a requester needs an unsigned component, the System Owner submits a risk acceptance for the CISO to decide.

Evidence: the approved signer list, enforcement policy settings, change requests with signature checks, scan reports, and signed risk acceptances.

4.3 Security Impact Analysis and Significant Change #

The ISSO runs the security impact analysis for every change request in the ticketing system before the Configuration Control Board meets on it. The first step follows the five analysis steps in NIST SP 800-128. The second step decides whether the change is significant and, if it is, who must act before production.

Step 1: Analyze the change #

Find out how the proposed change affects the system’s controls and risk.

Step 2: Decide whether the change is significant #

Send significant changes to the assessor and the Authorizing Official before production.

Step 3: Sign, store, and verify #

Keep the record and confirm the controls still work.

Evidence: the change ticket with the analysis and the significant change answer, the assessor’s review, the Authorizing Official’s decision, and the signed analysis in the GRC system.

Source: NIST SP 800-37 Rev. 2, Appendix F (significant change and reauthorization); NIST SP 800-128 with Update 1 (2019), section 3.3 (security impact analysis); NIST SP 800-53 Rev. 5, CM-04 and CA-06.

5. Parameters (ODP Values) #

The following organization-defined parameters apply to controls in this family:

6. Evidence Artifacts #

Carrying out this procedure produces these records:

• Configuration baseline documents
• Change request tickets and approvals
• Configuration change log
• CM board meeting minutes
• Evidence for IG FISMA metric RAM.01
• Evidence for IG FISMA metric RAM.02
• Evidence for IG FISMA metric RAM.03
• Evidence for IG FISMA metric RAM.04
• Evidence for IG FISMA metric CM.01
• Evidence for IG FISMA metric CM.02
• Evidence for IG FISMA metric CM.16

7. Performance Measurement #

The CISO measures this procedure with the indicators below, which meet IG FISMA Level 4 (Managed and Measurable). The ISSO collects the data, and the CISO trends and reports it. When a measure moves away from its target, the CISO starts corrective action through the POA&M process.

8. Training Requirements #

Before they carry out the steps in this procedure, and every year after, the people who perform them must complete:

• General security awareness training, which all personnel take under POL-AT.
• Role-based training on this procedure’s steps, tools, and evidence.
• Training on the technology platforms listed under Technology Implementation, matched to their duties.

Completion is a condition of continued access. The Agency Learning Management System (LMS) holds the completion records.

9. Governance References #

• CISA BOD 23-01: Improving Asset Visibility and Vulnerability Detection on Federal Networks, October 3, 2022.
• CISA BOD 23-02: Mitigating the Risk from Internet-Exposed Management Interfaces, June 13, 2023.
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk, June 10, 2026.
• OMB Circular A-130: Managing Information as a Strategic Resource, July 28, 2016.
• Federal Information Security Modernization Act of 2014 (44 U.S.C. § 3551 et seq.), December 18, 2014.
• OMB M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, January 26, 2022.
• OMB M-26-05: Adopting a Risk-based Approach to Software and Hardware Security, January 23, 2026.
• NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, September 2020.
• 2026 Minimum Elements for a Software Bill of Materials (SBOM) — CISA/NSA/FBI joint guidance: CISA/NSA/FBI joint guidance, July 29, 2026.
• CISA BOD 25-01: Implementing Secure Practices for Cloud Services, December 17, 2024.
• CISA BOD 26-02: Mitigating Risk From End-of-Support Edge Devices, February 5, 2026.
• CISA Known Exploited Vulnerabilities Catalog, updated continuously.
• Executive Order 14028: Improving the Nation’s Cybersecurity, May 12, 2021.
• FedRAMP Consolidated Rules for 2026 (including 20x Key Security Indicators), June 24, 2026.
• NIST Cybersecurity Framework 2.0, February 26, 2024.
• NIST SP 800-37 Rev. 2: Risk Management Framework for Information Systems and Organizations, December 2018.
• NIST SP 800-128: Guide for Security-Focused Configuration Management of Information Systems, August 2011.
• OMB M-21-30: Protecting Critical Software Through Enhanced Security Measures, August 10, 2021.