> For the complete documentation index, see [llms.txt](https://documentation.ocsinventory-ng.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.ocsinventory-ng.org/administrator-docs/server-setup/configuration/advanced/compliance.md). # Compliance Compliance checks whether your devices follow your organization's security and software policies. It also tells you whether a device's operating system is still supported by its vendor (end of life / EOL). Results are available from the global dashboard and from each device's page. ### Overview Compliance covers two areas: | Area | What it checks | | ------------------------ | --------------------------------------------------------------------------------------------------------------------- | | **Rule compliance** | Whether a device follows the security or software rules you've defined. | | **OS End-of-Life (EOL)** | Whether a device's operating system is still supported, based on data from [endoflife.date](https://endoflife.date/). | Rules are checked automatically on a regular schedule. You can also trigger a full check manually at any time. For details on scheduling automatic checks, see Automated actions. Each result has one of these statuses: * **Compliant** * **Non compliant** * **Unknown** **Unknown** usually means the check couldn't be completed, most often because some required information is missing from the device. {% hint style="warning" %} The OS End-of-Life check requires your server to have network access to [endoflife.date](https://endoflife.date/). If the server can't reach this site, EOL results will show as **Unknown** for all devices. {% endhint %} ### Where To Find It | Location | Purpose | | --------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | **Inventory → Compliance** | View compliance and EOL results for all devices. | | **Configuration → Compliance settings** | Create, edit, and delete compliance rules; manage Windows version mappings and extended support overrides. | | **Device details → Compliance** | View compliance and EOL status for one device. | ### Configuration #### Managing Compliance Rules Compliance rules are managed under **Configuration → Compliance settings**, in a dedicated **Rules** tab. For general rule behavior (when rules run and in what order), see [Managing Rules](/administrator-docs/server-setup/configuration/advanced/managing-rules.md). Each rule offers three actions: * Edit the rule's details * Open the condition editor * Delete the rule **Adding A Rule** {% stepper %} {% step %} Go to **Configuration → Compliance settings**. {% endstep %} {% step %} Open the **Rules** tab. {% endstep %} {% step %} Click **Add rule**. {% endstep %} {% step %} Fill in the rule's details. | Field | Description | | --------------- | ----------------------------------------- | | **Name** | Unique display name for the rule. | | **Description** | Optional text shown alongside the result. | | **Type** | `Security` or `Software`. | | **Severity** | `Critical`, `High`, `Medium`, or `Low`. | | **Enabled** | A disabled rule is skipped during checks. | | {% endstep %} | | {% step %} Click **Add**. The rule is created without a condition yet. You'll need to open the condition editor next to define when it should trigger. {% endstep %} {% endstepper %} **Editing Rule Details** Click the **pencil** icon to reopen the rule's general details (name, type, severity, etc.). To change the condition itself, use the condition editor. #### Setting a Rule's Condition The condition editor lets you define when a rule should mark a device as compliant or not. It shows the rule's name, type, severity, and enabled state at the top. A condition is built line by line: each line compares something about the device to an expected value. Multiple lines can be combined with **AND** or **OR**. **Where the information in a condition comes from** For each line, you first choose where the information comes from: | Source | What it gives you access to | | ---------------------------- | ------------------------------------------------------------------------------------------------------ | | **Device field** | Standard information like device name, serial number, domain, operating system, or installed software. | | **Inventory template field** | Custom fields from your inventory templates (you pick the template, section, then field). | | **Admin field** | Administrative information recorded on the device. | | **Group membership** | Whether the device belongs to a specific group. | | **Software Inventory** | Standard software information like name, publisher, or version. | For more on inventory templates, see [Inventory and Templates](/user-docs/asset-management/inventory-and-templates.md). For admin fields, see [Administrative Data](/user-docs/asset-management/administrative-data.md). For groups, see [Asset Groups](/user-docs/asset-management/asset-groups.md). For more on detected software, see [Software inventory](/user-docs/asset-management/inventory-and-templates/software-inventory.md). #### Example: Creating a Rule Here's a full example: a rule called **Web browser update policy** that flags devices running an outdated version of Firefox or Google Chrome. {% stepper %} {% step %} Go to **Configuration → Compliance settings**, open the **Rules** tab, and click **Add rule**. {% endstep %} {% step %} Fill in the rule's details: | Field | Value | | --------------- | ---------------------------------------------------- | | **Name** | `Web browser update policy` | | **Description** | `Firefox and Chrome must be on a supported version.` | | **Type** | `Software` | | **Severity** | `High` | | **Enabled** | Yes | | {% endstep %} | | {% step %} Click **Add**. {% endstep %} {% step %} Open the condition editor for the new rule. {% endstep %} {% step %} Add a first line: choose `Software Inventory`, then `Software versions`, set `firefox` for software name, and set the minimum version you require (e.g. version is at least `153`). {% endstep %} {% step %} Add a second line the same way, this time for `google-chrome`, with the minimum version you require (e.g. version is at least `120`). {% endstep %} {% endstepper %}
Once saved, this rule runs automatically on the next compliance check. Any device with an outdated Firefox or Chrome will appear as **Non compliant** with `High` severity, both on the global dashboard and on the device's own Compliance panel. #### Mappings Used for End-of-Life These mappings are managed under **Configuration → Compliance settings**, in the **Mapping** tab. **Windows Build Mapping** OCS Inventory stores Windows versions as build numbers. For example, `10.0.26100`. This mapping table converts that build number into the release name expected by endoflife.date. For example, build `26100` corresponds to `24h2`. The table covers known Windows 10 and Windows 11 releases. It doesn't apply to Windows Server, whose version is determined directly from its name. {% hint style="info" %} When Microsoft releases a new Windows update, its build number may not be in the table yet. Affected devices will show as **Unknown** until you add the missing entry. {% endhint %} **Extended Support Mapping** This tab lets you set a custom end-of-support date for an operating system when your organization has an extended support contract (for example, Ubuntu Pro). As long as the date you set hasn't passed, the device is treated as "active" even if the vendor's standard support has ended. | Field | Description | | -------------------------- | ----------------------------------------------------------------------------------- | | **Product** | Name of the operating system, as defined on endoflife.date (e.g. `ubuntu`, `rhel`). | | **Cycle** | Release version (e.g. `20.04`, `8`). | | **Extended support until** | Date until which the operating system should be treated as active. | | **Label** | Optional name to identify the contract (e.g. `Ubuntu Pro OCS`). | ### Viewing Results #### Compliance Dashboard Go to **Inventory → Compliance**. The dashboard has three tabs: * **By assets** * **By rules** * **System End of Life** **By assets Tab** Summary cards show: | Card | Meaning | | ------------- | ------------------------------------------------------------------------ | | Critical | Number of failed critical-severity rules. | | High | Number of failed high-severity rules. | | Medium | Number of failed medium-severity rules. | | Low | Number of failed low-severity rules. | | Compliant | Number of devices that pass all rules, plus the overall compliance rate. | | Non compliant | Number of devices that not pass all rules. |
**By rules Tab** Summary cards show: | Card | Meaning | | -------- | --------------------------------------------------------------- | | Critical | List all critical-severity rules and number of impacted assets. | | High | List all high-severity rules and number of impacted assets. | | Medium | List all medium-severity rules and number of impacted assets. | | Low | List all low-severity rules and number of impacted assets. |
**System End Of Life Tab** Summary cards show the overall picture: | Card | Meaning | | ---------------- | ------------------------------------------------------- | | Monitored assets | Devices whose operating system could be identified. | | Supported | Devices whose operating system is still supported. | | Extended support | Devices whose operating system support is extended. | | End of life | Devices whose operating system is no longer supported. | | Unknown | Devices whose operating system could not be identified. | {% hint style="info" %} A device shows as **Unknown** when OCS Inventory can't match its operating system to a known entry on endoflife.date. This is common with uncommon distributions or custom OS names. For Windows devices, a matching version mapping (see above) is also required. {% endhint %} #### Device Compliance Panel The **Compliance** section on a device's page shows the full result for that device. **Overall Status** The main indicator shows one of these values: * **Compliant** - all checked rules pass * **Non compliant** - at least one rule fails * **Not applicable** - no rules have been checked yet **OS End-of-Life Panel** This section shows the identified product, release cycle, EOL date, extended-support date (if any), and latest available version. It shows **Unknown** if the operating system couldn't be identified. **Per-Rule Results**
Results are grouped by severity: * Critical * High * Medium * Low * Compliant Each row shows the rule name, type, severity and status. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://documentation.ocsinventory-ng.org/administrator-docs/server-setup/configuration/advanced/compliance.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.