NIST SP 800-128

Establish a formal change control process requiring submission, review, approval, implementation, verification, and closure of all configuration changes through a Configuration Control Board or equivalent authority.

• Change request register
• CCB meeting minutes
• Approved change records with timestamps
• Closed change verification records

• Emergency changes never reconciled
• CCB minutes missing
• Verification step skipped
• Backout plans absent

Define, document, and enforce physical and logical access restrictions associated with changes to information systems including privileged role separation, change tooling authentication, and audit logging of all change actions.

• Privileged account list
• Access review records for change tools
• Audit logs of configuration commits
• Role assignment evidence

• Shared admin accounts
• Audit logs not retained
• No access review for IaC repositories
• Developers can push to production

Test configuration changes in a representative non-production environment to validate functionality and security before deployment to production, and document test results as part of the change record.

• Test environment architecture
• Test plans per change type
• Test results attached to change record
• Promotion approval records

• No representative test environment
• Test results not archived
• Security tests omitted
• Direct-to-production changes

Retain previous versions of baseline configurations and change records for a defined period to support rollback, forensic analysis, audit, and trend analysis of configuration drift over time.

• Retention schedule
• Baseline version history
• Change record archive
• Rollback test evidence

• No retention policy
• Versions overwritten in repo
• Records purged early
• No rollback drill

Use automated tools such as configuration management databases, version control systems, and SCAP-enabled scanners to enforce change workflows, detect unauthorized changes, and record an audit trail of all configuration modifications.

• CMDB screenshots
• Version control commit logs
• SCAP scan integration evidence
• Unauthorized-change alert records

• Manual change spreadsheets
• Detection alerts not actioned
• No integration between ticketing and CMDB
• SCAP tooling absent

Define an expedited process for emergency configuration changes that bypasses routine CCB review but requires retrospective documentation, security impact analysis, and CCB ratification within a defined timeframe.

• Emergency change procedure
• Emergency change log
• Retrospective SIA records
• CCB ratification minutes

• Emergency path overused
• No retrospective review
• Emergency changes not flagged in CMDB
• No metrics on emergency volume

Identify and document the configuration items subject to SecCM including hardware, operating systems, applications, firmware, network devices, and virtual components, with sufficient granularity to support baseline management and change tracking.

• CI inventory database
• CI naming convention document
• CI hierarchy or relationship map
• Inventory reconciliation reports

• Virtual assets missing
• Firmware not tracked as CIs
• Shadow IT not inventoried
• Inventory stale by months

Develop, document, and maintain a current baseline configuration for each configuration item that records approved settings, software versions, patch levels, network topology, and authorized accounts forming the known-good state from which changes are measured.

• Baseline configuration documents per CI type
• Version history
• Approval records
• Comparison reports between baseline and live state

• No baselines for cloud workloads
• Baselines not version-controlled
• No comparison against live systems
• Baselines never updated after major changes

Adopt common secure configurations from authoritative sources such as USGCB, DISA STIGs, CIS Benchmarks, or vendor security guides as the starting point for baselines, and tailor them with documented justification for deviations.

• Mapping of baselines to USGCB or CIS Benchmark version
• Tailoring justification log
• Deviation register
• SCAP benchmark content references

• No documented benchmark source
• Deviations not justified
• Old benchmark versions in use
• Tailoring decisions not approved

Configure systems to provide only essential capabilities by disabling unused services, ports, protocols, and software, and document the rationale for enabled functions within the baseline.

• Approved services and ports list
• Disabled-features evidence per CI
• Port scan results
• Software allow lists

• Default services left enabled
• Allow list not enforced
• No periodic port scans
• Justification missing for enabled services

Implement approved baselines through automated provisioning, golden images, infrastructure-as-code templates, or scripted deployment so that new systems receive secure configurations consistently from initial build.

• Golden image inventory
• IaC repositories
• Provisioning playbooks
• Build verification scan results

• Manual provisioning
• Golden images not patched
• IaC not security-reviewed
• No verification scan after build

Establish continuous monitoring of configuration items to detect deviations from approved baselines using automated scanning, agent-based reporting, and SCAP content aligned with the organization's monitoring strategy.

• Monitoring strategy document
• Scan schedule
• Tool coverage report by CI type
• Sample scan output

• Monitoring limited to servers
• Cloud and OT excluded
• Scans run quarterly not continuously
• No agent on endpoints

Compare actual system configurations against approved baselines on a defined cadence to identify drift, unauthorized changes, or degradation of secure settings, and feed findings into incident response and remediation workflows.

• Drift report samples
• Baseline-vs-actual diff outputs
• Drift remediation ticket trail
• Trend dashboard

• Drift reports generated but not actioned
• No SLA for remediation
• Drift detection blind to firmware
• False positive rate not tuned

Identify vulnerabilities arising from configuration weaknesses, missing patches, or end-of-life software through scanning and threat intelligence, and remediate within risk-based timeframes documented in policy.

• Vulnerability scan reports
• Patch deployment records
• SLA metrics by severity
• Exception register

• Critical vulns past SLA
• Exceptions never expire
• EOL software undetected
• No re-scan after patch

Produce regular compliance reports showing configuration posture against baselines, benchmark scores, drift counts, and remediation timeliness, and distribute to system owners, authorizing officials, and executive stakeholders.

• Monthly or quarterly compliance reports
• Distribution list
• Executive dashboard screenshots
• Authorizing official acknowledgments

• Reports delivered but not reviewed
• Metrics inconsistent month over month
• No executive visibility
• Reports lack remediation status

Detect and respond to unauthorized configuration changes through file integrity monitoring, registry monitoring, change correlation with approved tickets, and alerting on deviations not tied to an approved change record.

• FIM alert logs
• Ticket correlation reports
• Incident records for unauthorized changes
• Response runbook

• FIM disabled on critical hosts
• No correlation to change tickets
• Alerts go to unmonitored mailbox
• Repeat offenders not tracked

Define and collect SecCM metrics covering baseline adoption rate, change approval cycle time, drift volume, vulnerability remediation SLA, and unauthorized change incidents to drive continuous improvement.

• Metrics catalog
• Quarterly metrics report
• Trend charts
• Improvement action register

• Metrics defined but not collected
• No baseline targets
• Metrics not reviewed at CCB
• No corrective action for missed targets

Use monitoring findings to refine baseline configurations, update common secure configurations, retire obsolete settings, and incorporate lessons learned into the SecCM Plan and procedures.

• Baseline revision history tied to findings
• Lessons learned log
• Updated SecCM Plan versions
• Retirement records for obsolete settings

• Findings never update baselines
• Lessons learned not captured
• SecCM Plan static for years
• Obsolete settings linger

Subject SecCM activities to periodic independent assessment to verify policy adherence, baseline accuracy, change record completeness, and effectiveness of monitoring controls, with findings tracked to closure.

• Audit reports
• Assessment plan
• Finding tracker
• Closure evidence per finding

• No independent assessment
• Findings open for years
• Same findings repeat
• Assessor not independent of CCB

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

• Access restrictions for change (logical/physical)

• Unrestricted change access
• No enforcement of change privileges

Develop, document, and maintain an approved baseline configuration of the information system as a basis for future builds and changes.

• Approved baseline configuration documentation

• No maintained baseline

Control changes to the baseline configuration through documented requests, approvals, testing, and tracking.

• Change requests, testing, approvals, tracking

• Changes not tested or tracked

Assess and report on the configuration of the information system and identify and address unauthorized or undesirable configuration changes.

• Configuration assessment/reporting and remediation

• Unauthorized changes undetected

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

• Security impact analysis records prior to change

• No security impact analysis before changes

A board with responsibility for reviewing and approving proposed changes to the configuration baseline, including their security impact.

• Configuration control board charter and minutes

• No CCB or change authority

Identify the configuration items, the system components placed under configuration management and treated as a single entity for control.

• Defined configuration items under management

• Configuration items not identified

Develop and maintain an inventory of the information system components that comprise the system and are subject to configuration management.

• Component inventory

• Incomplete component inventory

A comprehensive plan describing the SecCM roles, responsibilities, processes, and procedures applied to a system throughout its lifecycle.

• Configuration management plan

• No CM plan for the system

Establish secure configuration settings that reflect the most restrictive mode consistent with operational requirements.

• Secure configuration settings (e.g., benchmarks)

• Default/insecure configurations in use

Manage changes to the baseline configuration through an analyzed, documented, and approved change control process.

• Change control process and approval records

• Undocumented or unapproved changes

Develop, review, approve, and implement secure baseline configurations for information systems and their components.

• Approved secure baseline configurations

• No documented secure baselines

Validate that the system is adhering to organizational policies, procedures, and the approved secure baseline configuration.

• Baseline compliance monitoring reports

• No drift detection from baseline

Develop a configuration management plan, policy, and procedures, and establish the configuration control board to govern security-focused configuration management.

• SecCM plan, policy, and CCB establishment

• No SecCM planning artifacts

Establish the SecCM policy and procedures that address purpose, scope, roles, responsibilities, and compliance.

• Configuration management policy and procedures

• CM policy missing or outdated

Establish, document, and disseminate organization-wide security-focused configuration management policy and supporting procedures that address purpose, scope, roles, responsibilities, management commitment, coordination among entities, and compliance.

• SecCM policy document
• SecCM procedures
• Approval signatures and dates
• Annual review records
• Distribution acknowledgments

• Policy not separated from generic CM policy
• No review cadence
• Roles undefined
• Procedures missing for each SecCM phase

Develop a SecCM Plan documenting the strategy, roles and responsibilities, configuration items in scope, baseline configuration definition approach, change control board structure, monitoring approach, and tools used to enforce secure configurations across the system lifecycle.

• SecCM Plan
• System boundary diagram
• CI inventory scope statement
• Tool inventory
• Plan approval record

• No SecCM Plan distinct from system security plan
• CIs not enumerated
• Tools not mapped to phases
• Plan never updated

Define and assign SecCM roles including Information System Owner, Information System Security Officer, Configuration Control Board members, Configuration Manager, and SecCM analysts with documented authorities and separation of duties.

• RACI matrix
• Role appointment letters
• CCB charter
• Separation of duties matrix
• Training records for SecCM roles

• CCB charter missing
• Same person approves and implements changes
• ISSO not on CCB
• Roles documented but not staffed

Coordinate SecCM activities with broader enterprise configuration management, asset management, change management, and risk management processes to avoid duplication and ensure security considerations are embedded in CM workflows.

• Process integration diagram
• Cross-reference of SecCM to ITIL or CMMI processes
• Joint procedure documents
• Tool integration records

• SecCM operates in isolation from IT CM
• Duplicate CCBs
• Asset register and CI register inconsistent
• No handoff between change and security teams

Identify and document the automated tools, repositories, and resources required to support SecCM activities including configuration scanners, change management ticketing, software inventory, and SCAP-validated content sources.

• Tool catalog with SCAP capability flags
• Resource allocation budget
• Vendor SLAs
• Tool authorization records

• Tools selected without SCAP support
• No funding for ongoing licenses
• Tools not authorized to operate
• Duplicate tools across teams