How to Audit ISO 27001 Control 8.23: Web Filtering

Auditing ISO 27001 Annex A 8.23 Web Filtering is the technical verification of content-based restrictions applied to outbound internet traffic. The Primary Implementation Requirement is the deployment of SSL inspection and automated malicious domain blocking, providing the Business Benefit of protecting users from web-borne malware and preventing unauthorised data exfiltration.

ISO 27001 Annex A 8.23 Web Filtering Audit Checklist

This technical verification tool is designed for lead auditors to establish the efficacy of controls restricting access to malicious or unauthorised external websites. Use this checklist to validate compliance with ISO 27001 Annex A 8.23.

1. Web Filtering Policy and Rulebase Formalisation Verified

Verification Criteria: A documented policy or technical standard exists defining the categories of websites to be blocked (e.g. malware, phishing, illegal content, or unauthorised file sharing).

Required Evidence: Approved Acceptable Use Policy (AUP) or Web Filtering Standard cross-referenced with the active category list in the filtering tool.

Pass/Fail Test: If the organisation lacks a formalised mandate defining which web categories are prohibited, mark as Non-Compliant.

2. Malicious Domain and IP Blocking Enforcement Confirmed

Verification Criteria: Technical controls are active to automatically block access to known malicious domains, C2 servers, and phishing URLs based on real-time threat intelligence.

Required Evidence: Configuration logs from the Secure Web Gateway (SWG) or DNS filter showing “High Risk” and “Malicious” categories set to ‘Block’.

Pass/Fail Test: If the filtering tool is configured to ‘Alert’ rather than ‘Block’ for confirmed malware or phishing categories, mark as Non-Compliant.

3. SSL/TLS Inspection for Web Traffic Validated

Verification Criteria: The organisation possesses the technical capability to decrypt and inspect encrypted web traffic (HTTPS) to detect hidden threats and enforce filtering rules.

Required Evidence: SSL Inspection certificates deployed to endpoints and logs showing decrypted URL paths in the web proxy or gateway.

Pass/Fail Test: If the organisation cannot inspect HTTPS traffic (covering over 95% of the web), rendering filtering rules blind to encrypted content, mark as Non-Compliant.

4. Unauthorised Cloud Storage and File Sharing Restriction Verified

Verification Criteria: Technical rules restrict access to unauthorised personal cloud storage and file-sharing sites to prevent data exfiltration.

Required Evidence: Filtering logs or CASB reports showing blocked attempts to access non-corporate storage platforms (e.g. personal Dropbox or Mega).

Pass/Fail Test: If a standard user can successfully upload sensitive corporate data to a personal file-sharing site without technical restriction, mark as Non-Compliant.

5. Remote and Mobile Workforce Filtering Alignment Confirmed

Verification Criteria: Web filtering controls remain active and enforceable for endpoints when operating outside the corporate network (e.g. via roaming agents or enforced VPN).

Required Evidence: Evidence of a “Roaming Client” installed on laptops or an “Always-On” VPN configuration ensuring traffic routing through the gateway.

Pass/Fail Test: If filtering is only active on-premise and endpoints are unprotected when connected to home Wi-Fi or public hotspots, mark as Non-Compliant.

6. Automated Threat Intelligence Feed Synchronisation Verified

Verification Criteria: The web filtering tool receives automated, high-frequency updates from reputable threat intelligence providers to ensure protection against emerging threats.

Required Evidence: System status logs showing the timestamp of the last successful signature or URL database update (e.g. within the last 24 hours).

Pass/Fail Test: If the URL database or threat signatures are updated manually or have not been updated for more than 48 hours, mark as Non-Compliant.

7. Web Filtering Bypass and Proxy Restriction Validated

Verification Criteria: Technical controls prevent users from bypassing web filtering through the use of unauthorised VPNs, TOR, or web-based anonymisers.

Required Evidence: Configuration logs showing the blocking of “Anonymisers,” “Proxies,” and “Encrypted Tunnels” categories.

Pass/Fail Test: If a standard user can bypass filtering by using a common web-based proxy or a browser-integrated VPN extension, mark as Non-Compliant.

8. Exception Management and Authorisation Records Identified

Verification Criteria: Requests for temporary or permanent exceptions to web filtering rules follow a formal approval process and are documented.

Required Evidence: Approved Change Request tickets or IT service desk logs justifying specific URL whitelisting for business purposes.

Pass/Fail Test: If URLs have been whitelisted without a documented business justification or an authorised approver, mark as Non-Compliant.

9. Administrative Access and Rule Modification Monitoring Verified

Verification Criteria: Access to the web filtering management console is restricted to authorised personnel and all configuration changes are logged.

Required Evidence: Audit logs from the filtering platform showing administrative logins and changes to the URL block-list.

Pass/Fail Test: If an administrator can modify filtering rules or whitelist a domain without a corresponding entry in an immutable audit log, mark as Non-Compliant.

10. Periodic Web Traffic Trend Review Recorded

Verification Criteria: Management or security teams perform regular reviews of web traffic trends and blocked categories to identify potential security incidents or policy gaps.

Required Evidence: Monthly/Quarterly Security Reports presented to management containing web filtering metrics and blocked threat trends.

Pass/Fail Test: If logs are collected but there is no evidence that management reviews blocked traffic patterns for signs of targeted attacks, mark as Non-Compliant.

Control Requirement	The ‘Checkbox Compliance’ Trap	The Reality Check
SSL Inspection	Tool checks if a “Web Filter” is marked as ‘Active’ in the asset list.	Verify Decryption. Without SSL inspection, the filter cannot see the full URL path or the payload. GRC tools often miss this massive blind spot.
Roaming Protection	Platform records that the organisation uses a “Cloud Proxy”.	Verify Enforcement. Check if the roaming agent is actually running on mobile devices. If it can be disabled by the user, the control is failed.
Malicious Domain Blocking	GRC tool identifies “Malware Filtering” is checked in a dashboard.	Test the Response. Attempt to access a safe test domain (e.g. EICAR). If the tool only ‘notifies’ but doesn’t ‘block’, it fails Annex A 8.23.
Exception Control	Tool identifies a “Whitelist” exists.	Verify Expiry. GRC tools miss “temporary” exceptions that were added three years ago and never removed. Demand a whitelist cleanup log.
Bypass Prevention	Tool assumes the firewall blocks all other ports.	Check for Anonymisers. Test if the filter blocks common proxy sites. GRC tools don’t perform active “bypass” testing.
Intelligence Updates	Platform records “Auto-updates Enabled”.	Verify Ingestion. If the gateway cannot reach the update server due to a firewall rule, the status is “Green” but the data is stale.
Categorisation Accuracy	Tool assumes SaaS categorisation is 100% correct.	Audit Uncategorised Traffic. Real auditors check what percentage of traffic is “Uncategorised” and allowed. High uncategorised flow is a pass for a GRC tool but a fail for a real auditor.

What is the difference between URL filtering and DNS filtering?

URL filtering operates at the application layer, allowing for granular path-level blocks and SSL inspection, while DNS filtering blocks at the domain name lookup level, providing a lighter but less granular defense.

Is SSL inspection required for ISO 27001 Annex A 8.23?

Yes. Since most malicious traffic is delivered via HTTPS, filtering without SSL inspection is technically ineffective and fails to provide the required protection defined by the control’s objective.

About the author