How to Write a DNS Filtering Notice for Employees

QUICK ANSWER

Employees should be told why DNS filtering is used, which work resources and contexts it covers, what action the resolver may take, what activity may be retained, who can access it, how long it is kept, and how to question a block or inference. The notice should also state plainly what DNS data cannot reveal and avoid promising total security.

Published
May 25, 2026
Words
1,222 words
Reading time
6 min read

Employees should be told why DNS filtering is used, which work resources and contexts it covers, what action the resolver may take, what activity may be retained, who can access it, how long it is kept, and how to question a block or inference. The notice should also state plainly what DNS data cannot reveal and avoid promising total security.

The practical outcome is workplace transparency: a worker can understand the boundary before a problem occurs, while the operator has a disciplined checklist for policy and evidence. This is a plain-language governance model, not jurisdiction-specific legal advice. Have qualified counsel or a privacy professional review obligations that apply to your organization, workforce, sector, and locations.

Write for the affected worker

Lead with the real purpose, not the product. “We block domains associated with malware on company-managed devices” is understandable. “We monitor network activity for security and productivity” mixes purposes, exaggerates DNS visibility, and leaves the reader unable to predict what happens. If separate controls inspect web content, endpoints, email, or applications, explain those in their own accurate notices.

Name the boundary in ordinary terms: company office networks, managed laptops when connected through the approved resolver, a contractor resource group, or another defined context. Explain whether personal devices, guest networks, off-hours use, or remote connections are included. Do not imply coverage where a browser, VPN, operating system, or mobile network may use a different resolver path.

Include eight notice elements

  1. State each specific purpose, such as blocking known malicious domains or enforcing an approved-use category on named work resources.
  2. Define the people, devices, networks, profiles, and work contexts in scope, plus meaningful exclusions.
  3. Explain whether a lookup may be allowed, blocked, or redirected and what the worker sees when policy acts.
  4. Describe any retained fields and distinguish aggregate outcomes from detailed domain activity.
  5. Name the roles permitted to access detail, the approvals they need, and any recipients outside the organization.
  6. Give the retention period or the decision rule used to set it, including holds required for a specific investigation.
  7. Provide a route to report an incorrect block, request an exception, or challenge a conclusion drawn from DNS evidence.
  8. Name the notice owner, effective date, review date, and channel used to communicate material changes.

The UK Information Commissioner’s Office says transparency means being clear with workers about how and why their information is processed. Its monitoring guidance also emphasizes necessity, proportionality, and balancing an organization’s interests against workers’ rights and freedoms.1 Those are useful governance questions even when a different jurisdiction applies; they are not a substitute for identifying the law that actually governs your workplace.

Describe DNS evidence accurately

DNS filtering can evaluate a domain lookup and produce an allow, block, or redirect outcome. It cannot read page contents, full URL paths, search terms, in-app chats, voice audio, or full browser history. A query may come from a user action, browser prefetch, page dependency, update service, or background application, so it does not by itself prove intent, a successful connection, or content viewed.

The notice should acknowledge sensitivity without overstating precision. RFC 9076 explains that a DNS transaction can link an originator with query contents and that linked queries may expose use patterns.2 State that detailed activity is treated as sensitive, then explain the concrete safeguards: limited roles, scoped review, defined retention, protected exports, and a prohibition on unsupported person-level conclusions.

Adapt this employee notice template

We use DNS filtering on [covered work resources and networks] for [specific purposes]. When a covered resource asks to resolve a domain, the policy may allow, block, or redirect that lookup. DNS data can show the requested domain and policy outcome, but it does not show full web addresses, page contents, search terms, messages, voice audio, or complete browsing history. We routinely review [aggregate evidence]. Detailed activity is retained for [period or decision rule] and may be opened only by [roles] for [named purposes]. It is shared with [recipients, or “no external recipients”] under [safeguards]. Report an incorrect block, request an exception, or question an inference through [channel]. The owner of this notice is [role], and the next review is [date].

Replace every bracket with a verified fact. If the organization cannot name a retention rule, permitted reader, or challenge channel, the control is not ready for a transparent notice. Fix the operating practice rather than disguising the gap with broad language such as “as needed” or “authorized personnel.” Keep a separate concise summary only if it links to the complete notice and does not omit a material surprise.

Publish, test, and maintain the notice

  1. Inventory the actual resolver paths, policy actions, retained fields, readers, exports, and retention behavior before drafting.
  2. Ask security, privacy, HR, worker representatives where applicable, and the operational owner to challenge the purpose and scope.
  3. Give the draft to a worker unfamiliar with the project and ask them to explain what is covered and how to raise a problem.
  4. Run one safe expected block and one ordinary allowed task on a representative resource; make the observed behavior match the notice.
  5. Publish it through a channel workers can revisit, record the effective date, and communicate material changes before they take effect.
  6. Review access, retention, exceptions, complaints, and wording on a schedule; narrow or retire purposes that no longer justify processing.
  • Do not use acceptance of a notice as proof that monitoring is lawful or proportionate.
  • Do not bury a sensitive purpose inside a generic acceptable-use policy.
  • Do not say “anonymous” when resource, network, or timing data can still identify a person.
  • Do not promise that every harmful destination will be blocked.
  • Do not reuse security evidence for performance management without a separately assessed, disclosed basis.
  • Do not leave former administrators or vendors with continuing access.

Employee-notice questions

No. Employment relationships and privacy laws differ by jurisdiction, and consent may not be the appropriate basis. The notice supports transparency but does not replace legal review, consultation, contracts, policies, or an impact assessment where required.

Should the notice say all internet traffic is monitored?

No, unless that is independently true and accurately explained elsewhere. DNS filtering concerns domain lookups reaching the resolver and its policy outcomes. It does not expose full URLs, page contents, messages, search terms, or a complete browser history.

When should employees receive an updated notice?

Update and redistribute it before a material change to purpose, covered resources, visibility, recipients, retention, or automated use. Also review it on a schedule and after recurring false blocks or complaints reveal that the written boundary is inaccurate.

Review one team scope in Veilty

In Veilty, choose one team Tenant and one representative resource. Confirm its assigned profile, effective baseline and enforced policy, resolver path, and permitted roles. Account membership alone does not grant Tenant access. Test the narrowest rule on that resource before applying it to a wider group, and make the notice describe the observed scope rather than an intended future state.

Start with aggregate outcomes. Retained DNS activity belongs to its Tenant, is end-to-end encrypted with user-held keys, and is available only through permitted roles, while the resolver necessarily processes live requests. Open detail only for the disclosed purpose, resource, and time window. Close the review, remove unnecessary access, and record when the notice and policy will next be checked.

References

  1. Data protection and monitoring workers - ICO
  2. RFC 9076: DNS Privacy Considerations - RFC Editor

Related articles