Safeguard 9.7: Deploy and Maintain Email Server Anti-Malware Protections

Safeguard 9.7 requires you to deploy anti-malware protections on email servers (or your cloud email service) and keep those protections operating as intended through continuous updates, monitoring, and response. To operationalize it quickly, standardize inbound/outbound malware scanning, attachment and URL controls, alerting, and evidence capture tied to your email platform’s control points. ¹

Key takeaways:

• Email anti-malware must be deployed and maintained on the email server path, not just on endpoints. ²
• “Maintained” means updates, logging/alerting, and operational checks you can prove in an audit. ³
• Your fastest win is to map the safeguard to one owned control and set recurring evidence capture from the email security console. ¹

Safeguard 9.7: deploy and maintain email server anti-malware protections requirement is a control-operations problem disguised as a tooling decision. Many organizations already have some email security in place (cloud email filtering, secure email gateway, built-in malware scanning), but fail on two exam-critical points: (1) coverage across all mail flows and (2) proof that protections stay enabled, updated, and monitored over time.

CIS Controls v8 is a framework, not a law, but it is frequently used as an assessment baseline by customers, regulators’ exam teams in cybersecurity-adjacent reviews, and third parties during due diligence. Your job as a Compliance Officer, CCO, or GRC lead is to translate “deploy and maintain” into a control that has an owner, a defined operating cadence, measurable checks, and durable evidence.

This page gives requirement-level implementation guidance you can apply whether you run on Microsoft 365, Google Workspace, or an on-prem email stack. The goal: reduce malware delivery via email (attachments, links, and payloads) and be able to demonstrate control effectiveness with clean, repeatable artifacts. ¹

Regulatory text

Framework requirement (excerpt): “CIS Controls v8 safeguard 9.7 implementation expectation (Deploy and Maintain Email Server Anti-Malware Protections).” ¹

Operator interpretation:
You must implement anti-malware protections at the email server or email service layer so malicious attachments, links, and known-bad payloads are detected and blocked (or quarantined) before they reach users. Then you must keep those protections effective through ongoing maintenance: updates, monitoring, and evidence that the control stays enabled and works as designed. ¹

Plain-English interpretation (what the requirement really asks)

Implement malware defenses where email enters and leaves your environment, then run them like a production control:

• Coverage: All domains, all mailboxes, all inbound and outbound paths that matter (including third-party relays and marketing platforms if they can send as you).
• Prevention: Scan attachments and message bodies, detonate or analyze suspicious files when available, and block or quarantine by policy.
• Detection: Log and alert on malware detections and policy changes.
• Maintenance: Keep signatures/engines/configuration current and verify the control is continuously enabled. ¹

Who it applies to

Entity types: Enterprises and technology organizations using email for business operations. ¹

Operational contexts where auditors will test this hard:

• Cloud email (Microsoft 365 / Google Workspace) with native security controls and optional add-ons.
• Secure Email Gateway (SEG) in front of cloud or on-prem email.
• On-prem email servers (Exchange or other) with anti-malware agents and transport rules.
• Hybrid setups with split delivery, journaling, or third-party routing.
• Third parties that can send email “as you” (CRM, marketing automation, ticketing, payroll), because they expand the email threat surface even if they are not your primary mailbox provider.

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

1) Define scope and mail flow (don’t skip this)

Create a simple mail-flow diagram and an inventory list:

• Accepted domains.
• Primary email platform(s).
• Inbound gateways/relays.
• Outbound relays/smarthosts.
• Third-party senders authorized to use your domains.
• Special flows: journaling, encryption gateways, legacy SMTP devices (MFPs), scanners.

Output artifact: “Email System Data Flow + Control Points” (one-page is fine).

2) Choose the enforcement point(s) for anti-malware

Pick one of these common patterns, then document it:

• Cloud-native controls in the email service (preferred for operational simplicity).
• Dedicated SEG (inline) scanning before delivery.
• Hybrid (SEG plus cloud controls) if you need layered policy or legacy routing.

Decision rule for GRC: If you cannot show that every inbound path is scanned before delivery, you do not meet the spirit of 9.7 even if endpoints have EDR.

3) Configure baseline anti-malware protections

Set and document baseline controls in the email security admin console/gateway:

• Enable inbound anti-malware scanning for attachments and message bodies.
• Enable block/quarantine actions for detected malware.
• Turn on scanning for common compressed formats you allow (zip variants), and block file types you do not need for business.
• Configure URL and attachment reputation controls if available in your platform.
• Apply policies to all users by default; handle exceptions with named groups and approvals.

Practical policy stance: Default-deny uncommon executable formats via email. Allow by exception with business justification and compensating controls.

4) Add “maintain” mechanics: updates, monitoring, and change control

Audits are lost here. Maintenance needs a repeatable operating rhythm:

• Auto-updates: Ensure signatures/engines are vendor-managed or automated; disable “manual update only” modes where possible.
• Alerting: Route malware detections and admin policy changes to your SOC queue or ticketing system.
• Change control: Require tickets/approvals for changes to malware policies, allow-lists, and bypass rules.
• Health checks: Schedule an administrative review that confirms protections are enabled, applied to the right scope, and generating logs.

Daydream-friendly approach: Map the safeguard to one control statement (“Email anti-malware protections are enforced on all inbound mail flows and monitored for detections and policy changes”) and set recurring evidence capture from the email security console exports or screenshots. This aligns with the recommended best practice to map 9.7 to documented control operation and recurring evidence capture. ¹

5) Handle exceptions without breaking the control

You will need allow-lists and bypasses. Make them governable:

• Allow-list requests must include requester, business reason, duration, and scope (sender, domain, IP, attachment type).
• Approvals by Security (and Compliance if regulated content is involved).
• Time-bound exceptions with automatic expiry.
• Quarterly review of allow-lists/bypasses with removal of stale entries.

6) Test effectiveness in a safe way

Do not “test with real malware.” Instead:

• Validate that the policy is enabled and applied to a test mailbox group.
• Send benign test files that are commonly flagged (for example, password-protected archives) to confirm policy behavior aligns with your configuration.
• Confirm alerts create tickets and logs are searchable.
• Validate quarantine release workflow and end-user reporting process.

7) Operationalize incident response hooks

Email malware detections should trigger predictable actions:

• Triage: identify recipients, message IDs, and whether the message was delivered.
• Containment: retract/purge messages if the platform supports it; block sender and related indicators.
• Recovery: user coaching, endpoint scan if a click/open occurred, reset credentials if indicated.
• Lessons learned: update policy (block type, tighten sandbox thresholds, reduce bypasses).

Required evidence and artifacts to retain

Auditors will accept different formats, but they want proof of design and operation:

Design evidence (static):

• Email security standard / control narrative mapped to Safeguard 9.7. ¹
• Email mail-flow diagram and scope statement.
• Configuration baselines (exported policy settings, or dated screenshots) showing anti-malware enabled and enforcement actions (block/quarantine).

Operating evidence (recurring):

• Monthly (or other defined cadence) report/export of malware detections and dispositions.
• Alert routing proof: SIEM rules, ticket samples, or notification configuration screenshots.
• Change tickets for policy updates, allow-list changes, bypass creation/removal.
• Exception register with approvals and expiry dates.
• Admin audit logs showing policy changes and administrator actions.

Retention tip: Keep evidence packaged by period (for example, by month/quarter) so an assessor can sample without rummaging.

Common exam/audit questions and hangups

Typical questions you should be ready for:

• “Show me where anti-malware is enabled for inbound email and what happens on detection.”
• “How do you know it stayed enabled all year?”
• “Do you scan outbound email or only inbound?”
• “Who can create bypass rules, and how is that approved?”
• “How do you monitor for suspicious attachments that are not malware-signature matches?”
• “How do third-party senders fit into your control scope?”

Hangups that derail assessments:

• Multiple email entry points where one path bypasses scanning.
• Overbroad allow-lists (entire domains or IP ranges) with no review.
• No evidence package; the control “exists” but cannot be demonstrated.

Frequent implementation mistakes (and how to avoid them)

1. Relying only on endpoint AV/EDR.
   Fix: Put anti-malware at the email layer and show the enforcement action before delivery.

2. Turning on scanning but not logging.
   Fix: Enable and retain admin audit logs, detection logs, and alerting. Treat logs as part of the control, not an IT nice-to-have.

3. “Temporary” bypasses that become permanent.
   Fix: Require expiry dates and recurring reviews of exceptions.

4. Ignoring outbound pathways.
   Fix: At minimum, monitor outbound for malware to reduce spread and protect your domain reputation; document your risk decision if you limit outbound controls.

5. No ownership.
   Fix: Assign a control owner (Email/Security Engineering) and a control operator (SOC), with GRC tracking evidence collection.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this safeguard. Practically, the risk is straightforward: email is a primary malware delivery channel, and weak email-layer controls increase the chance of ransomware, credential theft, and business email compromise progressing past initial access. Your defensibility improves when you can show consistent operation, controlled exceptions, and monitoring tied to response.

Practical 30/60/90-day execution plan

First 30 days (stabilize and scope)

• Confirm email platforms, domains, and all mail-flow entry/exit points.
• Pick the enforcement point (cloud-native, SEG, or hybrid) and document the control narrative mapped to Safeguard 9.7. ¹
• Enable/verify inbound anti-malware scanning, quarantine actions, and logging.
• Stand up an exception workflow for allow-lists and bypasses.

Next 60 days (operationalize and prove it)

• Route detections and admin policy changes into tickets/SIEM.
• Define a recurring control check (owner attestation plus config snapshot/export).
• Produce your first evidence pack: configuration baseline + detection reports + example tickets + exception register.
• Run a tabletop for email malware response and update runbooks.

By 90 days (make it durable)

• Reduce bypass risk: expire and clean up allow-lists; tighten file type policies.
• Validate coverage for third-party senders and outbound routes.
• Automate evidence capture where possible (scheduled exports, API pulls, or console reporting).
• Put Safeguard 9.7 into your control monitoring calendar so it does not depend on individual memory.

Frequently Asked Questions

Does Safeguard 9.7 require a dedicated secure email gateway?

No. The safeguard is outcome-based: anti-malware protections must exist on the email server path and be maintained. Cloud-native email security can satisfy the requirement if it covers all mail flows and you can prove ongoing operation. ¹

If we have EDR on every laptop, do we still need email server anti-malware?

Yes for this safeguard. Endpoint controls help, but 9.7 is about email-layer protections that block or quarantine malware before it reaches users and that you can monitor and evidence. ¹

What evidence is usually enough for an assessor?

Provide a policy/config baseline showing anti-malware is enabled, plus recurring operational proof such as detection logs/reports, alerting/ticket samples, and change records for exceptions and policy updates. ¹

How do we handle business-critical senders that keep getting blocked?

Use a formal exception with narrow scope and an expiry date, then investigate why the sender is triggering controls (misconfigured systems, compromised accounts, or risky attachment types). Avoid permanent domain-wide allow-lists unless you document risk acceptance and compensating monitoring.

Do we need outbound anti-malware scanning to meet 9.7?

The safeguard text focuses on deploying and maintaining email server anti-malware protections; many programs include outbound controls to reduce propagation and protect recipients. If you limit outbound scanning, document the rationale, scope, and compensating controls so the decision is auditable. ¹

How can GRC track this without becoming the email admin?

Treat it as a mapped control with an owner/operator, then collect recurring evidence on a fixed schedule. Daydream-style workflows work well here: control mapping, assigned owners, and consistent evidence capture from the email security console. ¹

Footnotes

1. CIS Controls v8; CIS Controls Navigator v8

2. CIS Controls v8

3. CIS Controls Navigator v8