Setting up three policies is half the job. The other half is being able to answer, with evidence, "what did the student policy actually block this week — and did the staff policy behave differently?"
A multi-policy firewall that you cannot audit per policy is just a hopeful firewall. The good news is that this platform's reporting was built for the rack model: app events are recorded per policy, so the staff rack's Web Filter blocks and the student rack's Web Filter blocks are separate, readable stories. This page shows how to use reports the way Policy Manager intends — one policy at a time — both for a weekly sanity check and for the day someone senior asks whether the rules are actually being enforced.
| Policy | Look For | Healthy Sign |
|---|---|---|
| Staff | Blocked categories and top users | Only the categories you meant to block |
| Students | Block volume and repeat attempts | Blocks happening — the fence is being tested and holding |
| Default | Which devices appear here at all | Only guests and genuinely unknown devices |
Because each rack runs its own instances of the apps, each instance keeps its own events. The Web Filter in the student rack logs the sessions it processed; the staff rack's Web Filter has never seen them. When you open Reports and look at an app's events, you are therefore looking at one policy's world, and switching the report to another policy shows a different world. Admins who miss this read a single combined impression — usually the busiest rack — and conclude the whole firewall behaves that way. It does not. Always ask which policy is this report about before drawing any conclusion from it.
A routine that keeps a multi-policy setup honest:
Ten minutes a week sounds small, but it catches the two slow failures of policy setups — a group quietly living in the wrong policy, and a category blocked that a department actually needs — while they are still small.
Read the default policy's report differently from the others. For staff and students you read content; for the default you read names. Every device generating real traffic under the default is a device no rule claimed — guests, yes, but also the new staff laptop nobody reserved an address for, the replaced PC whose MAC changed, the lab machine on the wrong subnet. A weekly glance at the default's top hosts is the fastest audit of your rule coverage there is. When a device that should have a policy shows up here, the fix belongs in the rules or the DHCP reservations, not in the default policy.
Reports settle arguments. A teacher reports "the internet is blocked for my class", but the student policy's report shows normal traffic and a handful of correct category blocks — the class is filtered, not broken, and the conversation becomes about one specific site, which you can check and, if your rules allow, pass-list in that policy only. The opposite case matters too: a department insists its special access works, while its policy's report shows almost no events and the default's report shows its addresses. The evidence tells you the rule stopped matching before anyone wastes an afternoon inside Web Filter settings that were never the problem.
The Reports app can email scheduled reports, and with several policies the practical pattern is one scheduled summary per policy that matters — student and default weekly for a school's safeguarding file, staff monthly unless a manager asks otherwise. File them rather than deleting them: a three-month trail of per-policy reports is exactly what an auditor, a governor or your own future self wants when a question starts with "since when has this been happening?". Keep expectations honest, though — reports show what the firewall saw and did. They cannot show traffic that never crossed the firewall, such as a phone that switched to mobile data.
The video ends with policy application and a summary — combine that with these report checks and you have both halves of running Policy Manager well.
▶️ Watch Full VideoYou can review overall traffic at the firewall level, but app events such as Web Filter blocks belong to the policy that processed them. For enforcement questions — who was blocked, by which rulebook — read the report per policy. Combined views hide exactly the differences Policy Manager exists to create.
Run the Web Filter report for their policy for the period in question and export or email it. It shows the categories blocked, the volume and the devices, all from that policy's own app instance. Add the same period from the default policy if they ask about unknown devices.
Because no rule matched that PC, so the default processed it. Usual reasons are a changed IP address without a DHCP reservation, or a MAC condition that no longer matches. Fix the identity or the rule — the report has just shown you the gap.