SA-7: User-installed Software

SA-7 (User-installed Software) requires you to control whether users can install software, and to manage that activity through explicit policy, technical enforcement, and evidence. Operationalize it by deciding where user installs are allowed, enforcing allowlisting and least privilege, routing exceptions through approvals, and continuously monitoring endpoints for unauthorized installations.

Key takeaways:

• Restrict user-installed software by default, then allow it only where the business case is documented and approved.
• Enforce the rule technically (least privilege, allowlisting, managed app stores) and validate it continuously (endpoint monitoring, exception reviews).
• Keep auditor-ready evidence: policy, configurations, approvals, and recurring control health checks tied to specific endpoints and users.

SA-7 is one of those controls that fails quietly until it becomes an incident. A single user-installed app can introduce unreviewed code, bundled adware, unsafe drivers, unauthorized remote access tools, or unlicensed software into your environment. SA-7 exists to make “what can be installed” a governed decision, not a local user choice.

For a CCO or GRC lead, the practical challenge is that SA-7 spans multiple owners: IT endpoint engineering, IAM, security operations, and sometimes procurement and legal (licensing). If you only publish a policy, auditors will ask how you enforce it. If you only enforce technically, you still need governance: documented scope, approved exceptions, and an evidence bundle that shows the control operates over time.

This page gives you requirement-level guidance you can hand to operators: how to define the rule, where to enforce it, what artifacts to retain, and how to answer common audit questions with confidence, without overbuilding a program that stalls delivery.

Regulatory text

Control reference: SA-7: User-installed Software ¹
Provided excerpt: “NIST SP 800-53 control SA-7.” ¹

Operator meaning (what you must do):
Because the excerpt provided here is only the control identifier, you should treat SA-7 as a requirement to govern and control user-installed software in your environment under your NIST SP 800-53 program. Your implementation must show:

1. you have a documented rule for user-installed software,
2. you enforce it with technical controls aligned to system risk, and
3. you maintain evidence that the rule is operating as designed over time.
   ²

Plain-English interpretation (what SA-7 is asking for)

SA-7 expects you to prevent “shadow IT at the endpoint.” Users should not be able to install arbitrary executables, browser extensions, drivers, packages, or developer tooling unless you have decided that installation path is acceptable and you can manage the risk.

A practical interpretation that stands up in audits:

• Default deny user installs on managed corporate endpoints and servers.
• Permit via controlled channels (managed app catalog, packaged deployments, approved installers, VDI) where you can scan, version, and revoke.
• Allow exceptions only with documented business justification, time bounds, and compensating controls.
• Detect and respond when unauthorized software appears.

Who it applies to (entity and operational context)

Organizations:

• Federal information systems and contractors operating systems that must meet NIST SP 800-53 requirements ³.

Systems and environments in scope (typical):

• Managed end-user devices (Windows, macOS, Linux)
• Privileged admin workstations
• VDI/DaaS sessions used for sensitive access
• Servers (where “user-installed” may mean admins installing packages outside change control)
• Developer workstations (usually the hardest scope because tools install frequently)

Teams you need at the table:

• Endpoint management (Intune, Jamf, SCCM, etc.)
• IAM / PAM (least privilege, just-in-time admin)
• Security operations (EDR detections, response playbooks)
• IT service management (request workflows, approvals, change records)
• Procurement / legal (licensed software controls where applicable)

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

Step 1: Write the decision rule (not a generic policy)

Create a one-page “control card” that operators can run. Minimum fields:

• Objective: prevent unauthorized and unmanaged software installation
• Scope: which device classes and system tiers are covered
• Allowed installation paths: managed app catalog, packaged deployment, signed installers, etc.
• Prohibited paths: local admin installs, unknown publishers, sideloading, unsigned scripts (tailor to OS)
• Roles and responsibilities: endpoint team enforces; security monitors; GRC validates evidence
• Trigger events: new device enrollment, new software request, exception request, quarterly control check
• Exceptions: criteria, required approvers, duration, compensating controls, revocation method

This maps directly to audit expectations around ownership, cadence, and traceability ¹.

Step 2: Classify endpoints and set enforcement tiers

You need at least two enforcement tiers:

• High-control tier: privileged admin workstations, finance, production support, systems handling regulated data. Target: no local admin, strict allowlisting, installs only through managed channels.
• Standard tier: general corporate endpoints. Target: no local admin by default, installs through managed channels, controlled exceptions.
• Developer tier (if applicable): allow a curated toolchain; require packaging; use a software request workflow with fast SLA so developers do not route around controls.

Document the tiering logic. Auditors will accept different strictness by risk if you can explain it and show it is consistently applied.

Step 3: Remove standing local admin and control privilege elevation

Most SA-7 failures come from “everyone is local admin.” Fix the root cause:

• Enforce standard user accounts for daily work.
• Use PAM or endpoint privilege management for elevation with logging and approvals where needed.
• Separate admin accounts from user accounts for sensitive administration.

Evidence needs to show the setting is enforced and not “policy only.”

Step 4: Implement application control (allowlisting) where it matters

Pick the technical enforcement based on platform:

• Windows: application control/allowlisting + controlled software distribution.
• macOS: require signed and notarized apps; restrict unknown developer installs; manage extensions.
• Linux: restrict package managers where feasible; control repos; require change control for server package installs.

You do not need perfection everywhere on day one. You do need a defensible scope and a roadmap.

Step 5: Establish a software request and approval workflow

A workable workflow prevents “urgent install” exceptions from becoming permanent:

1. Requestor submits software name, publisher, version, business purpose, devices/users impacted.
2. Security/IT validates source, hashes/signature where applicable, and checks for known risk signals.
3. Approver (manager + system owner or security) signs off based on tier.
4. Endpoint team packages and deploys via managed tooling.
5. Record the decision: approval ticket ID, deployment record, and any compensating controls.

Keep the workflow inside your ITSM tool so you can report on it.

Step 6: Define exception rules that expire

Exceptions must be structured to survive audit scrutiny:

• Named user(s) and device(s)
• Explicit scope (what can be installed)
• Time bound (expiration date)
• Required monitoring (EDR rule, alerting, periodic review)
• Compensating controls (restricted network access, sandbox/VDI, additional logging)

Step 7: Detect and respond to unauthorized software

Detection is part of “operationalizing.” At minimum:

• Endpoint inventory that can answer “what’s installed, where, and by whom.”
• Alerts for new executables, persistence mechanisms, and unauthorized remote access tooling.
• A playbook: triage, remove software, reimage if needed, and open a root-cause action (how did the install happen?).

Step 8: Run recurring control health checks (prove it keeps working)

Schedule a repeating check that answers:

• Are local admin memberships within policy?
• Are allowlisting policies deployed and not in audit-only mode (where applicable)?
• Are exceptions still valid and not expired?
• Are software inventories reviewed for outliers?

Track gaps to closure with owners and due dates ¹.

Required evidence and artifacts to retain

Keep an “SA-7 evidence bundle” that is easy to export for auditors and customers.

Governance artifacts

• SA-7 control card (owner, scope, cadence, exception rules)
• User-installed software policy / standard
• RACI matrix for endpoint software governance

Technical enforcement evidence

• Configuration screenshots/exports showing:
  • no local admin baseline (or controlled elevation)
  • app control/allowlisting policies and assignment groups
  • managed app catalog settings
• Endpoint management compliance reports (device enrollment + policy compliance)

Operational evidence

• Sample of software requests: tickets with approvals and packaging/deployment records
• Exception register with approvals, expirations, and review notes
• Monthly/quarterly control health check report and remediation tracker
• Incident tickets for unauthorized software detections (sanitized if needed)

Retention
Align retention to your overall compliance evidence retention schedule. Make evidence location consistent (GRC repository, ticketing system exports, configuration baselines).

Common exam/audit questions and hangups

Auditors tend to probe the same failure points:

1. “Can users install software?”
   They want a direct answer by endpoint tier, not a policy quote.

2. “Show me enforcement.”
   Expect to demonstrate actual configuration in endpoint tooling and IAM/PAM, plus a device compliance report.

3. “How do you approve exceptions?”
   They will ask for an exception list and proof of periodic review.

4. “How do you know what’s installed?”
   Be ready with an inventory report and how you reconcile unknown items.

5. “What about developers?”
   Have a documented alternative path (managed dev images, curated catalog, VDI) rather than informal admin rights.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Policy-only SA-7. Fix: map each rule to a technical control and show evidence exports.
• Mistake: One giant exception bucket called “Engineering.” Fix: user/device-specific exceptions with expirations and monitoring.
• Mistake: Allowlisting deployed but not enforced. Fix: document modes (audit vs enforce), rollout stages, and current enforcement state by tier.
• Mistake: No single source of truth for installed software. Fix: pick one inventory system for audit responses and document coverage gaps.
• Mistake: Tickets approve software, but installs happen manually. Fix: require packaging and managed deployment so approvals tie to action.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for SA-7, so this page does not cite specific enforcement actions. Practically, weak control over user-installed software increases the likelihood of malware execution, unapproved remote access tools, and data exposure paths. It also increases audit findings because it is easy to test: auditors can inspect endpoint privilege and software inventory quickly.

Practical 30/60/90-day execution plan

First 30 days (stabilize decisions and scope)

• Assign an SA-7 owner and name backup owners.
• Publish the SA-7 control card with tiering and exception rules.
• Inventory device classes and identify where users currently have admin rights.
• Stand up the software request workflow in ITSM (even if fulfillment is manual at first).
• Define the minimum evidence bundle and where it will live ¹.

Days 31–60 (enforce defaults, build the managed path)

• Remove standing local admin for the standard tier; implement controlled elevation for exceptions.
• Launch a managed app catalog and packaged deployment process for common software.
• Start an exception register with expirations and compensating controls.
• Turn on software inventory reporting and define “unknown software” triage steps.
• Run your first control health check; log remediation items ¹.

Days 61–90 (tighten high-risk areas, prove operations)

• Apply stricter enforcement to the high-control tier (privileged workstations first).
• Implement allowlisting where risk justifies it, with documented rollout and enforcement status.
• Automate reports: local admin membership, policy compliance, exception expirations, inventory deltas.
• Complete a second control health check and show trend closure on the first round of findings.

How Daydream fits (without creating tool sprawl)

If you are managing SA-7 alongside many controls, Daydream can store the SA-7 control card, define the evidence bundle, and schedule recurring control health checks with remediation tracking to closure. That reduces the common audit failure where teams cannot show ownership, cadence, and proof of operation ¹.

Frequently Asked Questions

Do we have to block all user-installed software to satisfy SA-7?

You need a governed decision and effective enforcement. Many organizations allow installs only through managed channels and tightly control exceptions by role, device tier, and expiration.

How do we handle developer machines without slowing delivery?

Create a developer tier with a curated toolchain and fast packaging/approval workflow. If developers need elevated rights, make it time-bound with logging and compensating controls.

What counts as “software” for SA-7: browser extensions and scripts too?

Treat anything that executes code or changes runtime behavior as in scope, including extensions, packages, and scripts where users can introduce unreviewed code. Document your boundary and enforce it consistently.

What evidence is the fastest path to “audit-ready” for SA-7?

A control card, a current device privilege report (local admin), configuration exports from endpoint tooling, and a small sample of approvals tied to actual deployments. Add a recurring health check record to show it operates over time.

Our endpoints are partially unmanaged (BYOD). Can we still claim SA-7?

You can scope SA-7 to managed endpoints that access organizational data, and require managed device enrollment for access to sensitive systems. Document the boundary and the access controls that keep unmanaged devices from bypassing the rule.

How often should we review SA-7 exceptions?

Review on a fixed cadence that matches your risk tolerance and device tier, and also on trigger events like role changes or device reassignments. The key is that exceptions expire or receive documented renewal.

Footnotes

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

2. NIST SP 800-53 Rev. 5; Source: NIST SP 800-53 Rev. 5 DOI

3. NIST SP 800-53 Rev. 5