How do I check for configuration deviation without an approved change in Splunk?

Run the published SPL query on this page against Splunk Enterprise / Enterprise Security. It reads index=cloud sourcetype=config:snapshot, change_approvals.csv (lookup) and reports: Security-relevant configuration differs from the approved baseline with no matching approved change record.

NIST SP 800-53 Rev. 5 · Configuration Management

CM-6 / CM-3 on Splunk

Configuration deviation without an approved change — a published SPL query you can run against Splunk Enterprise / Enterprise Security, with the evidence it needs, the settings you decide, and what a result does and does not establish.

Why this matters

A security setting quietly changed with no approval behind it

Organizations agree a standard configuration and a process for changing it. Under time pressure the setting gets changed directly and the paperwork never follows, and the change is indistinguishable from one that was properly approved. Many changes are entirely legitimate, so reporting every change produces a list nobody reads.

Why this check earns its place. It reports only changes with no approval record behind them, which is a far shorter and far more useful list than every change that occurred.

What it reads: The organization's current settings, compared against its agreed standard and its own record of approved changes.
What it reports: Settings that differ from the agreed standard with no matching approval on record.

See related public disclosures on the Signals page →

ControlCM-6 / CM-3 — Configuration Settings / Configuration Change Control

PlatformSplunk (SPL)

SeverityMedium

ValidationLab-validated

What this finds

Security-relevant configuration differs from the approved baseline with no matching approved change record.

The requirement

The organization must establish and document configuration settings that reflect the most restrictive mode consistent with operational requirements, identify and document any deviations, and approve and control changes under configuration change control.
NIST SP 800-53 Rev. 5 — CM-6 (Configuration Settings) and CM-3 (Configuration Change Control).

NIST requires documented settings and controlled change. The approved baseline values, in-scope resources, the tolerance window for matching a change to an approval, and pre-authorized automation identities are all organization-defined.

How this maps to the CISA performance goals

The Cross-Sector Cybersecurity Performance Goals are a voluntary baseline published by CISA — the U.S. federal agency for critical-infrastructure cybersecurity — written for organizations too small to employ security staff. This control speaks to:

3.N — Establish change management processes
The goal is a change management process; the pack finds configuration that moved without an approved change.
3.P — Maintain hardware & software approval process (partial — see note)
Touches the approval process for what runs, but the pack checks configuration drift rather than the software approval list.

See the full coverage map, including the goals no query can answer →

Evidence this query needs

Change approval records `change_approvals.csv`

Lets a configuration deviation be matched to an authorisation. Without it, every drift event looks unauthorised — which is both wrong and unusable in volume.

Minimum fields: ticket_id, resource_id, approved_at

A ticket, a resource, and an approval time are enough to correlate. Adding the implementation window is what turns a coarse ±24-hour match into a precise one.

The query

Published as cm-6-config-deviation.splunk.spl. Reads index=cloud sourcetype=config:snapshot, change_approvals.csv (lookup). Requires: Search access to the cloud index; Read on the lookup.

Before this returns anything, index=cloud sourcetype=config:snapshot has to be reaching Splunk Enterprise / Enterprise Security, and change_approvals.csv (lookup) has to be landed there. If not, the query reports nothing found — which looks exactly like nothing wrong. What has to be switched on first →

index=cloud sourcetype=config:snapshot
| where current_value!=baseline_value
| eval change_key=resource_id.":".setting_name
| lookup change_approvals.csv resource_id, setting_name
    OUTPUT ticket_id, approved_at, window_start, window_end, approver
| eval snap_epoch=strptime(snapshot_time,"%Y-%m-%d")
| eval approved_epoch=if(isnull(approved_at) OR approved_at="",
                         0, strptime(approved_at,"%Y-%m-%dT%H:%M:%SZ"))
| eval in_window=if(approved_epoch>0
        AND abs(snap_epoch-approved_epoch)<=86400, 1, 0)
| where isnull(ticket_id) OR ticket_id="" OR in_window=0
| table resource_id, setting_name, current_value, baseline_value,
        ticket_id, approver, source_system, snapshot_time
| sort - snapshot_time

Open this pack on Splunk to adjust the settings and download it →

The interactive version opens on Splunk — the platform on this page — even if your environment profile does not list it.

Settings you decide

NIST states the objective and leaves these to your organization. The interactive version of this pack applies them to the query for you.

Approval matching tolerance (hours) (default 24): How far either side of the approval timestamp a change may fall and still be treated as authorised.
Limit to specific resources (optional): Paste resource identifiers, one per line.

What this query returned when it was run

Executed against Splunk Enterprise 10.4.2 on 2026-08-07 against purpose-built test data. The software examined 3 records and returned 1 result in 0.08 seconds.

resource_id	setting_name	current_value	baseline_value	source_system	snapshot_time
sql-reporting-prod	tls_version	TLS1_0	TLS1_2	Azure Resource Graph	2026-08-06

Test data, not a real organization. It shows the query executes and returns the intended shape of result.

Running it continuously

Correlation search → notable event

Search type:      Correlation search (Enterprise Security)
Cron schedule:    0 */4 * * *   (every 4 hours)
Time range:       -14d to now
Trigger:          Number of results > 0
Alert action:     Create notable event
Urgency:          Medium
Security domain:  Network
Throttling:       Suppress 4h on resource_id, setting_name

Throttling on resource and setting together, rather than resource alone, stops a second unrelated deviation on the same resource being suppressed by the first.

What a result does not prove

An unmatched deviation is not automatically unauthorized or harmful. Approval evidence usually lives outside the cloud platform, and correlation depends entirely on the completeness of the change feed.

Validation status for this platform: Lab-validated. Executed by the maintainer in a personally controlled laboratory environment on the date shown. Table names, field names, and operator support still vary by tenant configuration, API version, connector, and add-on.

Before you act on a result

Does an approved change exist outside the matching window or in another system?
Was the change made by a pre-authorized automation identity?
Is there an approved, current exception for this resource and setting?
Was post-change validation required, and was it completed?

Common questions

How do I check for configuration deviation without an approved change in Splunk?: Run the published SPL query on this page against Splunk Enterprise / Enterprise Security. It reads index=cloud sourcetype=config:snapshot, change_approvals.csv (lookup) and reports: Security-relevant configuration differs from the approved baseline with no matching approved change record.
What permissions are needed to run this Splunk query?: Search access to the cloud index; Read on the lookup.
What evidence does CM-6 / CM-3 need that Splunk cannot produce?: Change approval records (change_approvals.csv). Lets a configuration deviation be matched to an authorisation. Without it, every drift event looks unauthorised — which is both wrong and unusable in volume. At minimum it must carry: ticket_id, resource_id, approved_at.
Does a result from this query mean the control has failed?: An unmatched deviation is not automatically unauthorized or harmful. Approval evidence usually lives outside the cloud platform, and correlation depends entirely on the completeness of the change feed.

Terms used on this page

NIST SP 800-53the U.S. federal catalogue of security requirements: The catalogue of security and privacy requirements published by the National Institute of Standards and Technology, a U.S. federal agency. U.S. government systems are measured against it, and many private organizations adopt it voluntarily. Each requirement has an identifier such as AC-2. Official source →
CISACybersecurity and Infrastructure Security Agency: The U.S. federal agency responsible for national critical-infrastructure cybersecurity. Its publications are works of the U.S. government and are free to use. Official source →
SPLSearch Processing Language: The language used to ask questions of data held in Splunk. A query written in it is text and can be read before it is run.
CPGCross-Sector Cybersecurity Performance Goals: A voluntary baseline of security practices published by the U.S. Cybersecurity and Infrastructure Security Agency, written specifically for organizations too small to employ security staff. It is a short, plainly written starting list rather than a full standard. Official source →
lab-validatedexecuted in a controlled test environment: The check has been run, by the maintainer, against real security software loaded with purpose-built test data, and what it returned was recorded. It has not been run on any real organization's data.

Every term this project uses →

The same control on other platforms

CM-6 / CM-3 on Microsoft Sentinel — KQL
CM-6 / CM-3 on AWS — SQL (Athena) + Lambda
All platforms for CM-6 / CM-3