Safeguard 10.6: Centrally Manage Anti-Malware Software

To meet the safeguard 10.6: centrally manage anti-malware software requirement, you must run anti-malware (or EDR) from a central console that can deploy agents, enforce policy, push updates, and report coverage and health across all in-scope endpoints. Operationalize it by standardizing on one managed platform, integrating it with your asset inventory, and producing recurring coverage/exception evidence. ¹

Key takeaways:

• Central management is the control; “installed on laptops” is not enough. ¹
• Auditors will look for measurable coverage, policy enforcement, and exception handling, not screenshots. ¹
• Your fastest path is a documented operating cadence: deploy, enforce, monitor, remediate, evidence. ¹

CIS Safeguard 10.6 focuses on a practical problem: anti-malware tools drift out of alignment when each device is managed locally. Endpoints miss updates, policies differ by team, and there is no reliable way to prove coverage during an assessment. Central management fixes that by making anti-malware a governed service with standard policy, monitored health, and consistent reporting across your environment. ¹

For a Compliance Officer, CCO, or GRC lead, the goal is straightforward: define what “centrally managed” means for your organization, ensure it is true for all in-scope assets, and retain evidence that the control operates continuously. The work is less about picking a tool and more about making the tool provable: scope, required configurations, onboarding and offboarding, exception process, monitoring and response, and periodic attestation using data from the management console. ¹

This page gives requirement-level implementation guidance you can hand to endpoint/security operations and audit-readiness owners to execute quickly, with a clean evidence trail and predictable audit outcomes aligned to CIS Controls v8 and the CIS Controls Navigator v8 listings for Safeguard 10.6. ²

Regulatory text

Excerpt (as provided): “CIS Controls v8 safeguard 10.6 implementation expectation (Centrally Manage Anti-Malware Software).” ¹

Operator meaning (what you must do):

• Put anti-malware (often delivered as next-gen AV or EDR) under a central management plane so you can deploy, configure, update, and monitor endpoints consistently. ¹
• Demonstrate coverage and health from a single authoritative source (the console and its reporting exports), and remediate endpoints that fall out of compliance. ¹

Plain-English interpretation

You pass Safeguard 10.6 when you can answer, with evidence, these questions from one place:

1. Which endpoints are required to run anti-malware/EDR?
2. Are they enrolled and actively reporting to the central console?
3. Are updates, detections, and policy settings controlled centrally?
4. When endpoints drift, do you detect and fix the gap through a defined process? ¹

Local-only anti-malware configuration, ad hoc installs, or “we think most machines have it” fail the intent because they do not produce reliable enterprise control or repeatable proof. ¹

Who it applies to

Entity scope: Enterprises and technology organizations adopting CIS Controls v8 as a security baseline, including regulated organizations that map CIS Controls to other obligations. ²

Operational scope (typical in-scope assets):

• Corporate endpoints: Windows/macOS laptops and desktops
• Servers (on-prem and cloud instances) when they run an endpoint agent
• Privileged admin workstations and jump hosts
• VDI and persistent cloud desktops
• High-risk groups (executives, finance, engineers with production access) ¹

Common scoping decisions you must document:

• Whether Linux servers require an EDR agent or alternative compensating controls
• Whether mobile devices are covered by MDM security controls instead of endpoint anti-malware
• How you treat BYOD and contractor devices (block access, require VDI, or enforce enrollment) ¹

What you actually need to do (step-by-step)

1) Define “centrally managed” in your control statement

Write a control narrative that is testable:

• Single approved anti-malware/EDR platform(s)
• Central console is the system of record for enrollment, policy, and health
• Devices must check in on a defined cadence (state the cadence in your standard; keep it consistent with tool capabilities)
• Minimum required policies: real-time protection, tamper protection, update behavior, scan behavior, alerting, and quarantine/response actions ¹

Deliverable: Control description + scope statement + roles and responsibilities (Security Ops owns platform; IT owns deployment; GRC owns evidence and exceptions). ¹

2) Establish authoritative inventory alignment

Central management only works if you can detect missing endpoints.

• Pick an authoritative asset inventory source (CMDB, endpoint management, directory, or asset tool).
• Reconcile it with the anti-malware console device list.
• Create a “coverage gap” report: assets in inventory not present (or inactive) in the console. ¹

Practical tip: Make this reconciliation routine-owned. If it lives only in spreadsheets on one person’s laptop, it will not survive turnover or audits.

3) Standardize deployment and onboarding

You need a repeatable onboarding path for each platform:

• For endpoints: package and deploy via endpoint management (Intune/Jamf/SCCM or equivalent).
• For servers: bake agent install into golden images and provisioning pipelines.
• For remote devices: ensure off-network install path exists (VPNless enrollment, cloud-managed agent, or comparable method). ¹

Minimum acceptance criteria: a device is not “compliant” until it appears in the central console and reports healthy status.

4) Enforce centrally controlled policy baselines

Create policy baselines for:

• Real-time protection enabled
• Cloud-based protection / reputation (if used) and configured
• Automatic signature/engine updates
• Scheduled scanning behavior (if used) aligned to performance constraints
• Tamper protection enabled and restricted to authorized admins
• Alert routing to an operational queue (SIEM/SOAR/ticketing) ¹

Control design rule: endpoint users should not be able to disable protection without an approved exception.

5) Configure monitoring, alerting, and response workflow

Central management implies continuous oversight:

• Define health states (active, stale, out-of-date, policy drift, agent missing).
• Create alerts for stale check-ins, disabled protection, and failed updates.
• Route alerts to ticketing with clear SLAs owned by IT/SecOps (your internal SLAs do not need external citations; document them and follow them). ¹

Operational handoff: IT restores agent health; Security triages detections; GRC validates evidence and exceptions.

6) Build an exception process that does not break reporting

Some systems cannot run agents (legacy OT, specialized appliances).

• Require documented exception request with business justification, risk sign-off, and compensating controls.
• Tag exceptions so they remain visible in coverage metrics.
• Time-box exceptions with review dates and revalidation. ¹

7) Evidence capture and recurring attestation

Audits tend to fail on “we have the tool” because teams cannot prove ongoing operation. Set a recurring evidence cadence:

• Export device coverage and health reports from the console.
• Export policy compliance reports (which endpoints match the baseline).
• Retain alert samples and tickets showing remediation actions. ¹

Daydream fit (earned): If your GRC program struggles to keep evidence consistent across quarters, Daydream can map Safeguard 10.6 to a documented control operation and schedule recurring evidence capture so you do not rebuild the same proof package for every assessment. ¹

Required evidence and artifacts to retain

Keep evidence that proves central management, coverage, and operation:

• Control narrative for Safeguard 10.6 with scope, owners, and enforcement approach ¹
• Architecture diagram or written description showing endpoints → management console → alerting/ticketing flow
• Console exports (PDF/CSV) showing:
  • enrolled endpoints
  • last check-in / agent status
  • signature/engine update status
  • policy assignment and policy compliance
• Baseline policy configuration (screenshots are acceptable if paired with exports; prefer exports and configuration snapshots)
• Deployment records (endpoint management deployment profiles, scripts, server build docs)
• Exception register with approvals and compensating controls
• Incident/ticket samples: detection alert → ticket → remediation notes → closure ¹

Common exam/audit questions and hangups (what assessors press on)

Auditor question	What they want	What to show
“How do you know every endpoint has protection?”	Reconciled coverage, not assumptions	Inventory vs console gap report + remediation tickets 1
“Can users disable it?”	Enforcement, tamper controls	Policy settings + admin role restrictions 1
“How do you handle stale devices?”	Operational cadence	Health report + alerting rules + closure evidence 1
“What about servers and cloud workloads?”	Defined scope, consistent rollout	Scope statement + agent deployment approach + coverage exports 1
“What about exceptions?”	Governance and compensating controls	Exception workflow + approvals + review dates 1

Frequent implementation mistakes and how to avoid them

1. Mistake: treating installation as compliance.
   Fix: require “reports to central console” as the compliance gate, and measure stale check-ins. ¹

2. Mistake: multiple unmanaged consoles across business units.
   Fix: consolidate to one enterprise tenant or formally managed multi-tenant model with centralized reporting and ownership. ¹

3. Mistake: no reconciliation with asset inventory.
   Fix: produce a repeatable gap report and make it part of endpoint operations. ¹

4. Mistake: exceptions in email threads.
   Fix: maintain a controlled exception register with approvals and compensating controls. ¹

5. Mistake: evidence is screenshots only.
   Fix: keep exports that can be re-performed and validated; add tickets that show action over time. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this safeguard, so you should treat this as a control expectation used in assessments and maturity evaluations rather than a standalone enforcement hook. ¹

Risk-wise, failure modes are predictable: unmanaged endpoints drift out of date, detections are missed, and you cannot prove coverage during audits or customer security reviews. Central management reduces operational risk by making gaps observable and fixable through a defined workflow. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Publish the Safeguard 10.6 control narrative: scope, platform, owners, and what “centrally managed” means internally. ¹
• Confirm the management console is authoritative and access is role-based.
• Document baseline policies and required agent health states.
• Stand up a first-pass inventory-to-console reconciliation and identify missing/stale endpoints. ¹

Next 60 days (drive coverage and operational workflow)

• Roll out standardized deployment for all endpoint types (corporate endpoints first, then servers).
• Implement alert routing to ticketing and assign remediation ownership.
• Start exception workflow and migrate legacy exceptions into a register.
• Produce the first repeatable evidence bundle (console exports + sample tickets). ¹

By 90 days (prove repeatability)

• Make reconciliation and evidence capture recurring (same report, same owner, same storage location).
• Add QA checks: spot-check endpoints for policy drift and admin override paths.
• Run an internal mini-audit: can GRC reproduce evidence without Security Ops “walking them through” the console? ¹

Frequently Asked Questions

Does EDR count as “anti-malware” for Safeguard 10.6?

The safeguard focuses on centrally managed protection; many organizations meet the intent with an EDR platform that includes malware prevention and centralized policy/reporting. Your control narrative should define the selected technology and how you prove central management. ¹

Can we use more than one anti-malware tool?

You can, but you need centralized management and consistent reporting across the in-scope fleet. If multiple tools create blind spots or inconsistent policy enforcement, auditors will treat that as a control weakness. ¹

What’s the minimum evidence to keep for an assessment?

Keep console exports proving enrollment/health and policy compliance, plus at least a few tickets that show remediation of stale or noncompliant endpoints. Add an exception register for assets that cannot run the agent. ¹

How do we handle contractors or BYOD endpoints?

Decide whether you will require enrollment into the central console, restrict access to managed VDI, or block access to sensitive systems. Document the decision as part of scope and enforce it through access controls and onboarding workflows. ¹

What do auditors mean by “centrally managed” in practice?

They mean you can push policy and updates from a central console and report coverage and health without relying on local device settings. If users can disable protection or devices can fall out of date without detection, central management is not operating. ¹

How do we operationalize recurring evidence without burning Security Ops time?

Define a standard evidence package (specific exports + ticket samples) and a recurring collection owner. Tools like Daydream help by mapping Safeguard 10.6 to a documented control operation and scheduling recurring evidence capture tied to the requirement. ¹

Footnotes

1. CIS Controls v8

2. CIS Controls Navigator v8