What Safeguard 10.1 asks for and why coverage gaps matter
Safeguard 10.1 asks your enterprise to install anti-malware software on all enterprise assets and keep it maintained. If an auditor or customer questionnaire asks whether anti-malware covers every device, the honest answer is only as good as your asset list. The safeguard is measured as coverage: the share of assets that have properly configured, authorized anti-malware installed. A device you do not know about is a device that cannot be counted as covered, so the number you report can look healthy while the real exposure sits outside it. Within Control 10, 10.1 is the baseline. Safeguard 10.2 makes signature updates automatic, 10.6 puts the deployment under central management, and 10.7 adds behavior-based detection. Each of those refines a tool that 10.1 requires to be present in the first place. Safeguard 10.1 sits in Implementation Group 1, so it is part of the minimum standard for every enterprise, and it applies equally to IG2 and IG3 organizations. Larger or more regulated enterprises do not get a lighter version of it.
The usual difficulty is not installing the software. Endpoint protection products are straightforward to deploy to a managed fleet. The harder work is knowing the true population of devices, including laptops that rarely join the network, virtual machines, servers spun up by project teams, and equipment managed by a third party. The assessment specification expects the detailed asset inventory (Safeguard 1.1), the software inventory (2.1) and a secure configuration process (4.1) to be in place before 10.1 can be measured reliably. Before answering any coverage question, confirm that your inventory is current, that each asset is tagged as managed or unmanaged, and that you can produce the list of assets missing the agent. That gap list, not the product brochure, is the evidence an assessor will ask to see.
Which assets, teams and third parties fall inside Safeguard 10.1
Safeguard 10.1 is scoped by asset, not by tool. The decisions below determine which systems must carry anti-malware, who owns them, and what evidence the assessment will expect. Each card names a boundary that changes the size of the work.
Endpoints and servers
Workstations, laptops and physical or virtual servers form the core of Safeguard 10.1 because the Devices asset class sits in the endpoint layer. Confirm that every operating system family in use, including Linux and macOS hosts that are easy to overlook, has an authorized anti-malware product installed and reporting. Treat servers that sit outside the standard image as separate scope items, since they often drift from the endpoint baseline.
Virtual machines and images
Virtual machines count as enterprise assets in their own right, and so do the golden images and templates they are cloned from. A product installed on a template but not on clones, or on clones but not on short-lived instances, produces a coverage gap that looks correct in a single snapshot. Ask who owns the image pipeline and whether anti-malware is part of the build, not added after deployment.
Cloud workloads
Cloud compute instances, container hosts and serverless functions raise a scoping question about what the anti-malware agent can actually cover. Where an agent can run on a host, the host belongs in scope. Where the platform runs code without an agent, record that as a documented exception with a compensating control, and confirm the chosen approach with the assessor before measuring coverage.
Mobile devices
Smartphones and tablets are enterprise assets when they access corporate data or systems. Whether anti-malware applies depends on the device platform and the management model in place. Confirm which devices are enrolled in mobile device management, which protection the platform provides natively, and where a third-party product is required. Record the answer for each platform so coverage can be scored consistently.
Assets run by third parties
Laptops, servers or cloud accounts operated by a managed service provider still count if the enterprise relies on them for its data or operations. Put the anti-malware obligation in the service contract, require coverage reports, and include those assets in the same inventory used for measurement. Without that, the enterprise cannot show a complete Coverage figure, and an assessor will ask how it knows.
Prerequisites that make coverage measurable
Coverage is the share of assets with properly configured, authorized anti-malware, so it cannot be calculated without a denominator. The assessment specification lists Safeguards 1.1 (detailed asset inventory), 2.1 (software inventory) and 4.1 (secure configuration process) as prerequisites. Confirm that each exists and reconciles with the others before reporting a percentage, because an incomplete inventory overstates coverage.
How an assessor tests Safeguard 10.1 and what passes
This table shows how an assessor measures Safeguard 10.1 with the Coverage metric, which evidence closes each common finding and what the assessor needs to see. Use it to prepare the evidence set before an assessment starts, since the assessor will test the fleet against the inventory rather than accept a policy statement.
| Assessor step or finding | What the assessor checks or expects | What closes it |
|---|---|---|
| Coverage metric | Share of enterprise assets with authorized anti-malware installed and properly configured, measured against the asset inventory | Deployment report that matches the inventory, with the denominator stated and dated |
| Prerequisite inventories | Asset inventory (Safeguard 1.1), software inventory (Safeguard 2.1) and secure configuration process (Safeguard 4.1) exist and are current | Dated exports from each inventory and the approved configuration process document |
| Asset population | Every enterprise asset in scope is listed and checked against the anti-malware console or agent list | Reconciliation showing console count against inventory count, with differences explained |
| Unmanaged assets | Devices in the inventory with no anti-malware agent or a non-reporting agent | Agent deployed and reporting, or a documented exception with owner and expiry date |
| Stale or non-reporting agents | Agents installed but without recent check-ins, or with outdated engine or signature versions | Console showing recent check-in and current version, plus a rule that flags stale agents |
| Unauthorized products | Anti-malware software present that is not on the approved product list | Removal record or an approval entry with the business reason and the owner |
| Configuration records | Agent settings match the approved baseline, such as real-time protection enabled and tamper protection on | Policy export or configuration record for each asset group, with version and change history |
| Exception records | Each excluded asset or setting has a risk acceptance, compensating control and review date | Signed exception register with named approver and scheduled review |
How to implement Safeguard 10.1 in sequence
This sequence moves from a trusted asset and software baseline to anti-malware coverage that can be measured, exception-handled and reconciled on a recurring schedule. Each step produces a record an assessor can read against the Coverage metric.
Confirm the enterprise asset inventory
The security or IT operations lead confirms that the detailed asset inventory required by Safeguard 1.1 is current, covering every device that connects to the enterprise, including servers, endpoints, virtual machines and cloud workloads in scope. Coverage cannot be measured against assets nobody has listed, so the denominator for the metric comes from this inventory. The output is the exported asset register with a review date and an owner, which becomes the reference list for every later reconciliation.
Confirm the software inventory
The team confirms that the software inventory required by Safeguard 2.1 lists the operating systems and applications on each asset, so it can tell which platforms need anti-malware and which agents are compatible with them. Gaps here usually show up later as assets with no matching product. The output is a software inventory export tied to the asset register, with unsupported or unknown platforms flagged for a decision.
Set the secure configuration process
The organization documents the secure configuration process required by Safeguard 4.1, including the baseline for installing and configuring endpoint software, who approves changes and how deviations are recorded. The anti-malware settings belong in this baseline so that installation, tamper protection and update behavior follow one approved standard. The output is the approved configuration standard and its change record, which the assessor will compare against deployed settings.
Select authorized anti-malware software
The team selects the anti-malware product or products it is authorized to run, and records the approval in the software inventory so the Coverage metric counts only authorized installations. Selection should confirm that the product supports every platform in the asset register and can report installation status. The output is a signed approval record naming each authorized product, its supported platforms and its owner. Confirm vendor licensing and support terms before this step closes.
Deploy anti-malware to every asset class in scope
The deployment team installs the approved software on each asset class in the register (devices, servers and other managed assets in scope) using the configuration standard from the previous step. Deployment is usually done through a software distribution tool, a configuration management tool or the vendor's installer, and each installation should be logged with the asset identifier. The output is a deployment report showing the installation date, version and configuration state for each asset.
Reconcile inventory against agent presence
The team compares the asset register with the anti-malware console or a host inventory feed, such as an agent that reports installed software, and lists every asset that lacks a properly configured, authorized installation. Assets that appear in one source and not the other are investigated, not assumed to be covered. The output is a reconciliation report with the Coverage percentage calculated as the CIS assessment specification defines it, and a list of open gaps with owners.
Define exception handling for assets that cannot run it
Some assets, such as certain embedded or legacy systems, may be unable to run anti-malware. The risk owner documents each exception with the reason, the compensating controls, the approver and a review date, and the asset stays visible in the register rather than being removed from scope. The output is a dated exception register that an assessor can trace from the Coverage calculation to a formal decision. Confirm with the vendor which platforms truly cannot run the agent before recording an exception.
Schedule recurring reconciliation
The organization sets a recurring reconciliation of the asset register, the software inventory and the anti-malware console, with a named owner and a record of each run. New assets, retired assets and replaced agents change the Coverage figure, so a one-time check goes stale quickly. The output is a reconciliation log with dated Coverage results, exception reviews and the actions taken, which forms the ongoing evidence set for Safeguard 10.1.
Evidence that passes Safeguard 10.1 and how to keep it current
An assessor testing Safeguard 10.1 wants to see that the asset list, the anti-malware records and the exceptions all describe the same fleet. The artifacts below connect to one another, so each one should be refreshed on a fixed schedule and tied to a change record, not rebuilt from memory before an audit.
Reconciled asset-to-agent report
This report matches every enterprise asset in the inventory from Safeguard 1.1 against the hosts where anti-malware is reported as installed. Each unmatched record is either an asset without protection or a stale inventory entry, and both need a disposition. Keep the reconciliation as a dated export with the count of unmatched records and the owner who cleared each one. Re-run it on the same cadence as the inventory refresh so it does not drift.
Anti-malware console export
Export the install and version status from the central console or endpoint platform, including agent version, last check-in and protection state for each device. Assessors compare this export with the Coverage metric in the assessment specification, so the export should show the product name exactly as it is authorized. Schedule the export and store each one with its timestamp, since a single export from last year proves nothing about today.
Configuration baseline
The baseline records the settings that make the installed anti-malware properly configured, such as real-time protection, scan scheduling and tamper protection. It should be versioned and approved through the secure configuration process tied to Safeguard 4.1. Review it after each product upgrade and record any deviation as a change, so the console export and the baseline can be compared directly.
Authorized product list
This list names each anti-malware product and version the enterprise permits, along with the platforms it covers. It is the reference that tells an assessor whether a detected agent is authorized, and it links to the software inventory from Safeguard 2.1. Update the list whenever a product is added, replaced or retired, and keep prior versions so past evidence can be read in context.
Exception register with owners and dates
Every asset that cannot run approved anti-malware, such as certain embedded or legacy systems, needs a register entry with a named owner, a reason, a compensating measure and a review date. Unexplained gaps in the coverage figure are the first thing an assessor questions. Review each entry on its date and close it or renew it through a documented approval.
Periodic coverage snapshots
A coverage snapshot combines the reconciled report, console export and exception register into one dated record of the share of assets with properly configured, authorized anti-malware. Keep a series of snapshots rather than a single report, so trends and recurring gaps are visible between audits. Ask your implementation partner to confirm the calculation method in writing so the figure matches the assessment specification.
What meeting Safeguard 10.1 costs in money and effort
This table breaks down the cost and effort components of putting anti-malware on every enterprise asset, who is paid for each, whether it is one-time or recurring, and what moves it up or down. No prices are stated, because the cost depends on your asset count and environment. Use it to frame what a written scope and quote should cover.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Anti-malware licenses | Software vendor, or none for a built-in or open-source option | Usually recurring (subscription or renewal), where a commercial product is chosen | Number and type of endpoints, server versus workstation licensing, and whether a central console tier is included |
| Operating the chosen tool | Internal platform or security team, or a managed provider | Recurring | Whether someone owns updates, alert triage and exceptions, and whether the tool runs in your own environment |
| Asset inventory reconciliation | Internal IT and an implementation partner, if engaged | One-time, then recurring as assets change | Quality of the existing asset inventory (Safeguard 1.1) and software inventory (Safeguard 2.1), and how many unmanaged devices are found |
| Deployment and configuration engineering | Internal engineers or an implementation partner under a fixed scope | One-time, with later rollouts to new asset types | Asset diversity (Windows, Linux, macOS, servers, cloud workloads), legacy systems and the secure configuration process (Safeguard 4.1) |
| Exception handling and coverage evidence | Internal operations and security staff | Recurring | Number of exceptions, unsupported systems and assets that cannot run an agent, each of which needs documented justification |
| Ongoing evidence upkeep | Internal compliance or security staff | Recurring, usually tied to review cycles | How often coverage reports are exported, whether the Coverage metric is generated automatically, and how many frameworks reuse the same evidence |
| External review or testing | Independent assessor or testing provider | Recurring, at the frequency your program or contract requires | Scope of the assessment, asset sample size, and whether a readiness review runs before the formal assessment |
| Auditor sampling time | Your organization pays the external auditor or assessor | Recurring with each assessment cycle | Number of assets and endpoints sampled, and how quickly complete coverage records can be produced |
Open-source tools that produce Safeguard 10.1 evidence
Safeguard 10.1 is scored on coverage: the share of assets with a properly configured, authorized anti-malware product installed. The tools below help you build the asset and software inventory the assessment depends on, and then show where anti-malware status is present, missing or unexpected across the fleet. None of them replaces an anti-malware product, so each card explains what to confirm before you rely on it.
GLPI Assets and GLPI Agent inventory
GLPI (GPL-3.0-or-later) manages computers, software, network equipment and peripherals in its Assets module, either entered by hand or pushed automatically by the GLPI Agent through native inventory built into GLPI since version 10. This is the prerequisite layer for Safeguard 10.1, because the assessment relies on the enterprise asset inventory (Safeguard 1.1) and software inventory (Safeguard 2.1) to define what must be covered. Check that the agent reports every device class in scope, and that unmanaged assets appear as exceptions rather than silently dropping out of the denominator.
Wazuh Syscollector endpoint records
Wazuh (GPL-2.0-only) runs the Syscollector module on each endpoint, collecting hardware, operating system, installed software, services, running processes and open ports, then storing the results in the Wazuh indexer for dashboard views and reports. Filter the installed software inventory for the anti-malware products you have authorized, then compare that list with the assets where those products are present. Confirm with your chosen product whether its status, version and definition currency can be read by Syscollector, because Wazuh shows what is installed, not whether protection is working.
osquery fleet queries via osqueryd
osquery (Apache-2.0 OR GPL-2.0-only) exposes running processes, loaded kernel modules, open network connections and file hashes as SQL tables. The osqueryd daemon schedules those queries across an entire fleet, which lets you look for anti-malware service processes on each host and hash the agent binaries to confirm they match the authorized build. Results are only as good as the query design, so document each query, its schedule and who reviews the output for exceptions.
Velociraptor hunts for offline endpoints
Velociraptor (AGPL-3.0-only) collects forensic artifacts defined in VQL from endpoints and runs hunts that gather one or more artifacts across a group of systems. Hunts can schedule collection on machines that are offline and collect when they reconnect, which matters for laptops that rarely join the network. Use a hunt to confirm that a defined anti-malware artifact is present and healthy on endpoints that the inventory shows as in scope, and review the notebook for each hunt so exceptions are recorded with a date and an owner. Because AGPL-3.0-only carries network-use obligations for modified versions, have counsel review the license before you change the code.
Who owns Safeguard 10.1, who can help, and where the auditor stops
Your organization owns Safeguard 10.1. That means deciding which assets fall in scope, setting the anti-malware policy, approving exceptions for assets that cannot run the agent, and accepting residual risk when coverage falls short. An outside partner can build the deployment and produce the evidence, but the decisions and the accountability stay with your security and IT leadership. Assessors will ask who approved each exception and when it was reviewed, and the answer must come from your staff.
- Asset scope decisions: Decide which device classes are enterprise assets, including laptops, servers, virtual machines, and any cloud workloads, and keep that decision in a written record.
- Policy and standards: Maintain the written anti-malware policy and the configuration baseline that names the authorized products and minimum settings.
- Exception approvals: Approve, time-limit and review every asset that cannot run authorized anti-malware, such as certain appliances or legacy systems.
- Operational follow-up: Assign owners who act on coverage gaps, failed agents and offline devices reported by the monitoring stack.
- Governance sign-off: Accept the control status and the residual risk in writing before the assessment starts.
Before engaging anyone, confirm internally who will sign the policy, who approves exceptions and who receives the monthly coverage report.
An implementation partner prepares the systems and evidence that show Safeguard 10.1 is operating. DeployOpen works this way: it plans, deploys, configures and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For this safeguard, that typically means reconciling the asset inventory, which depends on the Safeguard 1.1 and 2.1 work, and building dashboards and exports that show coverage. The partner does not decide the policy, does not approve exceptions and does not issue an assessment result.
- Inventory reconciliation: Compare the asset inventory against endpoints reporting to the monitoring platform and list every gap for your team to resolve.
- Deployment and configuration: Install and configure the chosen anti-malware or endpoint agents on in-scope assets, following your baseline.
- Dashboards and exports: Build coverage views and scheduled evidence exports that show the share of assets with authorized anti-malware installed.
- Documentation: Write runbooks and a record of how the coverage metric is calculated, so an assessor can repeat it.
- Fixed-scope delivery: Agree the scope, deliverables and timeline in writing before work begins, and state what is excluded.
Ask any partner to name the deliverables in writing and confirm which tasks remain with your staff after handover.
The independent auditor, assessor or certification body tests Safeguard 10.1 and issues the report or conclusion. Testing follows the measures in the CIS Controls Assessment Specification, which scores the Safeguard with a Coverage metric: the share of assets with properly configured, authorized anti-malware installed. The auditor samples assets, checks the inventory, compares it with the agent data, and reviews exceptions. Neither your team nor a partner can issue that conclusion, and DeployOpen does not issue audit reports, attestations or certifications.
- Sampling and recomputation: The auditor selects assets and recalculates coverage from source data rather than accepting a summary alone.
- Inventory comparison: The auditor checks whether the asset inventory is complete, which is why the prerequisite safeguards matter.
- Exception review: The auditor tests whether each exception is approved, time-limited and reviewed.
- Configuration checks: The auditor confirms that agents are running, authorized and configured to the baseline on sampled devices.
- Reporting limits: The auditor reports only on the scope it tested and states where its work ends.
Confirm the auditor's scope, the sample method and the evidence format before preparation begins, so that the evidence built by your team and partner matches what will be tested.
Where Safeguard 10.1 programs usually fall short
Most Safeguard 10.1 findings are not about whether anti-malware exists. They come from a fleet list nobody reconciles, assets that fall outside the scan, and evidence that cannot prove coverage on a given date. The cards below cover the gaps assessors most often probe, with the artifact or check that closes each one.
No reconciled asset list
Coverage is measured as a share of assets, so the denominator matters. If the anti-malware console lists 400 endpoints while the asset inventory lists 430, the 30 gaps are invisible until someone compares them. Export the console's device list and the asset inventory from GLPI or Wazuh Syscollector, then reconcile them by hostname, serial number and MAC address. Every unmatched record needs an owner and a disposition: install, retire or document as an exception. Safeguard 1.1 is a prerequisite for measuring 10.1, so start there.
Servers and cloud workloads missed
Programs are often built around laptops and desktops, while servers, virtual machines, build agents and short-lived cloud instances sit outside the rollout. Assets count as enterprise assets whether they are on premises or in a cloud account, so each class needs its own deployment path, such as golden images, configuration management or autoscaling launch templates. Check the asset inventory by asset class and compare server and cloud counts against the anti-malware console for each class. Ask the reader to confirm which of these classes are in scope in their own environment.
Agents installed but not reporting
An installed agent that has not checked in for weeks does not protect the asset, yet it may look present in a deployment count. Coverage should require a properly configured, authorized agent that is currently reporting. Pull the last-seen timestamp from the console for every device and set a threshold your policy defines. Devices beyond that threshold go on a remediation list, not into the coverage figure. Osquery can run a scheduled query across the fleet to confirm the agent process is running on each host.
Undocumented exceptions
Some assets cannot run a supported anti-malware product, such as legacy operational technology, appliances or isolated lab systems. Quietly excluding them is the gap assessors find most often. Keep a written exception register with the asset, the reason, the compensating controls, the approver and a review date. Each exception should name the owner who accepted the residual risk. An exception without an expiry date tends to become a permanent blind spot.
Undated screenshots as evidence
A screenshot of the console taken during a project kickoff shows that a tool existed, not that coverage held during the audit period. Evidence should be generated on a schedule and carry a timestamp: a dated coverage export, the console's deployment report or an osqueryd result set with collection times. Store each export with the date, the query or report parameters and the person who ran it. Ask the reader to confirm how long their retention policy keeps these records.
Installed but not maintained
Coverage at one point in time says little if the agent falls behind on engine versions, policy changes or device health. Anti-malware that was deployed but never updated, or that was disabled by a user or a rogue configuration change, leaves the baseline in place on paper only. Monitor agent health, policy compliance and tamper-protection status on a regular cycle, and track the remediation of any device that drops out. Wazuh inventory reports can show installed software versions across endpoints so drift is visible between audits.
What buyers ask about Safeguard 10.1 cost, time and effort
What drives the cost of deploying anti-malware under CIS Safeguard 10.1?
The cost is driven mostly by the number and type of enterprise assets, the licensing model of the anti-malware product, and how much of the asset inventory and configuration work must be done first. Endpoint count, server count, operating system mix and whether assets are on premises, in the cloud or at remote sites all change the effort. Licensing for commercial endpoint protection is usually recurring, while agent packaging, deployment and exception handling are mostly one-time work that recurs only when assets change. Ask any partner to split the quote into one-time setup, licensing you buy directly, and ongoing support, so you can compare options on like terms.
Can our own team deploy anti-malware on every asset without a partner?
Yes, many organizations do this in-house, provided they can produce an accurate list of assets and keep it current. Safeguard 10.1 is measured by coverage, the share of assets with properly configured, authorized anti-malware installed, so the hard part is knowing what the assets are. The CIS Controls Assessment Specification lists Safeguards 1.1, 2.1 and 4.1 as prerequisites, which means an asset inventory, a software inventory and a secure configuration process should exist before coverage can be measured credibly. A partner adds the most value where those prerequisites are missing or where several platforms must be unified.
What skills and staff time does a Safeguard 10.1 rollout require?
The work needs people who own the asset inventory, people who administer endpoint and server platforms, and someone who can read coverage reports and act on gaps. Staff time concentrates in the first deployment cycle, when agents are packaged, tested against business applications and rolled out in waves. After that the effort shifts to reviewing assets that report no agent, handling exceptions for systems that cannot run standard agents, and checking that the agent itself stays healthy. Plan for change control around each wave, because anti-malware agents can conflict with line-of-business software or with other security tools.
How long does it take to put anti-malware on all enterprise assets?
The timeline depends on the size of the estate, how complete the asset inventory already is, how many operating systems and locations must be covered, and how much testing each rollout wave needs. Organizations with a reliable inventory and standard builds can move faster than those discovering assets during the project. Ask for a written schedule that ties each phase to an asset group, a test result and a coverage report, and confirm the dependencies on inventory and configuration work before accepting any date.
Is an open-source stack enough to meet Safeguard 10.1 and produce evidence?
An open-source stack can produce the evidence Safeguard 10.1 relies on, but it must be assembled carefully. The coverage measure needs a trustworthy asset list, so tools such as GLPI for asset management and Wazuh Syscollector for installed software inventory are useful starting points. Osquery can query running processes and file hashes across hosts, and Velociraptor can collect artifacts from groups of systems. Confirm each product's capability for your platforms, and confirm that the detection engine you choose meets the protection level your risk assessment requires. Open-source tooling supports the evidence trail, but the protection itself depends on the anti-malware product you deploy.
Will an auditor accept an open-source approach to Safeguard 10.1 coverage?
An auditor or assessor tests whether the control operates and whether the evidence supports it, not which brand of tool you used. The organization owns the control, so the question is whether coverage reports are complete, reproducible and tied to an authorized asset list. Auditors commonly ask for the coverage calculation, exception records, configuration baselines and proof that agents are running on sampled assets. Confirm with your auditor which framework they are assessing against, since CIS Controls mappings to frameworks such as ISO/IEC 27001:2022 and SOC 2 are maintained by CIS in the Navigator, but the acceptance decision belongs to the assessor.
What should we ask a partner to include in a Safeguard 10.1 quote?
Ask for a fixed scope that lists the asset classes and platforms covered, the prerequisites the partner expects you to have in place, and the deliverables for each phase. The quote should state what is handed over, such as configuration baselines, deployment runbooks, coverage reporting and training, and what remains your responsibility. Ask who holds the licensing, how exceptions are approved, and what ongoing support is included or offered as a retainer. If a partner offers to certify or attest to your compliance, that is outside their role, because only an independent auditor or certification body issues reports or certificates. If you are choosing a provider in a CIS-specific context, note that CIS Controls Accreditation applies to CIS SecureSuite member organizations and lists application fees of $1,500 for CREST members and $2,500 for non-members.
How DeployOpen scopes and prepares Safeguard 10.1 evidence
DeployOpen works on Safeguard 10.1 as an implementation partner: we help plan, deploy and document anti-malware coverage on the client's own infrastructure, and the client owns the control. We prepare systems and evidence for review, while independent assessors and auditors decide whether the requirement is met.
How we scope
- Agree in writing which enterprise assets, operating systems and environments fall inside the Safeguard 10.1 coverage scope.
- Confirm the prerequisite inventories from Safeguards 1.1, 2.1 and 4.1 exist before deployment work starts.
- Define the coverage measure the client will report, such as the share of assets with authorized anti-malware installed.
How we build
- Deploy and configure the agreed anti-malware platform on the in-scope assets within the client's own cloud, data center or air-gapped network.
- Identify and report unmanaged or misconfigured endpoints so gaps appear in the coverage figure before an assessment.
- Test the deployment on representative assets and record the configuration baseline the client approves.
How we hand over
- Deliver documentation of the deployment, configuration, coverage queries and responsibilities for each role.
- Provide evidence packages that show coverage results over time, with the exported data and the query definitions used to produce them.
- Walk the client's security and compliance staff through the evidence so they can answer assessor questions themselves.
How we support
- Keep the deployment current through upgrades and configuration changes when a retainer covers ongoing support.
- Re-run coverage checks on a schedule the client agrees, and flag drift from the approved baseline.
- Support the client's own assessment readiness work, while the independent auditor or certification body issues any report.
