Use one tenant with shared policy when the same administrators, privacy boundary, mandatory protections, and exception process cover the whole team. Use separate tenants when groups need genuinely independent roles, resources, retained activity, or policy ownership. Do not split merely for organizational neatness: each boundary adds administration, testing, and duplicated change work.
The outcome is a team structure choice that another administrator can defend. Draw the boundary around authority and data, then place reusable policy inside it. A department name, office floor, or stricter blocklist may justify a different profile without justifying a second tenant.
Start with the boundary
Ask four questions in order: who may administer the resources, who owns the DNS policy, who may review retained activity, and who approves an exception. If every answer names the same accountable group, one tenant is usually clearer. If an answer must remain independent for legal, contractual, privacy, or operational reasons, a separate tenant becomes plausible.
NIST describes least privilege as allowing only the access needed for assigned tasks and separation of duties as dividing sensitive responsibilities among roles.1 Those principles do not require a tenant for every team. They require access boundaries that match real duties. Use the smallest number of boundaries that can express those duties without broad access or informal workarounds.
| Decision factor | One tenant | Separate tenants |
|---|---|---|
| Policy ownership | One accountable owner | Independent accountable owners |
| Administrator access | Shared scoped roles | No routine cross-group access |
| Retained activity | One privacy and review boundary | Distinct privacy or contractual boundaries |
| Exceptions | One approval and precedence model | Independent approval processes |
| Operations | Shared changes and tests | Duplicated lifecycle work accepted |
Keep one tenant when ownership is shared
One tenant makes sense when a small security or IT team owns the same resources and applies one mandatory protective baseline. Reusable policy can cover common risky-domain decisions while narrower profiles express differences for contractors, guests, labs, or sensitive roles. This keeps one change path, one exception vocabulary, and one place to verify precedence.
Do not confuse shared ownership with identical policy. A finance laptop and a guest network can receive different domain decisions while remaining in the same tenant, provided roles and resource assignments stay appropriately scoped. The design should answer which rule won without copying the same rule into several consoles.
Split when authority or data must split
Separate tenants are appropriate when a subsidiary, client, or delegated operating group must control its own resources without exposing policy or retained activity to another group. They can also clarify independent contractual ownership or incompatible exception processes. Write the required isolation in plain language before choosing the structure, then test it with accounts from both sides.
A tenant label is not proof of isolation. During evaluation, confirm that a member of tenant A cannot enumerate, change, or review tenant B resources without an explicitly assigned role. Also test invitations, role removal, exported evidence, support access, and the behavior of account-level administrators. Record any intentional cross-tenant authority instead of discovering it during an incident.
Compare the operating cost
Every separate tenant creates lifecycle work: member changes, baseline updates, exceptions, resolver assignments, verification, reporting, and incident handoff. A protective change may need to be repeated and tested across every boundary. Count that labor honestly. Isolation that no one maintains becomes configuration drift rather than protection.
A single tenant has a different risk: one overly broad role or policy change can affect more resources. Reduce that risk with scoped roles, reviewable policy precedence, representative pilots, and separation between policy approval and routine support. The choice is not centralized good or separate good; it is which failure mode the team can control and verify.
Run a boundary tabletop
- List the resource groups, policy owners, administrators, activity reviewers, and exception approvers.
- Mark every pair that must not share routine authority or retained activity.
- Model the simplest one-tenant structure with scoped roles and profiles before adding boundaries.
- Test one allowed lookup, one blocked lookup, one exception, and one unauthorized cross-group action.
- Simulate an urgent protective change and measure how many places require editing and verification.
- Choose separate tenants only where the isolation benefit justifies that continuing work.
Review aggregate policy outcomes first. DNS records can expose sensitive associations, and a query does not prove a person intentionally visited content; browsers, applications, and devices make background requests.2 Open detailed activity only for a named purpose, representative resource, and limited time window.
Avoid structure mistakes
DNS filtering can act on domain lookups and policy outcomes. It cannot inspect page contents, full URLs, search terms, in-app chats, voice audio, or full browser history. Tenant structure changes who owns DNS policy and retained activity; it does not give DNS content-level visibility.
- Do not create a tenant for every policy variation when a scoped profile owns the difference.
- Do not keep one tenant when unrelated groups can review each other's retained activity.
- Do not duplicate mandatory rules without a reliable propagation and verification owner.
- Do not grant broad account access merely to simplify routine tenant support.
- Do not treat DNS as a content monitor: it cannot read pages, full URLs, search terms, chats, voice audio, or browser history.
Team structure answers
Do different blocklists require separate tenants?
No. Different resources can often receive different profiles, rules, or filter sets inside one ownership boundary. Split tenants when administration, retained activity, or policy authority must be isolated, not simply because one group needs a stricter domain rule.
Can one shared policy support local exceptions?
Yes, when the policy model has explicit precedence and the shared owner permits resource-level differences. Keep mandatory protection enforced, put adaptable defaults in baseline policy, and document who can approve a narrow exception.
Does a separate tenant create a security boundary by itself?
Only if the service consistently scopes roles, resources, policy, and retained data to that tenant. Buyers should test those controls rather than trusting the label. Organizational separation without access enforcement is only visual separation.
Map the decision in Veilty
In Veilty, a team Tenant is the boundary for its resources, scoped roles, policy, and retained DNS activity. Account membership alone does not grant Tenant access; a member needs an assigned Tenant role. Within one Tenant, reusable baseline policy can express shared defaults and enforced policy can hold protections that a resource may not weaken. Retained activity belongs to the Tenant, is end-to-end encrypted with user-held keys, and is available only through permitted roles, while the resolver necessarily processes live requests. Model one representative group, test the role and policy boundaries, and split only when authority or retained data must truly separate.