ISO 27001 control 8.23: web filtering requirements, implementation, and audit evidence

Most organizations already filter web traffic, but they treat it as a productivity tool rather than a security control. The filtering policy blocks social media and gambling sites while leaving the actual threat surface untouched. When ISO 27001 Annex A control 8.23 appears on an audit checklist, the gap between “we have a web filter” and “we have a web filtering control” becomes uncomfortably visible. Understanding what 8.23 actually demands, and why a category-based blocklist alone won’t satisfy it, is the difference between passing an audit and reducing real risk.

What 8.23 requires

ISO 27001 Annex A 8.23 requires organizations to implement technical controls that restrict access to external websites deemed malicious or prohibited by policy. The control’s official objective is to reduce the risk of malware infection and enforce acceptable use policies across all endpoints that access the internet.

This is a preventive control, not a detective one. The goal is to stop users from reaching dangerous destinations before any damage occurs, not to identify compromises after the fact.

Meeting the requirement means addressing three dimensions:

• What to filter: Define blocked categories based on both policy (gambling, adult content, file sharing) and threat intelligence (known malware domains, phishing infrastructure, Command and Control (C2) servers). Category-based filtering alone isn’t sufficient if it doesn’t incorporate real-time threat feeds.
• How to filter: Deploy technical enforcement through DNS filtering services, Secure Web Gateways (SWGs), proxy servers, or endpoint-based web filtering agents. The mechanism matters less than the coverage. Every path to the internet needs a filtering enforcement point.
• How to handle exceptions: Establish a formal exception process with documented business justification, named approvers, and time-limited access windows. Permanent exceptions are policy erosion by another name.

The control deliberately avoids prescribing specific technologies, consistent with the broader ISO 27002 implementation guidance approach. What auditors evaluate is whether the organization has made deliberate, documented decisions across all three dimensions and whether those decisions are enforced consistently.

Why 8.23 matters

An employee receives a convincing phishing email referencing a recent invoice. The link points to a domain registered 48 hours earlier, hosted on infrastructure that threat intelligence feeds have already flagged. The employee clicks. Without web filtering controls, the browser connects directly to the site, a malware payload executes, and the attacker establishes persistence on the endpoint.

What follows is predictable. Lateral movement across the network using compromised credentials. Privilege escalation through cached session tokens. Data staged in cloud storage accounts for exfiltration. Business operations disrupted for days or weeks while the incident response team works to isolate affected systems, rebuild compromised endpoints, and determine what data left the environment.

The cascading costs extend well beyond the technical response. Legal and regulatory obligations trigger notification requirements. Customers and partners demand incident reports. Insurance claims require documentation of preventive controls that were or weren’t in place. The Verizon 2025 Data Breach Investigations Report found that vulnerability exploitation surged 34% year over year, with web applications remaining a primary initial access vector for attackers targeting organizations without adequate preventive controls.

The risk classes that 8.23 addresses directly are:

• Malware infection: Drive-by downloads and weaponized sites deliver payloads when users reach domains that filtering would have blocked. Ransomware, infostealers, and remote access trojans all rely on web-based delivery as an initial access technique.
• Data exfiltration: Unauthorized cloud services and file-sharing platforms provide attackers with convenient channels to move data out of the organization. Without filtering controls, these services are accessible to both users and malware operating on compromised endpoints.
• Regulatory penalties: Auditors and regulators expect evidence of preventive internet access controls. When a cybersecurity risk assessment reveals no web filtering capability, the gap creates both compliance exposure and increased liability in the event of a breach.

What makes this control worth sustained attention is that web-based threats evolve faster than most organizations update their defenses. A filtering configuration that was adequate six months ago may already have gaps that attackers are actively exploiting.

What attackers exploit

The absence of web filtering controls creates specific attack opportunities that threat actors actively target:

• No URL or domain categorization: Users can reach known malicious sites because filtering either doesn’t exist or relies on stale, manually maintained lists rather than automated threat intelligence feeds.
• Missing SSL/TLS inspection: Encrypted traffic passes through uninspected, allowing malware, C2 communications, and data exfiltration to hide inside HTTPS sessions that the network sees as benign.
• Outdated blocklists: Filtering rules that aren’t updated with current threat intelligence miss newly registered phishing domains and fast-flux infrastructure that attackers rotate daily.
• No endpoint filtering for remote workers: Employees working outside the corporate network bypass perimeter-based controls entirely, creating an unmonitored path to the internet. CrowdStrike’s 2025 Global Threat Report found that 79% of detections were malware-free, meaning attackers increasingly rely on legitimate web tools and identity-based techniques that perimeter-only filtering cannot intercept.
• Overly broad exception approvals: Exceptions granted without expiration dates or periodic review accumulate into permanent holes in the filtering policy that no one audits.
• Shadow SaaS and unauthorized applications: Web applications adopted outside Single Sign-On (SSO) visibility create data flows that filtering policies don’t account for and security teams can’t monitor. These gaps in attack surface management visibility compound the risk.

How to implement 8.23

Implementation requires both internal controls and the ability to assess whether your vendors maintain equivalent protections.

For your organization (first-party)

1. Define an acceptable use policy that specifies blocked categories by both policy type (gambling, adult content, file sharing) and threat class (malware, phishing, C2 infrastructure). The policy should reference the threat intelligence sources that inform category decisions.
2. Select and deploy technical controls appropriate to your architecture. DNS filtering services provide broad coverage with minimal infrastructure changes. SWGs offer deeper inspection capabilities including content analysis. Endpoint-based agents extend filtering to devices regardless of network location. Most organizations need a combination rather than a single technology.
3. Ensure coverage for remote workers. Cloud-based filtering services or VPN-routed traffic through corporate inspection points close the gap for employees working outside the office. If your filtering only applies to traffic traversing the corporate network, remote workers are unprotected.
4. Implement SSL/TLS inspection for encrypted traffic analysis. Document the privacy considerations, define which traffic categories are inspected, and communicate the inspection policy to users. Without TLS inspection, the majority of web traffic passes through filtering controls without meaningful analysis.
5. Establish a formal exception process. Every exception request should require a documented business justification, a named approver, and an expiration date. The FBI’s 2024 Internet Crime Report recorded 193,407 phishing complaints, making it the most reported cybercrime category. Exceptions that bypass phishing protections without time limits and review cycles create exactly the kind of exposure that attackers count on.
6. Configure logging and monitoring for both blocked and allowed traffic. Logs should capture enough detail to support incident investigation and demonstrate control effectiveness to auditors.
7. Communicate the policy to all users and include web filtering controls in security awareness training. Addressing human factors in cybersecurity means users should understand what is blocked, why it is blocked, and how to request legitimate exceptions.
8. Schedule regular reviews of filtering rules, blocked categories, exception logs, and threat intelligence feed effectiveness. Quarterly reviews are a common cadence, but high-risk environments may require monthly evaluation.

Common mistakes that undermine implementation:

• Deploying filtering on the network perimeter only, leaving remote workers with direct, unfiltered internet access
• Using category-based filtering without threat intelligence feeds for zero-day malicious domains
• Granting permanent exceptions instead of time-bound, reviewed access
• Not testing filtering rules before deployment, causing legitimate business applications to break and generating pressure to weaken the policy
• Treating web filtering as a set-and-forget deployment rather than a continuously reviewed control

For your vendors (third-party assessment)

When assessing vendors against 8.23 as part of your vendor risk management program, the goal is to determine whether they have implemented web filtering as a deliberate security control rather than relying solely on user awareness.

Key questionnaire questions:

• Do you implement technical web filtering controls? What categories are blocked?
• How are filtering exceptions handled? Is there a documented approval process?
• How frequently are filtering rules and threat intelligence feeds updated?
• Does filtering coverage extend to remote workers and cloud-based infrastructure?

Evidence to request:

• Web filtering policy document defining blocked categories and exception procedures
• Configuration screenshots or exports showing active filtering rules and threat feed integration
• Exception approval logs demonstrating the formal review process
• Filtering rule review records with dates and documented changes

Red flags during assessment:

• The vendor says “we rely on user training” without demonstrating technical filtering controls
• No documented exception process exists
• Filtering applies only to on-premises users with no coverage for remote endpoints
• No logging or monitoring of filtered traffic is configured
• Threat intelligence feeds are not integrated or have not been updated recently

Verification beyond self-attestation: Request a live demonstration of filtering controls blocking a test category, review recent exception logs for appropriate approval workflows, and confirm integration with current threat intelligence feeds. A structured third-party risk assessment process ensures these checks are consistent across your vendor portfolio.

Audit evidence for 8.23

Auditors expect specific artifacts that demonstrate both the existence and ongoing effectiveness of web filtering controls.

The key distinction auditors make is between evidence that a control exists and evidence that a control operates effectively. A filtering policy document satisfies the first requirement. Logs showing active blocking, recent exception reviews, and updated threat feeds satisfy the second.

Prepare for audit by maintaining a centralized evidence repository where these artifacts are stored and updated on a defined schedule. Auditors will look for consistency across artifacts. If your policy says exceptions expire after 30 days but your exception logs show approvals from six months ago still active, the gap undermines the entire control narrative. Review your evidence package quarterly, the same cadence as your filtering rule reviews, to ensure all documentation reflects current practice.

Cross-framework mapping

Organizations operating under multiple compliance frameworks can map 8.23 to equivalent controls, reducing redundant implementation effort and consolidating audit evidence. A single web filtering deployment can satisfy requirements across ISO 27001, NIST, SOC 2, and CIS benchmarks when the evidence is structured to demonstrate coverage against each framework’s specific expectations.

The NIST 800-53 mappings are the most directly relevant for organizations pursuing both ISO 27001 and FedRAMP or NIST-aligned certifications. SC-07 and SC-07(08) together address the full scope of 8.23’s web traffic filtering and proxy routing requirements. The partial mappings indicate controls that overlap with 8.23 in scope but address a broader or narrower set of requirements.

Related ISO 27001 controls

Control 8.23 operates within a network of related Annex A controls that reinforce each other when implemented together. Understanding these connections helps organizations design web filtering as part of a cohesive security architecture rather than deploying it as an isolated control. Auditors frequently trace these relationships during assessments, checking whether filtering logs feed into monitoring systems, whether endpoint configurations align with gateway policies, and whether the acceptable use policy matches what the technical controls actually enforce.

Frequently asked questions

What is ISO 27001 8.23?

ISO 27001 8.23 is an Annex A control that requires organizations to implement web filtering controls restricting access to malicious or prohibited external websites. The control reduces the risk of malware infection from drive-by downloads, phishing sites, and C2 servers, while enforcing acceptable use policies across corporate and remote endpoints.

What happens if 8.23 is not implemented?

Without web filtering controls, employees can reach known malicious domains, phishing pages, and malware distribution sites with no technical barrier. This creates direct exposure to ransomware, credential theft, and data exfiltration, and leaves the organization without audit evidence of preventive internet access controls.

How do you audit 8.23?

Auditors verify that technical web filtering controls are deployed, actively blocking prohibited categories, and generating logs. They check for a documented acceptable use policy, a formal exception process with approval records, and evidence of periodic filtering rule reviews.

How UpGuard helps

Web filtering controls restrict access to known threats at the network level, but they can’t identify which users actively create risk through unauthorized applications that never appear in filtering logs.

• User Risk: Discovers Shadow SaaS and Shadow AI usage that exists outside SSO visibility, where 50% of applications typically hide. When an employee adopts an unapproved tool, User Risk delivers real-time coaching at the moment of risk, explaining the security concern, showing their personal risk score, and suggesting an approved alternative. User Risk complements network-level web filtering by addressing the human risk dimension that technical controls alone cannot cover, turning risky behavior into measurable security improvement.