Start free trial

By Yair Knijn · April 3, 2025

The MSP owner who sold 'managed filtering' and can't prove which policy applies to which client

You put "managed filtering" on the invoice. The promise was that your team tunes web policy so the client never has to think about it. What nobody priced in was where the tuning would land. Your technicians had admin on the console, and every time a client phoned about a blocked vendor portal or a false positive annoying the front desk, the fastest fix was the one in front of them, on that one machine. Do that across three years and sixty tenants, and "managed" becomes something you can no longer write down.

This lands on the owner, because you signed the contract. The tech who made the one-off change left eighteen months ago. The client holds an order line that reads "category-based web filtering, business-grade," their compliance officer wants you to produce it, and what you have is a console full of per-machine overrides and nothing that counts as an authority document.

How per-endpoint tuning becomes thousands of unique policies

None of those edits looked wrong on the day. One laptop needed *.payroll-vendor.com opened up. A reception PC needed streaming for the lobby screen. Reasonable, every time. But once the device is your unit of policy, each exception spins off a configuration that lives nowhere except on that one box. Four thousand endpoints will not settle into six clean profiles. They drift apart until no two are provably identical, and you can no longer reason about the fleet as a whole. People in the MSP tooling world call it policy sprawl: it bleeds margin and opens quiet security gaps, all because device-by-device edits never standardize.

When "what is enforced here" has no clean answer

Try it straight. For Client A: which categories are blocked, which feeds are live, what exceptions exist? With state scattered across machines, the only truthful reply is "give me a week to pull every device and diff them." You cannot hand that to a regulator, an insurer, or a client's lawyer. Selling a control means being able to evidence it, and a console that keeps configuration per machine has nothing client-level to export. Filtering being on is not the issue; being unable to show it is on, the same way, for the tenant named in the agreement, is.

Make the policy group the unit, not the device

Move policy up a level. Define what is enforced once, on a policy group, and attach devices to groups instead of editing devices. "Corporate Standard," "Front Desk," "Engineering" become the named things your contract points at. When a client asks what they pay for, you open the group, not a spreadsheet of hostnames.

Tenant isolation and the audit request

Multi-tenancy is not only about billing. When one client's auditor wants evidence, you have to produce that tenant's enforced policy without another client's rules leaking into the export. The console has to scope groups under a real tenant boundary, so a per-tenant report is built in, not a hand-cropped screenshot. If your separation is just visual grouping over a flat store, one misclick drops Client B's rules into Client A's audit pack. Proper isolation gives each tenant its own groups, exception list, and change log, and an export that is complete for that tenant and contains nobody else.

You don't fix this in a night. Read the effective policy off each device, cluster the real exceptions, and most collapse into the same dozen allow-lists repeated. Build groups for the common cases, fold the outliers into named exception sets, and cut over one tenant at a time. ClearScreen makes the policy group the thing a tenant maps to, so "what is enforced for this client" is one definition you can read, version, and export. To see the group model before you move a tenant, start with the feature overview.