An employee handbook should explain why DNS filtering is used, which networks and device classes it covers, what decisions it makes, and what happens off-network. State what DNS can and cannot reveal, whether activity is retained, which roles may open it, how long it remains, and how employees request support or an exception. The written boundary must match the deployed behavior.
Begin with the security purpose
Lead with the intended outcome: reducing connections from defined work systems to known or suspected malicious domains. CISA describes protective DNS in terms of analyzing DNS queries and preventing connections to malicious infrastructure.2 That purpose is more accurate than saying the company “monitors internet use,” which exaggerates DNS capability and leaves workers guessing how the evidence might be used.
Draw scope with concrete nouns: company laptops, personal devices, office networks, guest Wi-Fi, isolated work profiles, remote connections, and managed browsers. State whether policy follows an endpoint away from the office. A sentence saying “all systems may be monitored” does not tell anyone whether a personal phone is covered on mobile data, what happens after work, or which support team owns a mistake.
Answer eight policy questions
- Why is it used? Name the threats or work requirements the DNS policy addresses.
- Where does it apply? List device ownership classes, networks, work contexts, and roaming paths.
- What can it do? Explain that a domain lookup may be allowed, blocked, or redirected.
- What is visible? State what DNS activity can reveal and what remains outside its view.
- What is retained? Give the saved fields, routine period, and deletion process.
- Who may open it? Name authorized roles and the purposes that justify detailed access.
- How are mistakes corrected? Provide a route, required facts, owner, review date, and appeal path.
- When does it change? Explain testing, advance notice, periodic review, and offboarding.
DNS filtering can act on domain lookups and policy outcomes. It cannot read page contents, search terms, in-app chats, voice audio, or full browser history. A lookup is also not reliable proof of intent: applications contact domains in the background. Include those limits beside the visibility statement, not in a technical appendix employees will never find.
| Instead of | Write |
|---|---|
| We monitor all internet activity | The DNS service evaluates domain lookups from listed work endpoints and networks |
| Inappropriate sites are blocked | The policy blocks named threat or content categories for a stated work purpose |
| Logs may be reviewed | Authorized roles may review retained domain outcomes for listed purposes and periods |
| Exceptions require approval | Send the exact domain, work task, affected device, and required duration to the named owner |
Make every boundary predictable
A useful section lets a person predict the result. If a company laptop remains protected on home Wi-Fi, say so. If a personal phone is covered only on the office network, say that instead. If enforced Tenant policy prevents a resource-level override, explain the work reason in plain language. Put changing domain lists, forms, and contact details in a maintained support location rather than freezing volatile operations inside the handbook.
Describe retained activity with equal precision. Start investigations with aggregate policy metrics. Permit detailed review only for a named troubleshooting, security, or compliance purpose, by authorized Tenant roles, for a limited window. State the routine retention period and any valid preservation process. Do not promise anonymity when an endpoint is identified, and do not imply full browsing surveillance when DNS cannot provide it.
Employment and privacy obligations vary. The UK Information Commissioner’s Office, for example, emphasizes necessity, proportionality, transparency, and consideration of less intrusive means in worker monitoring.3 Use jurisdiction-specific legal and employee-relations review; do not treat handbook acceptance as a universal substitute for a lawful basis or consultation.
Give the document an operating owner
- Assign one policy owner and one technical owner, with review dates for both.
- Keep a device-class matrix that matches the handbook scope.
- Test one endpoint per class on every documented network path.
- Route false positives through a narrow, time-bounded exception record.
- Notify affected people before material changes to scope, visibility, or retention.
- Remove endpoint configuration and access during offboarding, then verify removal.
Run a tabletop review before publication. Give the draft to someone who did not write it and ask: Does this cover my personal phone? What happens at home? Who can open a blocked lookup? How do I challenge a mistake? Then ask operations the same questions and test a representative endpoint. When the answers differ, correct the deployment or document before asking employees to acknowledge it.
Common mistakes are copying generic surveillance language, hiding DNS limitations, mixing company-owned and personal devices, omitting off-network behavior, promising automatic expiry that the system does not enforce, and publishing a contact that nobody owns. Another is documenting a broad exception while operations applies it globally. The handbook is only credible when scope and precedence match production.
Keep the handbook section at the employee-policy level. A contractor notice should identify the separate relationship and access boundary; a guest Wi-Fi note should address visitors on that network; and a technical baseline should hold changing resolver details. Cross-link those owned documents rather than forcing every audience into one notice. This prevents a broad employee statement from silently becoming the authority for personal contractors, visitors, or unmanaged devices.
Handbook policy questions
Is an acceptable-use policy enough?
Usually not by itself. It may set conduct expectations, but employees also need a specific notice describing DNS scope, retained activity, access, exceptions, and support.
Should the handbook list every blocked domain?
No. Describe stable purposes and categories, link to a maintained policy source where appropriate, and provide a way to report false positives. Exact domain lists change too often for handbook text.
Does a signed handbook make any monitoring lawful?
No. A signature does not replace necessity, proportionality, security, consultation, or the lawful basis required in the relevant jurisdiction. Obtain qualified local advice.
Make the written boundary real in Veilty
Translate the handbook matrix into the narrowest current Veilty endpoint and Tenant scope. Reuse baseline and enforced policies across Tenants; within one Tenant, a resource may override its baseline but not enforced policy. Test every supported company-device class and document narrow exceptions. Invitations are account-scoped, while Tenant roles govern Tenant work and access to that Tenant’s end-to-end encrypted retained activity. The resolver still processes live requests. Managed BYOD remains a planned enterprise capability, not a current setup promise.1