ISO 27001 A.8.23: Manage web access without encouraging bypasses

What A.8.23 requires in practice

Annex A control A.8.23 asks the organisation to manage access to external websites so that exposure to malicious content is reduced. It does not demand a specific filtering product or a fixed list of blocked categories. What it expects is a considered, managed approach.

In practice that means deciding which kinds of external resources people legitimately need, which kinds create risk, and how the organisation will restrict or manage the rest. Rules should cover the people and devices that actually browse, wherever they work. A route for requesting exceptions keeps legitimate work moving.

The outputs are defined web-access rules linked to information-handling expectations, a clear picture of where those rules are enforced, a process for reviewing exceptions, and guidance that helps users recognise and report suspicious pages. Whether and how far the control applies follows risk treatment and the Statement of Applicability.

Define safe access in the context of work

Identify the kinds of external resources employees need and the risks they create. Relevant concerns can include malicious content, misleading sign-in pages or unapproved services that accept sensitive uploads. Connect the rules with the organisation's information-handling expectations rather than treating web access only as a productivity issue.

Explain the distinction between a business-approved resource and a resource that has simply not been blocked. No filter can establish that every permitted page is safe in every circumstance. Users still need to recognise relevant warnings and report concerns through an accessible channel.

Choose coverage that follows the working pattern

Understand where filtering is enforced and which users, devices or connections are covered. An office-based control may operate differently for a remote worker or a temporary project device. Record material gaps and determine appropriate treatment instead of reporting full coverage based only on the main office network.

Coordinate filtering with malware protection and data leakage prevention. These controls address related concerns, but they are not interchangeable. Blocking a known harmful website does not by itself control every disclosure through an otherwise legitimate service.

Why web access management matters to the business

Much malicious activity reaches organisations through ordinary browsing: a counterfeit sign-in page, a harmful download or an unapproved service that accepts sensitive uploads. Reasonable management of web access lowers the chance that one click becomes an incident. It also affects productivity and morale. Rules that block legitimate work push staff towards personal devices and workarounds, creating the very exposure the control was meant to reduce. Customers handling sensitive data often expect proof of web protection in their supplier assessments. At audit, a sensible, tested arrangement shows that technology and people measures are working together.

How to implement A.8.23

Effective web access management balances protection with usability. The sequence below keeps both in view. Revisit the arrangement whenever employees start using a new kind of service or a new working location, because coverage tends to drift quietly. Involve both technical staff and a business representative.

1. Identify the external resources people need for their work and the risks different kinds of site create.
2. Define rules in business language, such as the categories to restrict and those that need approval.
3. Map where filtering is enforced and which users, devices and connections it covers, including remote and temporary work.
4. Record material coverage gaps and decide how to treat each one.
5. Set up a visible exception request route with an assigned reviewer, so staff do not improvise.
6. Brief users on warnings, misleading pages and how to report concerns.
7. Coordinate with malware protection and data leakage prevention, since each covers a different part of the problem.
8. Test behaviour using safe designated test resources and review rules as working patterns change.

Evidence an auditor expects for A.8.23

An auditor will check that web rules are real and cover the way people actually work. Evidence may include:

• the web-access rules and how they relate to the information at risk
• a statement of where filtering applies and which devices fall outside it
• records of exception requests, reviews and outcomes
• observation of a safe test showing a restricted category is handled as intended
• awareness material or interview responses showing staff know how to report a suspicious site

Coverage records for remote devices are especially persuasive.

Common nonconformities with A.8.23

Findings usually concern coverage and exceptions rather than the technology itself. Most arise because rules were configured once for the main office and then left alone, so an auditor tests the situation of a remote worker as well as a desk-based one.

• Filtering enforced on the office connection only, with remote devices uncovered and unrecorded.
• No exception process, leaving staff to use personal devices for blocked but legitimate resources.
• Exceptions granted broadly and never reviewed.
• Web filtering assumed to replace malware protection or data leakage controls.
• Rules never tested, so nobody knows how they behave.

Illustrative BPO example: a legitimate resource is blocked

Illustrative construction example: a project laptop away from the office

A hypothetical construction company configures web filtering on its office connection. A project laptop regularly uses approved remote connectivity at a temporary site, but nobody has verified whether the same relevant protection applies there. A central report counts the laptop as an enrolled device and implies that it is fully covered.

The company tests the intended filtering behaviour using a safe designated test resource on the actual approved connection. It addresses the gap and records the circumstances covered by the check. The example shows why enrolment status and office test results should not be extended automatically to every working location.

Manage exceptions and warnings consistently

Exceptions should have an owner, a reason and an appropriate review condition. A request to access one resource should not silently become unrestricted browsing for an entire team. Review whether exceptions remain necessary after the project or customer requirement ends.

Train users on what to do when a browser or security service presents a warning. They should understand when to stop and seek support rather than treat every prompt as an obstacle to dismiss. Relevant awareness can be developed through ISO/IEC 27001 Awareness, followed by instruction on the organisation's actual reporting and exception routes.

Test both protection and legitimate access

Useful evidence includes the intended coverage, rule rationale, user guidance, exception decisions and safe test results. These are practical methods rather than a requirement for separate documents with fixed names. Consider applicable privacy and other obligations when collecting or reviewing browsing information, and restrict access to that evidence appropriately.

Use authorised harmless test resources suitable for the technology. Verify expected restrictions and representative permitted work without visiting real harmful sites. Check the support process too: a control is easier to sustain when users can obtain a timely, accountable decision about legitimate needs.

Common failures include unreviewed broad exemptions, remote coverage assumptions and success measures based only on the number of blocked pages. Through ISMS evaluation, review meaningful gaps and recurring workarounds. Use monitoring where relevant to understand signals, while avoiding the claim that a clean report proves every web interaction was safe.