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 Standard Actually Requires

Figure · Process

What A.8.23 asks you to do

The ISO 27001:2022 Text

Annex A 8.23 states:

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

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 recommends training personnel on secure/appropriate use of online resources, and putting rules in place defining acceptable use (including any necessary exceptions). Filtering should consider that techniques can be bypassed (e.g. via proxies/encrypted sites) and be combined with other controls.

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.

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.

Web-Threat Statistics

Indian Regulatory Context

• DPDP Act 2023: Web filtering supports "reasonable security safeguards" (Section 8(5)) by reducing malware/phishing that could lead to a personal-data breach.
• RBI / SEBI / IRDAI: Expect controls against malware and malicious web access for regulated entities, including secure web gateways/proxies.
• CERT-In Directions (2022): Web-access logs support incident detection and the 6-hour reporting obligation; threat-intel-driven blocking aligns with CERT-In advisories.
• IT Act, 2000 & acceptable use: Blocking illegal content and defining acceptable use intersect with legal obligations and organisational policy.

Industry-Specific Consequences

impact of Non-Compliance

Web filtering is inexpensive and preventive; the incidents it stops, ransomware, credential theft, data exfiltration, are premium-tier 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 (it can be bypassed).

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 (full version in the toolkit):

Web Filtering Policy — Acme Technologies Pvt Ltd (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.

Risk Assessment and Treatment

Audit and Compliance Checklist

(Full 25-question version in the toolkit 04-audit-evidence-checklist.md.)

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 (Singahi-guided, 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 (Singahi-guided, 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

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. Vendors: Zscaler, Netskope, Cisco Umbrella, Cloudflare, Palo Alto Prisma Access.

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, and CERT-In advisories) 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)

Target L3 for certification; distributed/remote workforces should pursue 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.
• In India, A.8.23 supports DPDP safeguards, RBI anti-malware expectations, and CERT-In 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? It is a strongly-expected preventive control; if you have users browsing the web, you should implement and be able to evidence web filtering. Declaring it not-applicable is rarely defensible.

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: 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); training; bypass awareness); 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.
• CIS Controls v8, Control 9 (Email & Web Browser Protections).
• PCI DSS v4.0, Requirements 1 and 5.
• SOC 2 (TSC 2017), CC6.6, CC7.1; COBIT 2019, DSS05.01.

Indian regulations

• Digital Personal Data Protection Act, 2023, Section 8(5).
• RBI / SEBI / IRDAI, anti-malware/web-access expectations.
• CERT-In, Directions under Section 70B of the IT Act, 2000 (2022); advisories.
• IT Act, 2000, acceptable use / illegal content.

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.