July 14, 2026
Custom blocklist categories: when the standard taxonomy isn't enough
Public category lists like UT1 and StevenBlack are excellent at what they cover: ads, phishing kits, gambling, adult content, AI chat tools — the domains millions of organisations want to control. What they cannot know is what only your organisation wants to control. Every fleet eventually collects a handful of domains that fit no public category, and how you handle them decides whether your policy stays auditable.
The domains no public list will ever have
The recurring cases: a terminated vendor whose portal should no longer receive logins. A competitor's careers page during a retention-sensitive quarter. A sector-specific forum that is a legitimate site for the world and a compliance problem for you. A file-sharing service that is fine in general but banned by one client contract. These are policy decisions, not threat intelligence — no feed will ever ship them, and they do not belong hand-edited into a hosts file where nobody can attest to them later.
The anti-pattern: the unstructured exception list
Most filtering products offer a flat tenant blocklist, and that is where governance goes to die. A single undifferentiated list of 400 domains, added over four years by admins who have since left, with no record of why any entry exists. When an auditor — or an employee's lawyer — asks why a specific domain was blocked, "it's on the list" is the whole answer. The block is enforced but unexplainable.
Categories are the governance unit
The fix is to give in-house blocks the same shape as public ones: named categories with a label, a defined domain set, and an on/off toggle per policy. "Offboarded vendors" and "Client-X contractual exclusions" are auditable objects — each block event records which category fired, the category explains itself, and when the client contract ends you switch one toggle instead of archaeology across 400 rows.
How ClearScreen implements it
Business-plan tenants define up to 20 custom categories with up to 2,000 domains each, managed in the same policy editor as the standard taxonomy. Custom categories ride the same enforcement path as everything else: agents receive them with the signed policy sync, cache them for offline enforcement, and block events carry the category name into the audit trail. The always-on security categories — malware, phishing, C2, stalkerware — stay enforced regardless; custom categories extend policy, they cannot weaken it.
Domains are validated on entry (real hostnames only), labels are required, and each category is tenant-scoped — an MSP managing several tenants keeps each client's exclusions in that client's tenant, which is the isolation story flat per-endpoint edits can never give you.
Keep the bar for entry
One discipline makes this work long-term: every custom category needs an owner and a review date, exactly like a firewall rule. The category structure gives you the audit surface; a quarterly fifteen-minute review of "does this category still need to exist" keeps it honest. That is a calendar invite, not a project.
Curious what the standard taxonomy already covers before you define your own? Run a few of your candidate domains through the free domain checker — a surprising share of "special" domains turn out to already be listed.