How to Set a Workplace Screen Policy Without Becoming the Police

Most companies that put filtering on their network do it badly, and the failure is almost never technical. The lists work. The configuration works. What goes wrong is that a group of adults discovers, on a random Tuesday, that a machine has started deciding what they are allowed to read, with no warning, no stated reason, and nobody obvious to ask.

The result is predictable. People find workarounds, trust drops a little, and the policy quietly becomes something the company pretends to have.

This is a guide to the other version: deciding what you actually want, saying it out loud, and configuring the smallest thing that achieves it.

Separate the two policies, because they are not the same

There are two completely different reasons a company puts a filter on its network, and merging them is the most common mistake.

Security filtering blocks phishing pages, malware infrastructure and known-bad domains. Nobody has ever objected to this. It costs the team nothing, it protects them personally as well as the company, and it needs no negotiation. If you do only one thing, do this one.

Distraction filtering blocks sites people would otherwise choose to visit. This is a completely different act. It says something about how the company sees its staff, and it has a cost in trust that has to be paid for by an actual benefit.

Treat them as two decisions with two justifications. If you announce them as one thing, the uncontroversial half gets dragged into the argument about the controversial half.

Decide these five things before you configure anything

Write the answers down. The configuration takes twenty minutes; these are the part that determines whether it works.

1. What problem are you solving, specifically?

"People are distracted" is not a problem statement, it is a mood. "Our shared reception machine is used for personal browsing and it is visible to visitors" is a problem statement, and it suggests a narrow fix. So does "our support team is missing response targets in the afternoon." The narrower the problem, the narrower the policy, and narrow policies survive.

If you cannot state the problem specifically, the honest conclusion is that you have a management question rather than a filtering question. A filter will not fix an unclear brief, a bad manager or an unrealistic workload, and applying one to those situations tends to make people feel watched without making them more effective.

2. Who does it apply to?

Company devices? The office network? Shared machines only? A specific team? The default answer of "everyone, everywhere" is rarely the right one and is always the most expensive one in goodwill.

3. What is the exception route?

There will be a legitimate need you did not anticipate. Marketing needs the social platform you blocked. Someone in support needs a site that got categorised oddly. If the answer to "this is blocking my work" is a two-week ticket, people will route around the policy and you will never hear about the next problem.

Name a person. Commit to a turnaround, ideally same day. This single detail does more for acceptance than anything else on the list.

4. What will you look at, and what will you not?

This is the one to decide before you have the data rather than after. Aggregate numbers tell you whether the policy is doing anything. Individual browsing histories tell you about people's health, finances, politics and relationships, and once you have looked you cannot unlook.

The workable posture is to state publicly that you review totals, not individuals; to keep access to anything more detailed restricted and rare; and to define in advance the narrow circumstances where an individual review would be justified and who has to approve one. If you never write that down, the boundary will be decided by whoever is curious on a bad day.

Some teams go further and choose to keep no per-query records at all, which removes the question entirely. That is a legitimate option and worth considering before you assume you need the history.

5. How will you know if it worked, and when will you revisit it?

Put a date on it. Three months is reasonable. A policy nobody reviews is a policy nobody owns.

What to say to the team, and when

Announce it before it happens, not after. A week is plenty.

Cover four things, briefly:

• What changes. "From Monday, company laptops and the office wifi will block known phishing and malware sites, plus these three categories."
• Why. The specific problem, in one sentence. Not "to improve productivity."
• What it does not do. This is the part that buys you the most credibility and is the part most companies leave out. Say plainly that it applies to company devices and the office network, that you are not reviewing individual browsing, and what the scope stops at.
• Who to ask. A name, and how fast they will answer.

Then, importantly, do what you said. The first time someone reports a wrongly blocked work site and gets it fixed within the hour, the policy stops being a rumour about management and becomes a normal piece of infrastructure.

Language matters more than you think

The words you use to describe this shape how people receive it. Avoid framing it as watching people. Describe it as what it is: a network setting that removes a class of bad connections and a small number of categories the company has decided are not for work devices.

It is also worth being clear internally that this is not the same as monitoring individuals, because the two get conflated by default and people will assume the worse of the two unless you say otherwise.

Start with the smallest version that solves the problem

A pattern that works for most teams under two hundred people:

1. Turn on security filtering everywhere. Phishing, malware, known-bad infrastructure. No announcement needed beyond a note that it exists.
2. Do nothing else for a month. Watch aggregate traffic. You may find the distraction problem you assumed you had is not visible in the data, which saves you a policy you did not need.
3. If there is a real problem, apply the narrowest fix. One profile for shared or public-facing machines rather than a company-wide rule. A category rather than a list of individual sites.
4. Revisit on the date you set. Loosen anything that has caused more friction than benefit.

This works technically because policies can differ per profile rather than being one rule for the whole company, so a tighter setting on a kiosk machine does not have to become a tighter setting for the developer who needs broad access.

The part that has nothing to do with software

If your team is distracted, filtering will change where the distraction goes, not whether it exists. Someone who is bored, blocked or badly briefed will find something. The filter buys attention back at the margins; it does not manufacture engagement.

That is not an argument against doing it. It is an argument for being honest about what you are buying, so that when the policy does not fix the underlying thing, you look at the underlying thing rather than tightening the filter.

If you want to try it

The lightest possible start is one profile for shared devices with security filtering on, watched for a week. That tells you what your own traffic looks like before you make any decision about categories.

You can create an account on the free tier, or read the setup guide to see what pointing a device or a router involves.

Related reading

• What a DNS Layer Actually Stops Before It Reaches Your Team
• DNS Filtering for Business: Block Malware, Phishing, and Distractions Without an Agent