Safeguard 2.3: Address Unauthorized Software

Safeguard 2.3 requires you to detect software that is not approved for use in your environment and take action to remove it, block it, or formally exception it. To operationalize it quickly, define “authorized software,” run recurring discovery, route findings into a remediation workflow, and retain evidence that each detection cycle produced decisions and outcomes. ¹

Key takeaways:

• You need an enforceable definition of “authorized” and a repeatable method to find deviations. ¹
• Treat every unauthorized software finding as a tracked ticket with disposition: remove, block, or approve via exception. ¹
• Audit success depends on evidence bundles per cycle: inputs, approvals, actions, and closure proof. ¹

Safeguard 2.3: address unauthorized software requirement is where “inventory” becomes “control.” An asset and software inventory helps, but it does not prevent risky tools, pirated apps, shadow IT, and bundled installers from landing on endpoints and servers. CIS Safeguard 2.3 expects you to notice unauthorized software and respond in a controlled, documented way. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to turn this into an operating routine with clear ownership, a fixed intake (what data proves something is installed), a decision rubric (what counts as unauthorized), and a closed-loop remediation workflow (what happens after detection). You also need to plan for legitimate business needs: developers testing tools, accessibility software, emergency incident tooling, and third-party support utilities. Those should be handled through a defined exception process, not ad hoc approvals in chat.

This page gives requirement-level implementation guidance you can hand to IT operations, endpoint engineering, and security operations, while keeping governance tight enough to satisfy audits and customer due diligence mapped to CIS Controls v8. ¹

Regulatory text

Excerpt (framework requirement): “CIS Controls v8 safeguard 2.3 implementation expectation (Address Unauthorized Software).” ¹

Operator interpretation: You must (1) know what software is allowed, (2) identify software that is not allowed, and (3) address it through removal, blocking, or a documented exception/authorization path that is governed and reviewable. The operational standard is consistency: the same rule set, the same workflow, and evidence you can replay later. ¹

Plain-English interpretation (what this means in practice)

Unauthorized software is any software that is installed or executed in your environment without explicit approval under your software governance rules. “Address” means you take a deliberate action, not just observe it.

A workable interpretation many auditors accept is:

• Detect: You can reliably discover installed and/or executed software.
• Decide: You can determine whether it is authorized using documented criteria.
• Act: You remove it, block future execution/installation, or approve it via exception with compensating controls.
• Prove: You can show evidence that each step happened for each detection cycle. ¹

Who it applies to

Entity scope: Enterprises, service organizations, and technology organizations using CIS Controls v8 as a framework baseline. ¹

Operational scope (where this bites):

• Corporate endpoints (Windows, macOS, Linux)
• Privileged admin workstations
• Servers (on-prem and cloud VMs)
• VDI environments
• Golden images and software distribution platforms
• Third-party managed devices where you still have policy obligations (your side of shared responsibility)

Common exclusions (must be explicit):

• BYOD where you cannot inspect device state (document as out-of-scope and address via access controls instead)
• SaaS “applications” (handle separately as unsanctioned SaaS / CASB-type governance, but don’t claim this control covers it unless your tooling does)

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

1) Publish an “authorized software” standard

Write a short standard (1–2 pages) that answers:

• What is considered software (installed apps, portable executables, browser extensions, packages, drivers, remote support tools).
• What makes software authorized (approved catalog, approved publisher/signature, approved hash, installed via managed deployment, approved via exception).
• Who can approve exceptions (role-based), and what conditions apply (business justification, time-bound approval, compensating controls). ¹

Practical tip: Avoid a single giant “allowed list” spreadsheet as your control. Treat the source of truth as your endpoint management catalog plus an exceptions register.

2) Assign ownership and trigger events (control card)

Create a control card/runbook with:

• Control owner: typically Endpoint Engineering or SecOps; GRC owner: maintains requirement mapping.
• Cadence: tie to your discovery cycle (recurring).
• Trigger events: new device onboarding, new software deployment, new critical vulnerability, M&A device ingestion, incident response. ¹

3) Implement software discovery (installed and, if possible, executed)

You need at least one reliable data source:

• Endpoint management inventory (installed applications)
• EDR telemetry (process executions) to catch portable apps that don’t “install”
• Server configuration management inventory for server fleets

Define minimum fields to capture per finding:

• Device identifier, user/owner, software name/version, publisher, install date (if available), install path, detection source, first seen timestamp.

4) Create a decision rubric for “unauthorized”

Build a triage matrix your team can apply consistently:

Category	Examples	Default disposition
Clearly unauthorized	pirated software, hacking tools not approved, unlicensed commercial apps	Remove + block + investigate
Probably unauthorized	random freeware, bundled toolbars, consumer VPNs	Remove or route to exception
Business-justified but unapproved	dev tools, database clients, accessibility tools	Exception workflow or add to catalog
False positive / misclassified	OS components, legitimate signed tools	Reclassify and tune detections

Document who can override the default disposition and how that approval is recorded. ¹

5) Route every finding into a tracked workflow

Pick one system of record (ITSM, ticketing, or GRC tasking). Every unauthorized software event should produce:

• Ticket ID
• Classification (unauthorized / exception candidate / false positive)
• Assigned owner (desktop team, server team, app owner)
• Due date based on risk (your policy)
• Closure evidence (uninstall proof, block rule, or approved exception)

Minimum governance requirement: no “handled in Slack” closures. If it isn’t in the system of record, it didn’t happen during an audit.

6) Remediate: remove, block, or exception

Your remediation menu should be explicit:

• Remove/uninstall via endpoint tooling or manual guided steps with confirmation.
• Block via application control, EDR policy, allowlisting/denylisting, or software restriction policies.
• Exception/authorization with:
  • business justification
  • approver name/role
  • scope (devices/users)
  • expiration and review requirement
  • compensating controls (restricted privileges, network segmentation, monitoring)

7) Measure control health (recurring check)

Run a periodic control health review with:

• Open findings aging
• Repeat offenders (same app reappearing)
• Coverage gaps (devices not reporting inventory)
• Tuning changes (reclassification rates, noisy detections)

Track remediation items to validated closure with due dates. ¹

Required evidence and artifacts to retain

Keep evidence that proves operation, not just design:

Core artifacts

• Authorized software standard and exception policy (approved, versioned)
• Control card/runbook (owner, cadence, triggers, steps, exception rules) ¹
• Data source description (which tools produce software inventory/telemetry)

Per-cycle evidence bundle (sample)

• Inventory/discovery export or report snapshot (date-stamped)
• List of unauthorized software findings generated that cycle
• Tickets created/updated for each finding (or a traceable subset with sampling method)
• Approvals for exceptions (including expiry)
• Closure proof: uninstall logs, EDR block policy change record, configuration change record
• Control health check notes and remediation backlog ¹

Retention location

• One system for policy/runbooks (GRC repository)
• One system for tickets
• One evidence folder per cycle with immutable timestamps (or an evidence feature in a GRC platform such as Daydream that binds inputs, actions, and outputs to the requirement)

Common exam/audit questions and hangups

Expect these questions from auditors and customer assessors:

1. Define “unauthorized.” Where is the definition documented, and who approves exceptions?
2. Show the detection method. Which devices report? How do you know coverage is complete?
3. Show a sample. Pick a recent finding and walk from detection → ticket → action → closure evidence.
4. How do you prevent re-install? Removal alone is weak if users can reinstall.
5. How do you handle third-party managed endpoints? What does your contract/SOW require, and what evidence do you receive?

Hangups that cause findings:

• Inventory exists, but no workflow proves action.
• Exceptions exist, but no expiry/review.
• Discovery misses portable executables or unmanaged servers.

Frequent implementation mistakes (and how to avoid them)

• Mistake: “Authorized software” is a vague policy statement.
  Fix: publish operational criteria (catalog, publisher/signature, exception path) and keep it current.

• Mistake: You only track installs, not executions.
  Fix: add EDR execution telemetry for high-risk tools, even if you can’t cover everything.

• Mistake: Findings are remediated but not provable.
  Fix: define the minimum evidence bundle per cycle and store it in one place. ¹

• Mistake: Exceptions become permanent approvals.
  Fix: require expiry and periodic review; make the default “remove unless justified.”

• Mistake: You treat this as an endpoint-only problem.
  Fix: include servers, golden images, VDI templates, and CI build agents in scope where relevant.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this safeguard, so you should frame the risk as control failure rather than regulator penalty. ¹

Risk implications you can cite internally without overstating:

• Unauthorized software increases malware exposure, licensing risk, and data handling risk.
• It also weakens incident response because you cannot quickly distinguish legitimate tools from attacker tooling.
• During customer diligence, inability to show a closed-loop process often results in control exceptions or remediation commitments tied to CIS Controls v8 mappings. ¹

Practical 30/60/90-day execution plan

First 30 days (stand up the control)

• Name the control owner and publish the control card (objective, cadence, triggers, workflow, exception rules). ¹
• Draft and approve the authorized software standard and exception template.
• Confirm data sources for software discovery and identify coverage gaps (non-reporting devices, servers without agents).
• Start a pilot: generate findings for a limited population and run the workflow end to end.

Days 31–60 (make it repeatable)

• Expand discovery coverage to the full endpoint fleet and priority server groups.
• Turn the triage rubric into a queue with dispositions (remove/block/exception/false positive).
• Implement re-install prevention for common unauthorized software (application control rules or EDR blocks where feasible).
• Begin storing per-cycle evidence bundles in a consistent repository (or bind them in Daydream for faster audit packaging).

Days 61–90 (make it auditable)

• Run a full control health check and document remediation backlog with owners and due dates. ¹
• Tune noisy detections; document tuning decisions as part of evidence.
• Run an internal “audit walk-through”: choose recent findings and rehearse the trace from detection to closure.
• Formalize exception review and remove expired exceptions.

Frequently Asked Questions

What counts as “unauthorized software” if teams install tools for legitimate work?

Unauthorized means “not approved under your rules,” not “malicious.” Route legitimate needs through a documented exception or add the software to your approved catalog with defined constraints. ¹

Do we have to block unauthorized software, or is uninstall enough?

Safeguard 2.3 expects you to “address” unauthorized software, and auditors usually look for prevention of repeat occurrences. If you cannot block broadly, block high-risk categories and document why other cases rely on removal plus monitoring. ¹

How do we handle portable apps that don’t show up in installed software inventory?

Add an execution-based detection source (commonly EDR process telemetry) for targeted categories like remote access tools and admin utilities. Document the coverage limits and focus on risk-based detections. ¹

What evidence is the minimum to pass an audit?

Keep your authorized software standard, your runbook/control card, a dated discovery output, and at least a sample set of findings with tickets and closure proof (uninstall log, block policy record, or approved exception). ¹

How should we manage exceptions without creating a permanent loophole?

Require an approver, business justification, scoped devices/users, compensating controls, and an expiration with review. Treat expired exceptions as unauthorized software findings. ¹

Can Daydream help with this safeguard?

Yes, if you use Daydream to package the control card, define the per-cycle evidence bundle, and run recurring control health checks with tracked remediation to closure. That reduces the most common audit failure mode: “we did the work but can’t prove it.” ¹

Footnotes

1. CIS Controls v8