Annex A 8.23: Web Filtering

Annex a 8.23: web filtering requirement expects you to control and restrict web access to reduce exposure to malware, phishing, and inappropriate or high-risk content, and to prove the control operates consistently. Operationalize it by defining allowed/blocked categories, enforcing filtering for all users and endpoints, logging exceptions, and retaining recurring evidence for audits. ¹

Key takeaways:

• Scope the control to real web paths (managed devices, corporate network, remote users, and high-risk roles), then enforce filtering consistently.
• Document categories, exceptions, and review cadence; auditors look for repeatable operation, not a one-time configuration screenshot.
• Keep evidence that maps policy → technical enforcement → monitoring → exceptions → periodic review. ¹

Web access is one of the fastest ways risk enters your environment: users click links, endpoints download code, browsers execute active content, and cloud apps blur the line between “web” and “business system.” Annex A 8.23 focuses on controlling that pathway through web filtering. Your goal as a Compliance Officer, CCO, or GRC lead is to make the requirement testable: a clear rule set, implemented in the right technical choke points, with documented exceptions and proof that the control runs every day.

For ISO 27001 work, teams often get stuck in two places: (1) scoping, especially with remote work and SaaS, and (2) evidence, because “we have a secure web gateway” is not the same as “we can demonstrate enforcement and governance.” This page gives requirement-level implementation guidance you can hand to IT/SecOps and then use to manage control ownership, testing, and audit readiness for the annex a 8.23: web filtering requirement. ¹

Regulatory text

Provided excerpt: “ISO/IEC 27001:2022 Annex A control 8.23 implementation expectation (Web Filtering).” ¹

Operator interpretation (what an auditor expects you to be able to show):

• You have defined what web content and web services are permitted, restricted, or blocked for your organization (or for different user groups).
• You enforce those rules through technical controls where users access the web (network egress, endpoint, DNS, browser controls, or a secure web gateway).
• You monitor and review effectiveness, manage exceptions, and retain evidence that the control is operating. ¹

Plain-English interpretation of the requirement

Web filtering means you intentionally reduce web-borne risk by blocking or restricting access to sites, categories, downloads, and web behaviors that are likely to deliver malware, enable credential theft, or violate policy. It is not a “set and forget” proxy setting. The requirement is satisfied when you can demonstrate:

1. a documented standard for web access,
2. consistent enforcement, and
3. governance around exceptions and review. ¹

Who it applies to (entity and operational context)

Entity types: Service organizations pursuing or maintaining ISO/IEC 27001 certification. ²

Operational scope (practical): Apply Annex A 8.23 wherever your people or workloads browse the web or fetch content over HTTP/HTTPS, including:

• Corporate offices and data centers (network egress)
• Remote workers (devices off-network)
• Privileged users (admins, engineers, finance)
• Non-human access paths (servers pulling packages, CI/CD runners reaching external repos)
• Third-party access where your organization provides managed devices or VDI, or where you control the egress path

Scoping decision you must make and document: Which web access paths are in-scope for filtering controls, and which are handled by compensating controls (for example, hardened servers with restricted outbound allowlists). Auditors accept scoping when it is explicit and risk-based. ²

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

1) Define the control objective and scope

• Objective statement (write this): “Prevent access to known malicious or inappropriate web content and reduce the likelihood of malware and phishing via web traffic by enforcing centrally managed web filtering controls.”
• In-scope populations: start with all workforce users on managed endpoints; separately identify “high risk” groups (admins, developers with package access, finance).
• In-scope traffic: web browsing, URL access from apps, file downloads via browser, and DNS resolution if you enforce category blocks at DNS.
  Deliverable: a one-page “Web Filtering Standard” with scope and ownership. ¹

2) Select enforcement points (use at least one that works off-network)

Pick the architecture that matches your environment and document it:

• Secure web gateway / proxy for managed devices (with agent or PAC) and corporate egress.
• DNS filtering for category-based blocking and fast rollout; treat as a baseline, not your only layer if you need deep inspection.
• Endpoint agent for roaming users when you cannot guarantee VPN backhaul.
• Network firewall URL filtering for on-prem egress control.

Control design rule: if you have remote users, you need a path that still filters when the device is not on your corporate network, or a documented alternative that provides equivalent risk reduction. ¹

3) Build a policy-backed category model

Translate “acceptable use” into enforceable categories. A practical minimum set:

• Block: known malicious sites, newly registered domains (if supported), phishing, command-and-control, malware distribution, anonymizers, illegal content.
• Restrict / warn: file sharing, personal email, URL shorteners, crypto mining, gambling, adult content (depending on your HR/legal stance).
• Allow: business-required SaaS and common research sites, with additional controls for risky categories.

Deliverable: a category matrix that maps category → action (block/allow/warn) → user groups → business justification. This becomes your audit anchor. ¹

4) Implement identity-aware enforcement

Auditors will ask whether filtering is applied “per user” or “only per IP.” Aim for identity-based controls:

• Integrate the filtering system with your IdP or directory so rules follow users and groups.
• Ensure service accounts and server egress are handled explicitly (either filtered or allowlisted with documented justification).

Deliverable: configuration evidence showing group-based policies and how identity is asserted. ¹

5) Create an exceptions workflow (and keep it tight)

Exceptions are where controls fail quietly. Define:

• Who can request an exception (and how)
• Who approves (security + business owner)
• Maximum exception duration (your choice; document it)
• Required justification and risk acceptance
• Logging and periodic review of active exceptions

Deliverables: exception ticket template, approval evidence, and an exceptions register. ¹

6) Turn on logging, alerting, and operational review

Minimum operating expectations:

• Log blocked events, allowed events by category (as feasible), admin changes, and exception usage.
• Alert on high-risk signals (malware category hits, phishing blocks, repeated policy bypass attempts).
• Review web filtering effectiveness on a defined cadence and after major changes (new office, new proxy, new IdP).

Deliverables: log retention settings, sample logs, alert rules, and a recurring review record. ¹

7) Test the control like an auditor

Run a lightweight test plan:

• Attempt access to a site in a blocked category from a managed endpoint on-network.
• Attempt the same off-network (roaming).
• Validate the event appears in logs and that the user receives the correct block page or warning.
• Validate exception process by requesting temporary access and verifying it expires.

Deliverable: a test script and test results with date, tester, evidence. ¹

Required evidence and artifacts to retain

Keep evidence that ties governance to real enforcement. A solid audit package:

• Web Filtering Policy/Standard (scope, roles, high-level rules) ²
• Category/action matrix (categories, block/allow, groups, rationale)
• System configuration exports or screenshots showing:
  • policy rules and assigned groups
  • off-network enforcement method (agent/VPN/backhaul)
  • TLS inspection posture if used (documented decision)
• Change management records for rule changes and admin access
• Exceptions register with approvals, expiry, and periodic review notes
• Logging and retention evidence (settings + sample log extracts)
• Periodic review minutes (what changed, what trends, decisions)
• Control mapping in your ISMS so 8.23 is mapped to owners, tools, and evidence capture ³

Practical tip: store a recurring evidence bundle per review period. Daydream is useful here because you can map Annex A 8.23 to a documented control operation and schedule recurring evidence capture so your audit package stays current without a scramble. ¹

Common exam/audit questions and hangups

Auditors commonly probe:

• Scope: “Does filtering apply to remote users and contractors on managed devices?”
• Consistency: “Can users bypass it with alternate DNS, VPN, or browser settings?”
• Governance: “Who approves category changes and exceptions, and how do you review them?”
• Evidence: “Show me logs from normal operations, not only config screenshots.”
• Effectiveness: “How do you know the control reduces web-borne risk in practice?” ¹

Hangup to anticipate: HTTPS. If you do not do TLS inspection, document what you can still enforce (DNS category blocks, SNI, endpoint protection, browser isolation) and why that meets your risk posture. If you do TLS inspection, document privacy impact, certificate deployment, and what content is excluded (for example, banking/health categories). ²

Frequent implementation mistakes and how to avoid them

• Mistake: filtering only on the corporate network. Fix: require an endpoint agent or always-on VPN/backhaul for managed devices, and test off-network.
• Mistake: “block lists” without business mapping. Fix: create the category matrix and tie exceptions to business owners.
• Mistake: no evidence of ongoing operation. Fix: schedule periodic reviews, export logs, and retain change records.
• Mistake: unmanaged admin access to the filtering console. Fix: restrict admin roles, log changes, and route changes through change management.
• Mistake: exceptions that never expire. Fix: enforce expiry and periodic re-approval. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, weak web filtering increases the likelihood of malware infection, credential theft, and data exfiltration routes via web apps. In ISO 27001 assessments, the most common “pain” is not the concept; it is the inability to prove consistent enforcement and review across remote endpoints and multiple egress paths. ¹

Practical 30/60/90-day execution plan

First 30 days (establish control design and scope)

• Name a control owner (Security/IT) and a compliance owner (GRC).
• Draft and approve the Web Filtering Standard and category matrix.
• Identify enforcement points for on-network and off-network users.
• Define exception workflow, approvers, and logging/retention requirements.
• Build an evidence checklist aligned to Annex A 8.23 and assign recurring collection in Daydream. ¹

Days 31–60 (implement and prove basic operation)

• Deploy the chosen filtering method to a pilot group, then expand to the workforce.
• Implement identity-based rules and admin access controls.
• Turn on logging and alerts; validate events flow to your logging platform if you have one.
• Run the test script (on-network and off-network) and store results as evidence.
• Start the exceptions register and process real requests through it. ¹

Days 61–90 (stabilize, measure, and operationalize)

• Expand coverage to privileged roles and any remaining device populations.
• Tune categories based on false positives and business needs, using change control.
• Hold the first formal effectiveness review; document decisions and action items.
• Validate bypass resistance (alternate DNS, local admin scenarios, split tunneling rules).
• Set a recurring review cadence and recurring evidence capture so audits are routine. ¹

Frequently Asked Questions

Does Annex A 8.23 require a secure web gateway (SWG), or is DNS filtering enough?

The requirement is outcome-based: you must control web access and show it operates. DNS filtering can be a baseline, but you still need to show coverage for roaming users, logging, and effective restriction of risky web destinations. ¹

How do we handle remote employees who don’t always connect to VPN?

Implement an off-network enforcement mechanism such as an endpoint agent-based filter or a web gateway client. Document the architecture and test it off-network, then retain logs and test results as evidence. ¹

Do we need TLS inspection for compliance?

ISO 27001 Annex A controls are not prescriptive about specific technologies in the provided excerpt. Decide based on risk, document the decision, and show what you can enforce and monitor over HTTPS in your chosen design. ²

What evidence is strongest for auditors?

Auditors respond well to a chain of evidence: policy/standard, category matrix, system config showing enforcement, samples of logs from normal operations, exception approvals with expiry, and periodic review notes. ⁴

How do we manage web filtering for servers and CI/CD runners that need internet access?

Treat them as separate egress populations. Either route them through filtered egress with allowlists or document compensating controls and strict outbound rules, then keep evidence of the allowlist approvals and reviews. ¹

What should the control owner review on an ongoing basis?

Review exceptions, category changes, high-risk blocked events, and bypass attempts, then document the actions taken. Retain the review record and any change tickets as proof of ongoing operation. ¹

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index

2. ISO/IEC 27001 overview

3. ISMS.online Annex A control index

4. ISMS.online Annex A control index; ISO/IEC 27001 overview