Safeguard 9.7 email server anti-malware requirements

What email server anti-malware means for your CIS Controls program

If your enterprise is in Implementation Group 3, Safeguard 9.7 asks you to deploy and maintain anti-malware protections on your email servers, such as attachment scanning, sandboxing or both. This is an IG3 Safeguard only, so it applies to organizations that already run security specialists and handle regulated, sensitive assets. Mail is one of the main routes by which malicious attachments and links reach people, and a message can reach a mailbox long before an endpoint agent sees the payload. The Safeguard moves part of that inspection to the point where mail enters or moves through your environment, so that known-bad content is stopped or quarantined before a user opens it.

The attack it addresses is simple to describe: a malicious document or archive arrives in a message, passes the sender and content checks, and lands in a user's inbox. If the only control is on the laptop, the first chance to detect the payload may come after a user has opened it, and by then the endpoint is already exposed. Email server scanning gives you an earlier decision point, and it can also hold suspicious attachments in a sandbox for behavioral analysis when signatures alone are not enough. The Safeguard does not replace endpoint protection under Control 10, and the two should be planned together.

The difficulty is usually coverage and upkeep, not installation. Hybrid mail flows mean messages may pass through an on-premises gateway, a cloud mail service, and a third-party filtering layer, and each hop needs its own scanning or a clear decision about which hop is authoritative. Scanning that was deployed during a project and then left alone tends to drift: signatures and sandbox engines fall behind, new connectors bypass the filter, and no one checks the logs. Before you scope the work, confirm with your mail platform vendor which scanning features are included in your license, which connectors are covered, and how detections are logged and reviewed, since those answers determine the evidence an assessor will ask for.

Which mail systems and teams fall under email server anti-malware scope

Safeguard 9.7 applies to every point where email is received, relayed, stored or delivered, not only the mail server with the best-known name. The cards below cover the scoping decisions that change the work, and each one should be traced back to the same asset inventory that the measurement relies on.

On-premises mail transfer agents

Any MTA that accepts inbound or outbound SMTP traffic for the enterprise falls in scope, including relays that route mail between internal systems and the internet. Confirm that each MTA is listed in the asset inventory from Safeguard 1.1 and that its configuration, captured under Safeguard 4.1, shows where anti-malware scanning sits in the message flow. A relay that skips the scanner is a gap the measurement will expose.

Mailbox and message store servers

Mailbox servers that hold delivered messages and attachments are part of the scope when they run scanning or sandboxing features of their own. Ask the mail team whether anti-malware runs at the transport layer, the mailbox layer or both, and record each setting. Scope lists often miss the mailbox tier because it is administered by a different team from the gateway.

Secure email gateways

Secure email gateways that sit in front of the mail platform are usually the primary control point for attachment scanning and sandboxing. Record the gateway model or service, its deployment mode and the policies that route messages through it. Confirm that every inbound and outbound path to the internet crosses a gateway, because a bypass rule can leave a route unscanned.

Hosted and cloud mail services

Cloud mailboxes and hosted filtering services are in scope when the enterprise relies on them for anti-malware, even though the vendor operates the infrastructure. Document which scanning features are enabled, which are licensed separately, and what the provider's configuration exposes for review. Ask the provider for evidence of its controls, and confirm the tenant or subscription appears in your asset inventory.

Relay and journaling servers

Journaling and archiving servers copy messages for retention, and relays forward them between systems. Both carry malicious content if they receive it unscanned, so decide whether each one is in scope and document the reason. Include them in the scope list, mark whether anti-malware applies, and confirm the decision with the team that owns retention.

Cross-references and ownership checks

The CIS Controls Navigator links Safeguard 9.7 to NIST SP 800-53 Rev. 5 SI-3 and SI-8, ISO/IEC 27001:2022 Annex A 8.7, and PCI DSS v4.0 requirements 5.2.1 and 5.4.1. Confirm each cross-reference in the Navigator before relying on it in an audit file, and make sure the scope list matches the asset inventory and the configuration records that support Safeguards 1.1 and 4.1.

How the assessment specification measures email anti-malware coverage

The CIS Controls Assessment Specification defines three measures for Safeguard 9.7 and combines them into one coverage metric. The specification tells an assessor what to measure, not how to build the tooling that produces the numbers. In practice, coverage asks what share of the in-scope email servers and mail paths have attachment scanning, sandboxing or both active and current. A mail path that accepts inbound messages without passing through a scanning control counts against the figure, even if the primary gateway is well configured. Your team owns the definition of "in scope" and must write it down before anyone measures anything.

The specification lists Safeguard 1.1, the enterprise asset inventory, and Safeguard 4.1, the secure configuration process, as prerequisites for measuring Safeguard 9.7. The reason is practical: the coverage denominator comes from knowing every mail server, relay, gateway and cloud mail tenant that handles messages for the enterprise. If an inventory omits a legacy relay or a shadow SMTP service, the coverage figure looks high while real inbound mail bypasses scanning. The same risk applies to configuration data. A scanner that is installed but disabled on one host, or a policy that was never applied after an upgrade, appears in the metric only if the configuration record is accurate.

Before you rely on the number, reconcile the inventory against mail routing records, DNS MX entries and firewall rules that permit port 25 traffic. Then check each measure's wording directly in the Assessment Specification, because the exact text defines what evidence an assessor will accept. Ask your assessor or the team that maintains the specification which evidence they expect for each measure. Treat the coverage metric as a reliable result only when the inventory it depends on has been verified.

How an assessor tests Safeguard 9.7 and what evidence passes

This table walks through the testing logic an assessor typically follows for Safeguard 9.7, from matching mail servers to the asset inventory through exception handling. Read each row as a question the assessor asks, the evidence they request, what a clean result looks like and where organizations most often fall short.

Test step	Evidence requested	Passing result	Common findings
Mail server inventory against asset inventory	List of all mail servers, gateways and relays, reconciled to the enterprise asset inventory (Safeguard 1.1 output)	Every mail-handling system in the inventory appears in the email server list, with a named owner and role	Cloud mailboxes or SMTP relays used by applications are missing from the list
Configuration exports showing scanning enabled	Exported configuration or console screenshots showing attachment scanning, sandboxing or both turned on for each mail server	Each server shows an active anti-malware policy that scans inbound and, where applicable, outbound messages	Scanning is set on the primary gateway but not on a secondary or failover server
Sampling of mail paths	Message trace or routing diagram for sample messages, showing which scanning engine each message passed	Each sampled mail path, including external and internal relay routes, passes through a covered scanner	A legacy route or direct-to-MX path bypasses the scanner
Signature and engine update records	Update logs, vendor release history and engine version reports for each scanning component	Signatures and engines update on a documented schedule and version reports match the vendor baseline	Update jobs show success but engines are several versions behind, or updates stopped after a certificate change
Exception handling for out-of-scope or excluded servers	Written exception register with the reason, approver, compensating controls and an expiry or review date	Each exclusion is approved, time-limited and matched by a documented compensating control	Temporary exclusions have no expiry date and are never revisited
Coverage metric review	Calculated coverage figure combining the measures above, with the calculation method	Coverage reflects the inventory and sampled paths, and the calculation can be reproduced from the source data	Coverage is reported as a single figure with no link to the inventory or sample

Implementing email server anti-malware in the order an assessor will check it

This sequence builds Safeguard 9.7 from the asset and configuration records up, so each control has a traceable inventory, a documented baseline and a coverage result that an assessor can test. Each step ends with an artifact that goes into the audit file.

Confirm the mail server and mail path inventory
Start from the enterprise asset inventory produced under Safeguard 1.1. List every mail server, relay, gateway and cloud mailbox path that accepts or forwards inbound or outbound email, including the hosts that handle internal relay. The organization owns this list, and the implementation partner can help reconcile it against network and DNS records. The step is done when each mail path has a named owner, a host or service identifier and a record in the inventory. That inventory is the denominator for the coverage check later.
Document the secure configuration baseline
Using the secure configuration process from Safeguard 4.1, write a baseline for each mail server and relay. The baseline should state the software version, the hardening settings, the TLS and relay restrictions, and the logging settings that apply to the mail service. Record who approved it and when it was last reviewed. The output is a versioned baseline document per mail path. An assessor will compare the deployed configuration against this document, so it must match what is actually running.
Choose attachment scanning or sandboxing for each path
For each mail path in the inventory, decide whether attachment scanning, sandboxing or both will apply, and record the reason. Safeguard 9.7 calls for either or both, so the choice must be documented, not implied. Consider whether the mail server is self-hosted, cloud-hosted or hybrid, because that determines where the control can sit. Confirm with the mail platform vendor which scanning and sandboxing features it supports. The output is a decision record per path that names the chosen control, the scope and the owner.
Deploy and enable the protection on each path
Install or enable the chosen anti-malware component on each mail path, following the baseline from the previous step. Enable attachment scanning on inbound and outbound traffic where the chosen design requires it, and enable sandboxing where it was selected. Verify the setting in the running configuration rather than in the vendor console alone. Keep the exported configuration as evidence. The step is done when each path shows the protection enabled in its live configuration with the export saved.
Set update and alerting rules
Define how signature or engine updates are applied, how often the service checks for them, and who receives alerts for detections, update failures and disabled protections. Route these alerts into the logging platform that Safeguard 8.2 and related Controls describe, so the events are retained and reviewable. Test one alert with a harmless test file to confirm it reaches the responder. The output is a written update and alerting rule set plus a test record showing the alert arrived.
Run a coverage check against the inventory
Compare the protected paths with the mail path inventory from the first step. Every path should show the protection as enabled, with no unlisted mail relay outside coverage. Safeguard 9.7 is measured through the CIS Controls Assessment Specification as a coverage metric built from its measures, so the check should produce a count of covered paths against total paths and list any gap. Resolve gaps or document an accepted exception with an owner. The output is a coverage report that ties each inventory entry to its protection status.
Record the result for the audit file
Assemble the artifacts from each step into the audit file: the inventory extract, the baseline, the decision records, the configuration exports, the alert test, and the coverage report. Date each item, record the owner, and note the review cycle. Store the file where the assessor can retrieve it without asking the team to rebuild it. The organization owns this file. An independent auditor or assessor, not the implementation partner, decides whether the evidence supports the control.

Evidence that shows email server anti-malware is deployed and maintained

Safeguard 9.7 is measured as coverage: whether anti-malware protection is applied to the email servers you actually run. The artifacts below connect the mail server inventory to scanning configuration, engine updates, detections, coverage reporting and documented exceptions, so an assessor can trace each email server from inventory to protection. Refresh each one on a schedule rather than assembling it at audit time.

Mail server inventory reconciled

Export the list of every system that accepts, relays or stores inbound and outbound email, including on-premises relays, cloud mail gateways and hybrid connectors. Reconcile that list against the enterprise asset inventory from Safeguard 1.1, since the CIS assessment specification treats that inventory as a prerequisite for measuring this Safeguard. Any mail server that appears in one list but not the other is a finding to resolve before coverage can be trusted. Schedule the export monthly and keep the reconciliation diff with a named owner.

Configuration exports for each path

Export the configuration of each mail path showing that attachment scanning, sandboxing or both are enabled for inbound and outbound traffic. Check each path separately, because a gateway may scan inbound mail while an internal relay or a journaling path bypasses it. Store the exports with timestamps and the change ticket that approved each setting. Re-export after every change to the mail flow and at a fixed interval so the evidence reflects the current state.

Engine and signature update logs

Collect the update history for the scanning engine, signature or reputation feeds and sandbox components on every mail server. The log should show successful updates within your defined interval and the handling of failed updates. Stale protection is a common gap: a scanner that runs but has not updated its definitions does not show that the Safeguard is maintained. Set an alert on update failures and keep the alert history with its resolution notes.

Detection records with handling tickets

Export the detections the mail protection produced over the review period, covering malicious attachments, blocked links and sandbox verdicts, and match each one to a ticket showing who reviewed it and what was done. Detection counts alone do not show that the protection works, but a detection with no recorded response is a gap. Sample a set of detections for the assessor to trace from the alert to the ticket to the user or message action taken.

Coverage report against the inventory

Generate a coverage report that compares the mail servers in the reconciled inventory against those with scanning or sandboxing enabled and current. The CIS assessment specification defines three measures for this Safeguard, combined into a single coverage metric, so the report should show each measure and the resulting percentage. Assign one named owner to produce it, set a fixed generation schedule, and retain each version so the trend across the period can be shown.

Documented exceptions with owners and dates

Record every mail server or path that lacks anti-malware protection, with the reason, a compensating control, an accountable owner, an approval and a review or expiry date. Exceptions without an expiry tend to become permanent gaps. Reconcile the exception register against the coverage report each cycle, so every uncovered server is either protected or formally excepted. An assessor will test whether exceptions are approved and reviewed, not only whether they exist.

What meeting Safeguard 9.7 costs in money and effort

This table compares the main cost components of deploying and maintaining email server anti-malware for Safeguard 9.7, showing who is paid, whether each cost is one-time or recurring, what drives it up, and how to keep it down. Use it to structure a written scope and quote request, since no figures are published here and the actual amounts depend on your mail architecture and chosen approach.

Cost component	One-time or recurring	What drives it	How to keep it down
Anti-malware license or subscription	Recurring	Number of mailboxes or domains, scanning features such as sandboxing, and vendor support tier. Confirm license terms with the vendor.	Compare commercial terms against a self-hosted open-source engine, and confirm its license terms with the project before relying on it.
Open-source engine or self-hosted infrastructure	One-time setup, then recurring hosting and updates	Server capacity for scanning peak mail volume, signature update workflow and the need for high availability.	Size for measured mail volume, automate signature updates and monitor scanner health.
Engineering time to deploy and integrate	One-time	Number of mail paths (inbound gateway, internal relay, cloud mailboxes, hybrid routing) and how many MTAs must be changed.	Map every mail path before work starts and agree the list of in-scope paths in the written scope.
Sandbox infrastructure (if sandboxing is chosen)	One-time build, recurring operation	Whether sandboxing runs on premises or in a vendor cloud, detonation capacity, and data residency constraints.	Decide early whether attachment scanning alone meets the need, and confirm sandbox data handling with the vendor.
Evidence upkeep for coverage reports	Recurring	How often coverage must be shown, the number of measures to evidence, and whether reports are generated by hand.	Automate coverage exports from mail logs and scanner consoles, and keep a fixed evidence calendar.
External testing or configuration review	Recurring or periodic	Scope of mail testing, whether bypass attempts are included, and whether an independent party reviews the configuration.	Pair internal configuration checks with a fixed-scope test rather than repeated open-ended testing.
Auditor sampling effort	Recurring, per assessment cycle	Number of mail servers and paths in scope, the sample size the assessor selects, and how clearly the evidence is organized.	Agree evidence formats with the assessor early and keep one inventory of mail paths that the sample can be drawn from.

Who does what for email server anti-malware: your team, a partner and the auditor

Your organization owns Safeguard 9.7. The Safeguard asks that anti-malware protections on email servers, such as attachment scanning, sandboxing or both, be deployed and maintained, and only your organization can decide what that means for its mail flow, risk appetite and data. Your team keeps the inventory of mail servers and gateways, makes the coverage decision for each one, approves any exception where a server cannot be covered, and is the named evidence owner when an assessor asks for proof.

Mail server inventory: Maintain a current list of every inbound and outbound mail path, including cloud mailboxes, relays and gateways, since the Safeguard's coverage measure depends on knowing what exists.
Coverage decision: Decide which scanning or sandboxing controls apply to each path and document the reasoning.
Exception approval: Record who accepts the risk of any server that is not covered, with an expiry date and a compensating control.
Evidence ownership: Keep configuration exports, scan logs and coverage reports current, and know where each artifact lives.
Dependencies: Confirm that the asset inventory (Safeguard 1.1) and secure configuration process (Safeguard 4.1) are working, because the assessment specification treats them as prerequisites.

Before engaging anyone, check that a named owner can answer each of these points for every mail path.

Where email server anti-malware programs usually fall short

Email anti-malware programs rarely fail on the product itself. They fail on coverage, upkeep and proof: which mail paths are scanned, whether engines stay current, whether sandbox verdicts get read, and whether anyone can reproduce the coverage figure. The cards below cover the gaps assessors and implementation teams see most often when they test Safeguard 9.7.

Mail paths missing from the inventory

Teams inventory the primary mailbox platform but forget the relays, smart hosts, journaling servers and archiving connectors that also receive and forward messages. Malware can reach users through any of these paths without touching the scanned gateway. Build the inventory from MX records, transport rules and connector configuration, then check each hop against the scanning policy. Confirm that the inventory feeds the coverage measure from Safeguard 1.1, since an unlisted relay cannot be measured.

Scanning enabled on some servers only

Anti-malware is often switched on for the production gateway while a disaster recovery mailbox server, a test environment or a newly added hybrid connector runs without it. Coverage then looks high in a summary and low in the detail. Compare the list of enabled scanning agents or policies against the asset list, not against a single dashboard tile. Treat any mail server without a recorded scanning policy as uncovered until proven otherwise.

Engine and signature updates that lapse

Scanning engines and signature or reputation feeds stop updating after a certificate expires, a proxy changes or a license lapses, and the server keeps reporting as protected. Set alerts on the age of the last successful update and on update failures, not only on service status. Record the update source and the update frequency in the configuration baseline so an assessor can see the expected state. Confirm the update process is covered by the secure configuration work under Safeguard 4.1.

Sandboxing without alert review

Sandboxing detonates suspicious attachments and links, then flags verdicts for review. Many programs enable the sandbox but send its alerts to a mailbox nobody checks, or set thresholds so high that malicious messages are released to users unflagged. Define who reviews sandbox verdicts, how quickly, and what happens to messages that were delivered before a later verdict changed. Keep the review record, because the reviewer's decisions are part of the evidence.

Coverage reports that cannot be reproduced

A coverage percentage is only useful if someone else can regenerate it. Many reports come from a manual spreadsheet or a console export that nobody can rerun from the current configuration. The CIS assessment measures coverage across three measures combined into one metric, so the inputs must be traceable. Store the query or script that produces the report, the date of the asset list it uses and the configuration snapshot, then rerun it before each assessment.

Exceptions without owners or expiry

Some mail servers are excluded from scanning for a vendor compatibility reason, a large attachment workflow or a legacy integration. These exceptions tend to outlive the reason for them and never reappear in review. Require each exception to name an owner, a business justification, a compensating control and an expiry date. Review the exception register at the same cadence as the coverage report, and remove any exception that has passed its date without renewal.

Questions buyers ask about Safeguard 9.7 cost, effort and outsourcing

How much effort does deploying email server anti-malware protection take?

The effort depends mainly on how many mail flows and mail servers are in scope, how the current mail platform accepts scanning engines, and how much tuning the organization needs before blocking begins. Work usually covers mapping every inbound and outbound path, choosing where attachment scanning or sandboxing sits, testing detection and false positives, and building the maintenance routine for signatures, engine updates and quarantine review. Safeguard 9.7 also depends on Safeguards 1.1 and 4.1, so an accurate asset inventory and a documented secure configuration process reduce the discovery work. Ask any provider to break the effort into discovery, build, testing and handover, with each item tied to a named mail system.

Can our own team implement Safeguard 9.7 without an outside partner?

Many teams can do it in-house if they already run their mail platform and have someone who understands both email routing and security monitoring. The gaps usually appear in sandbox tuning, in producing measurable coverage data for the assessment, and in writing the operating procedures that an assessor will sample. An implementation partner can take on system preparation, configuration, documentation and evidence collection, while your team keeps ownership of the controls and the decisions about what gets blocked. Be clear internally about who will answer for coverage gaps after the work ends.

What does the work need from the mail team and the security team?

The mail team needs to provide administrative access to the mail servers or gateway, a current map of mail routing, and time to test changes that can delay or quarantine legitimate messages. The security team needs to define what malicious attachments look like in its environment, approve the detection and response thresholds, and own alert triage for quarantined items. Both teams should agree on the metric that proves coverage, because the CIS assessment specification measures whether protections are deployed across the mail path. Set up a shared change calendar early so mail outages are not mistaken for security incidents.

How long does it take to deploy email server anti-malware protection?

The timeline follows from the written scope, so no duration applies until the scope is agreed. The main drivers are the number of mail servers and domains, whether scanning is added to an existing platform or a new engine, the time needed for sandbox and false-positive tuning, and how many approval cycles your change process requires. Maintenance then continues for as long as the mail service runs. Ask for a timeline that separates discovery, implementation, tuning and handover so you can see which steps depend on your own teams.

Does a self-hosted open-source scanning engine remove license cost?

A self-hosted open-source engine removes the software license fee for the scanning engine itself, but it does not remove the other costs. You still pay for the infrastructure that runs it, the staff time to configure, tune and maintain it, the integration with your mail platform, and the monitoring that produces evidence. Check each open-source component's license terms before deployment, because they differ between projects. Compare total effort over the life of the service, not only the initial software cost, and ask any provider to itemize these recurring costs in the quote.

Why is Safeguard 9.7 IG3 only, and what does that mean for smaller organizations?

CIS places Safeguard 9.7 in Implementation Group 3 only. CIS defines IG3 as the group for enterprises with security specialists and regulated, sensitive assets facing sophisticated, targeted attacks, so this Safeguard is not part of the baseline that CIS expects every organization to meet. Smaller organizations can still benefit from attachment scanning, and their IG1 Safeguards for browsers, DNS filtering and DMARC address much of the same email risk. If a customer or regulator asks for Safeguard 9.7 specifically, confirm the Implementation Group your organization is measured against before scoping the work.

Can a partner issue the audit result for Safeguard 9.7?

No. A partner such as DeployOpen can prepare the mail systems, configuration, documentation and evidence for Safeguard 9.7, but only the independent assessor or certification body can issue an audit report, attestation or certificate. The organization owns its controls and the decision about how they are assessed. The CIS Controls themselves do not replace any regulatory or compliance scheme, so the assessor used will depend on which scheme your contracts or regulators require. Ask any provider to state its role in writing so the assessment scope and responsibilities are clear before work starts.

How DeployOpen scopes and prepares email server anti-malware evidence

DeployOpen works on Safeguard 9.7 as a fixed-scope implementation inside your own infrastructure. We prepare the email server anti-malware systems and the evidence an assessor would need to see, while your organization keeps ownership of the controls and any independent assessor issues the conclusions.

How we scope

We agree in writing which email servers, gateways and mail flows fall inside the Safeguard 9.7 scope.
We confirm how the asset inventory and secure configuration process feed the email server records, since CIS lists Safeguards 1.1 and 4.1 as prerequisites.
We record which attachment scanning, sandboxing or both functions are in scope, and who in your organization owns each one.

How we build

We deploy or configure the chosen anti-malware engine on each in-scope email server or gateway inside your environment.
We set up signature and engine update processes and document how coverage is checked across every in-scope mail server.
We test detection with safe, controlled test samples and record whether each in-scope server applies the protection as designed.

How we hand over

We deliver configuration records, coverage reports and test results that map each measure in the assessment specification to a source.
We document the operating procedures your staff need to maintain the protections, including alert handling and exceptions.
We walk your team through the evidence set so you can explain coverage to your assessor, who forms the independent opinion.

How we support

Ongoing support, upgrades and continuous testing of the mail protections are available as a retainer.
We can refresh coverage evidence when new mail servers are added or the anti-malware product changes.
Ask any partner to confirm in writing which vendor features, versions and integrations they will rely on before work starts.