Safeguard 2.2 Ensure authorized software is supported

What Safeguard 2.2 Ensure authorized software is currently supported asks your team to prove

Safeguard 2.2 asks you to prove that only currently supported software is marked as authorized in your software inventory. Software the mission still needs but that the vendor no longer supports must be covered by a documented exception that describes the mitigating controls and the residual risk the organization has accepted. Any other unsupported software is treated as unauthorized. The practical test is simple: pick entries from the inventory, confirm each one's vendor support status, and show that the authorized list was checked against that status within the last month. The Safeguard expects the list to be checked for vendor support at least monthly, and the CIS Controls Assessment Specification scores the Safeguard as failing when the authorized software inventory was last updated more than four weeks ago. The Safeguard sits in the Software asset class and the Identify security function, and it applies at all three Implementation Groups, which makes it part of IG1 essential cyber hygiene.

The difficulty is rarely the policy. End-of-life dates are published in scattered places: vendor lifecycle pages, product release notes, distributor notices and internal change tickets, and each vendor uses its own terms for support, extended support and security-only updates. Inventories compound the problem because the support field is often filled in once at purchase and never revisited, so an entry can read as authorized long after the vendor stopped issuing patches. Before the first monthly check, confirm with each owner which lifecycle source is authoritative for each product, record the end-of-life date next to the inventory entry, and decide who signs off when a date is missing or ambiguous. Those decisions matter more to an assessor than the tool used to store them.

The inventory that feeds this check comes from Safeguard 2.1, which the assessment specification names as a prerequisite because it produces the data the measurement needs. Software records held in a self-hosted asset tool such as GLPI, or collected from endpoints by Wazuh Syscollector, can show what is installed, which makes it easier to find unsupported versions in use. Confirm with your vendor and your own environment how each tool captures version data, since a discovered product still needs a lifecycle date from an external source before it can be judged. Keep a dated record of each monthly review, including the entries changed, the exceptions raised and the people who approved them, because the freshness test and the exception measures both depend on that trail.

Which software, systems and teams fall under Safeguard 2.2 support checks

The monthly support check is only as complete as the list it runs against. Each scoping decision below determines which software enters the authorized inventory, which records must be reviewed, and who signs off when support has ended. Settle these decisions in writing before the first check so the results can be repeated and assessed.

Licensed and installed endpoint software

Operating systems, productivity suites, browsers, agents and line-of-business applications on laptops, desktops and servers form the core of the check. Each installed package needs a vendor, version and support end date recorded against it. Check whether the inventory captures version and edition, because a supported product line can still contain an unsupported release. Confirm that server roles and their dependencies are included, not only the user-facing applications.

SaaS and cloud-hosted applications

Subscription applications the enterprise configures or administers belong in the authorized list even though no agent runs on a device. Their support status depends on the provider's lifecycle policy, not on a local install, so the monthly check must reference vendor announcements. Decide whether shadow SaaS discovered through identity or expense records is in scope, and who owns the decision to authorize it. Ask the provider to confirm which versions or plans will be retired and when.

Embedded and appliance firmware

Routers, firewalls, storage arrays, printers and industrial controllers run firmware that often outlives the software layer above it. Include firmware in the inventory only where your asset records track it, and state that boundary in the procedure so auditors see a consistent scope. Vendors frequently publish end-of-support dates for hardware models rather than for each firmware build, so record the model and the date that applies to it. Confirm who receives vendor security advisories for each appliance family.

Software that is not on the list

Software discovered on an asset but absent from the authorized inventory is handled under Safeguard 2.3, not 2.2, so the support check must not silently absorb it. Define the boundary: the 2.2 check covers software already marked authorized, and newly found software is evaluated for support before it can be authorized. Document that rule, because it decides whether an unsupported tool appears on the authorized list at all.

Owners who approve exceptions

Unsupported software the mission still needs can be kept only under a documented exception that names mitigating controls and the accepted residual risk. Assign each exception to a named business owner with authority to accept that risk, and a technical owner who maintains the controls. Record who signed the exception, when it was last reviewed and when it expires. Without a named approver, an exception becomes an undocumented exemption that assessors will count as a failure.

Inventory dependencies and prerequisites

The support check reads from the software inventory, so Safeguard 2.1 is its prerequisite. The assessment specification scores the check as failing when the authorized software inventory was last updated more than four weeks ago, which means the inventory process and the support review must run on the same cadence. Confirm which system of record holds the authorized list and which team updates it. If the list lives in several tools, decide which one is authoritative before measuring.

How assessors test software support status and mislabeled entries

This table compares what an assessor checks for Safeguard 2.2, the evidence each check needs and the findings that usually come up. Read it as a test sequence: first confirm the inventory is current, then sample entries for support status, then count false positives, false negatives and undocumented exceptions against the CIS Controls Assessment Specification for v8.1.

Assessment step	What the assessor checks	Common findings
Inventory currency	Last update date of the authorized software list compared with the four-week threshold in the assessment specification	List last updated more than four weeks ago, or no recorded review date at all
Support status sampling	A sample of authorized entries checked against current vendor support or end-of-life dates	Authorized entries for products past end of support, or versions that are supported only for a subset of editions
False positive count	Entries marked authorized as supported that the vendor no longer supports	Mislabeled versions, such as a supported major release recorded for an older installed build
False negative count	Unsupported software in use that is missing from the authorized list or wrongly marked supported	Discovered endpoints running software absent from the inventory, or unsupported items hidden under a generic product name
Exception documentation	Each unsupported item the mission still needs has a written exception with mitigating controls and accepted residual risk	Exceptions with no owner, no expiry or review point, or no described mitigating control
Unsupported software in use	Share of unsupported software observed in use across the environment, traced back to the inventory	Unsupported software discovered on endpoints that the inventory does not record as unauthorized
Prerequisite data	Software inventory from Safeguard 2.1 used as the measurement source, cross-checked against discovery data	Inventory built from manual lists with no discovery feed, so counts cannot be reconciled
Evidence requested	Inventory export with timestamps, vendor support references used, exception register and sampling worksheet	Evidence produced after the assessment starts, or screenshots without dates or identifiers

How to implement the monthly support check in six steps

This sequence turns Safeguard 2.2 into a repeatable routine: an inventory with support data, a named owner, a documented source for vendor support status, a dated check, and a clear path for every unsupported item.

Confirm the inventory fields the support check needs
Before any check runs, confirm that the Safeguard 2.1 software inventory records the product name, installed version, vendor and a source for the end-of-support date for every licensed product. Without the version and vendor, a support check cannot match an installed item to a vendor lifecycle entry. The person who owns the inventory signs off that these fields are populated for each authorized item. The assessor will ask to see the inventory export with those columns filled in, and gaps will be counted against the check.
Assign a named owner for the monthly check
Name one accountable person, and a backup, for running the support check each month. The owner is usually in IT asset management, platform engineering or security operations, but the organization decides. Record the assignment in the software asset management procedure or the policy that covers Control 2 so the duty survives staff changes. The assessor will ask for the role assignment and will look for evidence that the check was performed by the person named, not only that it was planned.
Set the source list for vendor support status
Document which sources the owner uses to confirm support status for each product, such as vendor lifecycle pages, vendor security bulletins, or contract and support entitlement records for commercial products. Also define how open-source components are assessed, for example by upstream project release and maintenance status. Record the source for each product in the inventory so that the end-of-support date can be traced back to a published statement. Assessors ask for this source list because a support date with no source cannot be verified, and the list should be reviewed when a vendor changes its lifecycle policy.
Run the check and update the authorized list
Each month, the owner compares every authorized product and version against its documented support source and marks each item as currently supported or unsupported. Items that remain supported stay on the authorized list with an updated review date. Items past their support window are flagged for the next step rather than silently left as authorized. The output is a dated record of the comparison, with the list version and the reviewer identified. Assessors will check that the authorized inventory was last updated within the monthly window, since the CIS Controls Assessment Specification scores the Safeguard as failing when the authorized software inventory was last updated more than four weeks ago.
Route unsupported items to exception review or removal
For each unsupported item, decide between removing it from the authorized list (and from the enterprise, under Safeguard 2.3) or keeping it under a documented exception. A retained exception needs a written business justification, the mitigating controls applied to the product, and the residual risk accepted by an appropriate owner. Items the mission does not need are treated as unauthorized. The output is an exception register or a removal ticket for each flagged item. Assessors will sample exceptions to confirm each one names mitigating controls and an accepted residual risk.
Record the date of each update and retain the evidence
Close each monthly cycle by recording the date of the update, the reviewer, the list version and the outcome: items confirmed supported, items removed and items under exception. Store these records where they can be produced on request, such as the inventory tool's change history, a versioned spreadsheet or a ticketing system. Confirm that the record shows an update within the four-week threshold. Assessors typically request the dated history for several months, so consistent retention matters more than any single record.

Which evidence shows the authorized list is current and supported

An assessor testing Safeguard 2.2 wants to see that the authorized list was refreshed recently, that each unsupported item has a documented decision, and that the record can be replayed later. The cards below cover the artifacts that prove each part, plus how to keep them current between assessments.

Dated authorized software list

The authorized software inventory is the primary artifact, and its last-updated date is what the assessment specification checks. Each entry should show the product, version, owner and a support status field, so a reviewer can see which items were marked authorized and whether they were still supported on the date recorded. Confirm that the export carries a timestamp and that the inventory it comes from is the one the organization treats as authoritative.

Monthly vendor support check record

Safeguard 2.2 expects the list to be checked against vendor support at least monthly. The record should name the source used for each check, such as a vendor lifecycle page or a support database, the person who performed it and the date. A check that merely states it was done is weak evidence. Ask for the source and the list of items that changed status during each cycle.

Exception register with residual risk sign-off

Where the mission still needs unsupported software, the exception register records the product, the business reason, the mitigating controls such as network isolation or restricted access, and the accepted residual risk. Each entry needs a named owner who signed the acceptance, with a review date. Assessors measure the share of unsupported software that has this documentation, so an entry without an owner or a mitigating control will not count.

Removal and replacement tickets

Unsupported software that is not covered by an exception should be removed or replaced, and the ticket trail proves it. Each ticket should identify the affected assets, the target date, the replacement or decommissioning action and the closure evidence, such as an uninstall record or an updated inventory. Open tickets older than the monthly cycle show where the list is being left unresolved, which is what the unsupported-software metrics will expose.

Change history showing freshness

The inventory platform's audit log or version history shows when the authorized list was last edited and by whom. Reviewers use it to confirm the four-week freshness threshold was met across the period under test, not just on the day of the review. Confirm that edits are attributed to a user or service account and that history cannot be silently overwritten. Gaps in the log are a finding in their own right.

Recurring review and stored exports

Between assessments, the cadence depends on a recurring calendar entry assigned to a named role, with a backup owner. Each cycle should save a dated export of the authorized list, the support check record and the exception register to a controlled repository with restricted write access. This creates a continuous trail that answers any sample date an assessor selects. Ask the assessor which periods and exports they will sample before the engagement starts.

Writing exceptions that hold up when an assessor samples them

An exception is defensible only when its record names the business reason, the specific unsupported product and version, the mitigating controls in place, the residual risk the owner accepts, an expiry or review date, and an approver with authority to accept that risk. Safeguard 2.2 treats unsupported software the mission still needs as acceptable only under a documented exception, and any unsupported product without one is treated as unauthorized. An assessor sampling the inventory will therefore ask for the record first. A decision that was made in a meeting but never written down in these terms fails the same way as no decision at all, so the paperwork has to carry as much weight as the risk decision itself.

Be concrete about the product. A line that says "legacy reporting tool" does not let anyone match the exception to an inventory entry, so record the exact product name, the installed version, the vendor's end-of-support date as confirmed from the vendor's own lifecycle page, and the asset or asset group it runs on. Then describe the mitigating controls as things an assessor can check: network segmentation that blocks inbound and outbound traffic except to named hosts, restricted administrative access, enhanced logging or monitoring of that host, and any patching or hardening that still applies. Each control should point to evidence, such as a firewall rule identifier, an access list export or a monitoring alert rule. Illustrative example: an exception for a database engine on an isolated subnet is stronger when it cites the rule set and the monitoring source than when it simply says the system is "protected."

Set the expiry or review date in the record, and make the approver someone who owns the business risk, not only the engineer who runs the system. The residual risk statement should say what could still go wrong, such as an unpatched vulnerability being exploited through an allowed path, and who accepted that. Ask your auditor or assessor early which review cadence they expect, and confirm internally how exceptions are reported to the people accountable for them. Expired exceptions should trigger either removal or renewal with fresh evidence, because a lapsed record is what turns a documented exception back into unauthorized software in a sample.

What meeting Safeguard 2.2 costs in money and effort

This table lists each cost component of keeping authorized software supported, who pays for it, whether it is one-time or recurring, and what pushes it up or down. Read it as a checklist for a written quote: most of the spend is staff time, and open-source tooling mainly removes license cost rather than labor.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up and how to reduce it
Tooling or licenses	Software vendors or none if open source	Recurring if commercial, one-time setup otherwise	Commercial inventory or patch-data subscriptions scale with endpoints and users. Self-hosted open-source inventory such as GLPI or Wazuh Syscollector removes license spend, but hosting and storage remain.
Engineering time to connect inventory to support sources	Internal platform engineers or an implementation partner under a fixed-scope agreement	One-time build, with recurring upkeep when sources change	Number of product catalogs, custom applications and data feeds to match against vendor end-of-life dates. Reduce it by limiting the first release to the highest-risk products and documenting the matching rules.
Owner time for the monthly support check	Named owner of the authorized software list	Recurring, at least monthly	Size of the authorized list and how many entries need manual vendor lookups. Reduce it with a standing review template and automated flags for approaching end-of-life dates.
Exception reviews	Risk owner, security lead and the system owner who requests the exception	Recurring, per exception and at each review	Number of unsupported products the mission still needs. Each exception needs documented mitigating controls and accepted residual risk. Reduce it by retiring products and keeping the exception register short.
Remediation or replacement work	Application owners, infrastructure teams and sometimes vendors	One-time per product, with recurring replacement cycles	Number of unsupported products, their dependencies and how hard they are to upgrade or isolate. Plan replacements into normal release cycles where possible.
Evidence upkeep	Compliance or security operations staff	Recurring	Frequency of inventory updates and how many records must be kept for assessors. Automated exports from the inventory tool reduce manual collection.
External testing or review	Independent assessor or testing firm, if engaged	Recurring or per engagement	Scope of the review and whether it tests the mislabeled and unsupported software measures. Ask a quote to itemize sampling and report effort separately.
Auditor sampling	Independent auditor or assessor, paid by the organization	Per audit cycle	Number of assets and records sampled and how cleanly the inventory matches the authorized list. Clean, dated records typically reduce sampling effort.

Open-source tools that produce software inventory data for the support check

A support check is only as good as the software list it runs against. The two tools below can populate that list from the endpoints and assets you already operate, but neither one tells you whether a product is still supported, so the support status source has to be defined separately.

GLPI Assets module

GLPI's Assets module tracks computers, software, network equipment and other managed items, with software records entered manually or pushed automatically by the GLPI Agent through native inventory, which has been built into GLPI since version 10. For Safeguard 2.2, the software records are the starting list the support check runs against, so check that every in-scope endpoint reports, that version fields are populated, and that software is linked to the asset it runs on. GLPI is licensed under GPL-3.0-or-later. Confirm the agent version and inventory coverage in your own environment before relying on the list.

Wazuh Syscollector inventory

Wazuh's Syscollector module collects installed software, operating system details, and other endpoint data and stores it in the Wazuh indexer, where the dashboard presents inventory views and reports. For Safeguard 2.2, this gives you a continuously refreshed view of what is installed, which helps you spot software that is absent from the authorized list. Check that agents are enrolled on all endpoints in scope and that the inventory timestamps are recent, since stale inventory undermines the monthly review. Wazuh is licensed under GPL-2.0-only.

Vendor support status source

Neither GLPI nor Wazuh knows vendor end-of-life dates on its own. Both report what is installed, not whether the vendor still supports it. Define the authoritative source for support status, such as vendor lifecycle pages or a maintained lifecycle register, and record the date you last checked each product. Assign an owner to the check and keep the result alongside the authorized software list so an assessor can see the monthly review and its outcome.

Coverage and version checks

Before the support check, confirm which endpoints, operating systems and product versions each tool actually covers in your environment. Gaps in agent deployment, unreachable hosts, or products reported under unfamiliar names will produce false negatives, where unsupported software is missed. Reconcile the tool output against a sample of known endpoints and record the result, since assessors measure false positives and false negatives directly.

Who owns the support check, what partners prepare and what the auditor tests

Your organization owns Safeguard 2.2 in full. Your security and IT leaders decide which software is authorized, which unsupported products the mission still needs, and who accepts the residual risk of running them. Those decisions are management decisions, and the Safeguard depends on them being made by people with the authority to accept risk. A partner can prepare the information for those decisions, but it cannot make them for you.

The authorized list: Your team approves each entry in the software inventory and marks it authorized only when vendor support is current.
The monthly support check: Someone on your staff owns the recurring review of vendor support status, with a named owner and a dated record of each run.
Exception decisions: Your leadership decides whether unsupported software stays in service, documenting the mitigating controls and the business reason.
Risk acceptance: A named executive signs off on accepted residual risk. This signature belongs to your organization and should not be delegated to a contractor.
Removal and replacement: Your teams schedule upgrades, migrations or removal for software that loses support.

Before engaging any partner, confirm internally who holds each of these duties and how the decisions are recorded, because the assessor will ask for that record first.

Questions teams ask about Safeguard 2.2 cost, effort and outside help

How much effort does the monthly Safeguard 2.2 support check take?

The check itself is a recurring review of the authorized software list against vendor support dates, so its effort depends on how many products are on that list and how well the list is kept. Effort rises when the inventory has many products, inconsistent product names, or no owner per product, because each entry must be looked up and confirmed. It falls when the list records a vendor, version, and end-of-support date for each product, and when the support dates are pulled from vendor lifecycle pages in one pass. Ask your team to time one full review on your current list before you plan the recurring work, since no fixed duration applies across environments. The CIS Controls Assessment Specification scores the Safeguard as failing when the authorized software inventory was last updated more than four weeks ago, so the cadence itself is part of the work.

Can we run Safeguard 2.2 ourselves without an outside partner?

Yes, most organizations can run the monthly check in-house, provided someone owns the software inventory and the exception register. The CIS Controls are free for any organization to use to improve its own cybersecurity, and the Assessment Specification describes what to measure without prescribing tools or procedures. Outside help is usually considered when the list is large, when the team lacks time to keep it current, or when a customer or regulator asks for evidence that the process works. An implementation partner can prepare the inventory, the exception workflow and the evidence trail, but the organization keeps ownership of the decisions to authorize or retire software. Only an independent auditor or assessor issues any report or attestation.

What does the work need from owners and engineers?

Safeguard 2.2 needs two groups to work together. Business owners must state whether unsupported software is still needed for the mission, and accept or reject the residual risk in writing. Engineers must confirm installed versions, check vendor support status, and retire or isolate software that has reached end of life. The Assessment Specification lists Safeguard 2.1, the software inventory, as a prerequisite because it typically produces the data the measurement needs, so engineers also maintain that inventory. In practice, each product should have a named owner, a support end date, and a documented exception if it stays in use after support ends. Expect owners to be asked to review exceptions on a fixed schedule, not only when a problem appears.

How long does initial setup take, and what sets the duration?

Initial setup length depends on the current state of the software inventory, the number of systems and products in scope, and how many unsupported products already need exceptions or retirement. A clean, recently reviewed inventory shortens setup, while a list built from memory or spread across spreadsheets lengthens it, because discovery and reconciliation come first. Retiring end-of-life software can take far longer than documenting it, since migrations depend on application owners, change windows and testing. No duration applies across environments, so ask any provider for a timeline tied to a written scope, with the systems, products and exception count stated. Your own team can produce a rough baseline by counting products and listing unsupported ones before asking for quotes.

Do open-source inventory tools remove the need for paid tooling?

Open-source tools can cover much of the discovery and recording work, but they do not decide support status or make exceptions for you. GLPI's Assets module can manage software records, and its GLPI Agent can push inventory automatically, which supports the authorized list and its owner fields. Wazuh's Syscollector collects installed software and stores it for inventory views and reports. Both licenses are open source (GPL-3.0-or-later for GLPI, GPL-2.0-only for Wazuh), so software licensing cost is not the main variable. Still, you must confirm that each tool captures the product versions you need, and you must supply vendor end-of-support dates from vendor sources. Staff time, hosting and integration remain costs even when the software is free.

What should a written scope include so quotes can be compared?

A written scope lets you compare quotes on the same work. Include the environments and systems covered, the number of products expected on the authorized list, the inventory sources to be used, and whether discovery is included or only review. State who owns each exception decision, what evidence must be delivered (such as the dated inventory, the exception register and the monthly review record), and how the work is handed back to your team. Name any open-source tools to be deployed or integrated, and whether hardening, retirement or migration of unsupported software is in or out of scope. DeployOpen works from fixed-scope agreements with deliverables and timelines agreed in writing before work starts, and it does not publish a price list, so a quote follows from that written scope. Ask every provider to state what is excluded as clearly as what is included.

How DeployOpen scopes and prepares evidence for Safeguard 2.2

DeployOpen is a Chainscore Labs company that plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure. For Safeguard 2.2, we help the organization build the software inventory, support-status check and exception records that show only currently supported software is marked authorized, while the organization keeps ownership of its controls and the independent assessor issues any conclusion.

How we scope

Agree in writing which inventory sources, asset groups and business units the Safeguard 2.2 scope covers before work starts.
Confirm who owns the monthly vendor support review and who approves each documented exception for unsupported software.
Ask us to list the Safeguard 2.1 inventory dependency and confirm its current state, since 2.2 measurement relies on it.

How we build

Configure the inventory tooling, such as GLPI Assets or the Wazuh Syscollector module, to feed a single authorized software list.
Add a support-status field and a documented exception template capturing mitigating controls and accepted residual risk.
Test the monthly update cadence and the four-week staleness threshold so the list reflects vendor support and assessors can verify it.

How we hand over

Deliver the written procedure, exception register, configuration records and sample reports that show the support check was performed.
Walk your security and IT teams through how each measure is calculated, including false positives and false negatives for mislabeled software.
Provide an evidence index mapping each artifact to the Safeguard 2.2 measures so your auditor or assessor can trace it independently.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, covering tool updates and monthly list reviews.
Revisit exception records when vendors announce end-of-life dates or when the authorized software list changes materially.
Confirm with your assessor which evidence format and retention period they require before handing over the final package.

Safeguard 2.2 Ensure authorized software is currently supported