Content filtering is a policy, not a product. The same rule can be enforced in four different places, and choosing the wrong one is why most deployments get switched off.
The short answer
Content filtering is the practice of restricting what people can reach from company devices and networks. It covers everything from blocking known malicious sites to enforcing an acceptable-use policy, and it can be applied at the name lookup, in the web request, on the endpoint or in email. The technology is a detail. The policy decision comes first.
Two very different objectives hide inside content filtering, and confusing them is the most common reason a rollout fails.
On this page
The four content filtering layers
| Layer | What it can enforce |
|---|---|
| DNS filtering | Block or allow a whole domain, across every protocol, before any connection is opened |
| URL filtering | Allow one page and refuse another on the same site, plus warn, log or apply a quota. Requires decryption for real depth |
| Endpoint agent | The same policy applied on the device, so it holds on a home network or a hotspot rather than only inside the office |
| Email filtering | Malicious links and attachments removed before delivery, which is where most harmful content actually arrives |
Secure web gateways bundle the middle two and add inspection of the response body. In a SASE architecture that gateway is the delivery vehicle. None of that changes the policy question underneath.
Two jobs that get confused
| Question | Acceptable use | Threat blocking |
|---|---|---|
| Purpose | Productivity, legal exposure, workplace conduct | Stopping malware, phishing and data theft |
| Owner | People or legal team | Security team |
| Typical categories | Gambling, adult content, streaming, social | Malware hosts, phishing pages, newly registered domains, command and control |
| Cost of a false block | An annoyed employee | The same, but the alternative is an incident |
| Cost of a miss | Wasted time or a conduct issue | A compromised device |
| Right default | Warn rather than block | Block outright |
Do not run both on one policy
Threat categories should be blocked silently and without exception, because nobody has a legitimate reason to reach a command and control server. Acceptable-use categories should mostly warn, because the judgement is contextual and a marketing team genuinely needs social platforms. Companies that apply one severity to both either block too much and generate a permanent exception queue, or loosen everything to stop the complaints and lose the threat blocking along with it.
Choosing where to enforce
The right content filtering layer depends less on the feature list than on where your people actually work.
| Situation | Where to enforce |
|---|---|
| Fully remote or hybrid team | Endpoint agent. Network-level policy stops applying the moment someone leaves the office |
| Small team, threat blocking only | DNS filtering. Covers all protocols, deploys in hours, needs no certificates |
| Regulated acceptable-use obligation | URL filtering, because category evidence and per-user records are usually what the obligation requires |
| Need to block one path on an allowed service | URL filtering with decryption. Nothing shallower can distinguish two pages on the same domain |
| Most harmful content arrives by mail | Email filtering first. Filtering the web while leaving inbound mail unfiltered protects the wrong door |
| Contractor or unmanaged devices | None of these reach them. Restrict what those devices can access through private access instead |
Where content filtering fails
| Failure | What happens |
|---|---|
| Over-blocking | Staff route around it with personal devices and hotspots, which removes visibility entirely rather than reducing risk |
| Encrypted DNS | Browsers resolving names through their own provider skip network policy silently, and nothing appears in the logs |
| Unmanaged devices | Contractor laptops and personal phones carry no agent, so the policy simply does not exist for them |
| Stale categories | New domains are uncategorised on the day they are used, which is exactly when a phishing site is most dangerous |
| Shared hosting | The malicious page sits on a platform you cannot block without blocking a service the business depends on |
| No exception process | Every block becomes a support ticket, and eventually someone widens the policy to stop the tickets |
The pattern in most of those is the same. Filtering that people experience as unreasonable does not get tightened, it gets bypassed, and a bypassed control produces neither protection nor evidence.
Where Osto fits
Content filtering runs inside the endpoint module rather than as a network appliance or a proxy you operate. That placement is the point: policy travels with the laptop, so it holds on a home network, in a coworking space or on a mobile hotspot, where anything configured at an office gateway stops applying the moment the device leaves.
The layers around it come from the same stack rather than from four vendors. DNS filtering covers traffic that never touches a browser. Inbound email security handles the door most harmful content actually arrives through. Endpoint protection deals with anything that does get downloaded, device control governs what can be copied off, and data loss prevention covers what leaves.
There is no break-and-inspect proxy and no certificate authority to distribute, which is a deliberate limit. If your requirement is per-path policy on decrypted traffic across a large managed estate, that is a gateway purchase. If it is enforceable acceptable-use and threat blocking that survives remote work, this is the shape that fits. Events land in one SIEM, and the records support the acceptable-use and malicious-code controls sampled under SOC 2, ISO 27001 Annex A and HIPAA.
Platform walkthrough
Policy that survives leaving the office
Content and DNS filtering enforced on the device, with email security, endpoint protection and data loss prevention behind them. One owner, one dashboard.
Book a demoEvidence from live controls · 200+ frameworks mapped · One platform, everything
Frequently asked questions
What is content filtering?
Restricting what people can reach from company devices and networks, covering both threat blocking and acceptable-use policy. It can be enforced at the name lookup, in the web request, on the endpoint or in email.
What is the difference between content filtering and DNS filtering?
Content filtering is the objective. DNS filtering is one way to achieve it, working at the domain level before any connection. URL filtering, endpoint agents and email filtering are the others.
Should content filtering block social media?
Usually warn rather than block. Whole teams have legitimate reasons to use those platforms, and a blanket block generates an exception queue that eventually gets widened. Reserve outright blocking for threat categories where no legitimate reason exists.
Does content filtering work for remote staff?
Only when enforcement sits on the device. Policy configured on an office network or gateway stops applying as soon as a laptop joins a home network or a hotspot, which for a distributed team is most of the time.
Is content filtering required for compliance?
No framework names it directly. SOC 2, ISO 27001 Annex A and HIPAA ask for protection against malicious code and for an enforced acceptable-use policy. Filtering with logs is a common way to evidence both.