No. Give a department its own Tenant only when its applications, exposure, ownership, or compliance needs require a distinct boundary. Reuse baseline and enforced policies across Tenants, add the smallest department-specific resources, name an owner and review date, then test representative devices. Organizational charts alone are a poor reason to multiply policy.
Segment by different outcomes, not the org chart
A separate department boundary is useful when the change is concrete: engineering needs package registries that other devices never use, support needs a customer communication service, or finance needs tighter protection against newly observed and deceptive domains. It is not useful when the only argument is that Sales and Operations have different managers. Mirroring every team and subteam creates overlapping rules, uncertain ownership, and exception tickets that nobody can explain six months later.
Start with reusable baseline and enforced policies that can be assigned across Tenants. Within the department Tenant, enforced policy stays above resource discretion, while its resources may override baseline policy when the work requires a different result. Keep that delta to the few categories, explicit hostnames, or redirect outcomes that genuinely differ. This keeps the answer to “why was this blocked?” short enough for an operations generalist to find and defend.
| Signal | Decision | Reason |
|---|---|---|
| Same applications and risk | Share the baseline | No distinct outcome exists |
| A few approved work domains differ | Add a narrow resource | The delta is explicit and testable |
| One unusual device differs | Scope to that endpoint | Do not burden a department |
| Short project requirement | Use a dated exception | Temporary work should not become permanent policy |
Choose the smallest useful boundary
Inventory where each device actually obtains DNS. Office VLANs may receive resolver settings from DHCP, managed laptops may carry an endpoint configuration off-network, browsers can use their own encrypted DNS setting, and a VPN may replace the resolver path. A department label in a console does nothing if its devices resolve somewhere else. Apple, Windows, Android, and managed browser controls each have different deployment paths, so test the path you really operate rather than assuming the operating system name proves coverage.234
Prefer the least broad scope that stays understandable. A shared network resource suits a stable office segment. An endpoint resource suits a managed laptop that travels. A special rule for one build machine should remain attached to that machine rather than becoming an Engineering-wide allowance. Record fallback behavior for home Wi-Fi, cellular hotspots, VPN use, captive portals, and browser secure DNS so support knows when the department outcome no longer applies.
There is also no requirement to align the technical boundary with human-resources systems. A device can move between projects before a directory group changes, contractors can support several departments, and shared rooms belong to no single employee. Maintain a small resource inventory with purpose, owner, assignment source, and last review. When the relationship is ambiguous, keep the baseline rather than guessing a stronger or weaker department policy from a username.
Build a low-friction department model
- Write one sentence naming the department outcome, such as allowing approved developer registries without weakening the company threat baseline.
- List representative devices, normal networks, required applications, and the current DNS path for each.
- Reuse baseline and enforced policies instead of copying them; record only the Tenant resource difference and its business owner.
- Use explicit hostnames before broad categories when the requirement is narrow, and attach a review date to every exception.
- Pilot on one representative managed endpoint and one office network path before assigning the rest of the department.
- Publish a short support note with the owner, expected block page or failure, fallback behavior, and exception route.
- Review deltas on a fixed cadence and remove any whose application, project, or owner has disappeared.
Do not turn DNS into an employee surveillance system. DNS filtering acts on domain lookups and policy outcomes. It cannot read a page, a search query, an in-app message, voice audio, or full browser history. Prefer aggregate health and block metrics. Open detailed retained activity only for a named support or security question, limit the time window, and close access when that question is answered.
Keep the request process equally small. The requester supplies the application, exact failure, affected device, urgency, and business owner. Operations checks whether the Tenant baseline already permits the work, reproduces the result on the correct resolver path, and chooses the narrowest change. A routine exception should not require a committee, but it should never be anonymous. Enforced Tenant policy cannot be weakened by a resource; requests to change it need the wider security or legal review appropriate to that policy.
Verify with work, not only domains
Run two kinds of checks from the actual device. First, query a documented safe test domain or a disposable hostname that should receive the intended policy result. Second, complete the department's essential workflow: sign in, load required assets, send a test transaction, update a package, or join the approved service. A successful DNS lookup alone does not prove the application works, because applications depend on multiple hostnames, certificates, identity, and network paths.
Repeat with the VPN on and off and, for roaming endpoints, on a hotspot. Confirm the resolver actually used, the expected allow or block outcome, and that an unrelated baseline protection still applies. Roll back the department delta if required work fails. Fix the narrowest hostname or scope, retest, and preserve the evidence with the change record. That is less bureaucratic than accumulating broad emergency allowances.
Review the model when a department adopts or retires a major application, changes location, reorganizes, or reports repeated false positives. The review question is not whether every rule was recently used; background services make that evidence noisy. Ask whether the distinct outcome still exists, whether its scope is still minimal, and whether a current owner will defend it. Merge layers that have become identical and retire endpoints that no longer appear in the inventory.
Measure operational cost as well as block counts. Track how many department deltas exist, how many have no current owner, how long ordinary requests take, and how often an exception is broadened during an incident. If support cannot identify the winning rule or employees regularly change resolvers to finish work, the model is too complicated. Simplify assignments and merge redundant deltas before adding another control layer. A small, explainable set of differences is stronger than perfect-looking taxonomy with unreliable enforcement.
Department policy questions
Should every department have a separate DNS policy?
No. Separate policy is justified by a distinct risk, application set, or required outcome, not merely by a reporting line. Departments with the same needs should share the baseline.
Who should approve a department DNS exception?
Use one operational owner and one business owner. They should record the exact hostname, reason, affected resources, expiry or review date, and evidence that the narrow change works.
Can DNS policy prove which employee visited a site?
Not reliably. Shared devices, background requests, caching, and network address translation weaken identity assumptions. DNS activity describes lookups and policy outcomes, not a person's intent or page-level behavior.
Apply the model in Veilty
In Veilty, reuse baseline and enforced policies across Tenants, then use the smallest resource inside the department Tenant for a justified difference. A resource in that Tenant may override its baseline policy but cannot override its enforced policy. Invitations are account-scoped: after a person accepts, assign a Tenant role before they can access that Tenant, its controls, or its retained history. Saved activity belongs to the Tenant, is end-to-end encrypted, and is available only to members whose Tenant roles permit access. Pilot one endpoint, verify a required workflow and a known block, then review the delta and its owner on schedule.1