For authorised workplace policy and network review
Use real business requirements and supported functions. Domain blocking, content inspection, network isolation and activity reporting are separate controls; keep their evidence and limits clear.
Step 1 of 9
In this guide
Agree the filtering goal and authorised scope
Agree the filtering goal and authorised scope
Identify the actual requirement: reducing access to known scam/malware domains, applying workplace content categories, separating staff and guest policies, or understanding an existing block. Name the business policy owner and network administrator. Agree which sites, devices, networks and remote users are included before changing a shared connection.
If somebody has already supplied credentials, approved an unexpected sign-in, downloaded something suspicious or lost money, use the relevant account, device, bank or incident response route promptly. Blocking the site afterwards does not undo the action or establish that the incident is resolved. Use the phishing guide for independent verification and next actions.
Keep suspicious links unvisited. Record only the minimum relevant domain/error, time and affected network privately. Do not open an adult, gambling or suspected scam site as a demonstration, and do not assume this guide authorises workplace monitoring, access to private devices or a production network change.
Define the exact goal, scope and responsible owners. Already-acted incidents need response; a new block is not remediation or permission to inspect private activity.
Next: Understand which filtering function is actually neededUnderstand which filtering function is actually needed
Understand which filtering function is actually needed
Protective DNS can refuse requests for domains recognised as malicious under its policies. A content-category filter may separately classify and block adult, gambling or other categories. Browser, endpoint and web-gateway controls can operate at different points. Confirm the actual supported functions rather than assuming any service called filtering provides all of them.
A DNS-level decision is generally about the requested domain, not every full URL, page, message or downloaded file. HTTPS encrypts web traffic; a basic domain filter does not automatically inspect the contents of encrypted pages. A permitted domain can still contain risky material or a compromised page. The Australian protective-DNS guidance describes blocking known malicious domains as one layer.
Brand-new scams, compromised legitimate sites, changing classifications and incomplete coverage can leave gaps. Some services offer controls for uncategorised/new domains, but availability, false positives and business impact need assessment. No filter can promise every new scam will be blocked. Retain supported device protection, updates, safer behaviour, account controls and a reporting process.
Separate malicious-domain decisions, content categories and page/file inspection. Verify actual capability and coverage; an allowed site is not a safety certificate and new scams can be missed.
Next: Record current coverage and preserve network continuityRecord current coverage and preserve network continuity
Record current coverage and preserve network continuity
Have the authorised administrator record the current network, filtering method, policy assignment and affected business services. Check whether the intended device is actually using the managed path and reporting where expected. Router settings, guest networks, managed browsers/devices, encrypted DNS, VPNs and mobile connections can affect coverage; do not change them to bypass or manufacture a block.
Identify essential dependencies such as name resolution, cloud apps, printers, approved remote work and authentication. Preserve the current approved configuration and agree a recovery plan before a change. Replacing DNS servers with a public address from a generic article can break internal names, management, service access or filtering, and is not a harmless universal fix.
Confirm whether remote devices need a separately supported managed arrangement. Coverage on office Wi-Fi does not establish protection on a home connection or mobile network. Do not claim every device is covered because one test computer shows a block. Record unknown or out-of-scope connections and who is responsible for them.
Confirm the actual managed path, assignments and dependencies before changes. Office Wi-Fi, guest, remote and mobile coverage differ; preserve the approved configuration and record unknowns.
Next: Agree categories and narrow exception handlingMore checks6 detailed checks
Agree categories and narrow exception handling
Agree categories and narrow exception handling
The business owner should define permitted use and required categories, including how adult or gambling content is handled at work. The administrator should check the service actually supports those categories and how classification, updates and uncategorised content behave. Do not apply a large preset list without considering essential services, legitimate business use and affected users.
For an approved change, confirm the exact policy, audience and domain/category effect before applying it through the supported management control. Pilot a limited authorised scope and retain continuity. The gateway guidance describes filtering capabilities; its advanced inspection controls are not a generic instruction to install interception certificates or decrypt staff traffic.
Agree a false-positive/exception process. The owner should assess the exact legitimate task, genuine destination, actual risk, affected scope and expiry/review date. Allowing a broad wildcard or whole category can undo useful protection. A narrow exception still carries risk and should not be approved solely because a user or unexpected caller asks.
Choose supported categories for the real business purpose and audience. Use limited approved changes and reviewed exceptions; do not blanket-allow or deploy advanced traffic inspection from a public checklist.
Next: Assign and check staff, guest and remote policiesAssign and check staff, guest and remote policies
Assign and check staff, guest and remote policies
If different rules are needed, confirm that the actual solution can assign policies to the intended networks, devices or identities. Have the administrator map the staff and guest scope explicitly and check for a more general rule that takes precedence. A shared address, anonymous device or unrecognised user can make identity-based reporting and assignment less precise than expected.
Keep visitor access separate from business access where the authorised network design requires it. Content filtering and network isolation are different controls: a visitor being blocked from one category does not prove business printers, storage or administration are isolated. Do not connect unapproved devices or attempt prohibited access to demonstrate separation.
Check the approved remote-work arrangements separately. Do not disable a VPN, encrypted DNS, browser protection or device management to make a policy appear to work. If required coverage cannot be established, record the gap and use the network/provider owner to assess a supported design instead of claiming universal enforcement.
Verify actual policy assignment for staff, guests and remote scope. A Wi-Fi label, category block or shared address does not prove isolation, identity attribution or offsite coverage.
Next: Diagnose a block or business-site failure without bypassDiagnose a block or business-site failure without bypass
Diagnose a block or business-site failure without bypass
Record the exact error or genuine block-page reason, requested domain, time, device and network. A content-category block, malicious-domain decision, certificate warning, unavailable service and ordinary DNS failure can look similar to a user. Avoid URLs containing private tokens or search terms in support screenshots; provide only what the responsible owner needs.
Ask the administrator to correlate the event with the actual policy and current service state. A request may come from an app, redirect, advertisement or background lookup rather than the page the user deliberately chose. For a legitimate service, independently verify the genuine address and necessary associated domains before considering an exception.
Do not click through certificate warnings, retry a suspicious destination through mobile data, change resolvers, add a broad allow rule or switch filtering off. If work is blocked, use a permitted existing alternative or preserve the task for the owner. A restored page should be checked under the intended policy, not accepted because a safeguard was bypassed.
Use the actual event and policy to distinguish a block from another failure. Keep secrets private and resolve a legitimate task without certificate bypass, alternate-path evasion or broad exceptions.
Next: Review block reports with context and appropriate accessReview block reports with context and appropriate access
Review block reports with context and appropriate access
Use the solution’s supported reporting view through an authorised account to review the agreed period, policy, domain/category, action and device/network context. Confirm time zone, reporting delay, available history and which connections are covered. The NCSC’s provider-selection guidance explains that reporting detail and integration vary between services; it does not establish this business has every feature.
A block count is not automatically a count of deliberate visits, unique users, infections or prevented losses. Apps, background requests, redirects and retries can generate events. Shared addresses and incomplete identity information can also limit attribution. Repeated events may deserve security investigation, but do not accuse a staff member or announce a compromise from one chart.
Agree who may see reports, what information is necessary, the approved retention and how findings are handled. Keep employee/customer browsing data and internal configuration private; do not circulate raw logs widely. Confirm appropriate organisational authority and applicable requirements before changing monitoring scope. Record reporting gaps instead of implying a complete browsing history exists.
Read authorised reports within their time, coverage and attribution limits. A blocked request is not proof of intent, infection or complete monitoring; restrict private log access and record gaps.
Next: Verify the agreed filtering scope with safe checksVerify the agreed filtering scope with safe checks
Verify the agreed filtering scope with safe checks
Have the administrator use a supported harmless test or policy-check method appropriate to the actual service. Confirm the intended staff/guest/device policy and agreed action without opening real malicious, adult or gambling material. Do not enter credentials or private business records into a supposed test page.
Check permitted essential tasks still work and confirm the agreed event appears in reporting with the expected context. Verify the actual network/device scope and separately record offsite, mobile or unsupported cases. A DNS block and a content-category block exercise different capabilities; one result does not prove both or every device.
Record the date, tested scope, expected/actual result, exceptions and owner of follow-up. Stop unrelated changes once the agreed policy works with required continuity. Keep category/threat updates and exception reviews owned. This limited test does not guarantee brand-new scams are caught, every bypass is impossible or the organisation meets a formal security standard.
Verify supported harmless tests, useful allowed tasks and actual reporting in the agreed scope. Record exclusions and stop unrelated changes; one block is not universal coverage or a future-scam guarantee.
Back to the symptom checkerGet help with the specific policy or coverage gap
Get help with the specific policy or coverage gap
Use the business/network owner for unsupported categories, unclear guest/remote coverage, false positives or unexplained reporting. Privately provide the device/network scope, minimal domain/error, event time and intended legitimate task. Do not send full browsing histories, internal management details, credentials or private URL tokens in an initial enquiry.
Our secure web filtering service can discuss the required function and a scoped assessment. Confirm actual supported categories, policy assignment, reporting, privacy/authority, continuity and verification before changes. Do not infer particular features, internal suppliers or round-the-clock human response from the generic word filtering.
If somebody has already acted on a scam or a genuine incident is suspected, follow the relevant response process rather than wait for a new filter rule. Filtering can reduce some risk; it is not a substitute for account/device recovery, payments response or the broader business security review.
Use an authorised scoped assessment for the actual function, event or coverage gap. Keep evidence minimal and private; active incidents need response rather than a claim a new filter undoes them.
