Safeguard 10.2 automatic signature updates: evidence guide

What Safeguard 10.2 automatic anti-malware signature updates asks for

An anti-malware product that is installed but holds stale signatures protects very little, because it can only recognize the threats it was told about. Safeguard 10.2 asks the enterprise to configure anti-malware signature files to update automatically on all enterprise assets, so protection does not depend on someone remembering to push an update. It sits in the Devices asset class and the Protect security function, and it is an IG1 safeguard, which means it applies to IG1, IG2 and IG3 enterprises alike. The risk it addresses is simple: a device that misses signature updates for weeks becomes a soft target for malware that is already well known and already has a detection somewhere in the market.

The difficulty is rarely the setting itself. It is the population of devices it has to cover. Laptops used off the corporate network, devices that sleep for long periods, servers in segmented networks, and systems that are offline during an update window all fall behind without anyone noticing. Update channels also fail quietly. A proxy change, an expired license, a certificate problem or a policy that was never applied to a new device group can leave a fleet with signatures that are days or weeks old while the console still shows the product as installed and healthy. Confirm with your anti-malware vendor how signature updates are delivered for offline and roaming devices, and whether the console reports signature age per device.

CIS describes what to measure in the CIS Controls Assessment Specification, not how to configure it, so the configuration choices are yours to make and document. The Specification scores this safeguard with a Coverage metric, the share of assets properly configured to update signatures automatically, and it lists Safeguard 10.1, the deployment of anti-malware software, as a prerequisite. In practice, that means you cannot prove 10.2 on a device that does not run the product at all. Start by reconciling your asset inventory against the anti-malware console, then decide how you will evidence signature freshness across the whole population, not just the devices that happen to be on the network today.

Which assets and teams fall under automatic signature update scope

Safeguard 10.2 applies to every enterprise asset, so the scope work is less about picking a tool and more about deciding which systems count, how they reach an update source, and which team controls each setting. The cards below set out the decisions that change the workload most.

Endpoints and servers as enterprise assets

Start with the asset inventory from Control 1 and mark every workstation, laptop and server that stores or processes enterprise data as in scope. Safeguard 10.2 asks for automatic signature updates on all enterprise assets, so a server excluded from the inventory is also excluded from the update check. Confirm that the inventory is current before you count coverage, because the Coverage metric in the assessment specification depends on the denominator.

Devices asset class boundaries

Safeguard 10.2 sits in the Devices asset class, so the scope question is which hardware and operating system instances are devices in the sense of the Controls. Decide whether mobile devices, network appliances and specialized equipment are in scope, and document the decision. Assessors will ask why an asset was excluded, so keep the reasoning next to the asset list.

Offline and intermittently connected systems

Laptops that travel, field devices and systems that power down on weekends often miss scheduled updates. Identify these assets by their check-in pattern, not by their owner. Confirm that the signature update runs when the device reconnects, and check the last successful update date for each group. A device that is in scope but never updates will lower the Coverage result without any visible alert.

Air-gapped segments and internal update sources

Systems on isolated networks cannot reach the vendor's update service directly, so they need an internal update source that mirrors signature files. Decide who hosts that mirror, how often it refreshes, and how the transfer is approved and logged. Ask the anti-malware vendor which update mirror options it supports for disconnected environments, because this capability varies by product and must be confirmed in writing.

Virtual machines, images and golden builds

Golden images and templates can carry an old signature file into every clone, so the update setting must live in the image and in the running instance. Check that new virtual machines pull signatures on first boot and that templates are rebuilt on a schedule. Treat ephemeral workloads, such as build agents that exist for hours, as a separate case that needs its own evidence of updates.

Ownership across endpoint, server and cloud teams

Update settings are usually owned by the endpoint team for workstations, the server team for on-premises hosts and the cloud platform team for instances and images. Write a RACI for signature update configuration that names one owner per asset group, and agree who receives failed-update alerts. Gaps appear at the boundaries, where a server built by one team is managed by another.

How an assessor tests automatic anti-malware signature updates

This table sets out how an assessor measures Safeguard 10.2 with its Coverage metric, what evidence to prepare, how samples are drawn and where tests usually fail. Read it as a checklist: confirm 10.1 first, then prove the update setting on every asset in scope.

Test step	What the assessor does	What to prepare
Prerequisite check (10.1)	Confirms anti-malware software is deployed on in-scope assets before any signature update setting is measured, because the Assessment Specification lists 10.1 as a prerequisite for 10.2.	Current anti-malware deployment inventory showing which assets run the product, with a reconciled count against the asset inventory.
Scope definition	Establishes the population of enterprise assets in scope, including endpoints, servers and any other devices that run anti-malware software.	Asset inventory export, the list of exclusions with written justification, and the date the population was taken.
Coverage measurement	Calculates the share of in-scope assets that are properly configured to update anti-malware signature files automatically. This is the Coverage metric the Specification uses to score 10.2.	Per-asset or per-policy configuration evidence showing automatic signature update is enabled, plus the numerator and denominator of the calculation.
Configuration evidence	Checks the update setting itself, not only the existence of the product. The assessor looks for an automatic update mode rather than a manual or scheduled-by-user process.	Exported policy or configuration files, central console screenshots or reports, and the policy assignment record for each device group.
Sampling approach	Selects assets across groups, such as laptops, servers, remote and offline devices, and one sample from each policy or build. Where the population is small, the assessor may test all assets.	A list of policies with assigned groups so the assessor can choose a representative spread without relying on one showcase device.
Update currency check	Looks at recent signature update timestamps to confirm updates actually occur, since a setting that is enabled but never applied will not protect the asset.	Last-updated timestamps or update logs from the management console, and any reports of failed updates with the remediation taken.
Common finding: manual settings	Assets where users or local administrators have switched signature updates to manual or disabled them are commonly found and count against the Coverage score.	A policy showing that users cannot override update settings, and a report of any local exceptions with their owners.
Common finding: excluded groups	Entire groups such as servers, lab machines, kiosks or offline devices are left out of the policy, which lowers Coverage even when the rest of the fleet passes.	A documented decision for each exclusion, the compensating control used, and evidence that excluded assets are reviewed on a set cycle.
Common finding: 10.1 not verified first	Assessments stall or produce unreliable results when the team cannot show anti-malware deployment, because the 10.2 measurement depends on it.	Deployment coverage evidence completed before the 10.2 test begins, so both measurements use the same asset population.

Evidence that shows automatic signature updates are working

Safeguard 10.2 is measured as coverage: the share of assets configured to update signature files automatically. The artifacts below show that configuration exists, that it reaches every asset, that signatures are actually current, and that changes and exceptions are controlled. Confirm with your anti-malware vendor which fields its console exports before you design the evidence calendar.

Exported endpoint policy

Export the anti-malware policy that governs signature updates and keep the setting that enables automatic updates, along with the update source and frequency. This shows the intent of the configuration, which the assessor compares against what each asset actually runs. Store a dated export each quarter and after every policy change, so the policy in force at any audit date can be reproduced. Confirm with the vendor whether the policy can be exported in a readable format, such as JSON or CSV, or only as a screenshot.

Fleet update configuration report

A per-asset report showing which devices inherit the automatic update policy and which do not. This is the primary input for the Coverage metric in the CIS Controls Assessment Specification, so the denominator must match your asset inventory from Control 1. Reconcile the report against the inventory each cycle, because devices added outside standard builds are the most common gap. Ask the vendor which console fields identify the policy assigned to each endpoint.

Signature version and timestamp sample

For a sample of endpoints, record the signature or definition version and the timestamp of the last successful update. Stale timestamps on a few devices can indicate offline machines, blocked update sources or failed agents rather than a policy problem. Sample across device types, locations and network zones, and document how the sample was chosen. Keep the raw export so an assessor can see the sampling method, not just the result.

Exception records with approvals

Each asset that cannot receive automatic updates needs a written exception with a reason, a named owner, an approver, a compensating control and an expiry date. Without these records, a device that stopped updating looks identical to a deliberate exception during review. Review open exceptions at a set interval and close those that no longer apply. Keep the approval trail with the exception itself rather than in a separate tracker.

Change records for policy edits

Keep tickets or change logs for every edit to the update policy, including the change, the requester, the approver and the date it took effect. These records show that automatic updates were not quietly disabled between audits. Compare change logs against the quarterly policy exports, because a mismatch between the two is a finding an assessor will raise. Confirm whether the console keeps its own audit log and how long that log is retained.

Configuring automatic signature updates on every asset

This sequence moves Safeguard 10.2 from intent to evidence: it confirms that anti-malware is already deployed, sets a signature update policy for each platform, applies it centrally, proves it on a pilot group, and keeps the coverage measure current so an assessor can see the Coverage metric hold over time.

Verify 10.1 deployment coverage first
Before changing any update setting, confirm that anti-malware software is installed and running on every enterprise asset in scope. Safeguard 10.2 is measured against Safeguard 10.1 as a prerequisite, so an asset without the agent cannot be counted as configured. Compare your asset inventory from Control 1 with the anti-malware console or endpoint query results, and list every gap. The output is a reconciled list of covered and uncovered assets that becomes the denominator for the Coverage metric.
Define the update source and policy per platform
Document where each anti-malware product pulls its signature files from, whether that is the vendor cloud, an internal update server or a mirror for segmented networks, and how each operating system family (Windows, macOS, Linux and mobile) receives them. Set the update frequency and the behavior when an asset cannot reach the source. Record who owns the policy and approves changes. The output is a signed-off update policy that states the expected configuration for each asset class.
Apply automatic update settings centrally
Push the documented update configuration through the central anti-malware console or your configuration management tooling so that automatic signature updates are enabled on every in-scope asset. Where the console cannot reach an asset, apply the setting locally through configuration management and record the method. Keep the change in version control or a change ticket so the setting is reproducible. The output is a policy assignment that covers the full asset list from step one.
Validate the configuration on a pilot group
Select a pilot group that spans each platform, network segment and asset class, including at least one device that is offline for long periods, and confirm that signature files update automatically without user action. Check the signature version and last update time on each pilot asset against the update source. Test the fallback path for an asset that cannot reach the primary source. The output is a pilot report with the observed signature versions and timestamps, which shows the setting works before fleet-wide rollout.
Roll out and track exceptions
Extend the validated policy to the remaining assets in waves, and record every asset that does not accept the automatic update setting, such as a locked-down system, a legacy operating system or an air-gapped segment. Give each exception a named owner, a documented reason and a compensating method, for example a controlled manual update with evidence. The output is a rollout record and an exception register that an assessor can trace back to the asset inventory.
Set up recurring coverage checks
Schedule a recurring query or report that counts the assets with automatic signature updates enabled and the assets with signatures older than your documented tolerance, then compare the result with the reconciled asset list. Osquery, Fleet policies or the anti-malware console's own reporting can support this check, but confirm that each tool can read the signature update status on your platforms before relying on it. The output is a dated Coverage calculation, the share of assets properly configured, retained with the exception register as evidence that the control runs continuously.

Using osquery, Fleet, Wazuh and Velociraptor to check signature update coverage

Safeguard 10.2 is scored as a coverage measure, so the evidence is a per-asset view of whether signature updates are configured and current. The four self-hosted tools below can each read endpoint state, but none of them replaces the anti-malware product's own update status, so confirm the exact queries with your vendor.

osquery for endpoint state

osquery exposes endpoint state as SQL tables, and its osqueryd daemon runs scheduled queries across a fleet of hosts. Use it to read file hashes, running processes and installed software, then compare the results with the signature location and version your anti-malware vendor documents. Its license is Apache-2.0 OR GPL-2.0-only. Confirm with your vendor which local files, registry keys or service states reliably show signature age, because a table query only reports what the endpoint exposes.

Fleet policies as yes or no checks

Fleet (MIT) turns each check into a yes or no policy written as an osquery query. A policy such as whether the signature update service is running and its files are recent can show, per fleet, which devices pass and which fail. That per-device list is the coverage numerator that Safeguard 10.2 asks for. Document the query, the pass condition and the owner who handles failing devices, since the policy result is only as good as the query behind it.

Wazuh configuration assessment checks

Wazuh Security Configuration Assessment (GPL-2.0-only) scans monitored endpoints against YAML policies that check files, directories, registry keys and running processes, and it recommends remediation. Most shipped policies follow CIS benchmarks, so they cover hardening rather than signature freshness. Write a custom policy for your anti-malware product's update settings and keep it under version control so auditors can see when each check changed.

Velociraptor hunts for update evidence

Velociraptor (AGPL-3.0-only) collects forensic artifacts defined in VQL from endpoints, and its hunts gather one or more artifacts across a group of systems. Offline machines are scheduled to collect when they reconnect, which matters for laptops that rarely join the network. Use a hunt to pull signature version and last-update data from every asset in one pass, then review the combined results in the notebook it creates. Confirm with your vendor which artifact reflects the update status they support.

What automatic signature update coverage costs to meet

This table breaks down the cost components of meeting Safeguard 10.2, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a quote request, because no price or duration is published for this safeguard and the real figures depend on fleet size and existing tooling.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Anti-malware licenses	Software vendor, usually already owned under 10.1	Recurring (subscription or renewal)	Up: more assets and more products. Down: existing enterprise agreement that already covers all devices
Policy configuration engineering	Internal IT or an implementation partner	One-time, then periodic review	Up: many OS platforms and separate consoles. Down: one central console and existing configuration management
Update source and network path setup	Internal network or endpoint team	One-time, with changes as networks change	Up: offline or remote laptops and restricted segments. Down: a single documented update path
Open-source monitoring tooling	Internal engineers or implementation partner for setup	Setup one-time, licensing typically none for the core tools	Up: wider query scope and more hosts to poll. Down: reusing a fleet query platform already in place
Hosting for monitoring infrastructure	Organization, on its own cloud or data center	Recurring	Up: fleet size and retention of query results. Down: consolidating with existing logging or management servers
Exception handling and evidence upkeep	Internal security or compliance staff	Recurring	Up: frequent offline assets and undocumented exceptions. Down: a written exception process with owners and expiry dates
External review or auditor sampling	Independent auditor or assessor	Recurring, per assessment cycle	Up: large asset populations and weak evidence. Down: clean, exportable coverage reports ready before fieldwork

Who configures, verifies and assesses signature updates

Your organization owns Safeguard 10.2. That means the decision that signature updates must run automatically, the policy that sets update frequency and acceptable lag, the list of assets that are excluded and why, and the evidence that the setting holds over time. Assessors look for an accountable owner who can explain the configuration and show how exceptions are approved and closed. Outsourcing does not move that accountability.

Policy ownership: Set the update expectations for signature files in your anti-malware standard and name the role that approves changes to them.
Exception handling: Record each asset where automatic updates cannot run, the compensating measure, the approver and the review date.
Coverage review: Confirm on a regular schedule that the share of assets configured for automatic updates matches your asset inventory, since the Coverage metric depends on that inventory.
Evidence custody: Keep the configuration baselines, console reports and exception records in a location the assessor can access.
Vendor oversight: Review the work an implementation partner delivers before you accept it.

Before an assessment, check that someone on your team can explain the update setting, the exception list and the evidence without reading the vendor documentation.

Common questions about Safeguard 10.2 cost, effort and evidence

How long does it take to configure automatic signature updates for Safeguard 10.2?

The duration depends on how many enterprise assets you run, how many anti-malware products are in use, and how much of the fleet is managed centrally. Configuring the update setting on a single product is usually a small task, but the effort grows with the number of device groups, operating systems and exceptions you must document. Neither CIS nor the assessment specification gives a duration, so ask any provider to base its estimate on a written inventory of your assets and a list of the anti-malware products already deployed. Confirm the timeline in the written scope before work starts.

Can a small team configure Safeguard 10.2 without outside help?

Often yes, if the team already runs an anti-malware product and can manage it from a console or policy tool. The work is mainly confirming that the update setting is enabled on every endpoint, reviewing exceptions and keeping a record of the results. Teams without a current asset inventory, or without a defined owner for anti-malware, usually find the measurement part harder than the configuration. Safeguard 10.1 must be in place first because the assessment specification treats it as a prerequisite for measuring 10.2.

What does it cost to meet Safeguard 10.2?

Most of the cost is labor and tooling you may already pay for. Costs fall into four groups: the anti-malware license you already hold, staff time to configure and verify updates, any monitoring tool used to report coverage, and external help if you want it. Costs recur through license renewals and periodic reviews, while configuration itself is largely one-time. The main cost drivers are fleet size, the number of product types and how much of the fleet is offline or unmanaged. When requesting a quote, ask for the asset count, the verification method and what the provider will hand over as evidence.

What evidence will an assessor ask for to show automatic signature updates?

An assessor will look for the configured update policy, proof that it applies to all enterprise assets, and measured coverage: the share of assets properly configured to update signature files automatically. Useful evidence includes exported policy settings, an asset list matched against policy membership, and recent records showing signature versions on endpoints. Keep dated snapshots so the assessor can see the state over time, not only at one moment. Confirm the exact measures and inputs with the Safeguard 10.2 entry in the CIS Controls Assessment Specification.

Can open-source tools replace a commercial anti-malware product for Safeguard 10.2?

No. Safeguard 10.2 asks for automatic signature updates of anti-malware software, so an anti-malware product must exist first. Open-source tools cannot provide signature-based detection on their own, but they can help verify the outcome. For example, osquery can run scheduled queries across hosts, and Fleet policies can ask yes or no questions of devices and show which devices pass or fail. Wazuh configuration assessment can check endpoint settings against YAML policies. Confirm with each tool's documentation which checks it supports on your operating systems before relying on it.

How should offline assets be handled for automatic signature updates?

Offline or intermittently connected assets still count as enterprise assets, so they must be in scope and recorded. Configure the update setting so it runs when the device reconnects, and track devices that have been out of contact for a long time as exceptions. Some products allow updates from an internal distribution point, which suits air-gapped or restricted networks. Velociraptor's hunts can schedule collection on offline machines when they reconnect, which illustrates the pattern, but confirm your anti-malware product's own offline update options.

When should an organization bring in an implementation partner for Safeguard 10.2?

Bring in a partner when the asset inventory is incomplete, when several anti-malware products run across mixed environments, or when the team lacks time to build the verification and evidence routine. A partner can prepare configuration, monitoring and documentation under a fixed written scope. The organization still owns the control, and only an independent auditor or assessor issues reports or certifications. DeployOpen plans, implements and documents self-hosted open-source platforms in your own infrastructure and runs security testing, so ask whether your anti-malware tooling falls within a defined scope.

How DeployOpen scopes, implements and prepares evidence for Safeguard 10.2

DeployOpen plans and implements the signature update configuration for Safeguard 10.2 inside your own infrastructure, then prepares the configuration records and evidence an assessor will ask for. Your organization owns the control, and only an independent auditor or assessor can issue a report or certificate.

How we scope

The written scope lists which enterprise assets fall under Safeguard 10.2 and which anti-malware products are in use.
Scope confirms that Safeguard 10.1 deployment is in place, since the CIS assessment specification treats it as a prerequisite.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any configuration work starts.

How we build

We configure automatic signature updates on each agreed asset class, using your existing anti-malware management tooling where it applies.
Update settings are tested on a sample of devices to confirm signature files refresh without manual action.
Where you use osquery or Fleet, we can write queries that report each device's configuration state for Coverage measurement.

How we hand over

You receive documented configuration baselines, the coverage query set and a record of tested assets and their results.
Evidence is organized to match the Coverage metric in the CIS assessment specification, so an assessor can trace each figure to its source.
We confirm with you which evidence your auditor accepts and which items remain your responsibility to maintain.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover periodic re-checks of signature update coverage as new devices join the environment.
Before any engagement, ask us to confirm in writing which tools, versions and evidence formats are in scope.

Safeguard 10.2 Automatic anti-malware signature updates