URL Category Data for Managed Security Service Providers
An MSSP watches dozens or hundreds of client networks, each with its own firewalls, proxies and DNS services. Every one of them speaks a different category language, and the SOC has to make sense of all of it.
This guide is for MSSP product and SOC teams who want their own URL category data: for alert triage, threat hunting across tenants, services they run themselves and the reports clients read.
Where category data plugs into an MSSP
Category data is useful at almost every layer of a managed security business. The stack below follows the path of a single event, from client device to monthly report.
Category based lists pushed to client firewalls and resolvers keep policy the same across very different devices. Your own resolver or proxy can enforce categories directly.
Logs from every client arrive with domains but mixed category names. An enrichment step adds one consistent category set to every record.
Playbooks look up categories to raise or lower alert priority, close benign noise and open cases for risky site types.
Hunts search all clients for rare categories, such as remote access tools on servers or anonymizers on finance laptops.
Own-brand DNS filtering, AI usage visibility, guest network filtering or secure browsing services built on the same data.
Monthly reports by category show what was blocked, what was allowed and how habits changed after a policy update.
One category vocabulary across mixed client estates
Client A runs one firewall brand, client B a cloud proxy, client C a DNS service. Their logs label the same website three different ways, which makes cross-client hunting and reporting painful.
What arrives
- Client A: "Storage Services"
- Client B: "Web Storage"
- Client C: "Sharing Sites"
- Client D: no category at all
What your SOC sees
- All clients: Cloud Storage / File Hosting
- Same rules for every tenant
- Same report columns for every client
- Hunts that work across the whole base
Categories that matter in managed security
MSSPs use the full set of 59 categories for policy and reporting, but a smaller group carries most of the SOC value. Definitions are on the category list.
| Category | SOC triage | Hunting | Client reports | Why |
|---|---|---|---|---|
| Malware / Phishing / Suspicious | High | High | High | Direct risk label for blocks, alerts and incident cases. |
| Remote Access Tools | High | High | Medium | Unexpected remote access is a common step in intrusions and scams. |
| VPN / Proxy / Anonymizers | Medium | High | Medium | Bypass of client controls and possible exfiltration routes. |
| Cloud Storage / File Hosting | Medium | High | High | Data leaving through personal storage, and payloads arriving from it. |
| Parked / For-Sale Domains | Medium | Medium | Low | Often staging for attacks or typo traffic worth a look. |
| Cryptomining | High | Medium | Medium | Mining traffic on business devices points to compromise or misuse. |
| AI / LLM Tools | Low | Medium | High | Clients ask which AI tools staff use and whether policy is followed. |
| Gambling, Adult | Low | Low | High | Acceptable use topics that clients want reported, not SOC alerts. |
Own data or a hosted filter?
Many providers start by reselling a ready service and later want the data inside their own platform. Both paths are valid, and they suit different stages; if you want a ready multi-client DNS filter, read the hosted DNS web filter for MSPs guide instead.
Hosted filter you resell
- Fast start with no engineering
- Client accounts and reports ready made
- Good for smaller MSPs and pilots
- Data stays in the hosted service
- Limited use inside your own SOC tools
Licensed category data
- Runs inside your SIEM, SOAR and resolvers
- One vocabulary across all client devices
- Powers several services from one source
- Works on-premise and air-gapped
- Needs your team to build and run the pipeline
Delivery: files, API, real-time lookup and export formats
An MSSP needs the data in several places at once. The same licence covers each of these forms, so one update job can feed the SOC, the resolvers and the client devices; file details are on the web filtering database page.
Database files
CSV, Parquet or JSON in your data platform for enrichment at ingest and at query time.
Lookup API
Included with licences for SOAR playbooks and analyst tools. See the API documentation.
Real-time lookup
A local index in your own resolver or proxy for in-line decisions with no outside calls.
Export formats
DNS RPZ, firewall external dynamic lists, hosts files and PAC files. See blocklist formats.
Freshness for a multi-client SOC
A new phishing domain can hit several clients on the same morning. Daily data means the first alert from one client protects the rest, and the look-back search finds who else was touched.
About 300,000 newly registered domains categorized and delivered as delta files.
New domains checked again as sites add content after launch.
A second recheck catches slower changes of purpose.
All other domains refreshed across the full database.
Playbook rules that use categories
Categories work best in SOAR playbooks as one input among several, never as the only reason to close or escalate. These rules show common patterns; tune thresholds with your own case history.
| Trigger | Category check | Extra condition | Playbook action |
|---|---|---|---|
| Outbound connection alert | Malware / Phishing / Suspicious | Any | Raise to high, isolate host if your client contract allows, open a case. |
| Outbound connection alert | Business, News/Media, Government & Legal | Domain older than a year and no other signals | Lower priority and close after automated checks, keeping the record. |
| New domain contacted | Parked / For-Sale Domains or no category | First seen across all tenants in the last day | Hold for analyst review and add to the watch list for the next delta. |
| Remote session started | Remote Access Tools | No open ticket with the client's IT team | Call the client contact and alert the on-call analyst. |
| Large upload | Cloud Storage / File Hosting | Personal account, outside working hours | Open a data handling case and notify the client's named contact. |
| DNS anomaly | VPN / Proxy / Anonymizers or Cryptomining | Server or kiosk device | Raise to medium and run the matching hunt across all tenants. |
Designing for many tenants
A multi-client SOC needs one shared copy of the category data and a thin layer of client-specific settings on top. Getting this split right keeps updates simple and client differences clear.
Shared across all clients
- The category database and daily deltas
- The mapping from device categories to your own
- Hunting queries and playbook logic
- Report templates and chart definitions
- Watch lists of new and parked domains
Set per client
- Which categories are blocked, warned or allowed
- Client allow and block lists that override categories
- Approved AI tools and file hosts
- Report recipients and language
- Escalation contacts and contract limits on response
Common pitfalls for providers
Providers that add category data to their SOC tend to meet the same problems in the first months. Each has a simple fix if planned early.
Overwriting device labels
Replacing the client device's category loses audit history. Keep both fields side by side.
Auto-closing too much
Benign categories lower priority but should not close an alert alone. Compromised good sites exist.
Forgetting the deltas
A database loaded once and left alone misses new attack domains within days.
One policy for all
A school, a clinic and a law firm need different category policies, even on the same platform.
Reports nobody reads
Show three or four categories that matter to each client, not all 59.
Wrong licence scope
Data that ends up inside a client-facing portal needs an OEM licence, not only internal use.
Services an MSSP can build on category data
Once the data runs inside your platform, the same source can support several billable services. These are the ones providers most often add.
Own-brand DNS filtering
Category policies per client on your own resolvers, with your name on the block page.
AI usage visibility
Reports on which AI tools staff use, drawn from 11,800+ AI-tool domains in 18 categories and 165 subcategories.
Acceptable use reporting
Monthly summaries by category for HR and management, without content inspection.
Guest and site Wi-Fi filtering
Simple category policies for branches, shops and visitor networks.
Policy harmonization
One baseline policy pushed to every client device, whatever the brand.
Compliance evidence
Category based records that support audit questions about web controls.
Secure browsing for remote staff
Category policy that follows laptops off the client network through your own resolver or agent.
Onboarding health checks
A first-week report for each new client showing which risky categories its users already reach.
Vendor risk snapshots
A category check of the websites a client depends on, flagging parked or changed supplier domains.
Examples from managed security providers
These scenarios show category data at work in a provider's daily operations. Each uses only domain categories plus data the provider already collects for its clients.
Noise cut in the alert queue
A playbook closes alerts for established business and news sites after checks, and lifts alerts for parked and new domains. Analysts spend their time on the cases that matter.
One hunt, all tenants
After a spike in remote access scams, one query finds every client device that reached a Remote Access Tools site outside IT hours in the past week.
Data handling report
A monthly report shows uploads to personal file hosts per office. Clients use it to adjust policy and training.
Policy in many formats
The same "block anonymizers" rule ships as an external dynamic list for firewalls and as RPZ for client resolvers, built from one source.
Same rules in 400 shops
Guest and staff networks in every shop get the same category policy from one source. A new shop is covered the day its router comes online.
Morning phishing wave
A new phishing domain arrives in the daily delta. The look-back search finds two clinics that reached it the evening before, and both get a case within the hour.
Rollout plan for an MSSP
Most providers roll out in this order, because enrichment pays off first and builds trust in the data before it drives enforcement.
Load the database centrally
Import the file into your data platform, keyed by host and registered domain.
Enrich at ingest
Add the category to every log record from every tenant, keeping the device's own label in a separate field.
Tune playbooks
Use categories to set alert priority and to auto-close clear benign noise after checks.
Build cross-tenant hunts
Save hunts for rare categories and run them after every daily delta.
Ship client reports
Add category charts and trends to monthly reports.
Enforce where you control the path
Use the local index in your own resolvers and push exports to client devices.
Add new services
Launch AI usage visibility or own-brand filtering on the same data.
Choosing a licence
MSSPs sit between internal users and product vendors, so licence choice depends on where the data runs. Details are on the OEM licensing page.
Internal use
- Enrichment, triage and hunting in your SOC
- Reports you write for clients
- Lookup API included
OEM
- Categories inside a platform or portal clients use
- Own-brand filtering services
- Group-wide terms for several products
MSSP questions
Why does an MSSP need its own URL category data?
Client estates mix many firewalls, proxies and DNS services, each with its own category names. Your own data gives the SOC one vocabulary for triage, hunting and reporting across every client.
Where does category data plug into a SOC?
Most often as an enrichment step in the SIEM or data platform, inside SOAR playbooks, in hunting queries across tenants and in monthly client reports.
How is this different from a hosted DNS filter for MSPs?
A hosted filter is a ready service you resell. Licensed category data is raw material for a provider that runs its own SOC, resolvers or reporting and wants the data in its own systems.
Which delivery format suits an MSSP?
A central database file in the SOC data platform, the lookup API for playbooks, and export formats such as RPZ, external dynamic lists or hosts files for client devices.
How fresh is the data?
About 300,000 newly registered domains are categorized every day as daily delta files. Each is checked again after a week and after a month, and all other domains are refreshed monthly.
Which licence does an MSSP need?
If the data stays inside your SOC, an internal use licence may fit. If categories run inside a product or platform your clients use, choose an OEM licence.
Can category data help with client compliance reports?
Yes. Reports by category, attempts to reach anonymizers or unapproved AI tools, and trends over time give clients clear evidence for audits and board meetings.
Does the data include AI tool categories?
Yes. The AI tools set covers 11,800+ AI-tool domains in 18 categories and 165 subcategories, which supports AI usage visibility services.
Should the SOC look up the full host or the registered domain?
Look up the full host first, then fall back to the registered domain. Large platforms and shared hosts can carry different categories on different hosts, and the host level label is the more precise one.
Can we keep client log data inside our own environment?
Yes, the database files run inside your own platform, including on-premise and air-gapped deployments, so client logs never need to leave your environment for enrichment. Send only bare domains to the API when you use it for misses.
One category set for every client you protect
Tell us how many clients you serve, which devices they run and where your SOC data lives. We will suggest the data layout and licence that fit.
License the database OEM licensing