A.8.23 Web filtering: requirements and evidence

What A.8.23 web filtering asks for and why it is hard to evidence

A.8.23 Web filtering asks the organization to manage access to external websites so that exposure to malicious content is reduced and access to unauthorized web resources is prevented. It is one of the 11 controls that were new in the 2022 revision of Annex A, so organizations that certified under the 2013 edition have no earlier control to point to and must build the requirement from scratch. The practical question for an assessor is whether the organization decided which categories of websites are off limits, enforced that decision on the paths users actually take to the web, and can show it working. The control protects systems from malware delivered through web pages and blocks use of sites that the organization has not authorized, such as file-sharing services that could carry data out of the business.

Auditors usually look for two things together. The first is technical enforcement: a secure web gateway, a proxy, DNS filtering or a firewall rule set that blocks the categories and known-bad destinations the organization chose, with logs of blocked requests. The second is written rules: a web filtering or acceptable use standard that names the categories, explains exceptions and says who approves them. Either alone is weak evidence. A filter with no documented policy cannot show what it was meant to do, and a policy with no enforcement cannot show that anything happens. The control overlaps with A.8.7 Protection against malware, which covers blocking malicious websites as part of wider malware defense, and with A.5.10 Acceptable use of information, which sets out what users may do with organizational assets. Reuse those documents where they already cover web access, and confirm with your certification body how it wants the overlaps shown in the Statement of Applicability.

NIST's crosswalk from SP 800-53 Rev. 5 to ISO/IEC 27001:2022 relates A.8.23 to AC-4 (Information Flow Enforcement) and SC-7 (Boundary Protection), which is a useful way to think about the enforcement point. NIST cautions, however, that mapped controls are not always equivalent, so an AC-4 or SC-7 result cannot be copied across as proof of A.8.23 without checking the wording against the Annex A attributes. Before scoping the control, confirm which web paths exist in your environment: office proxies, cloud workloads, remote laptops, and servers that fetch packages or updates from the internet. Each path needs a decision about whether filtering applies, and a gap in that inventory is the most common reason the control is hard to evidence.

Which web traffic, users and systems fall inside the web filtering scope

Web filtering under A.8.23 only works if the organization knows which traffic, users and systems pass through the filter. The cards below cover the scoping decisions that most change the rule set, the logs and the people who own them. Confirm each boundary against your own asset inventory and risk assessment before writing rules.

Office and remote user browsing

Office staff are usually routed through a proxy or secure gateway, while remote staff may reach the internet directly from home networks. Decide whether filtering follows the user (an agent or cloud-delivered service) or the network (a gateway in your own infrastructure), because each choice changes which rules apply off-site. Confirm how remote sessions are enrolled and what happens to filtering when a device is off the corporate network. Decide the enforcement point before writing any category rules.

Server and workload egress

Servers, containers and build agents often make outbound requests to package repositories, update services and third-party APIs. These flows rarely resemble user browsing, so a rule set built for staff can break workloads or leave them unfiltered. Maintain an explicit allowlist of destinations for each workload group, and log denied egress to the team that owns the service. Illustratively, a patch server may need a short list of update hosts while every other outbound destination is denied by default.

Mobile and unmanaged devices

Phones, tablets and personal laptops may access corporate data without passing through your gateway, particularly on cellular networks. Decide which device classes are in scope, whether filtering is enforced through managed profiles or only applies to corporate-owned endpoints, and how guest or contractor devices are handled. Document the exceptions in the Statement of Applicability so an assessor can see the boundary was a deliberate decision rather than an oversight.

Cloud and SaaS access paths

Staff reach SaaS applications, cloud consoles and collaboration tools directly, often bypassing the corporate proxy. Inventory these services, decide which ones require filtering, and confirm whether any cloud-hosted filter can inspect or log traffic to them under your contracts and data protection obligations. Check that administrative consoles and developer tools are covered by the same policy as ordinary web browsing, and record who approves exceptions.

Logs, retention and ownership

Each scoping decision produces its own logs, and those logs need named owners. Identify who reviews blocked-request reports, who approves category changes, and who investigates a user complaint about an unexpectedly blocked site. Set retention so that an assessor can trace a blocked or allowed request back to a rule and a decision. Confirm log retention periods against your legal and contractual requirements, since these vary by jurisdiction and sector.

Boundary confirmation and risk linkage

The final scope should match your asset inventory and the risks in your risk assessment, not the preferences of the team that installs the filter. Walk each asset class through the decisions above, record the in-scope and excluded items with reasons, and link each exclusion to a risk treatment decision. Review the boundary after major changes such as new offices, acquisitions or cloud migrations, and ask any implementation partner to test the boundary against your actual inventory.

How an assessor tests web filtering and what they ask to see

This table lists each test an assessor is likely to run for A.8.23 Web filtering, the evidence they will ask for, and the findings that commonly come up. Read it as a preparation checklist: if your organization cannot produce the evidence in the right-hand column, the matching finding is the likely result. The main takeaway is that a written rule alone rarely passes; the assessor wants proof that blocking works and that someone reviews the rules.

Test approach	Evidence requested	Common findings
Review the written web access rules and policy	Web filtering or acceptable use policy, defined category list, approved exceptions process, and the link to A.5.10 and A.8.7	Policy says sites are blocked but no category or rule set is documented
Compare rule configuration with the stated policy	Export or screenshot of filtering rules, block lists and allowlists with change dates	Rules in production differ from the approved policy, or allowlists are broader than documented
Sample blocked and allowed categories	Category assignments, rule match logs and records showing why each category is blocked or permitted	Categories with no named owner, or uncategorized sites that default to allow without a decision
Observe or review block events for known-bad sites	Live demonstration or recorded logs showing blocked requests to test or known-malicious destinations	No evidence that blocking works in practice, such as logs that were never generated or never retained
Check exception approvals	Exception requests with business justification, approver, expiry date and removal record	Exceptions granted verbally, never expired, or kept after the business need ended
Review evidence of periodic rule review	Review meeting records, reviewer sign-off, changes made and threat intelligence used as input	Rules never reviewed since deployment, or reviews that record no changes or decisions
Check coverage across endpoints and remote users	Scope statement showing which devices, networks and cloud workloads the filtering covers	Remote or unmanaged devices bypass filtering with no compensating control or user guidance
Interview staff about user guidance	Training material, awareness communications and acknowledgment records	Users unaware of blocked categories or the route to request access to a blocked site

How to implement web filtering step by step

This sequence takes web filtering from a written access policy to a tested, logged and reviewed control that an assessor can trace back to A.8.23. Each step produces a named artifact, so the output of one step is the input the next step needs.

Define the web access policy and categories
Start by writing the rules for which external website categories are allowed, blocked or allowed with conditions, such as business need or a named role. Security, IT and the business owners of high-risk groups such as developers or finance staff should agree the categories, and the policy should state who may request an exception. The output is an approved web access policy with a category table that names the owner and the review date. Confirm that the policy cross-references the acceptable use rules under A.5.10 so that users can see the same expectations in both documents.
Map filtering points to the scope
Identify every point where users or systems reach external websites: office and remote egress, guest networks, cloud workloads, servers that call out for updates, and any proxy or DNS resolver already in place. Record which of these are in the ISMS scope and which can reach the internet without passing a filter. The output is a short egress inventory that lists each path, the device or service that enforces filtering on it, and the gaps. An assessor will compare this inventory with the network diagrams, so keep the two consistent.
Build and approve the rule set
Translate the approved categories into rules on the filtering platform. Typical choices are a secure web gateway or proxy, a DNS-based filter, or firewall rules, and self-hosted options exist for each. Each rule should name its source feed or category list, its action and its owner. Threat intelligence feeds, if used, should be documented with their origin and update method, and the change should go through the normal change process under A.8.32. The output is a versioned, approved rule set with a change record for each rule.
Test blocking with known test URLs
Test each category and action before go-live. Use test URLs that the security team has agreed are safe to request for blocking tests, such as URLs from a documented test list, and confirm that blocked categories are denied and allowed categories pass. Test from each egress path in the inventory, including remote users and guest networks where applicable. Record the date, the tester, the URL, the expected result and the actual result. The output is a signed test report. Any failed test returns the rule set to the previous step rather than going live with a known gap.
Route filtering logs to a retained store
Configure the filter to log allowed and blocked requests with user or device identity, timestamp, destination and category, then send those logs to a central store that the platform team cannot silently edit. Set retention in line with the logging policy under A.8.15 and confirm that the logs are time-synchronized under A.8.17 so that events line up with other sources. The output is a working log pipeline with a sample retrieval demonstrating that a blocked request can be traced to a user and a rule version.
Set a review cadence for exceptions and rules
Create an exception register for every user or group granted access to a blocked category or a normally denied destination. Each entry should record the business reason, the approver, the expiry date and the rule it changes. Set a recurring review of the exception register and the rule set, with the cadence written into the policy, and have the owner sign off each review. The output is a signed exception register and review records. Assessors often sample these records, so an expired exception still open in the register is a common finding.
Write user guidance tied to A.5.10
Publish short guidance for users explaining what is blocked, why, how to request an exception, and how to report a site that appears wrongly categorized or that looks malicious. Link the guidance to the acceptable use rules under A.5.10 and to the malware handling process under A.8.7. Confirm that staff acknowledge the guidance during onboarding and at the usual awareness cycle. The output is published guidance with a recorded acknowledgment. Users who understand the rules report fewer false positives, which reduces pressure on the exception process.

Evidence that passes a web filtering assessment

An assessor testing A.8.23 Web filtering looks for a chain of evidence: a policy that sets the rules, a configuration that enforces them, logs that show enforcement, and records that show someone reviews and maintains both. Each artifact below should be produced on a schedule so it is current when the auditor arrives, not assembled for the audit.

Approved web access policy

This is the written rule set that defines which external website categories are blocked, which are allowed for business use, and who may request changes. An assessor compares the filtering configuration against this document, so the two must agree. Keep it under version control with an approval date and owner, and confirm that it cross-references the acceptable use rules under A.5.10 and the malware controls under A.8.7. Re-approve it on a fixed schedule even if nothing changed.

Category and rule baseline with change history

The baseline is the current list of categories, allow and block lists, and rule order on the filtering point, together with a record of every change. Auditors often sample a change and ask who requested it, who approved it and why it was made. Store the baseline in a Git repository or a similar system so each change has an author, a timestamp and a linked request. Confirm that emergency changes follow the same record-keeping path.

Configuration exports from the filtering point

Exports of the live configuration show what the system actually enforces, which is what the assessor will compare against the policy. Schedule exports from the firewall or proxy, store them with a date, and compare each export with the previous one to detect unapproved drift. For OPNsense-based deployments, the rule set can be exported and reviewed alongside the alias definitions that group blocked or allowed destinations. Ask the auditor which export format and retention period they accept.

Block and allow logs with sample events

Logs demonstrate that the filter works in operation, including blocks of known-bad or unauthorized destinations and the allowed traffic that passed. Retain the logs for a period that you define in the policy, protect them from alteration, and pull representative samples for the assessor, including a blocked malicious domain and an exception. Check that log timestamps are synchronized with your time source, because a sample is hard to correlate otherwise. Confirm the retention period with your certification body before you set it.

Exception approvals with expiry dates

Every allow exception to a blocked category should carry a business justification, a named approver, and an expiry date. Expired exceptions that remain active are a common finding, so run a scheduled report that lists exceptions nearing expiry and removes those past it. Keep the approval record linked to the configuration change that implemented it. Ask the assessor whether they expect exceptions to be reviewed at a fixed interval or only at expiry.

Periodic review records

Review records show that the organization checks the filtering rules, categories and exceptions at planned intervals and acts on what it finds. Each review should record the scope, the reviewer, the findings, the actions and the sign-off by a manager who is not the person who maintains the rules. Set the review frequency in the policy and calendar the reviews so they recur without reminders. The auditor decides whether the frequency and depth of these reviews are sufficient for your risk profile.

What meeting A.8.23 costs in money and effort

This table breaks the cost of meeting A.8.23 Web filtering into its components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. No fees are stated because none are supplied; use the table to build the scope you send for a written quote.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Filtering or proxy licenses, or open-source deployment effort	Vendor for commercial filtering subscriptions; implementer or internal team for open-source deployment	Commercial licenses usually recur; open-source deployment is mostly one-time setup, with upkeep recurring	Number of users and devices, number of internet egress points, and whether filtering runs on-premises or in cloud accounts
Engineering time to design and tune web rules	Internal engineers or an implementation partner	One-time for initial design; recurring for tuning after false positives	Number of allowed categories, exceptions, and in-house familiarity with proxy or firewall policy languages
Log storage and retention	Internal platform or cloud team; storage provider	Recurring	Retention period set in the policy, log volume per user, and whether logs are kept centrally for review
Ongoing rule and category review	Internal security operations or a managed service provider	Recurring	Frequency of review, rate of new threat intelligence, and how many blocked-request exceptions users raise
External testing or review of filtering controls	Independent security testing firm or implementation partner	Recurring if tested on a cycle; one-time for readiness reviews	Scope of testing, number of egress paths, and whether bypass attempts from user devices are in scope
Auditor time to test and sample evidence	Certification body or independent auditor	Recurring across the certification cycle	Quality of evidence on hand, number of sites in scope, and how many rule changes the auditor samples

How self-hosted open-source tools support web filtering evidence

Web filtering under A.8.23 depends on controls at several layers: network egress, the application edge and the threat intelligence that tells you what to block. The open-source tools below each produce a different kind of evidence, and none of them replaces a documented web filtering policy that the organization owns and reviews.

OPNsense rules and live logs

OPNsense is a stateful packet filter under the BSD-2-Clause license. Its rules pass, block or reject traffic by source, destination, port and protocol, and aliases let you group address lists such as blocked destinations or approved update servers into one rule. Enabling per-rule logging lets you show an assessor which rule matched a given connection in the live log view. Check whether your deployment can filter by URL or content category, because packet filtering alone works on addresses and ports, not on page content.

Coraza at the application edge

Coraza is a web application firewall under the Apache-2.0 license, compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It targets attacks such as SQL injection, cross-site scripting and code injection in traffic reaching your applications, and it integrates with Caddy, HAProxy, Traefik and Nginx. It protects inbound web traffic to your services rather than outbound browsing by users, so it supports a different part of the control. Confirm which proxy you run and keep its rule set version and audit log output as evidence.

MISP for indicator sharing

MISP is a threat intelligence platform under the AGPL-3.0-only license. It correlates indicators by exact match and advanced patterns such as fuzzy hashes and CIDR overlaps, and it records sightings, which shows when a blocked indicator was actually seen. Its REST API exports indicators to STIX 1 and 2, CSV and to Suricata, Snort and Zeek rule formats, so a block list can be generated from curated events rather than maintained by hand. Keep the event history and distribution settings as evidence of where each block entry came from.

OpenCTI for threat intelligence feeds

OpenCTI is a threat intelligence platform under the Apache-2.0 license. It organizes intelligence as STIX-based entities, relationships and containers, and it ingests data through connectors and TAXII, RSS, CSV and JSON feeds or manual file upload. Its value for A.8.23 is a documented record of which feeds inform which blocking decisions and how stale feed entries are reviewed. Confirm which feeds your organization is licensed to use and who approves changes to the block lists they feed.

Who owns web filtering: your team, a partner and the auditor

Your organization owns the control. That means deciding what web access is acceptable, who may request an exception, which risks you accept, and how the rules are reviewed. ISO/IEC 27001 places these decisions with management, so they cannot be handed to a vendor or a partner. Your team also answers for the outcome when a blocked site turns out to be needed or a malicious site gets through.

Filtering policy: Set the categories to block, the categories to allow, and the rules for uncategorized sites, tied to your acceptable use rules in A.5.10.
Exceptions: Define who approves an exception, how long it lasts, and how it is recorded.
Risk decisions: Document accepted residual risk, such as encrypted traffic that cannot be inspected or personal devices outside the proxy.
Review: Schedule periodic reviews of rules, logs and exceptions, and keep the minutes.
User guidance: Write and deliver the guidance employees receive about permitted browsing and how to report a blocked legitimate site.

Check that each decision has a named owner, a date and a record that an assessor can read without your team explaining it.

Where web filtering programs usually fall short

Web filtering often looks complete on the day it is switched on and then drifts. The gaps below share one root cause: the filter is treated as a product rather than as a controlled process with owners, exceptions, records and user communication that an assessor can trace.

Filtering covers only the office

Many programs filter traffic on the head office network and miss laptops, remote staff, branch sites and cloud workloads that reach the internet directly. A.8.23 asks the organization to manage access to external websites, so the scope must match where users and systems actually connect. Check that the policy names every network path, that roaming devices are covered by an agent or a DNS-based control, and that cloud servers without a web proxy are listed as an explicit exception with a reason.

No owner for category changes

Blocked and allowed categories change over time, usually through a vendor update or a helpdesk request, and nobody is accountable for the decision. An assessor will ask who approved each category and where that approval is recorded. Assign a named owner for the category list, require a change ticket for every rule adjustment, and keep a dated record of the baseline so that changes can be compared against it.

Exceptions that never expire

Temporary allowances for a vendor portal, a research team or a one-off test tend to stay in place for years. Each exception quietly weakens the control the policy describes. Require every exception to carry a business justification, an approver, a named system or user group and an end date. A monthly review that lists active exceptions and removes expired ones gives you evidence that the control is maintained, not just configured.

Logs too short to show past blocks

Web filter logs are often rotated after a few weeks, which means a question about a block from several months earlier cannot be answered. Incident investigators and assessors both need history. Decide a retention period in the policy, confirm that the filter or the log platform keeps records for that period, and protect the logs from unauthorized change. Ask the vendor or your own platform team to confirm the retention setting before you rely on it in an audit.

Guidance not tied to the policy

Users who hit a block often have no idea why it happened or whom to ask. Without guidance, they email the helpdesk, request exceptions or find workarounds such as personal devices. A.8.23 sits alongside acceptable use under A.5.10, so the user guidance should restate the web use rules in plain language, explain what happens when a site is blocked and give a route to request review. Keep a versioned copy of the guidance and record that staff received it.

Questions buyers and engineers ask about A.8.23 web filtering

How much effort does web filtering take to run under A.8.23?

The effort is set less by the filtering product than by the decisions behind it: which categories of site are blocked, who may request exceptions, and how often the rules are reviewed. Expect ongoing work in three areas: maintaining block and allow lists, reviewing blocked-request logs, and reviewing exceptions with the people who asked for them. A small estate with a clear acceptable use policy needs far less continuous attention than a large, multi-site organization with many user groups. Ask any provider to confirm, in writing, which of these recurring tasks their scope includes and how many hours per month they assume for review.

How long does it take to get web filtering running?

No duration is set by the standard, and the time depends on the size of the estate, the number of user groups, and how many existing proxies, firewalls or DNS services must be integrated. The work usually falls into four stages: defining the policy and categories, deploying the filtering points, testing with pilot users, and documenting the rules as evidence. Teams that already run a managed firewall can often reuse its inspection points, which shortens the deployment stage. Ask a provider for a written timeline that names each stage, its dependencies and the client tasks it assumes.

What does the work need from our own staff?

Your staff must own the policy decisions, because A.8.23 is about your organization's rules for external websites, not a tool setting. Typical inputs include an approver for the acceptable use policy, a network or security engineer to change firewall or proxy configuration, and a service owner who can say which sites business processes depend on. Your team also keeps the records: change approvals, exception requests and log review results. An implementation partner can prepare the configuration and evidence, but the controls remain yours.

Can a small team run web filtering without an implementation partner?

Yes, a small team with a network engineer can run basic web filtering if it has a written policy, a filtering point it already administers, and time for periodic reviews. The harder parts for small teams are mobile and remote devices, which may bypass office network controls, and keeping evidence current. Partner help is most useful when the team lacks a technical owner, the estate spans several sites or clouds, or an audit is approaching and the records need to be assembled. Whether to bring in help should follow a written gap assessment of your current setup.

Are open-source tools enough to meet A.8.23?

Open-source tools can supply the technical enforcement and logging that A.8.23 depends on, but no tool satisfies the control on its own. Firewall rules in OPNsense, for example, can pass, block or reject traffic by source, destination, port and protocol and can log rule matches for review, which gives you enforcement and records. Threat intelligence platforms such as MISP and OpenCTI can inform which indicators feed your block lists. Web-specific filtering by content category may need a proxy or dedicated product, so confirm that capability with the vendor before relying on it.

What will an auditor ask to see for A.8.23?

An auditor will usually ask how you decided which external websites are blocked, how that decision is enforced, and how you know it works. Expect requests for the documented web access rules, the configuration export of the filtering point, samples of blocked-request logs with review records, and the process for handling exception requests. The auditor will also check that the rules tie back to your acceptable use and malware controls, which relate to A.5.10 and A.8.7. Because the auditor independently tests the control, your job is to keep these records current, not to pre-certify them.

What should a quote for web filtering include?

A quote should list the scope in writing: the filtering points covered, the number of users and sites, the policy and category decisions included, and the integration work with firewalls, proxies or DNS. It should separate one-time work, such as design and deployment, from recurring work, such as rule reviews, log reviews and upgrades. It should also name the deliverables, including configuration exports and evidence packs, and state which tasks remain with your staff. DeployOpen does not publish a price list; a quote follows from a written scope, and any fee or duration should be traceable to the items above.

How DeployOpen works on this

DeployOpen plans, implements and documents self-hosted web filtering inside your own infrastructure, so the controls and their records fit your ISMS. We prepare systems and evidence for your assessment, while your organization owns the control and the independent auditor or certification body issues any report or certificate.

How we scope

Agree in writing which egress paths, user groups and sites the A.8.23 web filtering scope covers.
Confirm which blocking categories, allowlists and exception processes your organization owns and approves.
Map related controls such as A.8.7 malware protection and A.5.10 acceptable use to the same scope.

How we build

Deploy and configure filtering on your chosen platform, such as OPNsense rules or Coraza for web traffic, inside your environment.
Integrate threat intelligence feeds from MISP or OpenCTI so blocklists are sourced and updated under a documented process.
Test blocking and logging behavior against agreed scenarios, and record the results for the assessor.

How we hand over

Deliver configuration records, rule documentation and blocklist update procedures in a form your assessor can review.
Document the test results, logged block events and review steps that show the control operates as described.
Walk your team through the runbook so the organization can operate and evidence the control after handover.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work ends.
Review rule changes and feed updates against the written scope before they reach production.
Confirm with your auditor which evidence they expect for the control before your assessment begins.