What Safeguard 2.3 asks you to do with unauthorized software
Safeguard 2.3 requires that every unauthorized software package on an enterprise asset is either removed or covered by a documented exception, and that those exceptions are reviewed at least monthly. If your team has found software on endpoints that nobody approved, this Safeguard tells you the outcome to reach: the package is gone, or someone has written down why it stays, who owns that decision and when it will be looked at again. The risk it addresses is simple. Software nobody approved has usually not been patched, configured or monitored, so it becomes an entry point or a hiding place. In CIS Controls v8.1 the Safeguard sits in the Software asset class and the Respond security function, which makes it a response measure that depends on the inventory being right. It belongs to IG1, the essential cyber hygiene baseline that CIS expects every enterprise to meet.
In practice the Safeguard tends to stall in three places. First, ownership is unclear: the person who finds an unapproved package may not know who installed it, which business unit depends on it or who may approve it. Second, removal is slow, because uninstalling a tool that a team uses daily needs a change, a replacement plan and sometimes a vendor conversation. Third, exceptions never expire, so a temporary waiver becomes permanent and drops out of the monthly review. The assessment specification treats this as measurable: CIS's Assessment Specification for v8.1 scores the Safeguard as failing when discovered unauthorized software takes longer than four weeks to resolve, and it counts software still unaddressed on a follow-up scan. Confirm the current measurement wording in the specification itself before you set internal targets.
Before you can act, confirm two prerequisites that the specification names: an enterprise asset inventory (Safeguard 1.1) and a software inventory (Safeguard 2.1). Without them you cannot say which package is unauthorized on which device, and the monthly review has nothing reliable to review. Decide who owns the removal decision, which exception fields you will record (owner, justification, compensating controls, expiry date) and how the monthly review will be evidenced, such as meeting minutes and a dated exception register. The organization owns these decisions and the controls behind them. An implementation partner can help set up the inventory data, the exception workflow and the reporting, but only an independent assessor can test and report on whether the Safeguard is met.
Which assets, software and teams fall under unauthorized software review
Safeguard 2.3 is only as complete as the population it checks. The cards below cover the decisions that set that population: which assets count, who defines what is authorized, who signs off exceptions, and how devices outside your control are treated. Settle these before the first scan, because each one changes how many findings you must resolve within the review window.
Endpoints and servers in scope
Every enterprise asset that can run software belongs in the review, including laptops, desktops, virtual machines and physical servers. The Safeguard 2.1 software inventory and the Safeguard 1.1 asset inventory are the inputs that tell you which hosts exist, so a host missing from either inventory is a host where unauthorized software goes unseen. Confirm that the population your scanner covers matches the population in your asset register before you start measuring.
Cloud workloads and ephemeral instances
Cloud workloads often start and stop faster than a monthly review cycle. Decide whether short-lived instances are measured at the point of launch, from a golden image, or only when they persist beyond a set period. Each choice changes the number of assets an assessor counts and how much tooling you need to run inside the cloud accounts themselves, so write the rule down and apply it consistently.
Mobile devices where applicable
Mobile devices fall in scope only if they are enterprise assets that run software you are responsible for. Corporate-managed phones and tablets may be covered by mobile device management reporting, while personal devices used for work usually are not. Record which device classes you include, since mixing managed and unmanaged devices in one count produces findings that no one can act on.
Who owns the authorized software list
The authorized list is the baseline every finding is measured against, so its owner determines how fast unauthorized software is recognized. Name one accountable owner, usually in IT operations or the platform team, and define who may add entries. Without a named owner, teams approve software informally, and the review produces findings that cannot be resolved because no one can say whether the software was ever approved.
Who approves exceptions
An exception documents why unauthorized software stays on an asset, and it must name an approver. Decide whether security, the business owner or a risk committee signs off, and set the approval path before the first finding appears. Exceptions approved by the team that also benefits from the software weaken the control, so separate the requester from the approver in your process records.
Managed and third-party devices
Devices run by a managed service provider, contractors or a business partner may not report to your inventory tooling. Decide whether these devices are in scope, who runs the review on them, and what the contract requires them to report. Where you cannot measure a device, record it as a gap with a named owner rather than leaving it out silently, because assessors check whether the population was complete.
How the CIS assessment specification counts unaddressed software per asset
The CIS Controls Assessment Specification scores Safeguard 2.3 as failing when resolving discovered unauthorized software takes longer than four weeks. Assessors do not stop at the first finding. They run a follow-up scan, and any software still unaddressed is counted per asset and then across the enterprise. For you, that means the clock starts when unauthorized software is discovered, not when someone first notices it in a report, so the detection path and the ticket path both need timestamps. Confirm the exact measurement logic in the current specification at cas.docs.cisecurity.org before you write it into a procedure, since the specification defines what is measured and the wording of the test is authoritative.
The specification lists Safeguard 1.1 (the enterprise asset inventory) and Safeguard 2.1 (the software inventory) as prerequisites because the measurement needs their data. Without an asset record, you cannot say which device a piece of software sits on, and without an approved software list, you cannot say whether it is unauthorized. Safeguards 2.4 and 2.5 work the other way around: they list 2.3 as a prerequisite, so an organization that cannot remove or document unauthorized software has little to gain from automated discovery or allowlisting. Treat 2.1 through 2.3 as one chain and check that each link produces records the next one can read.
CIS describes what to measure, not how. The specification does not prescribe a ticketing tool, a review board, an exception form or a scanning schedule, so the process design is your decision. Document who decides between removal and exception, what evidence an exception must carry, how the monthly review is recorded, and which system holds the timestamps an assessor will ask for. A sound design lets you answer the four-week question for any asset on demand, and a weak one fails the test even when the software was eventually removed. Ask your assessor early which evidence they expect to see for each of these decisions.
How an assessor tests Safeguard 2.3 and what they ask to see
This table compares each step of an assessor's test of Safeguard 2.3 with the evidence to prepare and the findings that usually cause problems. Read it as a checklist for your own pre-assessment review, since the assessment specification measures timing and follow-up scans as well as the existence of records.
| Test step | What the assessor does | Evidence to have ready | Common finding |
|---|---|---|---|
| Sample discovered software | Selects a sample of software discovered on enterprise assets and compares it against the software inventory from Safeguard 2.1 | Discovery scan exports with timestamps, and the software inventory they are compared against | Software found on endpoints that never appears in any inventory record |
| Trace each item to a disposition | Follows each sampled item to an approved list entry, a removal record or a documented exception | Approved list entries, removal tickets with dates, and exception records with owners | Software with no disposition at all, so it is neither approved, removed nor excepted |
| Check the resolution window | Measures how long it took to resolve each discovered item against the four-week window in the assessment specification | Discovery date and removal date for each sampled item, taken from scan and change records | Removals that took longer than four weeks with no documented exception covering the delay |
| Confirm removal with a follow-up scan | Runs or reviews a follow-up scan to see whether the software is still present on the asset | Post-removal scan results showing the item is gone from the asset | Removals recorded as complete with no follow-up scan, so the software may still be installed |
| Review exceptions | Checks that each exception is documented, approved and still valid | Exception register with business justification, approver, compensating controls and a review date | Exceptions without a review date, or exceptions whose review date has passed without a new decision |
| Review the monthly review record | Confirms that unauthorized software was reviewed at least monthly and that the review produced decisions | Dated meeting notes or ticket queue reports for each month, with the list reviewed and actions taken | Gaps in monthly reviews, or review records that list software without recording a decision |
| Count unaddressed software | Counts software still unaddressed per asset and across the enterprise at the time of the follow-up scan | Asset-level reports showing unaddressed items by asset and a total for the enterprise | Unaddressed software left on assets that the team did not know were in scope |
How to build the unauthorized software process in six steps
This sequence turns Safeguard 2.3 from a written requirement into a working loop: discovered software is checked against an authorized list, removed or covered by a dated exception, and re-scanned until nothing unaddressed remains per asset.
Confirm the authorized software list and its owner
Start by naming one accountable owner for the authorized software list and confirming that it matches the software inventory built under Safeguard 2.1. The owner approves additions, sets the criteria for what counts as authorized, and records the approval date. Software that is not on the list is the population the rest of the process acts on, so gaps here create false positives later. The output is a written, versioned authorized list with an owner, a review date and sign-off from the business or IT function that approves software.
Establish the discovery feed from the software inventory
Connect the process to a source of discovered software so that unauthorized software is found rather than reported by hand. Teams often use an inventory platform such as GLPI, Wazuh Syscollector or osquery, depending on their estate, and should confirm which assets each tool covers and how often it refreshes. Compare each discovered item with the authorized list and flag the mismatches. The output is a documented data source, a comparison query or report, and a test run showing that a known unapproved package appears in the results.
Define disposition rules and the four-week resolution target
Write the rules that decide what happens to each flagged item: remove it, replace it with an authorized equivalent, or record an exception. The CIS Controls Assessment Specification fails Safeguard 2.3 when resolving discovered unauthorized software takes longer than four weeks, so the procedure must set that target and say who is alerted when it is at risk. Define roles for the asset owner, the endpoint or platform team and the security reviewer. The output is a written disposition procedure approved by the process owner.
Set up the exception register with owners and review dates
Create a register for software that stays on enterprise assets under a documented exception. Each entry should name the software, the assets it runs on, the business reason, the owner, the approver, the compensating measures and the next review date. Monthly review is required, so the register must show when each exception was last reviewed. Exceptions without an owner or a review date are treated as unaddressed. The output is a populated register, maintained in a system the auditor can access, with a history of changes.
Schedule the monthly review and follow-up scans
Put the monthly review on a recurring calendar and run a follow-up scan after remediation work so that software still present is counted. The review should check open tickets against the four-week target, confirm each exception is current and decide on any new items. Keep the scan output so the count of unaddressed software per asset can be reproduced. The output is a review record with attendees, decisions and the scan reports it relied on.
Test the process once end to end
Before relying on the process, run one controlled test: install an unapproved test package on a sample asset, confirm the discovery feed flags it, open a ticket, remove the package or log an exception, and confirm the follow-up scan no longer shows it. Record timestamps so the time to resolution can be measured against the four-week target. Ask the independent assessor which evidence format they expect for this test. The output is a dated test record with screenshots or exports, and a list of gaps fixed before the first formal review.
Which evidence shows that unauthorized software is addressed
An assessor testing Safeguard 2.3 wants a trail that runs from discovery to resolution: what was found, when it was removed or excepted, who approved it, and whether it is still there on a later scan. The cards below cover the artifacts that tie those steps together and what each one must show to hold up at audit.
Discovery scan results over time
Scan exports from the software inventory show when each unauthorized package first appeared on each asset. The assessor uses the first-seen date as the starting point for the four-week resolution clock, so timestamps must come from the tool itself rather than from a manual spreadsheet. Keep dated exports from every scheduled run, not only the latest. Confirm that scans cover the same asset population as the Safeguard 2.1 software inventory, or the gaps will appear as unaddressed software later.
Removal tickets with timestamps
Each unauthorized item that is removed needs a ticket that records the asset, the package, the discovery date, the removal date and the person who verified removal. The assessor compares the removal timestamp with the discovery timestamp to test the four-week limit. Tickets closed without a follow-up scan confirming the software is gone do not prove removal, so link each closure to a later scan result.
Exception register with mitigations
Where removal is not possible, the exception register records the software, the business reason, the owner, the mitigating controls, the accepted residual risk and the next review date. Assessors look for an approver with authority over the risk and for a review date no further than the monthly cycle. A blank mitigation column or an exception with no expiry is a finding. Store the register under change control so that edits leave a history.
Monthly review minutes
Minutes from the monthly review show that someone with authority looked at open unauthorized software, decided on removal or exception, and recorded the decisions. Attendance, the date and the list of items reviewed should be in the minutes themselves. Assessors check that the meeting actually happened each month, so gaps in the sequence matter as much as the content. Keep the agenda and the scan extract attached to each set of minutes.
Follow-up scan reports
A follow-up scan after each removal or exception decision shows whether unaddressed software remains, counted per asset and across the enterprise. This is the evidence that turns a claimed removal into a measured result. Keep the count of unaddressed items by asset in each report, so the assessor can compare reports from different dates. Ask your assessor which report format and retention period they accept before you start collecting.
Retention and sign-off records
Set one retention period for scan exports, tickets, register entries and minutes, and apply it to all of them so the trail does not break. Record who signs off each exception and each monthly review, and keep their role and authority in the same repository. Confirm the retention period with your auditor, since the period they expect for a full audit window may differ from your default. Review sign-off records quarterly to catch departed approvers or lapsed delegations.
What meeting Safeguard 2.3 costs in money and effort
This table breaks the cost of meeting Safeguard 2.3 into its components, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to structure a written quote, since the largest ongoing cost is usually staff time rather than tool licenses.
| Cost component | Who is paid or who spends time | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Tooling or licenses | Software vendor or open-source project; no license fee for GPL or Apache tools | Recurring if commercial; open-source removes license spend only | Commercial license tiers track endpoint count; self-hosted tools still need servers, storage and backups |
| Discovery and removal workflow setup | Implementation partner or internal platform engineers | One-time | Number of software packages, OS mix and whether removal runs through existing endpoint management |
| Monthly unauthorized software review | Internal IT operations or security analysts | Recurring every month | Count of new unauthorized findings, asset count and how much triage is automated |
| Exception management | Business unit approvers, risk owners and the security team | Recurring, tied to each exception's review | Number of business units approving exceptions and whether each exception has a documented owner and expiry |
| Removal and remediation work | Desktop support, server administrators or application owners | Recurring, variable | Whether software is removed by automated push or manual visits, and how often users depend on the software |
| External review or testing | Independent assessor or consultant, if engaged | Periodic, per engagement | Scope of the review, number of sampled assets and whether evidence is already organized |
| Auditor sampling | Independent auditor or certification body | Periodic, per audit cycle | Sample size set by the auditor, quality of exception records and how quickly findings are closed |
| Engineering time for evidence reports | Internal engineers or the implementation partner | One-time build, recurring refresh | Whether monthly reports are generated from the inventory tool or compiled by hand |
Which self-hosted open-source tools produce the unauthorized software evidence
Safeguard 2.3 needs a record of what software is on each asset, when it was found and what happened to it. The tools below each produce part of that record, from the asset register and ticket trail to live queries and fleet-wide hunts. None of them removes software on its own unless your own response process does that step.
GLPI asset and software records
GLPI holds the asset register and software records that the organization uses to decide whether discovered software is authorized. Its Assets module covers computers, software, network equipment and peripherals, entered manually or pushed by the GLPI Agent through native inventory available since version 10. Use it to record the authorization decision, the owner, and the ticket that tracks removal or a documented exception. Confirm that the license (GPL-3.0-or-later) and the module set fit your deployment and your internal policy on open-source use.
Wazuh Syscollector installed software
The Wazuh Syscollector module collects installed software, operating system details, services, processes and Windows updates from each endpoint and stores them in the Wazuh indexer. This gives you a per-asset software list that dashboard reports can compare against your authorized list. Check that every in-scope endpoint reports, and that the reports show when each entry was last seen, because the assessment counts software that remains unaddressed across follow-up scans. Wazuh is licensed under GPL-2.0-only, so confirm that this license works with how you plan to distribute or modify it.
osquery scheduled fleet queries
osquery exposes host data such as running processes, loaded kernel modules and browser plugins as SQL tables. Its osqueryd daemon schedules queries across an entire fleet, so you can run a recurring query for installed software and compare results with prior runs. This supports the monthly review rhythm that Safeguard 2.3 expects and helps show that software was found on a specific date. osquery is dual-licensed under Apache-2.0 OR GPL-2.0-only, and you should confirm which license option your organization relies on and how the query results will be stored.
Velociraptor hunts across systems
Velociraptor collects forensic artifacts defined in VQL from endpoints and runs hunts that gather one or more artifacts across a group of systems. Offline machines are scheduled to collect when they reconnect, which helps close gaps caused by laptops that are often away from the network. Each hunt gets a notebook for analyzing the combined results, so you can document which assets were checked and what was found. Velociraptor is licensed under AGPL-3.0-only, so review the obligations that apply if you modify and offer it to others, and confirm that its collection scope fits your data handling rules.
Who owns the removal decisions and what can go to a partner
Your organization owns the Safeguard. Named owners must maintain the authorized software list, decide which unauthorized software is removed and which receives a documented exception, run the monthly review, and answer for removals that miss the four-week window the assessment specification uses. These are management decisions, so they cannot be delegated to a vendor or a consultant without the organization still signing them off.
- Authorized list: Security and IT leadership approve what counts as authorized, so every removal decision has a reference point.
- Exception decisions: An accountable owner records the business reason, the compensating measures, the approver and an expiry date for each exception.
- Monthly review: A named person reviews the unaddressed software list and signs the review record each month.
- Removal accountability: Asset owners or service desk staff remove software and record the date, so the four-week timing can be shown per asset.
- Policy and procedure: Your own documented process defines the steps, roles and escalation path, and staff follow it.
Confirm with your auditor which role signs each record and whether your existing change or software management policy already covers these steps.
An implementation partner prepares the systems and paperwork that make the process repeatable. Scope, deliverables and timelines are agreed in writing before work starts, and the partner works inside your infrastructure. The partner does not decide what is authorized, does not grant exceptions and does not sign the monthly review on your behalf.
- Discovery feeds: Configuring open-source inventory tools such as GLPI, Wazuh, osquery or Velociraptor so that unauthorized software appears in reports per asset.
- Procedure and register drafting: Writing the removal procedure, the exception register template and the monthly review checklist for your owners to adopt.
- Evidence packs: Assembling exports, dated scan results and removal tickets that show the process operated.
- Tool hardening and documentation: Securing the tool deployment and documenting how each report is produced.
- Training: Showing your owners how to run the review and read the reports.
Ask the partner to state in the scope which records they draft and which records your staff must produce and approve.
An independent auditor, assessor or certification body tests the records and issues the report or certificate. The auditor must stay independent of the process being tested, so it cannot design the procedure, configure the tools or run the monthly review. A partner that helped build the process can still prepare evidence, but the auditor forms its own view from the records and from sampling assets.
- Sampling: The auditor selects assets and checks whether unaddressed software was removed or excepted within the expected time.
- Record testing: The auditor reviews the monthly review evidence, the exception register and the scan history for consistency.
- Re-performance: The auditor may repeat a discovery scan to confirm the tool results match the reports.
- Reporting: Only the auditor issues the opinion, attestation or certificate.
- Independence boundary: The auditor does not write your procedure or fix the gaps it finds in the same engagement.
Confirm with the auditor, before fieldwork, which evidence it will accept and how it will treat tooling built by a partner.
Questions buyers ask about unauthorized software before hiring help
How long does addressing unauthorized software take, and what drives the duration?
The duration depends on how many unauthorized packages exist, how many assets they sit on, and how much change each removal triggers. The CIS Controls Assessment Specification scores Safeguard 2.3 as failing when resolving discovered unauthorized software takes longer than four weeks, so the real planning question is whether your change process can clear each finding inside that window. Drivers include whether removal can be automated, whether business owners must approve exceptions, and how many systems are unmanaged. Ask any partner for a written scope that lists the asset count, the discovery source and the change path before agreeing to a timeline.
Can a small team handle Safeguard 2.3 in-house?
A small team can usually handle Safeguard 2.3 in-house if it has a software inventory to compare against and authority to remove software. Safeguard 2.3 depends on Safeguards 1.1 and 2.1, so the asset inventory and software inventory must exist first. Where those inventories are incomplete, the work grows because the team must discover what is installed before it can judge what is unauthorized. Check whether one person can run the monthly review, approve exceptions and reach every endpoint, and whether an outside party is needed for specialist tooling or an independent view.
What does the internal team need to provide?
The internal team must own the decisions, even when a partner prepares the systems. The organization needs:
- A maintained list of authorized software with named owners
- Authority to remove software from enterprise assets, or a route to the teams that can
- A written exception process with approvers and review dates
- Access to endpoint management or change tools to execute removals
- Someone accountable for the monthly review and its records
These roles belong to the organization. Describe them in your policy so an assessor can trace each action to a person.
What can an implementation partner change, and what can it not do?
A partner can deploy and configure discovery tooling, build the comparison between discovered and authorized software, set up removal workflows, and prepare the evidence trail. It cannot decide which software is authorized, approve exceptions on your behalf, or issue an assessment result. Only your organization owns the control, and only an independent auditor or assessor can report on whether it operates. Confirm in writing which of these tasks sit with the partner, which stay with you, and which deliverables the evidence package will contain.
How should exceptions for unauthorized software be documented?
Each exception should be recorded with the software name and version, the assets it runs on, the business reason, the approver, the compensating controls, and an expiry or review date. Safeguard 2.3 accepts a documented exception as an alternative to removal, so the record must be specific enough for a reviewer to test it. Exceptions that never expire, or that name no asset, are the most common weakness assessors find. Keep the register in a system with change history so you can show when each entry was approved and reviewed.
What will an assessor reject?
An assessor will reject evidence that cannot be reconciled to the asset inventory, that shows unaddressed software past the four-week window, or that depends on a single scan with no follow-up. Gaps in the monthly review, undocumented exceptions and exceptions without owners are also common findings. Because the assessment specification counts unaddressed software per asset and across the enterprise, a few forgotten endpoints can fail the measure. Run your own follow-up scan before the assessor arrives and fix any items that remain open.
How often must the unauthorized software process be reviewed?
Safeguard 2.3 requires the review to happen at least monthly, and the review must produce records of what was found, what was removed and which exceptions were approved or renewed. Monthly is the floor, not the target, so schedule the review, assign an owner, and keep dated outputs. The cadence can increase if your environment changes quickly. Confirm the calendar and evidence format with your assessor early, because a missed month is easier to explain before it happens than during fieldwork.
How DeployOpen prepares unauthorized software evidence
DeployOpen helps organizations build the process, tooling and records that show unauthorized software is removed or covered by a documented exception within the assessment timeframe. The organization keeps ownership of its controls, decisions and exceptions, while DeployOpen prepares the systems and evidence an independent assessor would review.
How we scope
- Confirm which enterprise assets and software inventories fall within the written scope for Safeguard 2.3
- Agree how Safeguards 2.1 and 1.1 data will feed the unauthorized software workflow before work starts
- Define the monthly review cadence, exception approvers and the four-week resolution window
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins
How we build
- Configure a self-hosted inventory platform such as GLPI, Wazuh or osquery in the client's own infrastructure
- Set up the workflow that flags unauthorized software, records owners and tracks removal dates
- Build the documented exception template with justification, compensating controls and expiry dates
- Test that follow-up scans correctly count software still unaddressed on each asset
How we hand over
- Document the unauthorized software procedure, tooling configuration and review schedule for the client's team
- Deliver sample reports showing per-asset counts of unaddressed software and exception records
- Provide a mapping of produced evidence to the assessment steps, so the assessor can trace each measure
- Clarify that only the independent assessor or certification body issues the resulting report or certificate
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Retainers can cover monthly review checks, tooling upgrades and updates to exception records
- Ask the assessor which evidence formats and sampling periods they expect before final delivery
- Confirm with your team how often the monthly review must run in your own environment
