ISO 27001 Annex A 8.23: web filtering without the enterprise proxy

The due-diligence questionnaire asks how you control access to malicious websites, and your answer is an acceptable-use policy and a hopeful shrug. ISO 27001 Annex A 8.23 expects technical enforcement, but nowhere near the enterprise proxy appliance you may be dreading.

This guide is for IT directors and information security managers at 25–250-person firms. It covers what the control requires, how DNS-layer filtering meets it in days, how to design exceptions that stop shadow IT, and the evidence an auditor will sample.

What does ISO 27001 Annex A 8.23 web filtering require?

The ISO 27001:2022 Annex A 8.23 web filtering title is simply “Web filtering”. The control asks you to decide which outside websites your people can reach, so they meet less malicious content. It is a preventive control: the filter stops the hostile connection before the payload lands or credentials leave.

You will also see it cited as the ISO 27001 2022 Annex A 8.23 web filtering title. A third form is the ISO/IEC 27001:2022 Annex A A.8.23 web filtering title. All three name the same control.

The ISACA technical analysis of ISO/IEC 27002:2022 controls describes it as a preventive control built on two things: blocking known-bad sites and setting rules for safe use of the web. In plain English, you enforce your web rules with technology, not with a policy paragraph and good intentions.

The filter protects all three security properties:

• Confidentiality: blocking credential-harvesting pages and exfiltration routes.
• Integrity: keeping malware that would tamper with systems off endpoints.
• Availability: stopping drive-by ransomware, which is an outage by another name.

Blocklists should be fed by threat intelligence under Annex A 5.7. The filter works alongside malware protection under Annex A 8.7 as a first line, not a replacement. Its scope is narrow: hostile destinations, not staff productivity.

Is web filtering mandatory, and why does it matter?

Web filtering is mandatory whenever A.8.23 sits in your Statement of Applicability, which it does for almost every firm. Auditors read the 2022 wording as technical enforcement, not a policy asking nicely. The control does not oblige you to block social media or monitor staff: the security case covers hostile destinations only.

The browser is the cheapest attack path into your business. One convincing phishing page hands an attacker staff credentials, and one drive-by download gives ransomware a foothold. The NCSC guidance on Protective DNS for the private sector names the categories a protective filter blocks: malware distribution domains, command-and-control domains and phishing domains.

For a regulated firm the stakes compound:

• Illegal content: staff reaching it from company systems is a legal liability.
• Data leakage: data pasted into an unsanctioned web tool or a personal cloud store is a reportable breach waiting to happen.
• Questionnaires and insurance: security questionnaires and cyber-insurance proposals both ask about web protection, and “we trust our people” does not survive underwriting.

Staff often hear “web filtering” and picture surveillance. The design answers that worry: the filter blocks hostile destinations and does not report browsing habits. Blocking time-sink categories such as social media is a management choice, so make it consciously and write it down either way. Say what is blocked and why in the policy, give people a fast exception route, and most objections evaporate.

What is the three-layer control model behind A.8.23?

The model has three layers working together. Written acceptable-use rules name what is blocked and why. A technical filter enforces them. Trained staff understand block pages, know how to request exceptions and never click past a browser security warning. Each layer covers a gap the others leave.

Each layer is lighter than it sounds:

1. Written rules. A short acceptable-use section in your staff security policy, not a standalone tome. It names what is blocked and why: malicious and phishing domains, attacker command channels, illegal material, and upload or file-sharing sites without a business case.
2. Technical filter. The enforcement that makes those rules true on every endpoint. The next section sizes it for your headcount.
3. Trained staff. Awareness training covers spotting phishing, what the block page means, how to ask for an exception and why nobody clicks through a browser certificate warning.

An acceptable-use policy with no filter behind it is a wish, not a control.

Our guidance is to keep the “don't override the warning” message in training, because that single click undoes the protection the warning offers.

The layers fail in a predictable order. Rules without a filter go unenforced. A filter without rules blocks things nobody agreed to. Training without either leaves staff guessing what a block page means.

How do you implement ISO 27001 web filtering for 25–250 staff?

At 25–250 staff, DNS-layer filtering is the right-sized enforcement: it covers laptops wherever they are, deploys in days and handles malicious, phishing and command-and-control categories out of the box. A full secure web gateway with TLS inspection is enterprise kit; adopt it only if a regulator or specific risk demands content inspection.

DNS-layer filtering works at name resolution. When a laptop asks for a domain on the threat list, the answer is a block page instead of a connection. The check does not decrypt traffic. You avoid the privacy, speed and certificate headaches of TLS inspection and still catch most web-borne threats.

If a regulator or a specific risk does justify a secure web gateway, keep a written bypass list for banking and health traffic. Inspection should never touch it. Most firms of this size have no risk driver for content-level inspection. Spend the effort on coverage and exceptions instead.

A realistic sequence for a 50-person regulated firm:

1. Confirm the endpoint inventory. You cannot filter a laptop you do not manage.
2. Write the acceptable-use section. The rules come first, and the filter then enforces them.
3. Deploy the DNS filter. Put an agent or DNS profile on every managed device, contractors included. Tool deployment is an afternoon.
4. Check the threat feed. The product updates its blocklists itself. Your job is to confirm the subscription is on and the agent reaches every endpoint.
5. Build the exception route and block page, then fold web risk into awareness training.

Place the work in the endpoint and network hardening phase of your programme, alongside malware protection under Annex A 8.7. The policy wording and exception workflow are the real work. That makes this a project of days, not months, with no appliance to rack and no office perimeter to assume.

How do you keep remote laptops, contractors and the filter console covered?

Put an endpoint agent or DNS profile on every managed device, contractors included. Protection then travels with the laptop instead of depending on the office network. Then protect the filter itself: admin access behind multi-factor authentication, configuration changes logged, and block events feeding central logging.

Office traffic filters beautifully while laptops at home browse raw. Endpoint-based or DNS-based filtering exists to close that gap, so push the agent or profile through the same tooling that manages the device. If a contractor laptop cannot be enrolled, treat that as a decision about what the device may reach, not a gap to discover at audit.

Lock down the console with three settings:

• Multi-factor authentication on every administrator account.
• Change logging that shows who edited the configuration and when. Auditors ask who can change the filter and how you would know if they did, so the log answers a question you will be asked.
• Block and allow events in central logging, so activity does not live only in the vendor's portal.

A console without these is the pitfall in reverse: the control protecting everyone else becomes the unprotected admin surface.

How do you design an exception workflow that stops shadow IT?

Build the exception route before the first block: a ticket, a quick security check of the site, a time-limited approval and a log. A filter without a working exception path gets worked around, and personal-hotspot tethering is shadow IT you cannot see. An informative block page tells users how to request access.

The route in four steps:

1. Ticket. The user names the site and the business reason.
2. Security check. A quick look at the site's reputation and purpose before anyone approves it.
3. Time-limited approval. The approver sets the review date at the moment of approval, not later.
4. Log. The ticket holds request, assessment, approval and expiry, which is the trail an auditor samples.

An exception with no expiry date is a permanent hole with a ticket number.

The block page does half the work. It should say what was blocked, why, and how to request access or report a concern. A blank error page creates helpdesk noise and quiet workarounds. A clear one creates tickets you can audit. If the same site is requested repeatedly, change the category rule instead of approving one-off exceptions.

Blocking aggressively with no route teaches staff to tether to personal hotspots. The traffic then leaves your logs entirely, and you have lost visibility rather than gained control. The route has to beat the workaround, which is why a quick security check works better than a committee.

What audit evidence proves A.8.23 is operating?

Auditors expect five exhibits: the web filtering policy, configuration exports with proof of full agent coverage, block logs, exception tickets and training records. Each one has to show the control running today, not a plan for it, so collect records the auditor can date and trace.

What each exhibit needs to show:

• Policy: the restricted categories and the exception route, approved and in force, so "where is that written down?" has one answer.
• Configuration exports: categories enabled, blocklists and allowlists, and feed subscriptions, plus the agent list checked against the device inventory.
• Block logs: recent blocks from remote laptops as well as office devices, ideally flowing into the SIEM.
• Exception tickets: a sample where each trail runs from request and assessment to an expiry that was honoured.
• Training records: completion records plus the course content itself, including the browser-warning message.

Fleet coverage is the exhibit to plan for first. A configuration screenshot shows what the policy says, while only a reconciled agent list shows which laptops it applies to. Keep exports dated and, where the tool allows, make the exhibit a query rather than a screenshot. The final section shows how.

What will an auditor ask and test for A.8.23?

Expect a live demonstration: the auditor asks someone to visit a test-malicious URL and watches for the block page. The auditor then traces a recent exception from request to expiry and checks that remote laptops are covered. Training content gets cross-checked for the browser-warning message. Policy-only, with no technical filtering, grades major.

Five questions to expect in the room:

• “Show me what happens when someone browses to a known-bad site.”
• “Which categories do you block, and where is that written down?”
• “Someone needs a blocked site for a legitimate reason. Walk me through the process.”
• “How do your blocklists stay current?”
• “Who can change the filter configuration, and how would you know if they did?”

Each question maps to an exhibit: the first to block logs, the second to the policy, the third to exception tickets, the fourth to feed verification and the fifth to console MFA and change logs.

Grading follows certification-body practice rather than the wording of the standard. A stale blocklist, an exception without an approval trail or a gap in fleet coverage each grades minor. A pattern of minors adds up to a major. Run the demonstration yourself a week early. If the block page appears on a remote laptop as well as an office one, you have already covered the demonstration and the coverage check.

How can you automate A.8.23 evidence and detection?

Automate four checks. Reconcile filter agents against the MDM or device inventory daily. Give every exception an expiry date. Stream block events to the SIEM, with alerts on command-and-control categories. Verify threat-feed updates on a schedule. Each check turns an audit question into a query.

Each check closes a pitfall named earlier. The daily reconciliation turns a laptop without the agent into a finding raised automatically, not a surprise at audit. Expiring tickets make the exception log a query. A scheduled feed check stops the filter running on last year's threat list, which passes casual inspection and misses current campaigns.

Block telemetry makes the filter a detection sensor. Repeated blocks to command-and-control categories from one host are an incident-response trigger, not a statistic. The Joint CISA and NSA Cybersecurity Information Sheet on Protective DNS notes that DNS query logs also support incident response and threat hunting.

Coverage you check once a year is coverage you only have once a year.

The commercial upside is fewer audit surprises and faster answers when a customer questionnaire or cyber-insurance proposal asks about web protection. If you want a hand, a fractional CISO can own the acceptable-use rules and exception approvals. GRC engineering builds the reconciliation, expiring-exception workflow and SIEM telemetry. The table sets the four checks side by side.

Frequently asked questions