CIS Control 2 Inventory and Control of Software Assets Guide: Safeguards, Implementation Groups and Evidence

Most organisations cannot say with confidence what software is running on their estate, and an attacker only needs one unsupported, unapproved or unwanted program to get in or to stay in. CIS Control 2, Inventory and Control of Software Assets, asks you to actively manage (inventory, track and correct) all operating systems and applications so that only authorised software is installed and runs, and anything else is found and dealt with. This guide works through the seven Safeguards in CIS Controls v8.1 by Implementation Group, explains what the CIS Controls Assessment Specification actually measures, and sets out the evidence an assessor will ask for. It is written for security engineers, endpoint and platform owners, and GRC leads building or auditing a CIS programme. For the wider programme see the CIS Controls Guide; for the companion hardware inventory see the CIS Control 1 Inventory and Control of Enterprise Assets Guide.

Key takeaways

• Seven Safeguards, three of them IG1. 2.1 software inventory, 2.2 supported software and 2.3 address unauthorised software apply to everyone; 2.4 to 2.6 arrive at IG2 and script allowlisting (2.7) at IG3.
• The cadences are written into the Safeguards. Review the inventory at least every six months, check support status and unauthorised software at least monthly, and reassess allowlisting at least every six months.
• Control 2 depends on Control 1. The Assessment Specification measures software coverage against the enterprise asset inventory, so an incomplete device list makes every Control 2 metric wrong.
• Allowlisting is the payoff. Inventories describe the problem; 2.5, 2.6 and 2.7 enforce the answer by blocking executables, libraries and scripts that are not authorised. Start in audit mode and move to enforcement in rings.
• Software carries identities. Agents, CLIs, browser extensions and scripts hold tokens, keys and service account credentials, so the software inventory is also a map of where non-human identities live.

What it is and who it applies to

CIS Control 2 is the second of the 18 CIS Critical Security Controls. The current version is v8.1, an iterative update to v8 that, according to CIS, realigned security functions to NIST CSF 2.0, added the Govern function, revised asset classes and clarified Safeguard wording without changing Implementation Group assignments. All seven Control 2 Safeguards sit in the Software asset class.

The control applies to every organisation adopting the CIS Controls, because its first three Safeguards are in IG1, the set CIS describes as essential cyber hygiene. Its scope is wider than the word "applications" suggests:

• Operating systems and firmware-level software: every OS build on servers, end-user devices, network appliances and virtual machines.
• Installed and portable applications: licensed packages, freeware, portable executables run from user folders, and software installed by users without admin rights.
• Libraries and components: DLLs, shared objects and language packages loaded into processes (Safeguard 2.6).
• Scripts: PowerShell, batch, VBScript, Python and shell scripts, and the interpreters that run them (Safeguard 2.7).
• Cloud and SaaS footprint: container images, serverless functions and browser extensions are not named in the Safeguard text, but they execute code on enterprise assets and belong in scope in a modern estate. Record that decision in your scope statement.

Control 2 pairs with Control 7 (vulnerability management), which needs the software inventory to know what to scan, and Control 4 (secure configuration), which supplies the configuration standard the allowlisting Safeguards are measured against.

Structure and key requirements

The table lists the seven Safeguards as published in the CIS Controls Assessment Specification for v8.1, with the minimum cadence written into each one.

Implementation Group summary

• IG1 (three Safeguards): know what is installed, make sure it is supported, and remove what should not be there. A spreadsheet fed by an endpoint management export can satisfy 2.1 for a small estate, but the monthly review in 2.2 and 2.3 quickly pushes teams towards automation.
• IG2 (three more): automated discovery (2.4) and allowlisting of executables and libraries (2.5 and 2.6). This is where Control 2 shifts from record-keeping to prevention.
• IG3 (one more): script allowlisting with signatures and version control (2.7), the hardest Safeguard operationally because administrators, developers and automation all run scripts.

Choosing an allowlisting rule type

NIST SP 800-167, Guide to Application Whitelisting, frames allowlisting as a list of approved applications and components used to control which applications may execute on a host. The rule type you pick determines how much maintenance the allowlist needs. Microsoft App Control for Business (formerly Windows Defender Application Control) is used here as a worked example because its rule levels are documented; Linux options such as fapolicyd and macOS controls follow the same trade-offs.

For a fuller treatment of allowlisting design across platforms see the Application Allowlisting Guide.

Identity and NHI requirements

Control 2 says nothing explicit about identities, but software is where many non-human identities are stored and used. Build these links into the inventory rather than treating them as a separate project:

• Record the identity a package runs as: add a field to the 2.1 inventory for the service account, managed identity or local system context each server application uses. This feeds Safeguard 5.5 (inventory of service accounts) in Control 5. See the Service Account Security Guide.
• Flag software that stores credentials: cloud CLIs, backup agents, monitoring agents, CI runners and database clients typically cache tokens, keys or connection strings. Tag them so secret scanning and rotation cover those hosts. See the Secrets Management Guide.
• Treat remote access tools as unauthorised by default: remote monitoring and management and remote desktop tools are a favoured persistence route, mapped in ATT&CK as T1219 Remote Access Tools. Allow only the sanctioned tool, by publisher rule, and alert on the rest. See the RMM Tool Security Guide.
• Scripts carry secrets: Safeguard 2.7's signing and version control requirement is also the cleanest way to stop hard-coded keys spreading through ad hoc scripts, because signed scripts pass through a repository where secret scanning runs.
• Browser extensions hold OAuth grants: an extension with access to a SaaS session acts with the user's tokens. Inventory extensions through browser management policy and allowlist by extension ID. See the Browser Extension Security Guide.
• Removing software must remove its identity: when 2.3 removes an application, disable the service account, revoke API keys and delete the OAuth grant it used, otherwise the credential outlives the software. See the OWASP NHI Top 10 NHI1 Improper Offboarding Guide.

Implementation steps

1. Confirm the denominator. Take the Control 1 asset inventory and mark which assets can run software (the Assessment Specification calls this the list of software-capable assets). Coverage metrics for 2.4 and 2.5 are percentages of this list.
2. Collect what is installed. Pull installed software from every source you already have: endpoint management (Intune, Configuration Manager, Jamf), EDR inventories, vulnerability scanner authenticated scans, package managers on Linux, and cloud image inventories. Normalise publisher and title names so the same product is not counted ten ways.
3. Build the authorised software list. For each normalised title record publisher, version range, business purpose, owner, install date and support end date. Anything without an owner or purpose goes to a review queue, not straight to authorised.
4. Apply support status (2.2). Match each title against the vendor's published lifecycle. Unsupported titles either get a time-limited exception with compensating controls (isolation, restricted network access, extra monitoring) and a named risk owner, or join the removal list. Repeat monthly.
5. Remove unauthorised software (2.3). Publish a removal timeframe (the Assessment Specification treats more than four weeks as failing), uninstall through your management tooling, rescan to confirm, and record exceptions.
6. Automate discovery (2.4). Make sure every software-capable asset reports to at least one inventory tool, and alert on assets that stop reporting. Agentless scanning covers assets where you cannot install agents.
7. Deploy executable allowlisting in audit mode (2.5). Start from a base policy (for Windows, an App Control policy with option 3 Enabled:Audit Mode), deploy to a test group, and collect would-have-blocked events for two to four weeks. Add rules for legitimate software found, preferring publisher rules over hashes.
8. Enforce in rings. Move to enforcement on a pilot ring of about 5 to 10 per cent of devices, then broaden. Keep a supplemental policy mechanism for business-unit additions, and define rollback: redeploy the previous policy version or switch the ring back to audit mode.
9. Add libraries (2.6). On Windows, App Control evaluates DLLs as well as executables when user-mode code integrity is enabled (option 0 Enabled:UMCI). Test carefully: blocked DLLs fail quietly inside applications rather than with a clear prompt.
10. Add scripts (2.7) last. Require scripts in production to be signed by an internal code signing certificate and committed to version control. Leave option 11 Disabled:Script Enforcement off so PowerShell runs unsigned scripts in Constrained Language Mode. See the PowerShell Security Guide and the Code Signing Security Guide.

Small versus large organisations

• Small (IG1 target): one endpoint management tool export, reviewed monthly, plus a published list of approved software and a block on standard user installs, covers 2.1 to 2.3. Consider cloud-reputation based allowlisting rather than hand-built rules if you later move towards 2.5.
• Mid-sized (IG2 target): a single software distribution channel makes managed installer style trust practical, and a packaging team can own the authorised list.
• Large or regulated (IG3 target): separate policies per device role (kiosk, developer, server, privileged access workstation), signed policies, and a change process for script signing certificates.

Evidence and assessment

The CIS Controls Assessment Specification defines inputs, operations and measures for each Safeguard. Assessors working from it, or from CSAT, will look for the following.

Detection and metrics

• Events to collect: on Windows, CodeIntegrity Operational event 3076 (would have been blocked, audit) and 3077 (blocked, enforced), 3089 for signature detail and 3099 for policy loads; AppLocker MSI and Script events 8028 (audit) and 8029 (enforced). Forward them to your SIEM; a sudden fall to zero usually means a policy was removed. See the CIS Control 8 Audit Log Management Guide.
• Alerts worth writing: new software title seen on more than one asset in 24 hours, unsanctioned remote access tool installed, interpreter launched from a user-writable path.

Metrics that show the control is working:

• Percentage of software-capable assets reporting to an inventory tool in the last 7 days (target above 98 per cent).
• Percentage of installed titles with owner, purpose and support status recorded.
• Number of unsupported titles in use, and the share covered by an in-date exception.
• Median days from detection to removal of unauthorised software (target under 28).
• Percentage of devices with allowlisting in enforced mode, by ring.
• Audit-mode block events per 1,000 devices per week, trending down before each ring moves to enforcement.

Mapping to other frameworks

The CIS Controls Navigator maps v8.1 to 30 frameworks; the mappings below are confirmed against the NIST catalogues. Use the Navigator export for audit-grade mapping.

In ISO/IEC 27001:2022 the closest Annex A controls are 5.9 (inventory of information and other associated assets) and 8.19 (installation of software on operational systems). The Australian Signals Directorate Essential Eight application control strategy and the UK Cyber Essentials requirements on software also overlap, and both are in the Navigator.

Common pitfalls

• Inventory without a denominator: reporting "2,400 titles found" without knowing how many devices reported. Tie every Control 2 metric to the Control 1 asset list.
• Exceptions that never expire: unsupported software kept "until the replacement project finishes" with no end date. Give every 2.2 exception an expiry and a named risk owner.
• Allowlisting stuck in audit mode: teams collect would-have-blocked events for a year and never enforce. Set a date for each ring when you start.
• Path rules on writable folders: allowing anything under a folder that standard users can write to turns the allowlist into a suggestion.
• Trusting a publisher too broadly: a publisher-level rule also trusts that vendor's remote administration tools and utilities. Use file-level publisher rules where the vendor ships dual-use tools, and plan for a vendor revoking its signing certificate after a compromise, which means certificate-based rules must be updated to the new certificate and old versions retired, as in the AnyDesk breach.
• Removing software but not its credentials: uninstalling an agent while its API key or service account stays active.

Practitioner checklist

• Agree the software-capable asset list with the Control 1 owner and use it as the denominator for every metric.
• Publish the authorised software list with publisher, version range, purpose, owner and support end date.
• Run the support status check monthly and give every unsupported title an expiring exception or a removal date.
• Set and measure a removal timeframe for unauthorised software of four weeks or less.
• Confirm every software-capable asset reports to at least one inventory tool and alert when one goes silent.
• Deploy executable allowlisting in audit mode, then enforce by ring with a written rollback.
• Add library and script enforcement, with internal code signing and version control for scripts.
• Record the service account or token each server application uses and revoke it when the software is removed.
• Forward allowlisting events to the SIEM and reassess policies at least every six months.

Standards and references

• CIS: Controls Assessment Specification v8.1, Control 2 Inventory and Control of Software Assets
• CIS: Control 2 Inventory and Control of Software Assets
• CIS: Critical Security Controls Version 8.1
• CIS: Controls Navigator
• NIST: SP 800-167 Guide to Application Whitelisting
• NIST: SP 800-53 Rev. 5
• Microsoft Learn: Understand App Control for Business policy rules and file rules
• Microsoft Learn: Understanding App Control event IDs

Related NHI Mgmt Group resources: CIS Controls Guide · Application Allowlisting Guide · Asset Inventory and CMDB Security Guide · SBOM Guide · CIS Control 3 Data Protection Guide