CIS software asset management policy template guide

What a CIS software asset management policy template must cover

A customer questionnaire or regulator asking for CIS Control 2 evidence usually wants to see one thing first: a written policy that makes the software inventory and its upkeep a standing duty. The free CIS template for Software Asset Management supports IG1 Safeguards only, so it does not reach the IG2 or IG3 additions. The policy has to set three things: the software inventory required by Safeguard 2.1, the supported-software rule and documented exceptions required by Safeguard 2.2, and a clear process for handling unauthorized software. The topic facts name 3 IG1 Safeguards in Control 2, but confirm the full Safeguard list and which of them apply to your organization in the CIS Controls Assessment Specification before you write the policy around them.

The organization owns the policy, the inventory and the decisions behind them. Someone accountable must approve which software is authorized, who may grant an exception, how long an exception runs and who accepts the residual risk. A partner can help prepare the inventory, configure discovery tooling, draft the exception register and collect the evidence an assessor will sample. The partner does not decide conformance. Only an independent assessor or auditor reaches that judgment, so the policy should be written in terms an assessor can test: named owners, stated review intervals and records that show each review actually happened. Ask any implementation partner to deliver the written scope and evidence list before work starts, and confirm with the assessor which evidence format they accept.

Which parts of the policy each Control 2 requirement needs

The Control 2 policy has to cover two Safeguards: a software inventory that is kept current and a support check that decides what counts as authorized. The six parts below map each requirement to the Safeguard it supports and the evidence an assessor will ask for, so the policy text and the records line up.

Licensed software inventory fields

Safeguard 2.1 asks the enterprise to keep a detailed record of every piece of licensed software installed across its assets. Each entry should give the title, publisher, business purpose and date of first installation or use, plus the number of licenses, decommission date, deployment method, versions, app stores and URL where relevant. Check that the policy names these fields and that the inventory actually populates them for every asset class in scope. The assessor will sample entries and look for blank business purpose or install date fields.

Twice-yearly inventory review

The Safeguard 2.1 record must be reviewed and updated at least twice a year. The policy should name the owner of the review, the date of each cycle and what the reviewer checks, such as new installations, removed packages and changed licenses. Keep the signed review record or the change history that proves each cycle happened. Without dated records, an assessor has no way to confirm the inventory stayed current between audits.

Monthly vendor support check

Safeguard 2.2 expects the software list to be checked for vendor support at least monthly. The policy should assign who runs the check, which source confirms end-of-support dates for each product, and where the result is recorded. The assessment specification scores Safeguard 2.2 as failing when the authorized software inventory was last updated more than four weeks ago, so the monthly check needs a timestamp the assessor can read. Confirm how your tooling exposes that last-updated date.

Documented exception for needed unsupported software

Safeguard 2.2 lets only currently supported software be marked authorized. If the mission still needs an unsupported product, the policy must require a documented exception that describes the mitigating controls and the residual risk the organization accepts. The exception should name an approver, a review date and the systems it covers. Assessors will ask for the signed exception record next to the inventory entry it governs, so keep both linked.

Unsupported software treated as unauthorized

Under Safeguard 2.2, unsupported software that has no documented exception is treated as unauthorized. The policy should state that rule in plain terms, define the response (removal, isolation or a time-bound exception request) and name who acts on it. Test the rule by finding one unsupported package on a sample endpoint and tracing whether the inventory flags it and the response is logged. This is the point where a policy stops being text and becomes a control.

Evidence the inventory stayed current

Assessors judge the policy by its records. Plan to show the inventory export with timestamps, the twice-yearly review records, the monthly support check logs and any exception documents in one evidence folder. Automated discovery helps here: the Wazuh Syscollector module collects installed software from each endpoint and stores it in the Wazuh indexer for inventory views and reports. Confirm that the collection frequency and retention meet your own review schedule before relying on it as evidence.

How the software inventory rule in Safeguard 2.1 shapes the policy

Safeguard 2.1 asks the enterprise to keep a detailed record of every piece of licensed software installed across its assets, and to review and update that record at least twice a year. For the policy, this means the software inventory is not a one-time export from a discovery tool. The policy should name the inventory owner, the systems that feed it, and the review cadence, so an assessor can see that the record is maintained rather than merely existing. A twice-yearly review with dated sign-off is the simplest evidence an assessor can check against the policy text.

The policy should require each entry to carry the fields the Safeguard 2.1 description lists: title, publisher, business purpose, and the date of first installation or use. Where relevant, it should also require the number of licenses, decommission date, deployment method, versions, app stores and URL. Write these as required fields in the policy rather than as suggestions, and decide which ones are mandatory for every entry and which apply only to certain software types, such as subscription services or software deployed from an app store. Confirm the exact field definitions and their conditions against the Safeguard 2.1 text in the CAS before you fix them in the template, because the wording of the 'where relevant' conditions determines what an assessor will accept as complete.

An entry without a named owner or a stated business purpose is a practical failure at review. If nobody can say why a title is installed, the reviewer cannot decide whether it should stay, be authorized, be documented as an exception, or be removed. The policy should therefore make owner and business purpose required fields and state who approves them. Illustrative example: a reporting tool installed on a finance workstation with no owner listed would be flagged at the next review and held until someone accepts responsibility for it. Ask your inventory tool whether it can capture owner and purpose manually, because discovery tools typically report what is installed, not why.

How the policy turns into assessment evidence

The sequence below turns a written policy into a set of dated records that an independent assessor can sample and test against Safeguards 2.1 and 2.2. Each phase closes with a specific output, so the policy stays a working control rather than a document on a shelf.

Adopt and adapt the CIS template
Start from CIS's Software Asset Management template, which is written for IG1 Safeguards, and adapt it to your scope: which business units, cloud accounts, endpoints and software sources are covered, who owns the inventory, and who approves exceptions. The policy should name the owner, the review cadence and the location of the inventory and exception register. Management approves the adapted text and signs it. The output is a signed policy with a version number and an effective date, which becomes the first item an assessor requests.
Build the first inventory from discovery data
Populate the initial software inventory from discovery data rather than from memory or spreadsheets. Agent-based inventory tools, such as the Wazuh Syscollector module, can collect installed software from endpoints, and cloud or endpoint management consoles can add software that agents miss. Reconcile the output with procurement and license records, then fill in the Safeguard 2.1 fields: title, publisher, business purpose, date of first installation or use, and where relevant license count, version, deployment method and URL. The output is an inventory export with a timestamp, plus a short note on which sources were used and what was reconciled manually.
Set and log the monthly support check
Schedule the vendor support check for every software title in the inventory at least monthly, assign a named owner and record the date it was completed. For each title, confirm whether the version in use is still supported by its publisher and mark it authorized only if it is. Because the CIS Controls Assessment Specification scores Safeguard 2.2 as failing when the authorized software inventory was last updated more than four weeks ago, the cadence must sit in a calendar or ticketing system with reminders, not in someone's memory. The output is a dated support check record that shows each title, its support status and the reviewer's initials.
Open the exception register for unsupported software
Each unsupported title the business still needs must have an entry in a documented exception register before it remains in use. The entry should name the software, the business reason it is needed, the mitigating controls applied (for example, network isolation, restricted access or enhanced monitoring), the residual risk accepted, the approver and a review date. Any unsupported software without an approved exception is treated as unauthorized and goes into the unauthorized software process. The output is an exception record for each retained title, and an assessor will test whether the register matches what the support check found.
Run the twice-yearly review and sign-off
At least twice a year, review the full inventory against Safeguard 2.1, confirm that every entry has its required fields, remove decommissioned software with its decommission date, and check that each exception is still valid. The policy owner then signs off the review, and any changes to the policy text are recorded in its version history. Ask your assessor which review evidence they expect to see in the form they accept, such as a signed report or ticket. The output is a review record with a date, the reviewer's name, the findings and the corrective actions opened.
Hand dated records to the independent assessor
When an independent assessor or certification body examines your program, give them the dated records produced in the earlier phases: the signed policy, inventory exports, monthly support checks, exception records and review records. Confirm that the timestamps line up, so the monthly checks show no gap longer than the four-week window the assessment specification uses. Your implementation partner or internal team prepares the evidence, but the assessor decides what it proves. The output is an evidence package indexed to Safeguards 2.1 and 2.2, with an owner who can explain how each record was produced.

Use the CIS template as written or extend it for higher Implementation Groups

This table compares adopting the CIS Control 2 policy template unchanged with extending it for IG2 and IG3 Safeguards. Read each row as a question you must answer before choosing, and use the final row to decide what to put in a partner quote request.

Decision point	Option one: template as written (IG1)	Option two: extended template (IG2 and IG3)
Who this fits	Organizations in scope for IG1 only, where the CIS Controls are the baseline and no sensitive-data or specialist-team obligations apply	Organizations at IG2 or IG3, or those that must show the additional Control 2 Safeguards to a customer, regulator or contract
Safeguards covered	2.1 (detailed software inventory), 2.2 (supported software and documented exceptions) and the IG1 software controls in the template	Everything in option one, plus the three additional IG2 Safeguards and the one additional IG3 Safeguard in Control 2, which the CIS templates do not address
Drafting effort	Adapt the template's wording to your asset owners, inventory tool and approval chain, then confirm each stated rule (twice-yearly review, monthly support check) is achievable	Write new policy text for each added Safeguard, define owners and review cycles, and reconcile it with the IG1 text so the document reads as one policy
Approval path	Policy owner and executive sponsor approve the adapted template; record the approval date and version	Same approval path, plus review by the teams named in the added text, since they take on new duties; record which text came from CIS and which was written locally
Evidence produced	Approved policy, dated software inventory with the Safeguard 2.1 fields, monthly support-check records, and the exception register for unsupported software	All IG1 evidence, plus the documented text and records for each added Safeguard that the organization's own assessor will request
Main risk	Treating the template as a finished policy without checking that the inventory is actually refreshed within the window the assessment specification uses	Adding policy text that describes controls the organization does not run, which creates findings more visible than a missing IG1 control
Who may help	A partner can tailor the template to your environment and set up inventory collection, with the organization keeping ownership of the policy	A partner can draft the extended text, map it to your systems and gather evidence, but the organization owns and approves every rule it adopts
What to ask a partner to quote	Scope of template adaptation, number of systems and tools in the inventory, and the evidence pack delivered at handover	Scope of extended policy drafting per Safeguard, workshops with owners, evidence capture for each added Safeguard, and any independent assessment that is handled separately by an assessor

Who owns the policy, who prepares the evidence and who judges it

Your organization owns CIS Control 2. The policy, the authorized software list and every exception decision sit with your people, and an outside partner or assessor cannot take them over. Someone in the security or IT governance function should hold the policy, get it approved by the accountable executive and review it on the schedule the policy sets. The same owner should make sure the monthly vendor support check actually happens and that its results reach the people who decide.

Policy ownership: Name one accountable owner for the policy and a delegate for the inventory process, and record both in the policy.
Approval: Have an executive or governance body approve the policy and each change to it, and keep the approval record.
Monthly support checks: Assign who checks vendor support status each month and who signs off that the check was done.
Exception decisions: Decide, in writing, which unsupported software the mission still needs, with the mitigating controls and the accepted residual risk named.
Unauthorized software: Decide what happens to software that is neither authorized nor covered by an exception, and who removes it.

Check that each role has a named person, that the approval and exception records exist, and that the monthly checks have a dated trail.

Where open-source inventory tooling fits the Control 2 evidence

Open-source inventory tooling can build and refresh the software inventory that Safeguard 2.1 requires, but it does not decide what goes on the authorized list. The Wazuh Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups, and Windows updates from each endpoint, then stores that data in the Wazuh indexer for inventory views and reports in the dashboard, as described in the Wazuh system inventory documentation. That gives the organization a current, machine-collected record of what is installed. Each software entry still needs the fields Safeguard 2.1 expects, such as business purpose, publisher and license count, and those usually come from the owning team, the procurement record or the license register rather than from the endpoint itself.

Syscollector data does not, on its own, classify support status, approve an exception, or prove that the monthly vendor support check or the twice-yearly review happened. Safeguard 2.2 depends on a person or documented process marking software as currently supported, recording mitigating controls and accepted residual risk for any unsupported software the mission still needs, and treating everything else as unauthorized. Keep those decisions, with their dates and approvers, in the policy record. Use the inventory export as the snapshot that supports them.

Before relying on Syscollector as evidence, confirm which endpoints, operating systems and software sources it actually covers in your environment. Check whether servers, cloud workloads, mobile devices and network appliances report into the indexer, and whether software installed outside the package manager is captured. Record any gaps as known limitations with an owner and a closing date. The Control 2 assessment specification checks whether the authorized software inventory was updated within four weeks, so a stale or partial agent deployment will show up as a failed measure even when the tool itself works. Ask your implementation partner to document this coverage check as part of the readiness work, and have the independent assessor test it directly.

What usually breaks the Control 2 policy in practice

The Control 2 policy rarely fails on the wording. It fails when the inventory goes stale, the support checks leave no record, exceptions lack risk decisions, unauthorized software sits unresolved, and nobody local owns the process. Each card below names one failure and a check you can run this week.

Inventory built once, never refreshed

A software inventory exported at go-live looks complete until the first patch cycle, new team tool or retired application makes it wrong. Safeguard 2.1 expects the record to be reviewed and updated at least twice a year, and the CIS Controls Assessment Specification scores Safeguard 2.2 as failing when the authorized software inventory was last updated more than four weeks ago. Check the last-updated timestamp on the authorized list and confirm an owner is named for each review. If the timestamp is older than four weeks, the inventory is already failing the assessment window.

Monthly support checks with no dated record

Teams often confirm vendor support status informally, so when an assessor asks for proof, nothing shows when the check happened or what it found. Safeguard 2.2 expects the software list to be checked for vendor support at least monthly. Ask for the last three monthly check records and confirm each one names the reviewer, the date, the software reviewed and the outcome. A check without a date and a named reviewer is treated as no check at all.

Exceptions approved without risk decisions

Business-critical software that has passed vendor end of support often gets a verbal exception that never states what protects it or who accepted the leftover risk. Safeguard 2.2 requires a documented exception that describes the mitigating controls and the accepted residual risk. Pick one open exception and check that it names the compensating controls, such as network isolation or restricted access, and that a named risk owner signed it. An exception missing either element does not satisfy the Safeguard.

Unauthorized software left without a decision

Software discovered outside the authorized list is often tolerated for months because no one decides whether to remove it, approve it or add an exception. Under Safeguard 2.2, unsupported software that the mission does not need is treated as unauthorized, so it has to be handled rather than ignored. Compare the latest discovery scan against the authorized list and confirm every unlisted item has a recorded disposition, either removal or a dated approval decision.

Policy copied without local owners

Many organizations adopt the CIS policy template as written and never assign the roles it depends on, such as the inventory maintainer, the support-check reviewer and the exception approver. The template is built for IG1 and assumes someone performs each step. Check that every section of the policy names a role, that each role holds a named person, and that those people have seen the process at least once. A policy with unassigned roles will not produce the dated records assessors request.

Questions buyers ask about the CIS software asset management policy

Is the free CIS software asset management template enough for IG1?

For an IG1 organization, the template is a sound starting point because CIS built it around IG1 Safeguards and aligned it with Controls v8 and v8.1. It does not replace the work. The organization still has to decide who owns the software inventory, where the inventory data comes from, how exceptions are approved and how the policy is enforced day to day. CIS policy templates address only IG1 Safeguards, so an organization that has moved into IG2 or IG3 needs additional policy content. The template also cannot tell you whether your inventory is accurate. The Assessment Specification defines the measures, so use it as the test script when you review your own draft.

How often must the software inventory be reviewed and updated?

Safeguard 2.1 asks for a detailed record of licensed software across the enterprise, reviewed and updated at least twice a year. That is the minimum review cadence. The inventory should also change whenever software is installed, upgraded or removed, because a stale record creates false assurance. Your policy should state the review dates, name the owner of each review and describe how changes from endpoints reach the record. Confirm the exact measures in the Assessment Specification for Safeguard 2.1 before you set internal deadlines, since the specification defines what an assessor checks.

What does the monthly vendor support check require in practice?

Safeguard 2.2 expects the software list to be checked for vendor support at least monthly. In practice, someone compares each authorized title and version against the publisher's support or end-of-life information and records the result. The work has three parts: a current list of authorized software, a reliable source of support dates for each product, and a recorded outcome for every item that is unsupported or approaching end of support. Many teams automate the first part with an inventory tool, then perform the support review manually. Your policy should name the role that signs off the check and where the results are stored.

How do we document an exception for unsupported software?

Safeguard 2.2 allows unsupported software to stay in use only when the mission needs it and a documented exception exists. The exception should describe the business reason, the mitigating controls that reduce exposure, such as network isolation or restricted access, and the residual risk the organization accepts, along with who accepted it. Unsupported software without such an exception is treated as unauthorized. Set an expiry or review date for each exception so it does not become permanent. Your policy should define the approval path and the review trigger, for example a change in the system's exposure or a publisher's end-of-life notice.

What does the four-week rule in the Assessment Specification mean?

The Assessment Specification scores Safeguard 2.2 as failing when the authorized software inventory was last updated more than four weeks ago. This is a measurable test, not a suggestion. It means the monthly support check needs a visible update date that an assessor can verify, such as a dated record or a timestamped export. A review that happened but was not recorded will fail the test. Plan the process so that the record changes at least every four weeks, and keep the dated evidence. Confirm the exact evaluation rules with the Assessment Specification for Control 2 and your assessor before relying on them.

How much of this work can our own team do without outside help?

Most organizations can write the policy and run the inventory themselves, provided someone owns the process and has time for the reviews. The effort depends on the size of the estate, how many sources of software exist (endpoints, servers, cloud workloads and SaaS subscriptions), how mature the license records are and how many exceptions exist already. Internal costs are recurring, because the review, support check and exception cycle continues for as long as the policy applies. An implementation partner can help with a fixed-scope piece, such as deploying an inventory tool, integrating its output with the review process and documenting the evidence. Ask any partner for a written scope before work begins.

Can a partner or assessor sign off that our software policy is compliant?

A partner cannot sign off compliance. DeployOpen plans, implements and documents systems and evidence, but only an independent auditor, assessor or certification body issues reports or certificates. Your organization owns its controls and its policy. Use the Assessment Specification to decide what evidence to prepare, then ask your assessor which artifacts they will request. CIS states that the Controls do not replace any regulatory or compliance scheme, so if a contract or regulator requires a specific framework, confirm with that party how the CIS Controls map to their requirements before you rely on the mapping.

How DeployOpen prepares Control 2 evidence for your assessment

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the software inventory and review records behind CIS Control 2 are produced where your data lives. Your organization owns the policy and its approval, and DeployOpen prepares the systems and evidence that the policy describes.

How we scope

Agree in writing which Control 2 Safeguards (2.1 to 2.7) and which Implementation Group level the engagement covers
Confirm which endpoints, servers and cloud workloads the software inventory must reach
Define who approves exceptions for unsupported software and who receives the monthly vendor support check

How we build

Configure a software inventory that records title, publisher, business purpose and first installation date for each entry
Deploy the Wazuh Syscollector module to collect installed software from each endpoint into the Wazuh indexer
Set up a documented review cadence and a register for unsupported software exceptions with mitigating controls and residual risk

How we hand over

Deliver the software asset management policy text, mapped to Safeguards 2.1 and 2.2 with the review schedule stated
Provide exported inventory reports, review logs and exception records that an assessor can sample
Document the procedure your staff follow to handle unauthorized software and keep records of the response

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover
Review inventory coverage and exception records with your team on the agreed schedule
Confirm with your independent assessor which evidence formats they accept before the assessment starts

CIS software asset management policy template (Control 2)