How do I check for privileged role without documented ownership in Splunk?

Run the published SPL query on this page against Splunk Enterprise / Enterprise Security. It reads privileged_role_register.csv (lookup) and reports: Privileged role lacking a documented owner or justification, or overdue for its required review.

NIST SP 800-53 Rev. 5 · Access Control

AC-6(7) on Splunk

Privileged role without documented ownership — 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

Powerful access that nobody in the organization owns or has reviewed

Someone grants a colleague elevated access to solve an urgent problem. Years later the access is still there, the colleague has changed roles twice, and nobody can say who approved it or why. Organizations are expected to review privileged access periodically, but a review needs a list of who is accountable for each grant, and that list is usually the thing that was never written down.

Why this check earns its place. It reports the absence of a record rather than a technical fault. That is a different kind of finding, and it is the one that makes the periodic review possible at all.

What it reads: The organization's own register of administrative roles and who is accountable for each.
What it reports: Administrative roles with no named owner, no recorded reason for existing, or a review that is overdue.

See related public disclosures on the Signals page →

ControlAC-6(7) — Review of User Privileges

PlatformSplunk (SPL)

SeverityMedium

ValidationLab-validated

What this finds

Privileged role lacking a documented owner or justification, or overdue for its required review.

The requirement

The organization must review the privileges assigned to users at an organization-defined frequency to validate the need for such privileges, and reassign or remove privileges when no longer appropriate.
NIST SP 800-53 Rev. 5 — AC-6(7) (Least Privilege | Review of User Privileges).

NIST requires periodic validation of privilege need. Whether that is evidenced by an owner field, a ticket reference, or a signed attestation is an organization-defined implementation choice. A missing field is evidence about the record, not proof about the access.

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.H — Implement the principles of least privilege
A privileged role nobody owns cannot be justified as the minimum necessary.
3.G — Administrators maintain separate user and privileged accounts (partial — see note)
Related to separating administrative identity, but the pack checks ownership of the role, not whether admins hold a second account.

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

Evidence this query needs

Privileged role register `privileged_role_register.csv`

Defines which roles your organisation treats as privileged, who owns each one, and how often it must be reviewed. Cloud platforms know which roles exist; only you know which ones matter and who is accountable for them.

Minimum fields: role_name, platform, privilege_classification

Three fields make the staleness and MFA checks work. The ownership fields are what make AC-6(7) answerable at all — without them that check has nothing to test against.

The query

Published as ac-6-7-unowned-role.splunk.spl. Reads privileged_role_register.csv (lookup). Requires: Read on the lookup.

Before this returns anything, privileged_role_register.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 →

| inputlookup privileged_role_register.csv
| eval cycle_days=if(isnull(review_cycle_days) OR review_cycle_days="",
                     90, tonumber(review_cycle_days))
| eval review_epoch=if(isnull(last_review_date) OR last_review_date="",
                       0, strptime(last_review_date,"%Y-%m-%d"))
| eval days_since_review=if(review_epoch=0, 9999,
                            round((now()-review_epoch)/86400))
| eval has_owner=if(isnotnull(documented_owner) AND documented_owner!="",1,0)
| eval has_justification=
        if(isnotnull(business_justification) AND business_justification!="",1,0)
| eval review_overdue=if(days_since_review>cycle_days,1,0)
| where has_owner=0 OR has_justification=0 OR review_overdue=1
| eval gap=case(has_owner=0,"no documented owner",
                has_justification=0,"no business justification",
                1=1,"review overdue")
| table role_name, platform, privilege_classification, documented_owner,
        business_justification, last_review_date, days_since_review, gap
| sort - days_since_review

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.

Default review cycle (days) (default 90): Applied to roles whose register entry does not specify its own review cycle.

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 0 records and returned 3 results in 0.018000000000000002 seconds.

role_name	platform	privilege_classification	days_since_review	gap
AdministratorAccess	aws	tier0	9999	no documented owner
break-glass-emergency	azure	tier0	188	review overdue
Global Administrator	azure	tier0	118	review overdue

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 */12 * * *   (every 12 hours)
Time range:       n/a (lookup-driven)
Trigger:          Number of results > 0
Alert action:     Create notable event
Urgency:          Medium
Security domain:  Access
Throttling:       Suppress 30d on role_name

This search reads only the supplied lookup, so it runs with no index cost and remains accurate even where role telemetry is not forwarded.

What a result does not prove

A missing field is evidence about the completeness of the register, not proof that the access itself is inappropriate. Documentation may exist outside the queried source.

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

Is the ownership evidence recorded somewhere this query does not read?
Was this an emergency assignment following a separate documented process?
Does the role remain necessary in its current form?
Who will attest to this privilege at the next review cycle?

Common questions

How do I check for privileged role without documented ownership in Splunk?: Run the published SPL query on this page against Splunk Enterprise / Enterprise Security. It reads privileged_role_register.csv (lookup) and reports: Privileged role lacking a documented owner or justification, or overdue for its required review.
What permissions are needed to run this Splunk query?: Read on the lookup.
What evidence does AC-6(7) need that Splunk cannot produce?: Privileged role register (privileged_role_register.csv). Defines which roles your organisation treats as privileged, who owns each one, and how often it must be reviewed. Cloud platforms know which roles exist; only you know which ones matter and who is accountable for them. At minimum it must carry: role_name, platform, privilege_classification.
Does a result from this query mean the control has failed?: A missing field is evidence about the completeness of the register, not proof that the access itself is inappropriate. Documentation may exist outside the queried source.

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 →