Safeguard 10.1: Deploy and Maintain Anti-Malware Software

Safeguard 10.1: deploy and maintain anti-malware software requirement means you must standardize on anti-malware protection, install it across in-scope enterprise assets, keep it current, and prove it stays enabled and reporting. Operationalize it by defining scope, enforcing deployment through centralized tooling, monitoring health/coverage, and retaining repeatable evidence for audits. ¹

Key takeaways:

• Scope first: define which endpoints/servers/cloud workloads must run anti-malware, including exceptions with compensating controls. ²
• Centralize: manage deployment, configuration, updates, and alerts from a single console tied to asset inventory. ³
• Evidence wins exams: keep coverage reports, policy settings, update status, alert handling records, and exception approvals on a cadence. ²

Safeguard 10.1 sits in the “Malware Defenses” control family and is a requirement you can operationalize quickly if you treat it like an engineering rollout with compliance-grade receipts. The exam risk is rarely that you “don’t own an AV tool.” It’s that protection is inconsistent across asset types, update hygiene is unclear, alert handling is ad hoc, and you cannot prove sustained operation without scrambling for screenshots.

This page translates the safeguard 10.1: deploy and maintain anti-malware software requirement into an implementable control you can map into your GRC system, enforce through IT operations, and defend during audits. You’ll get a practical interpretation, applicability boundaries, step-by-step execution, and an evidence plan designed for repeatable collection.

CIS Controls is a framework, not a law, but many internal security programs, customer security requirements, and third-party risk reviews expect alignment. Your job as CCO/GRC lead is to turn “we have anti-malware” into “we can demonstrate coverage, currency, and response across the fleet,” with clear exceptions and accountability. ¹

Regulatory text

Excerpt (provided): “CIS Controls v8 safeguard 10.1 implementation expectation (Deploy and Maintain Anti-Malware Software).” ¹

Operator interpretation of the text

• You must deploy anti-malware software broadly, not selectively. That implies defined scope, standardized tooling, and a mechanism to push/install at scale. ²
• You must maintain it. In practice this means: the agent stays installed, stays enabled, stays updated, and produces actionable telemetry/alerts that someone reviews. ³
• You must be able to prove it. CIS assessments and customer due diligence commonly fail on missing evidence of ongoing operation, not on tool selection. ²

Plain-English requirement

Put an anti-malware capability on every in-scope endpoint and server, manage it centrally, keep signatures/engines current, and monitor health so you can detect where protection is missing or broken. Then retain evidence that shows coverage and maintenance over time. ²

Who it applies to

Entity types

• Enterprises and technology organizations implementing CIS Controls v8 as a security baseline. ²

Operational context (what to include in scope)

• Corporate endpoints: laptops, desktops, VDI sessions, privileged workstations.
• Servers: on-prem and cloud IaaS instances.
• Supported OS variants in your environment (Windows, macOS, Linux), plus high-risk “specials” (jump boxes, bastions).
• Cloud workloads where an endpoint agent is feasible, or where you use a provider-native equivalent that meets the intent (document this as a mapped control). ³

Common scoping decisions you must make

• What counts as “anti-malware” in your environment (EDR with malware prevention, classic AV, or both).
• Whether bring-your-own-device is excluded (if excluded, define access restrictions and compensating controls).
• How you handle ephemeral assets (autoscaling groups, CI runners) so protection is present at build time or enforced at runtime.

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

1) Define the control in control language (one page)

Write a control statement that answers:

• Purpose: prevent/detect malware on enterprise assets.
• Scope: asset categories and ownership boundaries.
• Standard: approved anti-malware platform(s) and minimum required features (real-time protection, updates, tamper protection, alerting).
• Roles: IT/SecOps owns deployment and monitoring; GRC owns evidence and exception governance.
• Frequency: continuous enforcement with recurring reporting and review. ²

Deliverable: “Anti-Malware Standard & Operations Procedure” mapped to Safeguard 10.1. ²

2) Build an authoritative in-scope asset list

You cannot prove coverage without a denominator.

• Pull device/server inventory from your asset inventory/CMDB/MDM and reconcile duplicates.
• Tag in-scope assets (endpoint, server, production, privileged) to support coverage reporting.
• Identify “dark assets” (unmanaged devices) and decide whether to onboard or block. ²

Deliverable: in-scope asset register export + logic for inclusion/exclusion.

3) Standardize on tooling and configurations

Pick a primary anti-malware platform per platform type, then document baseline settings:

• Real-time protection on.
• Automatic updates on (engine and definitions).
• Cloud-delivered protection or equivalent, if used.
• Tamper protection enabled (where supported).
• Central logging/telemetry enabled, routed to your SIEM/SOAR if you have one. ³

Deliverable: configuration baseline (policy) and a change-control path for modifications.

4) Enforce deployment via centralized management

Execution methods that usually pass audits:

• Endpoints: deploy via MDM/UEM, device management, or software distribution.
• Servers: deploy via configuration management, golden images, or cloud-init.
• New builds: bake the agent into base images and require it in build pipelines. ²

Minimum operational requirement: you can show that installation is not “best effort,” but enforced by standard build and device management.

5) Implement health monitoring and coverage reporting

Set up monitoring for:

• Agent installed and checked in.
• Protection enabled.
• Signature/engine update status.
• Devices not reporting within a defined internal threshold (your policy should define what “stale” means).

Create a repeatable report:

• Coverage % by asset class (endpoints, servers, production).
• Exceptions list (approved and time-bound).
• Noncompliant list with remediation owner and status. ²

6) Define alert triage and escalation

Anti-malware without response becomes shelfware.

• Define what constitutes a security incident vs. routine hygiene.
• Assign an on-call or queue owner for detections.
• Require ticketing for significant detections with containment steps, root cause notes, and closure. ³

7) Create an exception process that auditors will accept

You will have exceptions (OT, legacy systems, vendor-managed appliances). Make them safe and auditable:

• Written justification (technical constraint).
• Compensating controls (network segmentation, application allowlisting, restricted internet egress, enhanced monitoring).
• Approval by risk owner.
• Expiration date and review trigger. ²

8) Evidence capture: make it recurring, not manual

A practical pattern:

• Monthly (or your chosen cadence): export coverage/health reports and archive them.
• Per-change: archive baseline policy settings and approvals.
• Per-incident: archive detection tickets and post-incident notes.
• Quarterly (or your cadence): management review sign-off of metrics and exceptions. ²

If you use Daydream to run compliance operations, treat this as a mapped control with scheduled evidence requests to IT/SecOps and automated reminders so your audit binder builds itself over time, not the week before an assessment.

Required evidence and artifacts to retain

Keep artifacts that prove design, implementation, and operation:

Design

• Anti-Malware Standard / control narrative mapped to Safeguard 10.1. ²
• Configuration baseline (policy settings) with change history. ³

Implementation

• Deployment method documentation (MDM package assignment, server automation job, base image recipe).
• Approved tool list and licensing/entitlement proof (contract or admin console screenshot).

Operation

• Periodic coverage/health reports showing in-scope assets vs protected assets.
• Update compliance reports.
• Alert/detection logs and associated tickets.
• Exception register with approvals, compensating controls, and expiry reviews. ²

Common exam/audit questions and hangups

Auditors and assessors tend to ask:

• “Show me your complete inventory of in-scope devices and how you confirm anti-malware coverage.” ²
• “How do you ensure the agent stays enabled and up to date?” ³
• “What happens when a device stops checking in or is missing protection?” ²
• “Show exceptions. Who approved them, and what compensating controls exist?” ²
• “Demonstrate operation over time, not just today.” Bring dated exports. ²

Hangups that create findings:

• No denominator (no trustworthy in-scope asset list).
• Point-in-time screenshots only.
• Exceptions handled in email/Slack without a register.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Relying on “installed” status only	Agents can be disabled or stale	Track enabled status + last check-in + update status. 2
Servers treated as out of scope	Attackers target servers for persistence	Put server coverage in the same reporting model as endpoints, even if tooling differs. 3
No plan for ephemeral assets	Autoscaling/CI hosts can launch unprotected	Build agent into images and validate at startup; block deploy if missing. 2
Exceptions have no expiry	Exceptions become permanent holes	Time-box exceptions and re-approve with evidence of constraints. 2
Alerts don’t map to tickets	No proof of response	Require ticket linkage for detections above your defined severity threshold. 2

Risk implications (why operators care)

Anti-malware coverage gaps increase the likelihood that common malware, commodity loaders, and post-exploitation tooling persist undetected on endpoints and servers. The compliance failure mode is predictable: a single unprotected or stale system becomes the sample an auditor or customer assessor asks about, and you cannot show preventive coverage or operational monitoring. Safeguard 10.1 is “medium” severity in many programs because it is foundational hygiene, but gaps tend to cascade into incident response, reporting, and customer trust issues. ²

Practical 30/60/90-day execution plan

Day 0–30: Establish scope, standard, and visibility

• Write the Safeguard 10.1 control narrative and anti-malware standard, including exception rules. ²
• Produce an authoritative in-scope asset list and reconcile with anti-malware console inventory.
• Define baseline policy settings and turn on centralized logging/alerting. ³
• Create the first coverage/health report and open remediation tickets for gaps.

Day 31–60: Enforce deployment and operational response

• Roll out agent via MDM and server automation; bake into base images for new builds. ²
• Stand up health monitoring for non-reporting/stale agents.
• Implement alert triage workflow: queue ownership, ticket templates, escalation path. ³
• Start the exception register with approvals and compensating controls.

Day 61–90: Prove sustained operation and make it audit-ready

• Run recurring evidence capture (coverage reports, update compliance, exception reviews). ²
• Perform a tabletop review of a recent detection (or a test detection) to validate ticketing and containment notes.
• Prepare an audit packet: control narrative, baseline settings, last several report exports, and sample tickets mapped to detections.
• If you use Daydream, configure scheduled evidence collection tasks so each period’s exports and approvals land in the right control record without manual chasing.

Frequently Asked Questions

Do we need anti-malware on every server, including cloud instances?

For Safeguard 10.1, treat servers as in scope unless you have a documented exception and compensating controls. If you use a different approach for certain workloads, document how it meets the intent and retain evidence. ²

Is EDR enough, or do we also need traditional antivirus?

CIS 10.1 is outcome-focused: deploy and maintain anti-malware software. If your EDR provides malware prevention and you can prove it is deployed, enabled, updated, and monitored, it can satisfy the requirement; document the features you rely on. ³

How do we handle legacy systems that break when we install an agent?

Put them into a formal exception register with risk-owner approval and compensating controls such as segmentation and restricted admin access. Set an expiration and track a remediation plan (upgrade, isolation, or replacement). ²

What evidence is most persuasive to an auditor?

Dated coverage/health exports tied to a complete in-scope asset list, plus the baseline policy configuration and a small sample of detection tickets with closure notes. Point-in-time screenshots alone usually trigger follow-up questions. ²

What does “maintain” mean in practice?

Maintain means the software remains installed, enabled, and current, and that detections are reviewed and acted on. Your operating model should show monitoring for stale/non-reporting agents and a process for remediation. ²

We outsource IT. Who owns Safeguard 10.1?

You still own the control outcome. Your third party can operate the tool, but your organization should set requirements (coverage, updates, reporting), receive recurring reports, and approve exceptions. ²

Footnotes

1. CIS Controls v8; CIS Controls Navigator v8

2. CIS Controls v8

3. CIS Controls Navigator v8