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 access 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 tenant policy the unit, not the device

Move policy up a level. Define what is enforced once for the client, and attach devices to that ruleset instead of editing machines one by one. Categories, allowlists, and blocklists become the named things your contract points at. When a client asks what they pay for, you open the tenant policy, 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. Isolation has to be a real boundary — separate storage and credentials — not visual grouping over a flat store. One misclick should never drop Client B's rules into Client A's audit pack. Proper isolation gives each tenant its own policy, 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. Collapse those into one tenant-wide ruleset, fold outliers into named allowlist entries, and cut over one client at a time. ClearScreen gives each customer a dedicated Customer Environment with one policy every enrolled device inherits — so "what is enforced for this client" is one definition you can read and export. To see the model before you move a tenant, start with the feature overview.