Safeguard 9.6 Block unnecessary file types: requirements and evidence

What Safeguard 9.6 requires at the email gateway

If you run an IG2 or IG3 enterprise, Safeguard 9.6 asks you to show that email attachments of file types your business does not need never reach users. The requirement is about the gateway: unneeded file types that try to enter through your email path should be blocked before a mailbox receives them. In practice, an assessor will want to see a rule set on the mail gateway that names the permitted types, a rule that refuses everything else, and records that show the rule is active across the mail flow. The Safeguard sits in the Network asset class and the Protect security function, so the evidence belongs with your network and email infrastructure rather than with endpoint configuration alone.

The risk is familiar. Executables, scripts, installers and macro-enabled Office documents are common carriers for malware and for initial access, and a user who opens one on a laptop has already crossed the perimeter. Blocking these types at the gateway removes a delivery route before anyone has to make a judgment call. The harder part is that the allowed-type list is a business decision, not a technical one. Finance may need spreadsheets with macros, engineering may exchange compressed archives, and vendors may send signed installers. Each exception weakens the control, so the list needs an owner, a documented justification and a review cycle. Confirm with your email platform owner which types it can block by content and extension, since detection by true file type differs from detection by file name.

Start by asking three questions: who approves changes to the allowed list, how exceptions are recorded and expire, and whether your gateway logs each blocked attachment so you can prove the rule works. Those answers become the evidence your assessor will ask for. If any answer is unclear, resolve it before you choose tooling, because a gateway rule without an owner and a log will fail review even when it blocks correctly.

Which email flows and systems does Safeguard 9.6 cover

Safeguard 9.6 is measured against the mail that reaches the enterprise through its gateway, so the first job is deciding which flows, platforms and relays sit behind that gateway. The cards below cover the decisions that change the workload, and the inventory and configuration data that the measurement depends on.

Inbound mail as the primary scope

Safeguard 9.6 is about unnecessary file types that try to enter through the email gateway, so inbound mail from external senders is the core of the scope. Confirm which accepted domains and MX records route external mail to the gateway, and whether any inbound path bypasses it. A mail flow that skips the gateway is outside the control's reach until it is closed or brought into scope.

Outbound mail and internal relay traffic

Whether outbound mail is in scope depends on how the enterprise defines the gateway and its policy. Many organizations focus on inbound attachments, but internal senders can still deliver files to external recipients or to partners. Record the outbound path and decide with the control owner whether the same file type rules apply, then document that decision so the assessor can test it.

The gateway as the enforcement point

The gateway is where the blocking rule is applied and where the metric is read. Identify every device, appliance or service that inspects and forwards mail, including any secondary gateway used for failover. Confirm the blocked file type list is enforced on the gateway itself and is not a setting that a mail client can override. Keep the gateway configuration in version control so changes are traceable.

Cloud versus on-premises mail platforms

A cloud mail service may provide its own attachment filtering, while an on-premises server may depend entirely on a separate gateway. Determine which layer performs the blocking, who administers it, and whether the rule set is the same across both. If the cloud platform blocks file types natively, export its policy as evidence and confirm whether it applies to every mailbox, shared mailbox and connector.

Mail relays and connectors

Mail relays, smart hosts, application connectors and scanning appliances can forward messages without passing through the main gateway. Printers, line-of-business applications and scanners often send mail through a relay, which may carry attachments the gateway never inspects. List every relay and connector in the asset inventory, then check that each one either routes through the blocking control or is documented as an approved exception.

Web downloads and file shares

Web downloads and file shares carry files into the enterprise without email, so they fall outside Safeguard 9.6 as written. Confirm this boundary with the control owner and record it in the scope statement, because an assessor will ask where those paths are addressed. Related controls such as Safeguard 9.7 or Control 10 may address them, and the scope statement should name them so the boundary is clear.

Inventory and configuration prerequisites

The assessment specification lists Safeguards 1.1 and 4.1 as prerequisites because they produce the data the measurement needs. Safeguard 1.1 supplies the enterprise asset inventory that shows which mail servers, relays and gateways exist. Safeguard 4.1 supplies the documented secure configuration process that shows how blocking rules are set and changed. Without both, the coverage figure cannot be reliably produced.

How an assessor tests Safeguard 9.6 coverage

The CIS Controls Assessment Specification (CAS) for v8.1 defines three measures for Safeguard 9.6, and those measures are combined into a single coverage metric. The CAS describes what to measure, not how to measure it, so the assessor's first request is usually for the data that feeds those measures. It names Safeguards 1.1 (enterprise asset inventory) and 4.1 (secure configuration process) as prerequisites because they typically produce that data. Without an inventory of the email gateways and mail domains in scope, the coverage denominator cannot be established.

Gateway inventory: A list of every inbound mail path in scope, including cloud mail gateways, on-premises relays and any direct-to-mailbox routes that bypass them.
Blocked type list: The current file type rules at each gateway, with the date and the approver for each rule.
Configuration baseline: The documented secure configuration process from Safeguard 4.1, showing how gateway rules are set, reviewed and restored.
Coverage calculation: The organization's own working of the metric, so the assessor can reproduce the result.

Confirm the exact measure definitions in the CAS for v8.1 before building the evidence pack, since the wording of each measure governs what an assessor will count.

How to implement file type blocking step by step

This sequence turns Safeguard 9.6 from a policy statement into a gateway configuration that blocks unneeded file types, backed by a documented allowlist, test results, an exception record and block logs an assessor can review.

Confirm which mail flows reach the gateway
Start from the enterprise asset inventory that Safeguard 1.1 calls for, and from the secure configuration process in Safeguard 4.1, which typically supply the data this measurement needs. List every inbound and outbound mail path, including mail servers, cloud mailbox services, relays and any third-party senders routed through the gateway. The output is a mail flow diagram tied to named gateway instances. Done when every inbound path is shown to pass through a filtering point, and any bypass is recorded for remediation.
Document the business need for each file type
Working with the business owners of mail-based workflows, record which file types arrive by email for a legitimate purpose, such as specific document, image or archive formats, and which have no business use. Assign an owner to each category and note the reason it is needed. The output is a file type register with a justification and owner per entry. Done when every type on the register has a stated need or is marked as unneeded.
Set blocked and allowed lists on the gateway
Translate the register into gateway policy. Block the file types with no business need, including executable and script formats, and allow only the types that have an approved need. Check detection behavior for renamed and nested files, since extension-based rules alone can be bypassed. The output is an exported policy configuration and a signed allowlist approved by the security owner. Done when the policy is in version control and the approval is on record.
Test the policy with known samples
Build a test set of sample messages containing blocked types, allowed types, renamed files and archives containing blocked content, then send them through each mail path confirmed in step one. Record expected and actual results. The output is a dated test log with pass or fail for each case. Done when every blocked sample is stopped, every allowed sample is delivered, and any failure has a fix and a retest recorded.
Define the exception process with approvals
Write a short procedure for requests to deliver a blocked file type. The requester states the business reason and the sender, the security owner approves or rejects, and any approved exception is time-limited and reviewed. The output is a written exception procedure and an exception register with approver names and review dates. Done when a sample request can be traced from submission to decision and back into the allowlist if it becomes permanent.
Monitor blocks and review them on a set cycle
Enable logging for every blocked and released message, route those logs to the central log platform described under Control 8, and review them against the register. Look for new file types, repeated blocks from one sender and exceptions that never expired. The output is a review record showing what was examined, what changed and who signed off. Done when each review cycle produces a record, and changes feed back into the policy and the test set.

Evidence that shows file types are blocked

An assessor testing Safeguard 9.6 Block unnecessary file types will want to see the decision, the configuration, the proof that it works and the record of who was allowed past it. The cards below cover the artifacts that connect those four parts, and how to keep each one current between assessments.

Written file type policy

The policy states which file types the enterprise does not need through email, who owns that list and when it was last reviewed. Record the owner by role and name, and set a review date that matches your change cycle. The Safeguard's measure depends on the blocked list being defined somewhere, so an unwritten or stale list leaves the gateway configuration without a basis. Check that the policy names the file types and matches the gateway rules exactly.

Gateway configuration export

Export the attachment and file type rules from the email gateway on a dated schedule and store the export with the policy. Include the rule order, the match criteria (extension, true file type and archive contents where the product supports them) and the action taken. Confirm with your vendor which of these the export captures, because a screenshot of one console page rarely shows the full rule set.

Benign sample test results

Send harmless test files for each blocked type through the gateway and record whether each one was stopped. Use files that carry no payload, such as a text document renamed to the blocked extension or an empty archive, so testing does not create real risk. Keep the sender, timestamp, file name, expected result and actual result for each test. Rerun the tests after each rule change, because a passing test from last year does not show that today's rule still works.

Block logs over a sample period

Collect gateway logs that show blocked attachments across a sample period and confirm that the recipient, sender, file type and action appear in each entry. Assessors look for evidence that blocking happens in production, not only in a test. Retain the logs for the period your audit requires and confirm the vendor's default retention before you rely on it. Filter out false positives so the sample shows real enforcement.

Exception register with approvals

Record every request to allow a blocked file type, with the business reason, the requester, the approver, the scope (users, mailboxes or groups), the expiry date and the compensating control. An exception with no expiry tends to become a permanent gap. Review the register on the same cycle as the policy and remove exceptions that are no longer needed. Assessors often sample this register first.

Change records for rule updates

Keep a change ticket for every edit to the gateway file type rules, showing the requester, the approver, the date applied and the test results that followed. Linking each change to the policy version it implements lets an assessor trace a rule back to its approved basis. Also record who has administrative access to the gateway, since a silent rule change is the most likely way the control fails without anyone noticing.

What blocking unnecessary file types costs to meet

This table breaks down the cost components of meeting Safeguard 9.6 and marks which items are one-time and which recur. No prices are given because none are supplied, so use the drivers and quote items to compare proposals. The main takeaway is that most of the cost comes from gateway capacity, policy upkeep and exception handling rather than from the blocking rule itself.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it and what to request in a quote
Gateway licensing or existing mail security capacity	Mail security vendor or internal IT for existing licenses	Recurring (subscription) or none if capacity exists	Mail volume and attachment size. Ask whether file type blocking is included in the current license tier and what capacity it assumes.
Policy design and file type inventory	Internal engineering or an implementation partner	One-time, with periodic review	Number of business units and the file types they actually exchange. Ask for the written scope of the inventory and the blocklist or allowlist deliverable.
Engineering time for rule testing	Internal mail administrators or a contracted engineer	One-time per change, plus retesting after upgrades	Number of gateway policies and whether a staging environment exists. Ask how test messages are generated and who signs off.
Exception handling effort	Internal service desk and security approvers	Recurring	Frequency of legitimate requests for blocked types and the approval steps. Ask how exceptions are logged, time-limited and reviewed.
Evidence upkeep	Internal compliance or security staff	Recurring, usually tied to review cycles	Number of rule changes, log retention settings and report format. Ask what gateway logs and rule exports the quote includes.
External review or assessor time	Independent assessor or auditor, who is paid by the organization	Recurring at each assessment cycle	Assessment scope and sample size. Only an independent assessor issues findings, so ask the assessor for its fee basis in writing.
Implementation partner support	Implementation partner, under a fixed written scope	One-time, with optional retainer for ongoing support	Number of gateways, integration with self-hosted mail systems and documentation depth. Ask for deliverables, timelines and exclusions in writing.

Who owns the policy, the configuration and the assessment

Your organization owns Safeguard 9.6. That means deciding which file types the business genuinely needs to receive by email, approving exceptions, and accepting the residual risk of anything allowed through. No partner or auditor can make those business decisions for you, and a control owner who cannot explain the reasons behind the file type list will struggle in any assessment interview.

Policy decisions: Define the list of blocked file types and the business reasons for each entry.
Exception approval: Name who can approve an exception, what justification is required and how long it lasts.
Ownership: Assign a named control owner and a backup who reviews the list on a set schedule.
Exception records: Keep a dated log of approvals, the requesting business owner and the expiry or review date.
Acceptance of risk: Record who signs off on allowed file types that carry known risk, such as macro-enabled documents.

Check that the policy names owners, approvers and review dates, and that someone outside the security team can explain why each blocked type is blocked.

Where file type blocking usually falls short

File type blocking looks finished once a rule exists on the gateway, but most gaps appear in the decisions around the rule: why each type is blocked, which mail domains it covers, what happens inside archives and whether anyone tests it. Each card below names one gap and the action that closes it for Safeguard 9.6 Block unnecessary file types.

No documented business justification

Blocked types often trace back to a vendor default or a rule copied from an earlier gateway, and nobody can say why each type is on the list. Safeguard 9.6 is about blocking types the enterprise does not need, so the need has to be recorded. For each blocked and each allowed type, record the owner, the business reason and the date of the last review. Ask the security team to show the record for three types chosen at random.

Blocking applied to some domains only

A rule may apply to the primary mail domain while acquired brands, legacy domains or regional tenants still accept the same attachments. Each accepted domain is a path around the control. Export the list of accepted domains from every mail flow and compare it with the domains covered by the file type policy. Any domain outside the policy needs either the same rule or a documented exception.

Archives carrying blocked files

A blocked executable inside a ZIP, 7z or ISO container may pass a gateway that inspects only the outer file name. Users then extract the payload on their endpoint. Check whether the gateway unpacks nested archives, how deep it looks and what it does when it cannot open an archive. Where the gateway cannot inspect a container, decide whether to block the container type or to quarantine it for review.

No evidence of testing

A rule that has never been tested cannot be shown to work, and an assessor will ask for proof. Send test messages with each blocked type, including renamed files and double extensions, through every mail flow. Keep the messages, the gateway logs showing the block action and the date of the test. Repeat the test after each gateway policy change.

Exceptions that never expire

A temporary allowance for one vendor or one department often remains in place for years, and the list of exceptions grows without review. Each exception should name the approver, the user group, the file type, the business reason and an expiry date. Review open exceptions at a fixed interval and remove any that lack a current reason. Ask for the exception register and check how many entries have passed their stated expiry.

Rules not tied to the asset inventory

File type policy depends on knowing which mail servers, gateways and mail clients the enterprise runs. A new gateway or a cloud mailbox added without the policy leaves a gap that nobody notices. Use the asset inventory from Safeguard 1.1 and the secure configuration process from Safeguard 4.1 as the checklist for each mail system, and confirm the file type rule is present on every one before it carries mail.

Questions buyers ask about Safeguard 9.6

Does IG1 require blocking unnecessary file types at the email gateway?

No. CIS Controls v8.1 assigns Safeguard 9.6 to Implementation Groups 2 and 3 only, so an enterprise that qualifies as IG1 is not expected to meet it to claim IG1 coverage. IG2 and IG3 enterprises do carry it. Confirm the assignment in the CIS Controls Assessment Specification for v8.1 before you scope your program, because the Implementation Group mapping determines which Safeguards your assessor will test. If you are IG1 today but expect to move up, plan for 9.6 as part of the next tier rather than as a current requirement.

How much effort does blocking file types take, and what drives it?

The configuration itself is usually small, but the effort depends on how much you already know about your mail flow. The main drivers are the number of mail domains and gateways, whether you have a current asset and software inventory, whether a secure configuration process already governs gateway settings, and how many business teams send or receive file types that would need an exception. Each exception adds review and documentation work. Ask any provider to break its quote into discovery, policy design, gateway configuration, testing, exception handling and evidence collection, so you can see which parts scale with your environment.

What does the team need to provide for this work?

You need someone who owns the email gateway and can change its configuration, someone who can approve the list of permitted and blocked file types, and a contact in each business area that regularly exchanges files by email. Security needs to define the policy and the exception process, and whoever runs change management needs to record approved changes. The assessment specification treats Safeguards 1.1 (enterprise asset inventory) and 4.1 (secure configuration process) as prerequisites because they typically supply the data the measurement needs, so the team should confirm that both exist or plan to build them first.

Can we implement Safeguard 9.6 in-house?

Often yes, if your team already runs the email gateway and maintains a documented configuration baseline. An in-house team has to produce the policy, configure blocking rules, test that blocked file types are actually stopped and that approved ones pass, and keep evidence of each measure. Outside help is most useful when the gateway is a platform your staff have not operated before, when mail flows are complicated, or when you need someone to prepare evidence for an assessment. Whatever the split, the organization owns the control. An implementation partner prepares systems and evidence, and only an independent assessor or auditor issues any report.

How long does it take to block unnecessary file types?

No duration is supplied for this Safeguard, so treat any timeline as something to confirm in writing rather than assume. The schedule depends on how quickly the policy is approved, how many gateways and domains need configuration, how many business exceptions need review, and whether the prerequisite inventory and configuration process already exist. A fixed-scope engagement sets the timeline in a written plan before work starts, so ask for the milestones, the dependencies on other teams and the point at which evidence is complete.

What will the assessor sample when testing Safeguard 9.6?

The CIS Controls Assessment Specification defines three measures for Safeguard 9.6, which are combined into one coverage metric. In practice, an assessor will ask to see the documented list of unnecessary file types, evidence that the gateway enforces that list across the mail flows in scope, and a sample of blocked messages or logs showing the rule in action. Expect to show how exceptions are approved and recorded. Confirm the exact measures with the Assessment Specification itself, because the wording determines the evidence you should keep.

How does Safeguard 9.6 map to NIST SP 800-53 SI-3, SI-8 and PCI DSS 5.4.1?

The CIS Controls Navigator for v8.1 links Safeguard 9.6 to NIST SP 800-53 Rev. 5 controls SI-3 and SI-8, and to PCI DSS v4.0 requirement 5.4.1. These mappings tell you where the same evidence may count toward other frameworks, but they do not make your controls compliant with those frameworks on their own. Each assessor decides whether a control meets its own requirements. Check the Navigator entries directly and ask your assessor to confirm how they will accept the evidence for each framework you are subject to.

Does blocking file types replace malware scanning on email servers?

No. Safeguard 9.6 addresses file types that the enterprise does not need, so they are blocked before they reach users. Safeguard 9.7 is a separate IG3 Safeguard covering anti-malware protection on email servers, such as attachment scanning or sandboxing. The two complement each other, and an assessment of one does not satisfy the other. Plan and evidence them separately so each has its own owner, policy and measures.

How DeployOpen prepares file type controls and evidence

DeployOpen scopes file type blocking for Safeguard 9.6 in a fixed-scope written agreement before any work starts. The scope names the email gateway or gateways in use, the mail domains and routing paths they handle, the file types the client has decided to block, and the systems that will hold the evidence. The client decides which file types are unnecessary for its business, since that decision is a risk-based choice the organization owns, not something an implementation partner can make on its behalf. Deliverables, the environment, and the acceptance criteria are written down so the client and DeployOpen agree on what done means before configuration begins.

DeployOpen then implements and documents the blocking rules inside the client's own infrastructure, whether that is a self-hosted mail gateway in the client's cloud account, data center or air-gapped network. The work covers the attachment policy itself, the rule order, logging of each block, and the change records that show who approved each rule and when. Because Safeguard 9.6 is measured against the asset inventory and secure configuration process (Safeguards 1.1 and 4.1, per the CIS Controls Assessment Specification), DeployOpen also checks that the mail servers being covered are on the inventory and that their configuration baselines are recorded. Testing uses sample messages with blocked and permitted attachment types, and the results are kept with the configuration.

The evidence pack DeployOpen prepares for the client's assessor typically includes the approved file type policy, exported gateway rules, test results, sample block logs, and a coverage view that shows which mail routes are protected. Coverage is the single metric the assessment specification uses for this Safeguard, so the pack is organized around it. DeployOpen does not issue audit reports, attestations or certifications. Only the client's independent assessor, auditor or certification body can conclude whether the Safeguard is met. Prices are not published; a quote follows from the written scope, and the client should ask for its scope, deliverables, exclusions and the process for changes in writing.