Safeguard 9.3: Maintain and Enforce Network-Based URL Filters

Safeguard 9.3: maintain and enforce network-based URL filters requirement means you must run centrally managed URL filtering at the network layer (or equivalent enforced egress point) and keep it current, so users and systems cannot reach known malicious or prohibited web destinations. Operationalize it by defining categories to block/allow, enforcing the policy everywhere users access the internet, and retaining evidence that filtering is working.

Key takeaways:

• Put URL filtering on the path to the internet (DNS, secure web gateway, firewall, or proxy) and prevent bypass.
• Maintain the filter: categories, threat feeds, exceptions, and change control must be governed and reviewable.
• Keep audit-ready evidence: policy, enforcement points, logs, exception approvals, and test results mapped to Safeguard 9.3. ¹

A URL filter is only a “control” if it actually stops traffic. Most organizations can configure category blocks in a tool within hours, then lose the security benefit because roaming endpoints bypass the corporate network, a second ISP egress exists, exceptions accumulate with no owner, or the control is never tested. Safeguard 9.3 focuses on two verbs: maintain and enforce. “Maintain” means your categories, reputation feeds, and exceptions reflect current threats and business needs. “Enforce” means you route traffic through the filtering decision point and prevent users, workloads, and third parties from going around it.

This page is written for a Compliance Officer, CCO, or GRC lead who needs requirement-level implementation guidance for safeguard 9.3: maintain and enforce network-based url filters requirement under CIS Controls v8. It assumes you will partner with Security Engineering/Network teams for implementation, but you own the control definition, governance, evidence, and assessment readiness. The goal is simple: you can explain the intended behavior, show where it is enforced, prove it works, and show how you keep it current. ¹

Regulatory text

Framework requirement: “CIS Controls v8 safeguard 9.3 implementation expectation (Maintain and Enforce Network-Based URL Filters).” ¹

Operator interpretation: You must (1) deploy URL filtering at the network boundary or egress control point(s) used for web access, (2) ensure it is consistently applied to in-scope users/systems, and (3) maintain it over time (updates, exceptions, governance) with evidence that enforcement is active and effective. ¹

Plain-English interpretation (what this control is really asking for)

URL filtering reduces the chance that users and systems reach known malicious infrastructure (phishing pages, malware delivery sites, command-and-control) and helps enforce acceptable use. For CIS Safeguard 9.3, auditors and internal stakeholders will look for three outcomes:

1. Coverage: Web-bound traffic from in-scope environments goes through an enforcement point you control (secure web gateway, firewall URL filtering, forward proxy, DNS filtering with policy enforcement, or SASE).
2. Policy: You have a documented, approved filtering policy (categories to block, allow, warn/coach, and how exceptions work).
3. Operations: You can show the filter is current, monitored, and tested, and that bypass routes are closed.

Who it applies to (entity and operational context)

This safeguard applies broadly to enterprises and technology organizations implementing CIS Controls v8. ¹

Operationally, treat these as in-scope contexts unless you explicitly document a risk-based exclusion:

• Corporate office networks and data centers with direct internet egress
• Cloud egress points (NAT gateways, internet gateways, load balancers that initiate outbound calls, managed Kubernetes egress)
• Remote users (laptops off-network) and BYOD where you allow web access to company resources
• Third-party access paths (contractors on VPN, third parties with VDI access, MSP tooling that browses externally)
• Servers and workloads that “shouldn’t browse” but still resolve and call out (package updates, telemetry, API calls)

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

Use the steps below as an implementation runbook you can hand to Network/SecOps, then use as your control narrative.

1) Define scope and enforcement points (make bypass hard)

• Inventory all internet egress points: corporate firewall(s), guest networks, branch circuits, cloud NATs, VPN concentrators, VDI, and any “temporary” circuits.
• Decide where URL filtering decisions are made:
  • Secure web gateway / proxy (central or cloud)
  • Firewall URL filtering at egress
  • DNS-layer filtering (only acceptable if you prevent alternate DNS and still have visibility/enforcement expectations met)
• Document which egress points are authoritative and which are blocked/retired.

Control test you want to pass: a user or workload cannot browse directly to the internet without traversing the filtering policy.

2) Establish the filtering policy (categories, actions, and rationale)

Create a short, enforceable policy that answers:

• What categories are blocked (malware, phishing, newly registered domains, anonymizers, illegal content, etc.)
• What categories are allowed but monitored (social media, personal email, file sharing) if relevant
• What the user experience is (block page, coaching page, silent drop)
• How TLS inspection is handled (if you do decryption, define where and for whom; if you do not, define compensating visibility)
• Who can approve exceptions and for how long

Keep it practical: a one-page policy plus an appendix listing the active category settings in your tool is usually stronger than a long narrative that nobody can map to configurations.

3) Implement technical enforcement (and close the common bypasses)

Work with Engineering to implement:

• Explicit proxy settings or transparent proxying where appropriate
• Firewall rules that force web ports through the proxy/SWG
• Egress allow-listing for servers that do not need general browsing
• DNS controls if you rely on DNS filtering:
  • Block outbound DNS to the internet except approved resolvers
  • Enforce DNS over HTTPS policies on managed browsers/endpoints if applicable
• Remote user coverage:
  • Client-based SWG/SASE agent, or always-on VPN with egress filtering
  • A documented decision for unmanaged devices (block, isolate via VDI, or accept risk with approval)

4) Put maintenance on rails (updates, reviews, and change control)

“Maintain” is where programs fail. Add operational discipline:

• Enable automatic updates for URL reputation feeds and category databases in the platform.
• Define a review cadence for:
  • Category policy (are blocks still appropriate?)
  • Exceptions (who owns them, are they still needed?)
  • Coverage (new egress points, mergers, new cloud accounts)
• Route changes through change management:
  • Ticket with requestor, business justification, approval, and expiration date for exceptions
  • Emergency change pathway with after-the-fact review

5) Monitor and respond (prove it works)

Minimum operating expectations you should require from SecOps:

• Alerts for spikes in blocked categories associated with malware/phishing
• Investigation workflow for repeated hits from a single endpoint/user
• Integration with SIEM (or platform reporting) to retain logs and trends
• A periodic control test:
  • Attempt to reach a known blocked category from a test endpoint
  • Verify block event appears in logs with user/device attribution
  • Verify bypass attempts fail (alternate DNS, direct IP browsing where feasible)

6) Map the control to evidence capture (make audits cheap)

Your GRC deliverable: a control statement that ties policy + tech + operations to Safeguard 9.3, plus a recurring evidence plan. The backend guidance explicitly calls out mapping 9.3 to documented control operation and recurring evidence capture. ¹

Practical tip: In Daydream, set Safeguard 9.3 up as a control with scheduled evidence tasks (policy export, config snapshots, exception register, sample logs, and a test record). That shifts you from “scramble before audit” to continuous readiness.

Required evidence and artifacts to retain

Keep artifacts that demonstrate design and operating effectiveness:

Governance artifacts

• URL filtering / acceptable use standard (approved, versioned)
• Scope statement: in-scope networks, remote users, cloud accounts, and exclusions with risk acceptance
• Roles and responsibilities (who administers, who approves exceptions)

Technical artifacts

• Architecture diagram showing egress points and where filtering occurs
• Tool configuration exports or screenshots:
  • Category settings
  • Policy rules (user groups, locations, networks)
  • Update settings for threat feeds
• Firewall/proxy rules that enforce routing through the filter
• DNS egress restriction rules if DNS filtering is part of the design

Operational artifacts

• Exception register (ticket IDs, approver, justification, expiration, review outcome)
• Log samples showing blocked events with timestamp and user/device context
• Monitoring/alerting runbook and at least one example alert/ticket
• Control test record (date, tester, test steps, expected vs actual result, remediation if failed)

Common exam/audit questions and hangups

Expect these questions from auditors, customers, and internal assurance:

• “Show me all internet egress points and where URL filtering is enforced.”
• “How do remote users get filtered off-network?”
• “How do you prevent bypass (direct-to-internet, alternate DNS, VPN apps, anonymizers)?”
• “Who can approve exceptions, and how do you ensure they expire?”
• “How do you keep the filter current? Show update settings and proof of maintenance.”
• “Provide evidence the control works: a block event, an alert, and a test.”

Hangups happen when you have a policy but cannot prove enforcement coverage, or when logs do not identify the user/device.

Frequent implementation mistakes (and how to avoid them)

1. Filtering only on HQ internet and ignoring remote endpoints.
   Fix: require SWG/SASE agent coverage or always-on VPN for managed devices; document the stance for unmanaged devices.

2. DNS filtering treated as sufficient while DoH and alternate resolvers remain open.
   Fix: block outbound DNS except approved resolvers; manage browser DoH settings on managed endpoints; test bypass explicitly.

3. Exceptions with no expiry.
   Fix: require an expiration date and an owner; review exceptions routinely; remove stale ones quickly.

4. Multiple egress paths created by cloud teams.
   Fix: add an egress design pattern for cloud (central egress, policy-as-code guardrails, and periodic discovery of new NAT/IGW paths).

5. No evidence plan.
   Fix: schedule evidence capture. Save config exports and log samples routinely so you can answer audits without reconstructing history.

Risk implications (why auditors care even without “enforcement cases”)

CIS Controls is a framework, not a regulator, so you usually won’t see CIS-only enforcement. The risk is still concrete: weak URL filtering increases phishing success rates, malware ingress, and data exfiltration paths. For compliance teams, the practical exposure is failing customer security reviews and internal audits because you cannot demonstrate control operation, especially for roaming endpoints and cloud egress.

Practical 30/60/90-day execution plan

Day 0–30 (Stand up and scope)

• Identify all egress points (on-prem and cloud) and remote access patterns.
• Choose the enforcement approach (SWG/proxy/firewall URL filtering/DNS filtering) and document the coverage model.
• Publish the URL filtering standard: categories, exception process, and responsibilities. ¹

Day 31–60 (Enforce and integrate)

• Route in-scope traffic through the enforcement point; close bypass routes (direct internet, alternate DNS).
• Enable logging, user/device attribution, and SIEM forwarding (or equivalent retained reporting).
• Launch exception workflow with approvals and expirations; build an exception register.

Day 61–90 (Prove operation and make it repeatable)

• Run a defined control test and retain results.
• Tune categories to reduce unnecessary business disruption without weakening security intent.
• Put maintenance on a recurring calendar: policy review, exception review, and coverage review.
• Implement recurring evidence capture in Daydream so each audit asks for exports you already collect. ¹

Frequently Asked Questions

Does DNS filtering alone satisfy Safeguard 9.3?

It can be part of an acceptable design if it is enforced (users can’t switch resolvers or use DoH to bypass) and you can produce logs and test evidence that prohibited destinations are blocked. If you cannot reliably prevent bypass, auditors will treat it as partial coverage.

How do we handle TLS inspection for URL filtering?

Decide and document where decryption is required versus where you rely on category/reputation and SNI/metadata. The audit focus is consistency and evidence: you need to show what is inspected, what is exempt, and how exemptions are approved.

What’s the minimum evidence set to keep for an audit?

Keep the approved policy, a diagram of enforcement points, a config export showing categories and enforcement rules, a sample of block logs with attribution, and an exception register with approvals and expirations. Add a control test record to prove it works in practice.

How do we cover remote employees who rarely connect to VPN?

Use an endpoint agent tied to your SWG/SASE or enforce always-on VPN for managed devices. If neither is feasible for a population, document an explicit exception with compensating controls and an owner.

What should we do about “servers shouldn’t browse the web” systems?

Treat them as higher risk for unmanaged outbound calls. Prefer egress allow-listing to known update repositories and APIs, then enforce URL filtering and logging for any remaining general web access.

How do we keep URL filtering from breaking business workflows?

Start with high-confidence malicious categories blocked, then add business-needed categories through controlled exceptions or scoped policy (group- or location-based). Track exceptions and remove them when the underlying need ends.

Footnotes

1. CIS Controls v8; CIS Controls Navigator v8