A contractor DNS notice should remove surprises, not advertise security technology. Before access begins, explain the business purpose, scope, visibility, limits, support route, and removal process in plain language. Contractors should be able to predict what happens when a domain is blocked and decide whether the device arrangement is acceptable before installing anything.
Lead with the work boundary
Begin with the work at risk: client records, source repositories, financial systems, production tools, or shared documents. Then say protective DNS can prevent connections to some known malicious domains before a page loads.2 It is a safety layer alongside endpoint protection, software updates, multifactor authentication, access roles, and human verification. Avoid claiming it makes the device secure or proves a contractor acted intentionally.
For project work, this device uses our protective DNS profile. It can block known risky domains and project-specific destinations. We review aggregate outcomes routinely and open detailed retained activity only for a named support or security purpose.
Tailor the notice to the real deployment. A company-owned laptop can carry managed policy across networks. A personal device deserves a narrower agreement and may be unsuitable for sensitive work. NCSC recommends making responsibilities, acceptable devices, organization-controlled settings, support, and incident reporting clear to users.3 Those principles apply particularly well to contractors, whose access is temporary and whose devices may be managed by another organization.
Give contractors six plain answers
- Why: name the work risk being reduced, such as phishing, malware, or access to project-only services.
- Where: state whether policy applies to a supplied device, a work profile, a project browser, office Wi-Fi, or every network the endpoint uses.
- What happens: explain allow, block, or redirect behavior and show the expected block message.
- What is visible: identify aggregate metrics, any retained domain activity, the purpose, retention window, and roles permitted to view it.
- How to get help: provide one route for mistaken blocks, urgent client work, and suspected security incidents.
- How it ends: explain when access, profiles, resolver settings, sessions, and retained project permissions are removed.
| Avoid | Say instead |
|---|---|
| All traffic is monitored | The resolver handles domain lookups from this work profile |
| Security may inspect activity | Named Tenant roles may open retained domain activity for a stated support or incident purpose |
| No bypass is allowed | Report a block; we will verify it and create the narrowest permitted exception |
| Policy applies indefinitely | Work configuration and access are removed at the contract or project boundary |
DNS filtering cannot read page contents, search terms, email text, in-app chats, voice audio, or full browser history. It may see a domain requested automatically by background software rather than a deliberate visit. It can also be bypassed when a browser, VPN, private relay, or application sends DNS elsewhere. Explain those limits so both the protection and the privacy disclosure are credible.
Public product documentation offers useful outline patterns without dictating your wording. Cloudflare organizes DNS policy around selectors, actions, scope, precedence, and limitations.4 Cisco Umbrella asks administrators to map users and groups before deployment.5 Control D separates reusable profiles from the endpoints that enforce them.6 A contractor notice should translate those technical decisions into consequences a person can understand.
Write a notice that can be questioned
Send the notice before the contractor accepts the device arrangement, not after configuration appears. Name a person who can answer questions about scope, retained activity, and exceptions. Include the effective date and the project or Tenant covered. Avoid asking for blanket consent to unspecified future monitoring. If the work changes enough to require a different device class, new visibility, or broader policy, issue a revised notice and offer a reasonable alternative such as a supplied endpoint.
- Use one short purpose statement tied to project risk rather than a generic right to monitor.
- List the device or work boundary, expected block behavior, retained activity, permitted Tenant roles, and retention period.
- Give separate contacts for routine false positives and urgent security reports.
- State the project end date, removal steps, and what happens if the contractor declines a personal-device arrangement.
- Ask the contractor to confirm understanding and provide a route to correct inaccurate device or role information.
Rehearse the first block
Do not wait for a client deadline to discover the support path. During onboarding, use a provider-owned safe test domain. Ask the contractor to capture the block message, report the hostname and time, and explain the work task. The team owner confirms the endpoint used the expected resolver, identifies the acting rule, and responds with either the reason for the block or the next verification step.
- Never ask a contractor to test a live malicious domain.
- Verify client-supplied domains through a known contact or established project channel.
- Allow one required hostname before an entire domain or category.
- Give every exception an owner, business reason, and review date.
- Use aggregate outcomes first and open the shortest detailed activity window that can answer the question.
If an enforced security policy blocks the destination and the team cannot establish that it is safe, provide an alternate approved workflow rather than demanding a bypass. The contractor should also know how to report a suspicious message even when DNS already blocked its destination. A block reduces one connection risk; it does not show that credentials, files, or another channel were untouched.
Make offboarding part of onboarding
Record the contract owner, Tenant role, endpoints, profiles, project resources, start date, and expected end date together. Invitations should add the contractor to the account; Tenant roles should then grant only the access required for the assignment. When work ends, revoke sessions and Tenant roles, remove work DNS configuration from personal devices, recover supplied devices, close exceptions, and confirm the contractor knows where project data must remain.
For longer engagements, repeat the disclosure when scope changes. A move from design review to production support can change device requirements, visibility, and the domains required. Consent to one practical arrangement is not a blank approval for every later control. Review the profile and access rather than silently expanding them.
After removal, verify both sides of the boundary. The team should confirm that sessions, Tenant roles, exceptions, and project resources are no longer available. The contractor should confirm that the work resolver or profile no longer affects the device. Keep the minimum administrative record needed to show who completed offboarding, but do not retain detailed domain activity merely because the engagement has ended.
Contractor DNS questions
Can team DNS filtering read a contractor's messages?
No. DNS filtering handles domain lookups and policy outcomes. It cannot read page contents, search terms, email bodies, in-app chats, voice audio, or full browser history.
Should filtering apply to a contractor's whole personal device?
Only with clear agreement and a proportionate need. Prefer a company endpoint, work profile, dedicated browser, or other boundary that avoids applying company policy to unrelated personal activity.
Who should approve a contractor exception?
A named team owner who understands both the client or project need and the security policy. The exception should be narrow, documented, tested, and reviewed or removed when the work changes.
Scope contractor resources in Veilty
In Veilty, invite the contractor to the account, then use a Tenant role to grant only the required Tenant access. Put contractor endpoints in a dedicated profile under reusable baseline and enforced Tenant policies. Resources may override baseline policy for a justified project exception, but not enforced policy. Retained activity is Tenant-scoped, role-limited, and end-to-end encrypted; the resolver processes live DNS requests. Test the support path, review blocked requests after the first week, and schedule profile and role removal with the contract end date.1