SI-7(12): Integrity Verification

SI-7(12) requires you to verify the integrity of specified user-installed software before it is allowed to run. Operationally, you implement allowlisting and execution controls so software can only execute after signature, hash, or publisher trust checks succeed, and you keep auditable evidence that the checks are enforced and monitored. ¹

Key takeaways:

• Define what counts as “user-installed software” in your environment, then scope which categories must be integrity-verified pre-execution. ¹
• Enforce verification at execution time, not just at install time, using OS/app control features and signed software policies. ¹
• Keep assessor-ready proof: policy, technical configuration, logs/alerts, and exception handling records that show verification is actually happening. ¹

The si-7(12): integrity verification requirement is a “gate” control: it expects you to prevent execution of user-installed software unless integrity checks pass. That means your success depends less on writing a policy and more on where you place enforcement. If the enforcement point is weak (for example, you only scan files periodically), you will struggle to demonstrate “prior to execution” in an assessment.

For most organizations, SI-7(12) becomes practical when you treat it as a combination of: (1) a clear scope statement of what “user-installed” means in your endpoints and servers, (2) a technical control that blocks or constrains execution based on trust (signature/publisher) or integrity (hash), and (3) an exception path with compensating controls and time bounds. You also need durable evidence that the controls are working day-to-day, not just configured once.

This page gives requirement-level implementation guidance that a Compliance Officer, CCO, or GRC lead can hand to endpoint engineering, server/platform, and security operations teams to implement quickly and defend in an audit against NIST SP 800-53 Rev. 5 expectations. ²

Regulatory text

Requirement (verbatim): “Require that the integrity of the following user-installed software be verified prior to execution: {{ insert: param, si-07.12_odp }}.” ¹

What the operator must do

1. Choose the scope parameter in the organization-defined parameter (ODP): identify the “following user-installed software” categories that must be integrity-verified before execution. ¹
2. Implement a pre-execution integrity verification mechanism for that scope (for example: signature validation, publisher trust, hash allowlisting, application control policy enforcement). The control has to occur before the OS/app loader permits execution. ¹
3. Make the control assessable: document scope, enforcement points, exceptions, and retain logs or other records proving the gate is operating. ¹

Plain-English interpretation (what SI-7(12) is really asking)

You must stop users from running software they installed (or introduced) unless the system first verifies the software has not been tampered with and is what it claims to be. “Verified prior to execution” is the key phrase: integrity checks must be part of the run decision, not just an advisory scan. ¹

Common integrity verification patterns that typically satisfy the intent:

• Digital signature / publisher trust: only allow execution if signed by an approved publisher or with an approved certificate chain.
• Hash-based allowlisting: only allow execution if the file hash matches an approved list (higher admin overhead, highest determinism).
• Managed application control: centrally managed policies that decide what can run, with audit logs and block events.

Who it applies to (entity and operational context)

SI-7(12) is applicable wherever NIST SP 800-53 is in scope, including:

• Federal information systems running agency workloads. ¹
• Contractor systems handling federal data, including regulated service providers and third parties operating systems in support of federal missions. ¹

Operationally, it matters most on:

• User endpoints where users can download installers, run portable executables, browser extensions, scripts, or developer tooling.
• Admin workstations / privileged endpoints where a compromise has outsized blast radius.
• Servers and build agents where “user-installed” may include packages, libraries, modules, containers, and binaries added outside standard images.

What you actually need to do (step-by-step)

Step 1: Define “user-installed software” in your environment

Create a short scoping statement that distinguishes:

• IT-managed software (gold image, corporate app store, standard package repos, MDM-managed apps)
• User-installed or user-introduced software (downloaded executables, scripts, plugins, packages installed without central approval, binaries copied from removable media)

Write this definition into your control narrative so an assessor understands what is covered by SI-7(12). ¹

Step 2: Populate the ODP scope (“the following user-installed software”)

Decide what categories are in scope for pre-execution integrity verification. Practical scoping options:

• All executables on endpoints not installed through sanctioned channels
• All scripting runtimes and script execution (PowerShell, Python, shell scripts) where feasible
• High-risk directories (Downloads, Temp, user profile executable paths)
• Portable apps and unsigned binaries

Document the exact scope statement you selected as the ODP fulfillment for SI-7(12). ¹

Step 3: Choose enforcement points that truly occur “prior to execution”

Your technical design should answer: “Where is the block decision made?”

• Endpoint OS application control (preferred for endpoints)
• Server application control (for critical servers and admin workstations)
• For managed environments, a centralized policy engine that pushes rules and collects logs

Avoid designs that only run after execution begins (for example, periodic file integrity scans alone). Those help other controls, but they do not cleanly meet the “prior to execution” language by themselves. ¹

Step 4: Implement the allow/deny policy model

You need a decision model assessors can understand. Use a simple table in your standard:

Software type	Default action	Integrity verification method	Exception path
Signed corporate apps	Allow	Publisher/cert trust	Emergency allow with approval
Unsigned executables in user paths	Block	N/A (blocked) or hash allowlist	Time-bound exception
Approved third-party tools	Allow	Signature/publisher allow	Vendor update workflow
Scripts	Constrain	Signed scripts / restricted execution policy	Signed-by exception

Keep this model consistent across endpoints and privileged devices, even if the technical control differs. ¹

Step 5: Build an exception workflow that doesn’t destroy the control

Assessors will look for a bypass. Your exception process should include:

• Business justification
• Security review (malware scan results, provenance, publisher info)
• Explicit approver
• Time limit or review trigger
• Removal process when no longer needed

Track exceptions as tickets with artifacts attached. ¹

Step 6: Operational monitoring and response

Define what Security Operations watches:

• Block events for attempted execution of unverified software
• Policy tampering attempts
• New signer/publisher introductions
• Drift between intended policy and deployed policy

If you can’t retain high-volume logs, retain summaries plus exemplars that show the control works and is reviewed. ¹

Step 7: Map ownership and recurring evidence (assessment readiness)

Minimum governance actions:

• Assign a control owner (often Endpoint Engineering or Platform Security)
• Publish an implementation standard and control narrative
• Define recurring evidence collection (config exports, policy versions, block logs, exception register)

If you use Daydream to manage your control library, map SI-7(12) to a named owner, a procedure, and a recurring evidence checklist so you can produce the same artifacts every audit cycle without rebuilding the story. ¹

Required evidence and artifacts to retain

Keep artifacts that prove design and operation:

Design evidence

• SI-7(12) control narrative (scope, ODP definition, enforcement points) ¹
• Application control / execution control standard (what is blocked/allowed, integrity methods)
• Exception procedure and approval matrix

Operating evidence

• Configuration exports or screenshots from the enforcement system showing policies are enabled and applied to target groups
• Sample block/allow logs showing integrity verification decisions and blocked untrusted executions
• Exception register (tickets) showing review, approval, time bounds, and closure
• Change records for policy updates (especially new publishers/certificates)

Evidence hygiene tips (what audits tend to reward)

• Time-align evidence to the audit period
• Show coverage across representative device populations (endpoints + privileged endpoints + relevant servers)
• Preserve policy version history so you can explain why a rule changed

Common exam/audit questions and hangups

Expect questions like:

• “Show me how you define ‘user-installed software’ and what categories are covered by SI-7(12).” ¹
• “Demonstrate that integrity verification happens before execution, not after.” ¹
• “How do you handle third-party updates that change signatures or hashes?”
• “Who can grant exceptions, and how do you ensure exceptions expire?”
• “How do you prevent users or local admins from disabling the control?”

Hangups that cause findings:

• The policy exists but is not enforced on privileged endpoints.
• Logs exist but are not reviewed, or retention is too short to support the period under review.
• Exceptions are granted informally (chat/email) without traceable evidence.

Frequent implementation mistakes (and how to avoid them)

1. Only verifying at install time. Fix: enforce at execution time with application control or equivalent gating. ¹
2. Hash allowlisting everything. Fix: use publisher/signature rules where possible; reserve hashes for high-risk unsigned tools.
3. No written ODP scope. Fix: explicitly document the “following user-installed software” categories and keep it stable unless formally changed. ¹
4. Exceptions become the real process. Fix: add time bounds, require security review artifacts, and report on exception volume and age.
5. Ignoring scripts and interpreters. Fix: decide explicitly whether scripts are included; if excluded, document rationale and compensating controls in the narrative.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat “enforcement” here as assessment risk: SI-7(12) commonly maps to malware defense and software supply chain integrity expectations. The operational risk is straightforward: if tampered or trojanized software runs, it can bypass preventative controls, steal credentials, and provide persistence. ²

Practical execution plan (30/60/90-day)

Use this as an operator plan; adjust scope to your environment and system authorization boundary. ¹

First 30 days (Immediate)

• Name the SI-7(12) control owner and backups.
• Write the ODP scope: exactly what “user-installed software” categories require integrity verification prior to execution. ¹
• Inventory current execution controls (application control, EDR blocking, OS policy controls) and identify the strongest pre-execution enforcement point available.
• Draft the exception workflow (ticket fields, approvers, time bounds, required review artifacts).
• Stand up evidence capture: policy exports, logging pipeline, and an exception register.

By 60 days (Near-term)

• Deploy enforcement to a pilot group (privileged endpoints first, then general endpoints).
• Implement publisher/signature allow rules for standard software, and block unsigned execution in user-writable paths where feasible.
• Produce the first “operating evidence packet”: policy config + sample block events + exception tickets.
• Train Service Desk and Desktop Support on how to request approvals and troubleshoot blocks without bypassing controls.

By 90 days (Operationalize)

• Expand coverage to the full in-scope population.
• Add monitoring and recurring review: policy drift checks, exception aging reviews, and periodic reporting to the system owner.
• Run an internal assessment: pick sample devices, attempt to run an unapproved binary, and collect the resulting logs and tickets as proof.
• In Daydream, standardize the evidence checklist and calendar it so each audit cycle produces the same artifacts with minimal scramble.

Frequently Asked Questions

Does SI-7(12) require code signing for all internal apps?

It requires integrity verification prior to execution for the user-installed software you scope into the control. If code signing is feasible, it is a clean way to prove integrity, but you can also use publisher trust rules or hash allowlisting for specific cases. ¹

Can EDR “detect and quarantine” satisfy the requirement?

Only if the EDR enforces a block decision before the software executes for the defined scope. If it detects after execution starts, treat it as supporting evidence, not the primary SI-7(12) control. ¹

What counts as “user-installed software” on servers where users don’t log in?

In practice, “user-installed” often means software introduced outside your controlled build and deployment pipeline (manual installs, ad hoc packages, copied binaries). Define that explicitly in your scope statement and align enforcement to server administration workflows. ¹

How do we handle third-party software updates that change hashes?

Prefer signature/publisher-based rules for software that updates frequently. If you must use hashes, establish an update workflow that refreshes allowlists based on verified packages and records the change approval. ¹

Are scripts included, or is this only about executables?

The control text is about “software,” so you need an explicit position. If scripts are in scope, enforce signed scripts or constrained language modes; if out of scope, document the rationale and what other controls reduce script risk. ¹

What evidence is most persuasive to an assessor?

A tight chain: documented scope (ODP), the enforced policy configuration, and real logs showing blocked attempts plus exception tickets that show governance. This combination demonstrates both design and operating effectiveness. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5