ISO 27001 A.8.23: Web Filtering

Quick Reference (60 Seconds)

ISO 27001:2022 Annex A 8.23 requires that access to external websites be managed to reduce exposure to malicious content, keeping users away from malware, phishing, command-and-control and other harmful web destinations.

The Bottom Line: The web is the most common delivery channel for malware and phishing. Web filtering is a high-use preventive control: by blocking known-bad and risky destinations before a user reaches them, it stops a large share of drive-by malware, phishing landing pages, and command-and-control callbacks, cheaply and quietly.

What the Control Asks For

The ISO 27001:2022 Text

In short:

ISO 27001:2022 Annex A 8.23 asks organizations to manage access to external websites to limit exposure to harmful content.

Do you need this control?

A.8.23 is not mandatory in itself: under clause 6.1.3 you include it if your risk assessment calls for it, and record the decision in your Statement of Applicability. Include it if users browse the web from your devices or networks. If browsing is impossible in your environment, you may exclude it with that reason.

What ISO 27002:2022 Adds

The guidance says to reduce the risk of personnel accessing websites that contain illegal information or are known to host viruses or phishing material, commonly by blocking the IP address or domain of the sites concerned (many browsers/anti-malware tools do this or can be configured to). The organisation should identify the types of websites personnel should or should not access, and consider blocking:

• (a) websites with an information upload function, unless permitted for valid business reasons;
• (b) known or suspected malicious websites (malware/phishing distribution);
• (c) command-and-control (C2) servers;
• (d) malicious websites identified from threat intelligence (see 5.7);
• (e) websites sharing illegal content.

It also says:

• Set the rules before you deploy filtering. Define safe and appropriate use of online resources, including any restrictions on unwanted websites and web applications, and keep the rules up to date.
• Train personnel on secure and appropriate use of the web. Training should cover the rules, a contact point for raising security concerns, and the exception process for reaching blocked sites for legitimate business reasons.
• Train personnel not to overrule browser warnings that say a site is not secure but let the user carry on (certificate errors, safe-browsing warnings).

The "shall vs should" Analysis

What Auditors Actually Check

1. Web filtering is in place for users (on-network and ideally roaming).
2. Malicious categories (malware, phishing, C2) are blocked.
3. Threat-intelligence feeds inform blocking (link 5.7).
4. An acceptable-use rule defines permitted/blocked categories and exceptions.
5. Logging of blocked/allowed access supports monitoring and incident response.
6. Training covers the rules, the contact point, the exception process and not clicking through browser security warnings.

Why Web Filtering Matters

The Business Risk Narrative

Most malware and phishing arrive through the browser, a user clicks a link, lands on a malicious page, and is compromised by a drive-by download or tricked into entering credentials. Even after a phishing email slips through the mail filter, web filtering provides a second chance to block the payload when the user clicks the link. And when malware does land, blocking its command-and-control callbacks can prevent it from activating or exfiltrating data. Web filtering sits on the most-used and most-abused channel in the organisation.

How It Goes Wrong (hypothetical patterns)

• No filtering for home workers. The office proxy protects only people in the office; a remote employee opens a phishing link and enters their credentials.
• Click-through on a certificate warning. A user ignores a "your connection is not private" warning on a fake login page, and the account is taken over.
• Stale block list. The list was loaded once and never updated, so newly registered phishing domains get through.
• Unblocked C2. Malware lands on a laptop and calls home freely because nothing blocks known command-and-control domains.
• Uncontrolled uploads. Staff use personal file-sharing sites to move customer data, outside DLP.

Indian Regulatory Context

• DPDP Act 2023: web filtering supports the reasonable security safeguards required by section 8(5), by reducing the malware and phishing that lead to personal-data breaches.
• CERT-In Directions (28 April 2022): report specified incidents (including phishing and malicious code attacks) within 6 hours, and keep ICT system logs, which include proxy and DNS logs, for 180 days in India.
• CERT-In advisories and I4C: CERT-In publishes advisories with malicious domains and indicators, and the Indian Cyber Crime Coordination Centre (I4C, Ministry of Home Affairs) flags fraudulent apps and websites. Use them as feeds for 27002 8.23(d) where you can.
• Illegal content (27002 8.23(e)): always block content that is unlawful in India, for example child sexual abuse material (IT Act s.67B).
• Betting and online money games: the Promotion and Regulation of Online Gaming Act, 2025 prohibits offering and advertising online money games, and many states restrict gambling. Block these categories on corporate devices.
• RBI, SEBI and IRDAI: the RBI Cyber Security Framework in Banks (2016), SEBI's CSCRF (2024) and IRDAI's Information and Cyber Security Guidelines (2023) expect protection against malware and phishing; web filtering is a common way to meet that.

Industry-Specific Consequences

Impact of Non-Compliance

Web filtering is inexpensive and preventive; the incidents it stops, ransomware, credential theft, data exfiltration, are expensive and disruptive. As a layer in defence-in-depth, it quietly removes a large fraction of opportunistic web-borne threats before they ever reach the endpoint.

Scope and Applicability

What the Control Covers

• Outbound web (HTTP/HTTPS) access by personnel and systems, on the corporate network and (ideally) for roaming/remote users, and the policies, technologies and logging that manage it.

Who It Applies To

Every organisation whose users browse the web. Coverage must extend to remote/roaming users, increasingly the majority, via cloud-delivered filtering.

Size-Based Applicability

Key Definitions and Terminology

Relationship to Other Controls

A Layer in Defence-in-Depth

Web filtering is not a standalone control, it is a layer that works with anti-malware (8.7), threat intelligence (5.7), monitoring (8.16), and awareness (6.3). ISO 27002 explicitly notes filtering can be bypassed (encrypted/proxy sites), so it must be combined with endpoint protection and user vigilance. Its strength is catching the opportunistic and known-bad before it reaches the endpoint.

What to Block and Why

Blocking is risk- and business-based: an upload site may be essential for one team and blocked for everyone else, hence exceptions are defined, approved and logged.

Web Filtering Technologies

SSL/TLS inspection: most web traffic is encrypted, so deep filtering may require HTTPS inspection, implement with privacy safeguards (exclude sensitive categories like banking/health, inform users, comply with law).

Detailed Implementation Guidance

Define the Web Acceptable-Use Rule

Document which categories are permitted/blocked and the exception process (link A.5.10). This is the policy basis the technology enforces.

Deploy Filtering Covering All Users

Roll out an SWG/DNS filtering solution covering on-network and roaming users (cloud-delivered for the latter). Block malicious/phishing/C2 and illegal categories by default (27002 (b)–(e)).

Integrate Threat Intelligence (link 5.7)

Feed threat-intelligence (malicious domains, C2, phishing) into the filter so blocking stays current against emerging threats (27002 (d)).

Manage Uploads and Exceptions

Block uncontrolled upload/file-sharing sites except where a documented business need exists (27002 (a)); route exceptions through approval and review (link DLP A.8.12).

Consider HTTPS Inspection with Privacy Safeguards

Where deeper inspection is needed, implement TLS inspection with category exclusions (banking, health), user notice, and legal compliance (Section 10).

Log, Monitor and Tune

Log blocked/allowed access; feed logs to monitoring (A.8.16) for detection and incident response; tune categories to balance security and business friction; review false positives.

Train Users (link 6.3)

Train personnel on safe web use and why filtering exists; reinforce that filtering is a safety net, not a substitute for vigilance. Cover:

• the web-use rules and what is blocked;
• who to contact with a security concern (name a mailbox or channel);
• how to request an exception for a blocked site needed for work;
• never click through a browser security warning (certificate error, "deceptive site ahead"). Report it instead.

Harden the Browser

Filtering works best with a managed browser. Enforce safe-browsing, block click-through on certificate and safe-browsing warnings through browser policy, allow only approved extensions, keep browsers updated, and prevent users from switching off these settings.

Start with DNS Filtering if You Are Small

For an SME, protective DNS on office routers and on laptops (via the device's DNS settings or an agent) is a low-cost first step that blocks known malicious domains everywhere. Add a secure web gateway when you need category control or content inspection.

Privacy, Legal and Acceptable Use

Web filtering monitors and controls employee browsing, so balance security with privacy and law:

• Transparency: inform personnel that web access is filtered/logged (in the acceptable-use policy and onboarding), consistent with the DPDP Act 2023 principles where personal data is processed.
• Proportionality: filter and log for security, not surveillance; minimise personal-data capture; restrict access to logs.
• TLS-inspection exclusions: exclude sensitive categories (banking, health, personal mail) from decryption.
• Lawful basis & retention: retain logs for the security/legal purpose and period; comply with the IT Act and applicable law.
• Acceptable use (A.5.10): define permitted use and consequences clearly so enforcement is fair and defensible.

Web Filtering Policy (Template)

Illustrative extract (the Control Pack has the full policy):

Web Filtering Policy — [Organisation Name] (A.8.23)

1. Access to external websites is managed to reduce exposure to malicious content.

2. The following are blocked by default for all users (on-network and roaming):
   known/suspected malware and phishing sites; command-and-control servers; malicious
   domains identified via threat intelligence (A.5.7); illegal content; and uncontrolled
   upload/file-sharing sites (unless business-approved).

3. Filtering covers all users via [cloud SWG / DNS filtering]; threat-intelligence feeds keep
   block lists current.

4. Exceptions require documented business justification and approval, and are reviewed.

5. Web access is logged for security purposes; logs are protected, access-restricted, and
   retained for [period]. Personnel are informed of filtering and logging (acceptable use,
   A.5.10) consistent with the DPDP Act.

6. Where HTTPS inspection is used, sensitive categories (banking, health, personal mail) are
   excluded from decryption.

7. Users shall not click through browser warnings that a site is not secure. Managed browsers
   are configured to prevent it. Security concerns go to [security contact].

8. These rules are set before filtering is deployed and reviewed at least [annually].

Risk Assessment and Treatment

Audit and Compliance Checklist

(The Control Pack's audit evidence checklist (04) lists where to find the evidence for each question.)

Metrics and KPIs

Common Pitfalls and Audit Failures

Illustrative Scenarios

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative Scenario 1, Indian IT Services Company (Pune, 1,500 staff): Cloud SWG for a Remote Workforce

Challenge. After shifting to hybrid work, the company's on-premises proxy protected only office users; remote employees browsed unfiltered: and the security team saw a rise in phishing-driven credential theft and malware on home-connected laptops. An ISO 27001 audit flagged the lack of consistent web filtering as a control gap.

Solution (5 weeks).

1. Deployed a cloud Secure Web Gateway (SSE) with endpoint agents covering all users on and off network.
2. Enabled malware/phishing/C2 and illegal-content blocking with threat-intelligence feeds (link A.5.7).
3. Blocked uncontrolled upload/file-sharing sites (with an approval workflow), paired with DLP.
4. Updated the acceptable-use policy and informed staff (privacy transparency); fed web logs into monitoring (A.8.16).

Results. 100% of users, including remote, now filtered; phishing-domain access and malware detections dropped sharply; the ISO gap was closed and web logs became a useful incident-response data source.

Illustrative Scenario 2, Indian NBFC (Mumbai, 900 staff): Blocking C2 and Phishing

Challenge. A malware incident on a finance laptop succeeded partly because its command-and-control callbacks were not blocked and a phishing site had been reachable. The RBI-aligned review required stronger web controls and threat-intel-driven blocking.

Solution (4 weeks).

1. Implemented SWG + protective DNS with category and C2/phishing blocking.
2. Integrated threat-intelligence feeds and CERT-In advisories to block emerging malicious domains rapidly.
3. Enabled logging and monitoring of blocked/allowed access for detection and CERT-In reporting readiness.
4. Ran a safe-web-use awareness campaign (link A.6.3).

Results. C2 callbacks and known phishing domains now blocked; mean time to block a newly-flagged malicious domain fell to hours; the control satisfied the RBI-aligned review and the ISO 27001 auditor.

16A. Advanced Implementation Guidance

Figure · Tiers

Maturity levels for web filtering

16A.1 The Layered Web-Filtering Stack

Mature web filtering is layered, not a single appliance. DNS layer (protective DNS) blocks resolution of malicious domains cheaply and everywhere, an excellent first line, even for SMEs. Secure Web Gateway (SWG) inspects HTTP(S), applies category/malware policy, and can do SSL inspection. Endpoint/browser protections (safe-browsing, in-browser isolation) catch what slips through. CASB governs sanctioned/unsanctioned cloud-app use beyond simple URL filtering. The layers compensate for each other's blind spots, DNS filtering doesn't inspect content; an SWG might miss an uncategorised domain that DNS reputation flags.

16A.2 SSE / SASE for the Roaming Workforce

The single biggest modern gap is roaming users, staff browsing from home or on the road, beyond the office proxy. Cloud-delivered SWG, part of a Security Service Edge (SSE) / SASE architecture, follows the user via an endpoint agent or DNS, so filtering policy applies identically on and off network. For a hybrid workforce this is essential; an on-premises-only proxy protects only the people who are increasingly not in the office.

16A.3 SSL/TLS Inspection, Done Responsibly

The large majority of web traffic is encrypted, so without TLS inspection an SWG sees only domains, not content, missing malware delivered over HTTPS. Inspection requires decrypting traffic, which raises privacy and legal considerations. Do it responsibly: exclude sensitive categories from decryption (banking, healthcare, government, personal webmail); inform users transparently (acceptable-use policy, onboarding); restrict access to decrypted data and inspection logs; and ensure legal compliance (DPDP Act, IT Act). Where you choose not to inspect, compensate with strong endpoint protection (A.8.7) and DNS-layer blocking.

16A.4 Threat-Intelligence-Driven Blocking

Static block lists age into irrelevance within days, malicious domains are created continuously. Integrate threat-intelligence feeds (commercial, ISAC, CERT-In advisories and I4C alerts) so newly-identified malware, phishing and C2 domains are blocked automatically and quickly (27002 (d), link A.5.7). Track mean time to block a newly-flagged malicious domain (target: hours). This is the difference between a filter that stops yesterday's threats and one that stops today's.

16A.5 Category Strategy and Exception Management

Define a clear category policy: hard-block malicious/illegal/C2 for everyone; block uncontrolled upload/file-sharing (data-exfiltration risk, pair with DLP A.8.12) except for approved business use; and apply acceptable-use categories (e.g. adult/gambling) per policy. Run a lightweight exception workflow (justification + approval + review) and tune for false positives, over-blocking without a release valve drives risky workarounds (personal devices, anonymisers). Balance security with business friction deliberately.

16A.6 Web Filtering Maturity Model (L1–L5)

Certification does not require a set maturity level. Most organisations aim for L3; distributed or remote workforces should add L4 roaming coverage.

16A.7 Anatomy of a Web-Borne Attack (and where filtering breaks it)

A phishing email slips past the mail filter; the user clicks the link. Web filtering's first chance: the destination is a known phishing domain (from threat intel) and is blocked, attack stopped. If not, the user reaches a page that attempts a drive-by download; second chance: the malware-hosting domain is blocked, or endpoint protection catches it. If malware does execute, it tries to call home to its command-and-control server; third chance: the C2 domain is blocked, so the malware cannot activate or exfiltrate. Web filtering provides multiple independent opportunities to break the chain on the most-abused channel in the organisation, which is why it is such a high-use preventive control.

Key Takeaways

• Web filtering blocks the most common malware/phishing delivery channel: and gives multiple chances to break the attack chain (link → payload → C2).
• Layer it: DNS + SWG + endpoint + CASB, with threat-intelligence keeping block lists current.
• Cover roaming users via cloud SWG/SSE, an on-prem-only proxy protects the wrong population.
• SSL inspection catches encrypted threats, implement with privacy exclusions, transparency and legal compliance.
• Control uploads (pair with DLP) and manage exceptions/false positives to avoid risky workarounds.
• Train and enforce: no click-through on browser security warnings.
• In India, A.8.23 supports DPDP safeguards, CERT-In log and reporting duties, and advisory-driven blocking.

Multi-Framework Mapping

Implementation Roadmap

Phase 1, Policy & Quick Win (Weeks 1–2)

• Define the web acceptable-use rule and block categories.
• Enable DNS/category + malicious-domain blocking for all users (quick win).

Phase 2, Deploy & Integrate (Weeks 3–4)

• Roll out SWG/cloud SWG covering roaming users; integrate threat-intel feeds (5.7).
• Configure upload-site control and exception workflow.

Phase 3, Encryption & Privacy (Week 5)

• Decide on HTTPS inspection with privacy exclusions; finalise transparency/legal posture.

Phase 4, Assure (Week 6+)

• Logging + monitoring (8.16); tuning/false-positive process; awareness (6.3).
• KPI dashboard; internal audit dry-run.

FAQ

Q1: Is A.8.23 mandatory for certification? Not automatically: it is selected through risk treatment (clause 6.1.3) and recorded in your Statement of Applicability. If your users browse the web, you will normally include it and should be able to evidence web filtering. Excluding it needs a convincing risk-based reason.

Q2: Is DNS filtering enough? DNS/protective-DNS filtering is an excellent, cheap first line (great for SMEs), but for full coverage add a Secure Web Gateway (especially for category control and malware inspection) and ensure roaming users are covered.

Q3: Do we need HTTPS (SSL) inspection? Most threats ride encrypted traffic, so deeper inspection often needs HTTPS decryption, but implement it with privacy exclusions (banking, health), user transparency, and legal compliance. Where you don't inspect, compensate with strong endpoint protection.

Q4: How does A.8.23 relate to anti-malware (A.8.7)? They are complementary layers: 8.23 blocks access to malicious destinations; 8.7 detects/blocks malware on the endpoint/network. Together they form web-borne defence-in-depth.

Q5: How do we handle employee-privacy concerns? Be transparent (acceptable-use policy), filter/log for security not surveillance, restrict log access, exclude sensitive categories from inspection, and align with the DPDP Act and IT Act.

Q6: Should users be able to click past a browser's "not secure" warning? No. ISO 27002 asks you to train people not to overrule these warnings. Back the training with managed-browser policy that removes the option to proceed.

Q7: Users complain about over-blocking, what do we do? Run an exception/approval workflow and tune categories; balance security with business need. Over-blocking without a release valve drives risky workarounds.

References and Further Reading

Primary standards

• ISO/IEC 27001:2022: Annex A control 8.23.
• ISO/IEC 27002:2022: Clause 8.23 (categories to block (a)–(e); rules before deployment; training including browser warnings); related §8.7, §5.7, §5.10.

Supporting frameworks

• NIST SP 800-53 Rev 5: SC-7, SC-18, SI-3.
• NIST CSF 2.0: PR.IR-01, DE.CM-01.
• CIS Controls v8: Safeguards 9.1–9.4 (Email and Web Browser Protections).
• PCI DSS v4.0.1: 1.3.2, 5.4.1 and Requirement 5.
• SOC 2 (TSC 2017): CC6.6, CC6.8, CC7.1; COBIT 2019: DSS05.01.

Indian regulations

• Digital Personal Data Protection Act, 2023: Section 8(5).
• RBI Cyber Security Framework in Banks (2016); SEBI CSCRF (2024); IRDAI Information and Cyber Security Guidelines (2023).
• CERT-In: Directions under Section 70B of the IT Act, 2000 (2022); advisories.
• IT Act, 2000: s.67B (child sexual abuse material). Promotion and Regulation of Online Gaming Act, 2025 (online money games).
• I4C (Indian Cyber Crime Coordination Centre): fraud alerts.

Singahi resources: the A.8.23 toolkit and related guides for A.8.7 Protection against malware, A.5.7 Threat intelligence, A.8.22 Segregation of networks, and A.8.16 Monitoring activities.