ISO 27001 Annex A.8.23: A Practical Guide to Web Filtering

ISO/IEC 27001:2022 Annex A.8.23 addresses web filtering as a technological control. Its purpose is commonly understood as managing access to external websites to reduce exposure to malicious content. The control sounds simple, but effective implementation requires more than blocking a list of categories at an office firewall.

Modern users work from home, install browser extensions, access cloud applications directly, and use encrypted web traffic. Developers may legitimately visit sites that generic filters classify as risky. A practical implementation should therefore begin with organizational risk and architecture, not a copied blacklist.

ISO/IEC 27001 is copyrighted, so consult the official standard and ISO/IEC 27002 guidance for authoritative wording and implementation considerations. This article is an educational implementation overview.

Put A.8.23 in the ISMS

Annex A controls are part of a risk-treatment process, not an automatic checklist applied identically to every organization. The organization should assess information security risks, select treatments, and document applicability in its Statement of Applicability.

For web filtering, relevant risks may include:

• malware delivery and phishing;
• credential theft through impersonated services;
• browser exploitation and drive-by downloads;
• command-and-control communications;
• accidental upload of sensitive information;
• access to unauthorized file-sharing or anonymization services;
• exposure to unlawful or inappropriate material;
• circumvention of security monitoring.

Describe which risks the control addresses, which users and devices are in scope, and what other controls support it. Email security, DNS protection, endpoint detection, browser management, security awareness, and incident response often work together with filtering.

Choose enforcement points based on architecture

A network gateway can protect traffic routed through a managed location, but it may not cover roaming devices or direct cloud access. Secure web gateways, managed DNS resolvers, endpoint agents, browser controls, and firewall services provide different coverage and visibility.

Map user paths before selecting technology. Include:

• office and remote endpoints;
• mobile devices;
• production servers and workloads;
• contractors and bring-your-own-device scenarios;
• guest networks;
• virtual desktops;
• administrative and development environments.

Not every path requires the same mechanism. A production server may need strict egress allowlisting, while a developer workstation may need category filtering plus endpoint detection and logged exceptions. The design should reflect risk rather than forcing one tool into every use case.

Encrypted traffic creates tradeoffs. TLS inspection may improve detection but can introduce privacy, trust, performance, and application compatibility concerns. If used, manage certificates securely, limit scope, define exclusions for sensitive categories, and assess legal and employee-privacy implications.

Define categories and threat intelligence

Filtering typically combines reputation, known-threat indicators, domain age, content categories, and custom rules. Establish a baseline that blocks known malicious destinations and prohibited categories. Treat vendor defaults as a starting point, not a policy decision.

Category labels can be inaccurate. Newly registered domains may include both phishing infrastructure and legitimate startup services. File-sharing sites may enable business workflows as well as data leakage. AI and code-hosting services can present similar ambiguity.

Document why categories are blocked, warned, monitored, or allowed. High-confidence malicious destinations should generally be blocked automatically. Ambiguous categories may use a warning or approval workflow. Review policies when business models and threat patterns change.

Threat feeds also require governance. Know their update frequency, failure behavior, and retention of query data. Monitor whether endpoints actually receive updates. A subscription does not provide protection if agents are stale or DNS settings can be changed by users.

Make exceptions controlled and usable

Overly broad blocking encourages bypasses. Create a clear exception process so users can request access for a legitimate business purpose.

An exception record should capture the requester, destination or category, reason, risk review, approver, scope, expiration, and compensating measures. Prefer narrow, time-limited exceptions over permanent global allowlisting. Recheck the destination before approval and review recurring exceptions for policy improvement.

Emergency access may be necessary during incident response or customer support. Define who can authorize it and how actions are logged. Blocking-page instructions should tell users how to request review without training them to ignore security warnings.

Developer needs deserve explicit treatment. Package repositories, code samples, tunneling tools, and testing sites may trigger controls. A dedicated development policy, sandbox, or isolated research environment can preserve productivity without weakening protection for all users.

Protect the filtering system itself

Administrative access to filtering platforms should use strong authentication and least privilege. Separate policy administration from routine support where feasible. Log rule changes, allowlist additions, and disabled agents.

Prevent simple circumvention through unauthorized DNS changes, unapproved VPNs, alternative browsers, or local administrator access. Perfect prevention is unrealistic, but the organization should detect material gaps and respond.

Design for failure. Decide whether traffic fails open or closed when a filtering service is unavailable, based on business and security risk. Monitor service health and maintain response procedures. A fail-closed design can create a broad availability incident; fail-open can create an unmonitored period.

Monitor outcomes, not just blocks

Useful metrics include endpoint coverage, policy-update health, blocked high-confidence threats, exception volume, repeated user attempts, bypass detections, and false-positive resolution time. Raw block counts alone can reward noise rather than risk reduction.

Integrate significant events with security monitoring. A single blocked advertisement may need no investigation, while repeated access to credential-phishing domains or command-and-control infrastructure should trigger triage. Correlate web events with identity, endpoint, and email telemetry.

Retain logs according to security, privacy, legal, and operational needs. Web logs can reveal sensitive information about individuals. Restrict access, minimize unnecessary detail, define retention, and communicate monitoring practices appropriately.

Build audit-ready evidence

Evidence for A.8.23 may include:

• risk assessment and treatment records;
• the Statement of Applicability rationale;
• web filtering policy and technical standards;
• architecture and in-scope population;
• configuration exports and category decisions;
• endpoint or resolver coverage reports;
• exception approvals and expirations;
• administrative change logs;
• alerts, investigations, and response records;
• service-health tests and policy review minutes.

Evidence should show that the control operates, not merely that a product was purchased. Sample a remote endpoint, confirm that policy is current, test a safe known-block category, and verify that the event reaches the expected monitoring workflow.

Review as the environment changes

Reassess filtering when remote-work patterns, endpoint platforms, network routes, legal obligations, or business use cases change. Include web filtering in internal audit and management review where relevant. Track nonconformities and corrective actions through the ISMS.

A.8.23 is most effective when it is one layer in a broader defense. It should reduce exposure, guide users away from dangerous destinations, and provide useful signals without pretending that every harmful site is known in advance. Risk-based scope, controlled exceptions, privacy-aware monitoring, and tested coverage turn a generic filter into a defensible information security control.

Disclaimer: Educational only — not certification advice. Obtain the official ISO standards and validate interpretation, applicability, and evidence with qualified professionals and your certification body.