By Yair Knijn · March 17, 2025

When the auditor asks 'why was this blocked,' and the GRC lead has no answer to give

The GRC lead brought a dashboard to the NIS2 surveillance audit: block counts trending up, a green tile reading "web filtering: active," a screenshot of the category list. To her, the filter existing was the control. The auditor wanted something narrower, the per-decision record proving the filter did what the policy said on a given day, with nobody quietly turning it off. The filter was running; the evidence that it operated as designed was not.

What a security auditor actually asks for behind a block decision

Sampling control effectiveness is not about counts. The auditor picks one event and pulls on it. Show me this block, on this date, for this user. Which policy applied? What category triggered it, which feed sourced that category, what was the exact timestamp in UTC, and can you show nobody with rights to the policy touched it first? Each of those is a question about provenance, and a block-count tile answers none of them. ENISA's NIS2 guidance leans on ISO 27001:2022 control mapping for exactly this reason: it makes a single event traceable back to a documented control, a named owner, and a test result.

Why "the list blocked it" fails an evidence request

"The list blocked it" describes configuration, not operation. ISO calls the distinction design versus operating effectiveness: a control can be flawless on paper and silently broken in production, and the only way to tell them apart is a record of individual decisions you can sample.

The failure I run into most is detached evidence. The block lives in one system, the policy version in a wiki, the category feed in a vendor PDF, the admin who could have overridden it in an IAM export nobody joined to anything. Most NIS2 findings I have seen trace back to evidence that was disconnected, not absent.

Mapping block-decision logs to ISO 27001 Annex A and NIS2 audit duties

These logs map onto controls you almost certainly already claim. Annex A 8.15 and 8.16 cover the decision record, 8.23 is the web-filtering control whose operation you are proving, and 5.18 with 8.2 cover the override question. NIS2 Article 21 folds these into a duty to show measures are effective, not merely present. A defensible entry satisfies a sample on its own:

• The policy version in force at decision time, not just "current policy"
• The triggering category and the feed that supplied it, with a feed version or fetch time
• The subject and assigned policy group, so the auditor can confirm the right profile applied
• A trustworthy UTC timestamp and a tamper-evident chain, so the record cannot be quietly edited later

Building exportable per-decision evidence by default

Make the evidence a byproduct of enforcement, not a scramble the week before the assessor lands. If every block already writes that joined record at decision time, the request for one event becomes an export, not a reconstruction across four systems under a clock. That is the living evidence chain NIS2 and ISO 27001:2022 reward.

The override question: who could have whitelisted this, and did they

This is the question that ends weak audits. A block proves nothing if any admin could have whitelisted the destination without a trace. The control has to bound who can weaken it: who can edit the policy or add an allow entry, the exception approval path, and whether anyone used that right before the event. "Nobody could have, here is the access record" answers it. "We are not sure who can change it" is a finding.

ClearScreen writes a per-decision record for every block, carrying the policy version, the category and its feed, the subject's policy group, and a UTC timestamp, exportable as audit evidence. Change rights and exception approvals sit against the same group, so the override question has an answer first. If your filter still produces only a block count, see how the decision record is structured on the security page.