SA-7: User-installed Software

SA-7 requires you to control and govern software that end users can install on organizational systems so unapproved or risky applications do not enter your environment. To operationalize it fast, you need a clear policy, technical enforcement (allowlisting/privilege controls), an approval workflow, and repeatable evidence that the control works in practice ¹.

Key takeaways:

• Define what “user-installed software” means in your environment, then set an allow/deny model and an exception path ¹.
• Enforce the policy with endpoint controls (least privilege, application control, and software inventory) and document how enforcement works ¹.
• Keep assessment-ready evidence: policy, configurations, approval tickets, and monitoring outputs mapped to SA-7 ².

The sa-7: user-installed software requirement is about controlling a common and under-managed path for introducing security, privacy, and operational risk: end users installing software directly on endpoints and servers. In regulated environments, “we trust our users” is not a control. Auditors and assessors expect to see that you’ve defined what users can install, how you technically prevent or detect unauthorized installs, and how you handle legitimate business need without turning every request into a fire drill ¹.

SA-7 sits in the System and Services Acquisition (SA) family, but day-to-day it lands squarely on endpoint management, identity and access management, and change/exception handling. If you support federal information systems or you are a contractor handling federal data, you will likely need to demonstrate that user-installed software is governed, consistently enforced, and evidenced in a way that stands up to assessment scrutiny ¹.

This page gives you requirement-level implementation guidance you can hand to control owners and operators: what to decide, what to configure, what to document, and what evidence to retain.

Regulatory text

Control excerpt (as provided): “NIST SP 800-53 control SA-7.” ²

What an operator must do with that text: SA-7 requires you to implement governance and technical controls around software installed by users. Practically, that means you (1) define rules for user-installed software, (2) restrict installation privileges or enforce application allowlisting/controls, (3) provide an approval/exception process, and (4) monitor and keep evidence that unauthorized software is prevented, detected, or remediated ¹.

If you only publish a policy but cannot show enforcement and operational records, expect an assessor to mark SA-7 as ineffective or “documented but not implemented” ¹.

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

End users should not be able to introduce unknown executables, browser extensions, agents, developer tooling, or “free utilities” onto corporate systems without guardrails. SA-7 is satisfied when you can prove:

• You know what software is allowed.
• You can stop or control installs that violate policy.
• You have a business-friendly way to request and approve software.
• You can detect unauthorized software and respond consistently ¹.

A simple mental model that works in audits: “Allow by exception” for high-risk environments (admins install; users request), and “Allow by policy” for low-risk environments (users can install from a managed catalog only). Either model can work if it’s well-defined and enforced.

Who it applies to (entity and operational context)

You should scope SA-7 to:

• Federal information systems and the endpoints/servers that support them ¹.
• Contractor systems handling federal data, including laptops, VDI, jump hosts, build servers, and any administrative workstations used to access federal data environments ¹.

Operationally, SA-7 most often applies to:

• Corporate endpoints (Windows/macOS/Linux)
• Admin workstations and privileged access workstations
• VDI/Citrix pools
• Server fleets where “users” include engineers with shell access
• Mobile devices if your environment allows sideloading or unmanaged app sources (your MDM policy becomes the enforcement point)

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

Step 1: Set the decision points (write them down first)

Document these SA-7 design decisions in one place (policy + standard):

1. In-scope assets: Which endpoints, servers, and VDI images are governed by SA-7.
2. Who counts as a “user”: Employees, contractors, third parties with accounts, developers with local admin, and break-glass admins.
3. Allowed software model:
   • Managed catalog only (preferred), or
   • Allowlist/denylist rules, or
   • Admin-only installs with request workflow.
4. Approval authority: Who can approve (IT, Security, application owner) and what review criteria apply.
5. Exception rules: Time-bound exceptions, compensating controls, and required re-approval triggers.
6. Enforcement points: EDR, endpoint management, app control, identity/privilege management, software inventory ¹.

Step 2: Remove routine local admin where feasible

SA-7 becomes much easier when standard users cannot install system-wide software.

• Use least privilege for endpoints: standard user by default.
• Where dev teams need elevated rights, use just-in-time elevation or controlled admin tooling with logging.
• Define “approved installer accounts” for IT packaging and deployment.

Assessors often focus here because it is a strong predictor of whether the rest of the program is real.

Step 3: Implement technical enforcement (pick a primary control, then a backstop)

Choose a primary enforcement pattern:

Pattern A: Managed software catalog

• Users can request from a curated set.
• Installations happen via endpoint management tooling.
• Non-catalog installs are blocked by privilege controls.

Pattern B: Application control (allowlisting)

• Approved executables and publishers run.
• Unknown binaries are blocked or require approval.
• Strong fit for high-sensitivity endpoints and admin workstations.

Then add a backstop:

• Software inventory reporting to detect drift.
• EDR detections for unauthorized installers, suspicious tools, and persistence mechanisms.

Step 4: Build the approval workflow you can evidence

Define a lightweight workflow that produces durable artifacts:

• Intake channel (service desk ticket type)
• Required fields: business justification, data accessed, license/source, vendor/third party name, requested scope (user/device group), and whether it needs elevated permissions
• Security review criteria: malware scanning expectations, publisher verification, update mechanism, network communications, and whether it introduces remote access capability
• Decision outcomes: approve, deny, approve with conditions (sandbox only, VDI only, no admin rights)
• Deployment method: packaged deployment, self-service catalog, or time-bound exception

Step 5: Monitor and respond (make it repeatable)

You need an operational loop:

• Detect: new software installs, unsigned binaries, new browser extensions, unauthorized package managers.
• Triage: confirm legitimacy, check ticket linkage.
• Remediate: uninstall, isolate host, remove privileges, or add to allowlist if approved.
• Trend: recurring requests indicate catalog gaps; recurring detections indicate enforcement gaps.

Step 6: Map SA-7 to an owner and evidence cadence

SA-7 fails in audits when it has no accountable operator.

• Name a control owner (endpoint/platform security is common).
• Define what evidence is produced and how often (policy review, configuration snapshots, sample tickets, reports).
• Store artifacts centrally with clear naming so you can respond in days, not weeks ².

Daydream fits here as the system of record to map SA-7 to an owner, the operating procedure, and the recurring evidence set so you can answer assessor requests without rebuilding context each cycle ².

Required evidence and artifacts to retain (assessment-ready)

Keep evidence that proves both design and operation:

Governance (design evidence)

• SA-7 policy/standard for user-installed software (approved sources, prohibited categories, exception path)
• Role definitions: who can approve, who can install, who packages
• Scope statement: in-scope endpoints/servers/VDI

Technical enforcement (configuration evidence)

• Endpoint privilege configuration (proof standard users lack install rights where required)
• Application control/allowlisting configuration exports or screenshots
• Managed software catalog configuration and deployment groups
• EDR/MDM policy settings relevant to installation controls

Operational evidence (run-the-control evidence)

• Sample of software approval tickets with decisions and deployment records
• Unauthorized install detections and the associated incident/service tickets
• Software inventory report showing installed software by device group
• Exception register: time-bound exceptions with approvals and expiration handling

Common exam/audit questions and hangups

Assessors tend to probe the same weak points:

1. “Can a standard user install software today?”
   Be ready to demonstrate controls on a test machine or provide configuration evidence.

2. “How do you know what is installed across the fleet?”
   Provide an inventory report and explain coverage gaps (offline devices, BYOD exclusions).

3. “Show me the last few approvals and how you validated the software.”
   Ticket evidence must show review, not just “approved.”

4. “What happens when unauthorized software is detected?”
   Provide a short SOP and real tickets showing remediation.

5. “How do exceptions expire?”
   If exceptions never expire, the exception process becomes a bypass.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Policy-only SA-7	No proof of enforcement	Pair policy with endpoint configuration exports and an approval workflow
“Denylist” mindset	New software appears faster than deny rules	Move to allowlisting or managed catalog for key populations
Local admin for large user groups	Users can install anything, silently	Standard user by default; controlled elevation for dev/admin needs
Exceptions with no end date	Permanent bypass	Require expiration + re-approval triggers
Inventory without action	You can see the problem but not correct it	Tie detections to tickets and defined remediation SLAs (internal)

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog, so this page does not cite enforcement outcomes. Operationally, uncontrolled user-installed software increases exposure to malware, credential theft tooling, unlicensed software risk, and unsupported applications that complicate incident response and patching. In federal and federal-adjacent assessments, the practical risk is a control failure finding that drives POA&Ms, delays authorizations, or triggers customer remediation demands ¹.

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Assign SA-7 control owner and publish a one-page standard: what’s allowed, what’s blocked, how to request.
• Identify in-scope endpoints/servers and current state: local admin prevalence, existing software inventory sources, existing endpoint tooling.
• Stand up a software request ticket type with required fields and approval routing.
• Start capturing evidence artifacts in a central repository mapped to SA-7 ².

Days 31–60 (enforce on the highest-risk populations)

• Remove routine local admin for the highest-risk group (admins, finance, security, systems with federal data access), with an exception mechanism.
• Implement managed software catalog or application control for that population.
• Produce your first “unauthorized software” report and run the remediation workflow end-to-end.
• Train service desk and endpoint engineers on packaging/deployment expectations.

Days 61–90 (scale and prove operations)

• Expand enforcement to broader endpoint populations.
• Formalize the exception register and expiration process.
• Add monitoring dashboards and a monthly operational review (requests, approvals, denials, detections, removals).
• Prepare an assessment packet: policy, configs, sample tickets, inventory reports, exception log, and SOPs.

Frequently Asked Questions

Does SA-7 mean users can never install software?

SA-7 does not require a blanket ban, but it does require governance and control. Many teams allow installs only through a managed catalog or via an approval workflow that results in IT-managed deployment ¹.

How do we handle developers who need tools quickly?

Create a developer catalog (approved IDEs, SDKs, package managers) and a fast-path approval lane with defined criteria. If devs need elevation, use controlled elevation with logging and time bounds rather than permanent local admin.

Are browser extensions included in “user-installed software”?

Treat them as in scope if they execute code, access data, or integrate with SaaS. Manage via browser enterprise policies, allowlisted extension IDs, and reporting from endpoint tools.

What evidence is most persuasive to an assessor?

A clean combination: policy/standard, technical enforcement configuration exports, a software inventory report, and a small sample of recent tickets showing approval and deployment. Add examples of unauthorized installs detected and remediated to prove operations.

What if we can’t technically block installs on certain legacy systems?

Document a compensating control: restricted admin access, monitoring for new executables, tighter network egress, and an exception record with a remediation plan. Track it as a known gap with ownership and milestones ¹.

How should we document SA-7 in our GRC system?

Record the control owner, the enforcement mechanisms (privilege management, app control, catalog), the SOP, and the recurring evidence list. Daydream is commonly used to keep that mapping and evidence set assessment-ready without rebuilding it each cycle ².

Footnotes

1. NIST SP 800-53 Rev. 5

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