Safeguard 9.3 URL filtering: requirements and evidence

What Safeguard 9.3 URL filtering requires and why assessors look at coverage

If your organization is in Implementation Group 2 or 3 and preparing for a CIS-aligned review, Safeguard 9.3 asks you to maintain network-based URL filters that are kept current and enforced on every enterprise asset, blocking connections to websites that may be malicious or that you have not approved. The filters can work by category, by reputation or from block lists, and CIS describes the outcome rather than a product. The Safeguard sits in the Network asset class, under the Protect security function, and is assigned to IG2 and IG3 but not IG1, so an IG1 organization will not be measured against it yet. The risk it addresses is familiar: drive-by downloads that fire from a compromised page, phishing hosts that harvest credentials, and command-and-control callbacks from infected machines that try to reach an attacker's servers. The difficulty is coverage. Unmanaged devices and contractor laptops often sit outside the filter, remote users may leave the corporate path entirely, and encrypted traffic hides the destination host unless you control DNS or proxy inspection. A filter that protects the head office but not the home-working finance team does not meet the Safeguard as written.

Assessors therefore look at coverage first. The CIS Controls Assessment Specification defines three measures for Safeguard 9.3, combined into a single coverage metric, and lists the enterprise asset inventory (Safeguard 1.1), the software inventory (Safeguard 2.1) and the secure configuration process (Safeguard 4.1) as prerequisites, because the coverage calculation depends on knowing which assets exist and how they are configured. Before the review, confirm with your own team which asset list is authoritative, how remote endpoints are routed through the filter, and who owns the block list and its change records. Check the exact measures in the CIS Controls Assessment Specification for Safeguard 9.3 before you size the work.

Your assessors will not accept a filter that exists only on paper. Expect to show the enforcement point for each asset class, the settings that define categories and block lists, the update cadence for those lists, and log evidence that blocked requests were recorded. Open-source options such as OPNsense can enforce rules by source, destination, port and protocol and log rule matches, but a firewall rule set alone does not prove remote devices are covered. Treat the coverage metric as the design target, and confirm with the vendor and your own environment which URL categories, reputation feeds and remote-access paths your tooling actually supports.

Which assets, users and traffic fall in scope for URL filtering

Safeguard 9.3 applies to every enterprise asset, so scope is set by what your inventory and configuration records actually show, not by the office network diagram. The cards below cover the populations that most often fall outside a filtered perimeter and the upstream records that tell you where filtering must reach.

Remote and roaming endpoints

Laptops and phones used off the corporate network browse the web without passing through your gateway, so filtering must travel with the device or sit at a path the device always uses. Ask whether the filter enforces on home, hotel and mobile carrier connections, and whether the measurement counts devices that were off-network during the reporting period. Roaming devices are the most common gap in coverage metrics.

Enterprise asset inventory from Safeguard 1.1

The asset inventory from Safeguard 1.1 is the denominator for coverage, so an endpoint missing from it is also missing from your filtering results. Reconcile the inventory against the filter's enrolled device list and flag any asset that appears in one but not the other. Treat unknown assets as in scope until they are identified.

Software inventory from Safeguard 2.1

The software inventory from Safeguard 2.1 shows which browsers, email clients and tools make outbound web requests, including background services and non-browser applications that fetch content. Filtering that only governs a managed browser misses traffic from other software on the same host. Use the inventory to confirm which applications must route through the filter.

Secure configuration process from Safeguard 4.1

The configuration process from Safeguard 4.1 determines how the filter is applied to each asset class, including proxy settings, DNS resolver assignment and host firewall rules. Check that the build standard for each platform sets the filter path and that a deviation from that standard is detected. A device whose resolver or proxy setting was changed locally is effectively out of scope.

Guest, BYOD and unmanaged networks

Guest Wi-Fi and personally owned devices often cannot run your agent, so the filter has to sit on the network path or the cloud resolver those devices use. Decide whether guest traffic is filtered at the same policy level as corporate traffic or under a separate policy, and document the choice. Confirm which unmanaged devices can reach internal resources, because those are the ones where an unfiltered path matters most.

Cloud workloads, servers and third-party endpoints

Servers and cloud workloads fetch packages, updates and external APIs, and a compromised server can be directed to malicious sites just as a laptop can. Third-party managed endpoints, such as contractor or service provider machines connected to your environment, need a stated owner and a filtering path written into the service agreement. Confirm with each provider how their devices are filtered and how that is evidenced to you.

How an assessor tests URL filter coverage under the CAS

This table maps the three CAS measures for Safeguard 9.3 to what the assessor does, the evidence requested and the findings that usually come up. Read it as a test plan: each row shows what the assessor compares, so you can assemble the same records before fieldwork starts.

Element	What the assessor does	Evidence requested and common findings
Prerequisite inputs	Confirms the enterprise asset inventory (Safeguard 1.1), software inventory (2.1) and secure configuration process (4.1) exist and are current	Asset list and inventory exports dated near fieldwork. Finding: inventory lists devices that never appear in filter enrollment
Measure 1: asset coverage	Samples devices from the asset list and checks each is enrolled under a URL filtering control, including remote and off-network devices	Enrollment reports matched to asset IDs. Finding: laptops used off site or cloud workloads fall outside the filter
Measure 2: policy enforcement	Reviews the filter policy configuration to confirm categories, reputation thresholds or block lists are set to block, not merely log	Exported policy with categories and actions, plus change history. Finding: policy set to monitor only with no documented exception
Measure 3: list currency	Checks that block lists and category databases are updated on a defined cadence and that updates are recorded	Update logs or vendor feed timestamps. Finding: block lists last refreshed months earlier with no owner
Sampled blocked-request logs	Selects sample requests to known-bad or unapproved sites and confirms they were blocked and logged for the sampled assets	Log extracts tied to asset identity. Finding: blocked events exist but cannot be traced to a specific device
Combined coverage metric	Calculates the share of in-scope assets where all three measures are met, which the CAS reports as one coverage metric	Working papers showing numerator and denominator. Finding: the denominator omits assets, which inflates coverage
Illustrative example	An assessor samples 20 devices from an inventory of 200, finds 3 unenrolled, and records the exceptions	Ask the assessor to confirm the sampling method and sample size before fieldwork. Results depend on the environment

How to implement URL filtering in order

This sequence moves from knowing which assets and software exist to a URL filter that is enforced on every enterprise asset, tuned on a set cadence and backed by logged decisions that an assessor can sample.

Confirm the asset and software inventories
Start from the enterprise asset inventory (Safeguard 1.1) and the software inventory (Safeguard 2.1), which the CIS Controls Assessment Specification lists as prerequisites for measuring Safeguard 9.3. Your network, endpoint and cloud teams confirm which devices, browsers and browsing paths exist, including remote laptops, servers and mobile devices. Done when every device that can reach the web is either in the inventory or flagged as a gap to close before enforcement begins.
Choose the enforcement point
Decide where URL filtering will run: a cloud or on-premises URL filtering service, an endpoint agent that follows the device off the network, or policy on the firewall that sees traffic leaving the office. Most environments need more than one point because a firewall alone does not cover remote assets. The output is a short decision record naming each enforcement point, the asset classes it covers and the gaps it does not close. Confirm the chosen product's category, reputation and block-list features with the vendor before you rely on them.
Define category, reputation and block-list policy
Write the filtering policy the business will defend. Set which website categories are blocked, which reputation thresholds trigger a block, and which custom block lists cover threats your provider does not catch. Document the approved exceptions, the owner who approves each one and the expiry or review date. Security and business owners sign off. The output is an approved policy document that maps each category or list to a reason, so an assessor can see that unapproved websites are blocked on purpose.
Enforce the policy on remote and on-premises assets
Deploy the chosen enforcement to every enterprise asset, including laptops used off the network, servers that need outbound web access and any devices outside the normal path. Test with a set of known-good and known-bad test URLs from each network location and from a remote device. Record which assets were tested and which failed. The check is complete when no in-scope asset can reach a blocked category or list through any path you have documented, and every exception is traceable to an approval.
Set the update and review cadence
Assign owners for keeping category databases, reputation feeds and custom block lists current, and set a recurring review of exceptions and blocked-traffic trends. Confirm with your provider how often its categories and feeds update, and record that frequency in the procedure. The output is a calendar or ticketed schedule with named owners. Assessors look for evidence that the policy is maintained over time, not only configured once.
Log decisions and blocked connections
Turn on logging of allowed and blocked web requests, and send those logs to the central log platform covered by Control 8, including DNS and URL logs where the provider supports them. Log exception approvals and policy changes in the change record. The output is a retained log set that shows which connections were blocked, by which rule and on which asset. Confirm the retention period against your own policy, since no retention figure is set here.
Review results and feed findings back
Review blocked-traffic logs and exception requests on the cadence from the previous step, and feed patterns back into the policy and the asset inventory. Investigate blocked connections that point to compromised assets through the incident process in Control 17. Record each review with its findings, changes and owner. The output is a dated review record that shows the policy is measured and adjusted, which is the evidence the Safeguard's coverage metric draws on.

How the enforcement point decides what is blocked

A URL filter only works if the request reaches a point that can see the destination name, so the first decision is where that point sits. In a typical path, the endpoint resolves a name, opens a connection to an IP address, and sends an HTTP or HTTPS request to the destination. A filter can intervene at the DNS lookup, at the firewall that forwards the connection, at a web proxy that terminates or inspects the session, or in an agent on the device itself. Each location sees different information, and the control you choose determines whether a category or reputation decision is possible at all. Ask your vendor exactly which of these points it enforces and whether it applies to laptops that leave the office network.

A stateful packet filter such as OPNsense, whose rules match source, destination, port and protocol, is a strong tool for network segmentation and for limiting which services a host may reach. It does not, by itself, know that a particular HTTPS session is going to a phishing site or a newly registered domain. Many sites share one IP address, and encrypted traffic hides the URL path. Packet rules can still block known bad address ranges through aliases, and the rule log helps you review matches. Treat them as one layer that complements, rather than stands in for, a control that classifies web destinations.

For Safeguard 9.3, URL decisions usually come from a secure web gateway or proxy with category databases, reputation feeds and custom block lists, from a DNS-layer service that filters by domain, or from an endpoint agent that follows roaming devices. Confirm with each vendor whether it inspects HTTPS through a managed certificate, whether it can enforce policy when a device is off the corporate network, and how it logs blocked requests. Those answers decide whether the coverage measure in the assessment specification can be met for every enterprise asset, including the remote and cloud-hosted systems that a perimeter-only design misses.

Which evidence shows that URL filters are enforced and current

What evidence shows that every enterprise asset is covered by URL filtering?

An asset-to-filter coverage report is the primary artifact, because Safeguard 9.3 is measured as coverage. It lists every asset from the enterprise asset inventory (Safeguard 1.1) and shows, for each one, whether its outbound web traffic passes through a URL filter or filtering agent. The report should reconcile to the inventory, so unexplained gaps are visible. Ask your assessor which asset classes they will sample, and export the report from the same source the filter uses so the numbers match. Refresh it on a schedule you define in your own documentation, and keep prior versions so you can show trend between audits.

What should a URL filter policy export contain for an assessor?

The export should show the active categories or reputation thresholds, the block lists in use with their sources and versions, the allow lists, and the policy rules that bind them to user groups or asset groups. An assessor needs to see that the policy blocks malicious or unapproved sites and that the approved exceptions are listed, not hidden in rule logic. Export the configuration in a readable format and date-stamp it. Between audits, schedule an automated export and compare it with the previous one, so unplanned policy changes stand out.

How do you prove that block lists and categories are updated?

Keep an update history that records when each category feed or block list was refreshed, which source supplied it, and whether the refresh succeeded. Pull this from the filter's update logs or the feed provider's change records. Gaps in the history are the finding an assessor is most likely to raise, so alerting on failed or stale updates is worth configuring. Between audits, review the history monthly and document any failure, the response and the date the filter caught up.

What does a sample of blocked and allowed decisions prove?

It shows that the filter makes decisions in practice, not only on paper. Assessors typically ask for a sample of logged decisions across different asset groups, including blocked requests to known-bad or unapproved sites and allowed requests to approved destinations. Each entry should show the time, the asset, the requested URL or domain, the category or list that drove the decision, and the action taken. Pull the sample from your own logs so it can be traced back to the policy export. Between audits, retain decision logs for the period your own retention policy sets and confirm that your log platform can search them quickly.

How do you show that remote users are filtered too?

Remote and roaming devices must be covered, so the proof needs to come from the remote path: an endpoint agent, a filtering client, or traffic routed through a filtering gateway when the device is off premises. Show a decision log entry or coverage record for a device that was off the office network at the time. Confirm with your filtering product how remote enforcement works, because capabilities differ and the method must match your architecture. Test it periodically with a device on an external network and keep the result.

What exception approval records do assessors expect to see?

Every allow-list entry or policy exception for a site that would otherwise be blocked needs a record showing who requested it, the business reason, who approved it, the date, the scope (which users or assets), and an expiry or review date. Assessors test whether exceptions follow the documented process and whether they are reviewed. Keep the records in your change or ticketing system and link each exception to the matching policy entry. Between audits, run a periodic review that removes expired exceptions and records the outcome.

Can an internal team gather this evidence without outside help?

Yes, most of these artifacts come from the filter, the asset inventory and the ticketing system, so an internal team with access to them can produce them. The effort usually lies in making the exports repeatable, reconciling the coverage report with the asset inventory and setting up alerts for stale updates. Outside help is useful when the architecture is unfamiliar or the evidence set must be designed before an audit. DeployOpen prepares systems and evidence for compliance assessments under a written, fixed scope, but the organization owns its controls and an independent auditor issues any report. Confirm your evidence requirements with your assessor before building anything.

What meeting Safeguard 9.3 costs in money and effort

This table lists each cost component of running network-based URL filtering under Safeguard 9.3, who is paid for it, whether it is one-time or recurring, and what drives it up or down. Use it to structure a quote request and to see where open-source tooling reduces license spend while engineering effort stays in the budget.

Cost component	Who is paid	One-time or recurring	What drives the cost
URL filtering service or license	Filtering vendor or cloud provider, or no fee for self-hosted open source	Recurring (subscription or support), with a one-time setup if a vendor is chosen	Number of enterprise assets, remote user share and category or reputation feeds purchased
Engineering time to deploy proxies or agents	Internal platform team or implementation partner under a written scope	One-time, with later changes as the estate grows	Mix of on-premises, cloud and remote endpoints, and how many agents or proxy paths must be built
Block list and policy management	Internal security or network team	Recurring, as categories, feeds and approved sites change	Number of approved-site exceptions, frequency of feed updates and the change approval process
Exception handling and review	Internal security and business owners	Recurring, usually tied to a review cycle	Volume of blocked-site requests and how quickly they must be decided and documented
Log retention and storage	Storage or SIEM provider, or internal infrastructure team	Recurring, scaling with retention period	Log volume per asset, retention period set for URL logs and whether logs are centralized
Coverage reconciliation	Internal asset management and security operations staff	Recurring, at each review of the asset inventory	Accuracy of the Safeguard 1.1 asset inventory and the Safeguard 2.1 software inventory, which feed the coverage metric
Assessor sampling and evidence preparation	Independent assessor or auditor for testing, internal staff for evidence	Recurring at each assessment cycle	Number of assets and sites sampled, and how readily the coverage and filter evidence can be produced
Open-source filtering stack	Internal or partner engineers, with no license fee for the software itself	One-time build, plus recurring patching and tuning	Engineering skill on hand, the number of sites needing filter rules and how much testing is required per change

Which open-source tools can support URL filter evidence

OPNsense is a stateful packet filter. Its rules pass, block or reject traffic by source, destination, port and protocol, so it can enforce the network-layer part of Safeguard 9.3 by stopping connections from enterprise assets to destinations you have listed. It keeps a record of those decisions, which gives assessors something to test. It does not classify websites by category or reputation, so it cannot stand in for a URL filtering service on its own.

Address and port rules: Rules match on source, destination, port and protocol, which lets you block direct paths to destinations that are not approved.
Aliases for destination lists: Aliases group addresses into named sets that many rules can reference, so a maintained block list lives in one place.
Rule-match logging: You can log individual rule matches and review them in the live log view, which produces evidence that a rule ran.
Scope limits: Without a category or reputation feed, your team maintains destination lists by hand, and websites that change addresses need ongoing review.

Review the OPNsense documentation on rules and test in your own environment to confirm whether any URL category or reputation feed is available in your version or through a plugin before you assume it.

Where URL filtering programs usually fall short

URL filtering rarely fails in the product itself. It fails in the places around it: devices that never reach the filter, inventories that disagree with enrollment, lists nobody refreshes, and exceptions nobody reviews. Each card below names one gap that an assessor is likely to test under Safeguard 9.3 and the fix that closes it.

Remote devices bypass the filter

Filters placed on the office network stop seeing traffic the moment a laptop leaves the building, connects over home Wi-Fi or uses a private DNS resolver. Safeguard 9.3 asks for enforcement across every enterprise asset, so coverage has to follow the device. Check whether roaming endpoints route through a cloud or agent-based filter or a VPN that sends their web traffic through the enterprise filter, and test it from an off-network laptop by requesting a known test category.

Inventory and enrollment drift apart

The filter console lists the devices that enrolled, while the asset inventory lists the devices that exist. Machines that are in the inventory but missing from the filter are unprotected, and filter entries for retired hardware can hide the gap. Reconcile the two sources on a fixed schedule, using the enterprise asset inventory from Safeguard 1.1 as the reference, and treat any inventory asset without filter enrollment as an exception to fix or document.

Stale block and category lists

Malicious and newly registered domains appear daily, so a block list that was accurate at deployment becomes a weak control within months. Safeguard 9.3 requires the filtering to be kept current. Confirm who owns list updates, which feeds the vendor refreshes and how often, and whether the team can see the date of the last successful update. A list that has not changed in a long period is a finding to explain, not a sign of stability.

Uncontrolled allow exceptions

Help desk staff and application owners often add allow rules to restore a business tool quickly, and those rules outlive the reason for them. Over time an allowlist can override the block categories that the policy was written to enforce. Require each exception to name an owner, a business reason, an approver and an expiry date, then review the full exception list on a schedule and remove entries that no longer have a reason.

Filter logs not retained

Blocked and allowed requests are the evidence that the control operated, and they are also the first place investigators look after a suspected compromise. Many consoles keep logs for a short rolling window by default. Confirm the retention period in your configuration, forward logs to the central log platform, and confirm that DNS and URL records from remote devices reach that platform, not only those from the office network.

Policy that lives only in the console

When the category choices, exception rules and review cadence exist only as settings in a vendor console, no one can show an assessor what was approved or who approved it. The configuration can also drift without a record. Write the URL filtering standard as a document, map each category to the business decision behind it, store the exported configuration under version control, and tie each change to a ticket that an approver signed off.

Questions buyers ask about URL filtering and Safeguard 9.3

Does Safeguard 9.3 apply to IG1 organizations?

No. CIS places Safeguard 9.3 in Implementation Groups 2 and 3, not IG1. IG1 is the essential cyber hygiene baseline that every enterprise should meet, while IG2 adds Safeguards for organizations with more operational complexity that often hold sensitive information, and IG3 covers regulated, sensitive environments facing sophisticated, targeted attacks. An IG1 organization can still choose to filter URLs, and DNS filtering under Safeguard 9.2 is the IG1 starting point for many teams. Confirm your Implementation Group against the CIS Implementation Groups page before scoping the work.

What effort does enforcing URL filtering on all enterprise assets involve?

The effort depends less on the filter product than on how complete your asset data is. Safeguard 9.3 requires enforcement on every enterprise asset, so the work starts with an accurate asset inventory (Safeguard 1.1), a software inventory (Safeguard 2.1) and a documented secure configuration process (Safeguard 4.1), which the CIS Controls Assessment Specification lists as prerequisites. The main work areas are:

Choosing a filtering method: category, reputation or block lists, or a combination
Routing every asset through the filter, including remote and off-network devices
Maintaining the lists and approved-site exceptions over time
Logging blocked and allowed requests so the coverage metric can be evidenced

Ask your partner to size each area in the written scope.

Can we implement URL filtering in-house?

Often yes, if the team already runs firewalls, DNS infrastructure and endpoint management and has someone who owns the policy. The harder part for most teams is not the first deployment but the ongoing work: keeping category and block lists current, handling exceptions, and proving coverage across every asset. Open-source options such as OPNsense, a stateful packet filter with aliases and per-rule logging, can enforce network rules, and Coraza can protect web applications you publish. Confirm that your chosen platform supports the filtering and logging you need, since capabilities differ between tools. A partner can take on platform build, integration and evidence collection while your team keeps ownership of the policy.

What should we ask a partner to include in a quote for Safeguard 9.3?

Ask for a written scope that names each deliverable and the assets it covers. A useful quote lists:

The asset populations in scope and how remote devices are handled
The filtering method and the platform components to be built or configured
How block lists are maintained and who approves exceptions
The logs and reports that will evidence coverage for the CAS metric
What is one-time (design, deployment, documentation) and what recurs (list maintenance, upgrades, monitoring)
What the client must provide, such as inventory exports and network access

DeployOpen works from a written scope agreed before work starts, so ask for the same level of detail from any provider you evaluate.

How long does implementing Safeguard 9.3 take?

The duration depends on the number of assets, the state of your inventories and how many network paths must be covered, so no general timeline applies. Your partner's written scope should give the schedule for each deliverable, and you should confirm it against your own environment, including change windows and approval steps. Inventory gaps are the most common source of delay, because the enforcement metric cannot be shown for assets that are not yet known. Ask for milestones tied to asset coverage rather than a single completion date.

How does Safeguard 9.3 map to ISO 27001 A.8.23 and PCI DSS 1.4.2?

The CIS Controls Navigator for v8.1 links Safeguard 9.3 to ISO/IEC 27001:2022 Annex A control 8.23 (web filtering) and to PCI DSS v4.0 requirement 1.4.2. These links are CIS's mappings, so cite them as CIS mappings rather than as independent assessments. Mapping to a framework does not mean one control satisfies the other: an assessor for ISO 27001 or PCI DSS will test against that standard's own requirements and evidence. Confirm the current mapping in the Navigator and ask your assessor how they will accept the evidence.

Who is responsible for proving that URL filtering works?

The organization owns its controls and its evidence. An implementation partner prepares the filtering setup, documentation and evidence, but only an independent auditor or assessor issues an audit report or certification. For Safeguard 9.3, your evidence will typically show the filtering policy, the coverage of enterprise assets, and logs of blocked and allowed requests, all of which should map to the measures the CIS Controls Assessment Specification defines for this Safeguard.

How DeployOpen prepares URL filter evidence for Safeguard 9.3

DeployOpen plans and implements self-hosted open-source URL filtering inside the client's own infrastructure, then prepares the evidence that the organization can present for Safeguard 9.3. The work is fixed-scope: the systems in scope, the filtering categories and block lists, the enforcement points and the deliverables are agreed in writing before any configuration begins. The organization remains the owner of its controls and its policy on which website categories are approved. DeployOpen does not issue audit reports, attestations or certifications. An independent assessor or certification body makes that determination, and it is the organization's decision which assessor to engage.

Coverage is the metric the assessment specification combines its measures into, so the evidence has to show that every enterprise asset is covered by the filter, not only the devices that were convenient to configure. DeployOpen documents the enforcement design: which network paths and remote access routes send traffic through the filter, how Network assets are mapped to filtering policy, and how the asset inventory and software inventory feed the scope, since Safeguards 1.1, 2.1 and 4.1 supply the data this measurement depends on. Confirm early which assets sit outside the filter path, such as roaming laptops or cloud workloads, because those gaps usually decide the coverage result.

In the testing phase, DeployOpen checks that blocked categories and block list entries are actually denied from representative client segments and that the denial is logged. The result is a coverage record, configuration exports, change records for policy updates and a runbook that describes how the filter is maintained and how exceptions are approved. Whether those records satisfy a particular assessor's expectations is a question to settle with that assessor before the work starts, and the client should ask for the expected evidence list in the written scope.

Safeguard 9.3 Maintain and enforce network-based URL filters