Safeguard 2.5 allowlist authorized software: evidence

What Safeguard 2.5 allowlist authorized software requires in practice

Safeguard 2.5 asks that software which is not on the authorized list cannot run or be reached, and that this enforcement is reassessed at least twice a year. It is a technical control, not a policy statement. CIS places it in Implementation Groups 2 and 3 only, so IG1 enterprises are not measured against it. Application allowlisting is the example CIS gives, but the Safeguard is about outcomes: a process that is not on the list should fail to start on the endpoints where allowlisting is installed. Unlike the inventory Safeguards 2.1 and 2.3, which record or respond to software after it is found, 2.5 stops it before it runs. That difference matters to the reader because the evidence changes: an inventory export is not enough, and you need proof that enforcement is active on each asset that can support it.

The risk it addresses is unvetted software executing on managed endpoints, including tools dropped by attackers, unlicensed or vulnerable applications, and changes made outside change control. Three things make the Safeguard hard in practice. Legacy hosts may not support allowlisting agents at all, so you need a documented list of those assets and a compensating approach. Exceptions for business-critical tools accumulate quickly and must be approved and recorded, not silently added. And the authorized list drifts as software is updated, so a list that was correct at deployment can block legitimate patches or leave new binaries unlisted. Confirm with your assessor how they will treat unsupported or excepted assets before you define your scope.

For cross-reference work, the CIS Controls Navigator for v8.1 maps Safeguard 2.5 to NIST CSF 2.0 PR.PS-05, to NIST SP 800-53 Rev. 5 CM-7(5) and CM-10, to ISO/IEC 27001:2022 Annex A 8.7 and 8.19, to SOC 2 CC6.8, and to PCI DSS v4.0 requirements 1.2.5 and 2.2.4. Treat these as CIS's mappings and confirm them against the current text of each framework with your auditor, since a mapping does not establish that one control satisfies another. Sequence your work accordingly: Safeguards 1.1, 2.1, 2.3 and 4.1 supply the asset, software and configuration data that the measurement depends on, so a 2.5 program built before those inventories are reliable will struggle to produce defensible coverage numbers.

Which endpoints, teams and third parties Safeguard 2.5 covers

Safeguard 2.5 only produces a meaningful measurement once you decide which assets, teams and providers it reaches. The CIS assessment specification counts coverage only on assets able to support allowlisting, so the scope decisions below change both the work and the result.

Assets able to support allowlisting

The assessment specification measures allowlisting coverage only on assets that can support allowlisting software. Assets that cannot run an allowlisting agent, such as some appliances or embedded devices, fall outside that denominator, but you must record why. Start from the detailed enterprise asset inventory under Safeguard 1.1 and mark each device with its supported agent platform. A documented exclusion for each unsupported asset is what keeps the coverage figure defensible.

Servers, workstations and shared kiosks

Servers, employee workstations and shared kiosks carry different risk and different change patterns. Servers usually run fixed workloads, so the authorized list is small and changes go through a change process. Workstations have more user-driven installs and need a tighter exception path. Shared kiosks often have the highest exposure because many people use them. Decide per endpoint class whether allowlisting enforces, audits only, or is deferred, and record that decision in the scope document.

IG2 and IG3 applicability

Safeguard 2.5 is assigned to Implementation Groups 2 and 3, not Implementation Group 1. An organization at IG1 is not required to meet it, although it may adopt it voluntarily. Organizations at IG2 apply it to in-scope assets in the same way as IG3. Confirm your Implementation Group with the CIS Controls Implementation Groups guidance before you commit budget, because the Group determines whether this Safeguard is an audit requirement for you.

Owners of the authorized list

The authorized list needs a named owner who approves additions and removals. In most organizations this is IT operations or endpoint engineering, with security reviewing exceptions and an architect or application owner approving business software. Write down who signs off a new entry, who can enforce a block, and who reviews exceptions. Without a clear owner, the list drifts and the twice-yearly reassessment has nothing reliable to compare against.

Managed endpoints run by a service provider

When a managed service provider operates endpoints, the allowlist, the enforcement policy and the reassessment evidence still belong to your organization. Confirm in the contract who maintains the authorized list, who approves changes, and how the provider delivers allowlist coverage reports. Under Control 15, the provider's role is evaluated like any other service provider. Ask for read access to the coverage data so that you can verify it rather than rely on a summary.

Prerequisite Safeguards 1.1, 2.1, 2.3 and 4.1

The assessment specification lists Safeguards 1.1, 2.1, 2.3 and 4.1 as prerequisites for measuring Safeguard 2.5. The asset inventory under 1.1 defines which devices are in scope, the software inventory under 2.1 defines what each device runs, and the handling of unauthorized software under 2.3 shows what must be removed or excepted. The secure configuration process under 4.1 defines how enforcement settings are deployed and kept. Gaps in any of these will show up as gaps in your 2.5 measurement.

How an assessor tests allowlisting coverage and the six-month rule

This table sets out how an assessor measures Safeguard 2.5, what evidence to prepare for each test and where implementations usually fail. Read it as a checklist: confirm each population is measured, each reassessment date is recent and each prerequisite Safeguard produces data the allowlist can be checked against.

Test area	What the assessor checks	Evidence to prepare	Common findings
Reassessment currency	Whether the allowlist was last reassessed within six months. A reassessment older than six months fails the Safeguard regardless of coverage.	Dated reassessment records, approval sign-offs and the schedule that triggers the next review.	Reassessment dates that were never recorded, or a last review that falls outside the six-month window.
Installation coverage	The share of assets able to support allowlisting software that actually have it installed.	Agent or enforcement deployment reports per asset, with the asset population they are measured against.	Coverage reported only on servers, with workstations or virtual machines left out of the count.
Configuration coverage	Whether the allowlisting software is configured to enforce the approved list on supported assets, not just installed.	Exported policy or configuration showing enforcement mode, not audit-only mode, applied to each asset group.	Agents installed in monitor or audit mode, so unapproved software still runs.
Asset population	Whether the denominator of supported assets is complete and traceable to the enterprise asset inventory (Safeguard 1.1).	Asset inventory export, classification of which assets can support allowlisting and the reason for each exclusion.	Assets excluded from the count without a documented reason, or an inventory that omits cloud or remote endpoints.
Approved list source	Whether the list is built from the software inventory (Safeguard 2.1) and the unauthorized software process (Safeguard 2.3).	Authorized software list, change history, and the records showing how unauthorized software was removed or excepted.	Lists that differ from what is installed, or additions approved with no matching inventory entry.
Secure configuration baseline	Whether allowlisting is part of the documented secure configuration process (Safeguard 4.1) for each asset type.	Configuration standard that names allowlisting, with the asset types it applies to and the owner of each.	Allowlisting absent from build images, so new assets are not covered until someone checks them manually.
Downstream dependency	Whether Safeguard 2.6 (library allowlisting) can be assessed, since it lists 2.5 as a prerequisite.	Confirmed Safeguard 2.5 measurements that can be reused as the starting point for library allowlisting.	Library allowlisting planned without a current, measured software allowlist beneath it.
Allowlists on paper only	Whether enforcement on endpoints matches the written policy when tested on sample assets.	Sample test results showing an unapproved program was blocked on selected assets, with timestamps.	Policy documents that describe enforcement, while sampled endpoints run unapproved software without any block.

How to implement allowlisting from inventory to recurring reassessment

This sequence moves Safeguard 2.5 from a software list to enforced, measured allowlisting, with each step producing a record an assessor can check. The prerequisites come first because the reassessment measures depend on them.

Confirm the software inventory and unauthorized software handling
Before any enforcement, confirm that the software inventory under Safeguard 2.1 is current and that unauthorized software is being addressed under Safeguard 2.3. The CIS Controls Assessment Specification lists 1.1, 2.1, 2.3 and 4.1 as prerequisites for measuring 2.5 because they produce the data the measurement needs. The internal team owns this step. Done means you can name the asset groups in scope, show the most recent inventory export, and show a log of how unauthorized software was removed or excepted.
Define the authorized list and exception process
Write the list of software the organization permits to run, with version or publisher detail where enforcement needs it, and assign an owner who approves changes. Define the exception process too: who can request an exception, what justification is required, and who signs it off. The output is a versioned approved list and a written exception procedure. Ask your reviewers to confirm that each entry traces back to an item in the inventory, since an allowlist built from unverified names will fail coverage checks later.
Choose an enforcement mechanism that blocks execution
Select a technical control that can prevent software outside the list from running or being reached, such as application allowlisting built into the endpoint platform or a policy engine on the host. Confirm with the vendor whether it blocks execution, only alerts, and which operating systems and asset types it supports. Record the decision, the supported platforms and the known gaps. An assessor will look for enforcement, so a mechanism that only reports is a finding to document, not a control that meets the Safeguard.
Pilot the policy on a small asset group
Apply the allowlist to a small, representative group of assets, including at least one that runs the business software most likely to be missed. Run it in audit or report-only mode first, then review every blocked or flagged item against the approved list and the exception process. The output is a pilot report listing false positives, the list changes they caused and the exceptions granted. Confirm the pilot covers the asset classes you intend to roll out to, because the assessment measures coverage on assets able to support allowlisting.
Roll out in stages and measure coverage
Expand enforcement across the in-scope assets in stages, tracking how many assets have the allowlisting software installed and how many have it configured. Those two measures, installation coverage and configuration coverage, are what the assessment specification scores. Produce a coverage report at each stage and record the assets that cannot support allowlisting along with the compensating handling you chose. Ask the platform team to show the report from the management console, not a spreadsheet, so the figures can be reproduced.
Configure and document the policy baseline
Build the allowlist policy as part of the secure configuration process under Safeguard 4.1, so that the policy, its settings and its change history are documented together. Store the policy definition in version control, record who approved each change and link it to the approved list version. The output is a baseline document and a change log that show how the policy was configured and why. Confirm with your platform team that configuration changes to the endpoint agent also follow this process.
Schedule and record the reassessment
Set a reassessment schedule that runs at least twice a year, as Safeguard 2.5 requires, and assign the person accountable for it. The assessment specification fails the Safeguard when the last reassessment is more than six months old, so the calendar entry matters. Each reassessment should produce a signed record covering the approved list version, coverage figures, exceptions granted and open items. Keep these records with the inventory and policy baseline so that an auditor can trace the full chain from software list to enforced control.

Which evidence shows allowlisting is enforced and reassessed

An assessor testing Safeguard 2.5 wants to see three things: which software is authorized, that enforcement is actually applied across supported assets, and that the control was reassessed on schedule. The artifacts below connect those three points, and each one needs an owner who signs it off before the next reassessment date.

Approved authorized-software list

This is the baseline everything else is measured against. Keep it as a versioned record with the owner, the business justification and the date each entry was approved or removed. Between audits, review additions against the software inventory from Safeguard 2.1 so that no executable is allowed simply because it appeared on a machine. The IT asset owner or service owner should approve changes, and the security function should countersign any entry that runs with elevated privileges.

Enforcement policy or configuration baseline

This artifact shows the technical rule that blocks unlisted software, such as an application allowlisting policy, and the scope it applies to. Export the policy and its version history, and record which operating system groups or device classes it covers. Because the baseline changes when hardening changes, Safeguard 4.1 secure configuration records should reference it. Security engineering should own the policy, and change control should approve each revision.

Installation and configuration coverage reports

Coverage reports answer the two metrics the assessment specification uses: how many assets able to support allowlisting have it installed, and how many have it configured correctly. Run the report on a schedule, keep the output with timestamps, and document the denominator, meaning which assets were excluded as unable to support allowlisting and why. Operations should produce the report, and the security lead should review gaps before it is filed as evidence.

Exception register with approvals

Every asset or application that runs outside the allowlist needs a recorded exception. The register should list the asset, the software, the business reason, the compensating controls, an expiry date and the approver. Review it at each reassessment, and remove exceptions whose conditions no longer hold. The risk owner, not the engineering team, should accept the residual risk, and the record should show that acceptance.

Dated reassessment records

Safeguard 2.5 is scored as failing when the last reassessment is more than six months old, so this record is what proves timing. Keep a dated record for each reassessment that states the scope, the results, the findings and the next due date. Schedule the next date at the time of the current review. The control owner signs each record, and a second reviewer should confirm that the date gap never exceeds the limit.

Remediation tickets for blocked or failed assets

When allowlisting blocks a legitimate tool or an asset fails its coverage check, the ticket shows the detection, the decision and the fix. Keep the ticket trail linked to the asset record so an assessor can follow one case from start to close. Tickets should record whether the software was removed under Safeguard 2.3 or added to the list under Safeguard 2.1. The operations team closes the ticket, and the control owner checks a sample each quarter.

What allowlisting costs in tooling, engineering, upkeep and review

The table lists the cost components of enforcing Safeguard 2.5, who is typically paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a written quote, since no price or duration is supplied for these components. The main takeaway is that the recurring cost of keeping an allowlist current and reassessed usually outweighs the initial rollout.

Cost component	One-time or recurring	Who is paid or who carries it	What drives it up or down
Enforcement tooling or licenses	Recurring (subscription) or one-time (perpetual), depending on vendor	Application control vendor or reseller; open-source tools carry no license fee but need hosting and staff	Asset count and operating system mix; open-source options can remove license spend but add self-hosting effort
Policy design and inventory alignment	One-time, revisited at each change cycle	Internal engineers or an implementation partner building the allowlist from the Safeguard 2.1 software inventory	Quality of the software inventory (Safeguards 1.1 and 2.1); a weak inventory means more manual approval work
Staged rollout and endpoint testing	One-time per platform, repeated for new platforms	Internal platform engineering or a partner preparing test rings and rollback plans	Heterogeneity of endpoints; each distinct OS build or hardware class adds test cases
Exception handling and approvals	Recurring	Security and IT operations staff reviewing requests and documenting decisions	Change frequency of business software and the volume of legitimate new installs
Configuration coverage monitoring	Recurring	Operations staff tracking allowlisting installation and configuration coverage on supported assets	Number of assets able to support allowlisting; unsupported devices need documented handling
Twice-yearly reassessment and evidence upkeep	Recurring, at least every six months under the assessment specification	Internal compliance or security staff, or a partner preparing evidence packages	Scope of in-scope assets and how automatically evidence is exported from the tooling
External review and auditor sampling	Recurring, timing set by the assessment or audit cycle	Independent auditor or assessor, who issues any report or attestation	Sample size chosen by the assessor and the quality of prepared evidence; ask the assessor for its fee basis in writing

Which open-source tools can produce allowlisting coverage evidence

Wazuh's Security Configuration Assessment scans monitored endpoints against YAML policies. Most policies are shipped based on CIS Benchmarks, and you can extend them with custom policies. The checks cover files, directories, registry keys and running processes, and each failed check comes with remediation guidance. For Safeguard 2.5, this produces dated pass and fail results showing whether the approved software and processes on each endpoint match your documented configuration. The tool reports on that state. It does not, by itself, prevent an unapproved application from starting.

Policy-based checks: Each YAML policy groups related checks, so you can map a policy to the assets in your allowlisting scope.
Custom policies: Write checks for the presence or absence of approved binaries, service executables or specific process names, then test them on a sample host first.
Registry and process coverage: Checks on registry keys and running processes address the places where unapproved software often persists on Windows hosts.
Per-endpoint results: Results tied to each agent let you show coverage by asset class, which is the form assessors usually request.
License terms: Wazuh is licensed under GPL-2.0-only. Have counsel confirm the obligations that apply to your deployment.

Confirm the policy files and operating systems covered by your Wazuh version against the Wazuh documentation before you cite them as evidence.

Where allowlisting programs fall short and how to close each gap

Most allowlisting programs fail Safeguard 2.5 on paperwork and scope long before they fail on technology. The gaps below are the ones that show up when an assessor compares the allowlist, the inventory, the reassessment record and the endpoint list against what is actually enforced.

Allowlist drifts from the software inventory

An allowlist that does not match the software inventory from Safeguard 2.1 cannot be measured. Assessors compare the two lists, and any authorized application missing from one or the other becomes a finding. Check that each allowlist entry traces to an inventory record with an owner, and that new installs update both. The allowlist should be generated from the inventory, not maintained as a separate spreadsheet.

Enforcement that only audits

A tool that logs unlisted software but never stops it does not enforce anything. Safeguard 2.5 asks for technical enforcement so that software outside the list cannot run or be reached. Confirm in the policy configuration that the mode is block, not audit or report-only, and test it on a non-production host by attempting to run an unlisted binary. Keep audit mode as a short, dated rollout phase with a written end date.

Reassessments that slip

The assessment specification fails Safeguard 2.5 when the last reassessment is more than six months old. The reassessment is a recorded review of the allowlist against current software, not an informal check. Put it on a calendar with a named owner, keep the dated record of each review, and set an alert before the six-month mark so the gap never reaches an assessor.

Exceptions with no owner or expiry

Temporary exceptions that let a blocked application run often become permanent and invisible. Each exception should name the software, the business reason, a responsible owner, a compensating control and an expiry date. Ask for a list of active exceptions and check whether any are past their expiry. An exception without these fields is an unauthorized allowance that the assessor can treat as a missing control.

Endpoints left out without reason

Coverage metrics count allowlisting installation and configuration on assets able to support it, so every excluded endpoint needs a reason. Compare the allowlisting agent's host list against the enterprise asset inventory from Safeguard 1.1. Hosts that cannot run the agent should be recorded with the technical reason and a compensating control, not silently absent from the report.

Policies that break business software

A rigid allowlist that blocks line-of-business tools, updaters or vendor agents will be disabled under pressure, and the program then fails. Route every new application through a documented change process that tests it on a pilot group, records approval and updates the allowlist before broad rollout. Ask who can approve additions and how long the process takes, and confirm it is written down.

Who does what: your team, an implementation partner and the auditor

Your organization owns the Safeguard. The CIS Controls ask the enterprise to decide what software is authorized, who may approve an exception, and when the allowlist is reassessed. No partner can make those decisions on your behalf, and an assessor will ask who signed them.

Authorized list ownership: A named owner maintains the list of approved software, libraries and scripts, and records the business reason for each entry.
Exception approvals: Someone with authority accepts or rejects requests to run software outside the list, with a documented mitigating control and an expiry date.
Reassessment decision: Your team schedules and signs off the reassessment at least twice a year, since the assessment specification fails a Safeguard last reassessed more than six months ago.
Coverage follow-up: Your operations staff act on coverage gaps, such as endpoints where allowlisting is not installed or not configured.
Prerequisite data: Your asset and software inventories (Safeguards 1.1 and 2.1) must be current, because the measurement depends on them.

Confirm internally who holds each of these roles before any partner starts work, and write the owners into the policy.

Common questions about meeting Safeguard 2.5

How much effort does application allowlisting take, and what drives it?

The effort depends mostly on how many asset types you run and how stable your software estate is. Allowlisting is not a one-time switch: you must build the authorized list from the software inventory (Safeguard 2.1), decide how exceptions are handled, test policies against real workloads, and then keep the list current as software changes. The main cost drivers are the number of distinct operating system builds, the number of business applications with frequent updates, the share of endpoints that need exceptions, and how well the asset and software inventories already match. Ask any provider for a written breakdown of discovery, policy design, pilot, rollout and ongoing maintenance, with the assumptions behind each.

Can an open-source stack meet Safeguard 2.5 without license spend?

Open-source tools can produce much of the evidence Safeguard 2.5 asks for, but they do not remove the need for an allowlisting control itself. Wazuh Security Configuration Assessment, Fleet policies and osquery can check whether software and configuration states match what you expect across endpoints, and Velociraptor can collect artifacts when you investigate exceptions. Confirm with each vendor whether a given enforcement capability, such as blocking execution rather than only reporting it, is available in the edition you plan to use. Licensing of the tools is only one line item; labor for configuration, integration and evidence collection usually costs more.

What does the internal team need to contribute?

Your team owns the decisions that make allowlisting meaningful. Someone must approve the authorized list, define the exception process with named approvers, and confirm which assets can support allowlisting software. Endpoint administrators need to test changes against business applications, and the change or patch process must update the list when software is upgraded. An implementation partner can prepare policies, tooling and evidence, but the organization remains accountable for the outcome and for the people who sign off on exceptions. Plan for this time before the engagement starts, because approvals are often the slowest part.

How long does an allowlisting rollout take?

The duration depends on the written scope, not on a general figure. A rollout typically covers an inventory baseline, a pilot group, staged enforcement and handover of the review process, and each phase depends on how quickly your teams approve software and exceptions. Ask any provider for milestones, the assets and business units in each phase, the client decisions each milestone needs, and what happens if a phase uncovers unsupported or unknown software. Timelines in a fixed-scope proposal should map to those milestones and the dependencies behind them.

Do IG1 organizations need to implement Safeguard 2.5?

No. Safeguard 2.5 is assigned to Implementation Groups 2 and 3, not to Implementation Group 1. IG1 organizations should still maintain an accurate software inventory and address unauthorized software, because those practices are foundational. If your organization is IG1 but a customer contract or regulator asks for allowlisting, confirm the requirement in writing, since the obligation then comes from that agreement rather than from the Safeguard's implementation group.

How is the six-month reassessment evidenced?

The assessment specification scores Safeguard 2.5 as failing when the last reassessment is more than six months old, so you must keep dated records showing that the authorized list and enforcement settings were reviewed at least twice a year. Useful evidence includes review minutes or tickets, the version and date of the authorized list, policy export files, and coverage reports showing which assets run the control. Set a recurring calendar item tied to the review and retain each review record in your evidence repository. An auditor will check the dates and whether the review changed anything.

Can our implementation partner also be our auditor?

No. DeployOpen plans, implements and documents systems and evidence for Safeguard 2.5, but it does not issue audit reports, attestations or certifications. Independent auditors, assessors or certification bodies perform the assessment and issue any report or certificate. Using the same firm for both roles would undermine the independence an assessor needs. Choose an assessor separately and confirm its independence and qualifications before the implementation work begins.

How DeployOpen scopes, implements and evidences Safeguard 2.5

DeployOpen prepares the technical enforcement behind Safeguard 2.5, so that software outside the authorized list cannot run on in-scope assets. We plan, implement and document the allowlisting platform and its evidence inside your own infrastructure, then hand over the records an independent assessor will ask for. We do not issue assessments or certifications.

How we scope

The written scope names which asset groups support allowlisting and which are excluded, with reasons.
Scope confirms the Safeguard 2.1 software inventory and 2.3 unauthorized software process that feed the allowlist.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We configure allowlisting enforcement on in-scope endpoints, with rules tied to the approved software list.
We set up osquery or Fleet queries that report allowlisting installation and configuration coverage per device.
We test that unapproved executables are blocked on representative devices and record the results.

How we hand over

You receive the documented allowlist process, reassessment schedule and named owners for each review cycle.
Coverage reports, query definitions and test records are delivered in formats your assessor can reproduce.
We document exceptions with their approvals, so every unlisted item has a traceable decision.

How we support

Ongoing support and upgrades are available as a retainer, covering reassessment cycles and rule changes.
Retainers can include continuous monitoring of coverage metrics against the six-month reassessment limit.
Ask your assessor which evidence they need before handover, so we can align the records to their test.