A small team should organize DNS profiles around stable work boundaries, not its org chart. Create a Tenant for each team, client, or lab that needs separate people, devices, rules, or retained activity. Reuse baseline and enforced policies across Tenants, then add explicit Tenant resources only where a workflow needs a narrower exception.
Start with boundaries that survive an org-chart change
A useful Tenant boundary remains understandable when a person changes roles or a laptop is replaced. A client environment, finance function, shared workshop, or testing lab may deserve its own Tenant because its resources, administrators, retained activity, or risk decisions need to stay separate. Two groups that use the same controls and have the same reviewers usually do not need separate policy architecture merely because they report to different managers.
This is a risk-design decision, not a naming exercise. NIST describes an organizational cybersecurity profile as a way to tailor outcomes to mission objectives, stakeholder expectations, threats, and requirements.2 Apply that idea at small-team scale: name the work, its devices, its accountable owner, the threats that matter, and the evidence needed to support it. Split a Tenant only when one of those boundaries truly differs.
Give each policy layer one job
| Layer | Use it for | Avoid |
|---|---|---|
| Account | Invitations and account membership | Assuming membership grants Tenant access |
| Reusable baseline policy | Common starting protection across Tenants | One-off app exceptions |
| Reusable enforced policy | Protection no Tenant resource may weaken | Preferences that need local choice |
| Tenant | People, roles, devices, rules, and retained activity for one boundary | A container for every employee |
| Tenant resource | A device or group with a justified local need | A duplicate of the whole baseline |
Baseline and enforced policies are reusable across Tenants. A Tenant resource may override its Tenant baseline when a documented workflow needs a narrower result. It must never override or weaken enforced policy. That precedence keeps the common starting point adaptable without turning essential protection into a suggestion. Put broad, durable requirements higher in the model; keep temporary and device-specific choices close to the resource they affect.
Least privilege supports the same shape. NIST zero-trust guidance says access should be granted per session with the least privileges needed, and policies should consider the requesting subject, asset, and environment.3 DNS policy is not an identity system, but the design lesson transfers: avoid broad access and broad exceptions when a narrower boundary can express the decision.
Use a five-column profile matrix
Before creating anything, list each proposed Tenant or resource with five fields: purpose, devices, policy difference, accountable role, and review trigger. A finance device might need the common threat baseline plus a narrowly documented allowance for a payment provider. A lab Tenant might need different test resources and separate history access. General employee laptops may share one profile when their risks and work dependencies are alike.
- Group devices by stable work purpose rather than owner name or hardware model.
- Write the common security outcome as a reusable baseline or enforced policy across Tenants.
- Create a Tenant only when people, devices, rules, administration, or retained activity need a real boundary.
- Add a Tenant resource for the smallest set of devices that needs different behavior.
- Record the exception reason, owner, evidence, and next review trigger.
Resist profile sprawl before it becomes policy debt
Profile sprawl usually begins with a reasonable exception and an unclear owner. A new resource is copied from an old one, its name records a person rather than a purpose, and nobody knows whether the original difference still matters. The next administrator creates another copy rather than risk changing it. Soon the team cannot predict which protection a device receives or safely improve the shared policy.
Use a merge test at every review: if two resources have the same purpose, effective policy, accountable role, and review trigger, combine them. If they differ only because one carries an old exception, verify whether the exception is still necessary. Never merge merely to reduce the count when the resources require separate Tenant access or retained-history boundaries. Clean architecture minimizes unexplained differences, not legitimate separation.
Test the work, not just the lookup
Run a harmless allowed-domain test, a harmless blocked-domain test, and a real business workflow on one representative device. A DNS result proves how a lookup was answered; it does not prove that a login, payment, upload, or API operation completed. RFC 9499 defines DNS as a query-response protocol.4 Verify the application outcome separately before widening an allowance.
DNS filtering can act on domain lookups and policy outcomes. It cannot inspect URL paths, webpage contents, search terms, files, in-app chats, voice audio, or full browser history. It also cannot replace network segmentation, endpoint security, authentication, or authorization. If two functions share one hostname, DNS policy cannot allow one page while blocking another.
Keep management access and history on the same boundary
Invite people to the Veilty account first. An accepted invitation creates account membership but does not expose a Tenant. Assign the appropriate Tenant role afterward, and review those roles when responsibilities change. Retained DNS activity belongs to its Tenant, is end-to-end encrypted with user-held keys, and can be opened only by people whose Tenant roles permit it. The resolver still has to process each live request to answer it.1
The result should be boring in the best way: a short list of understandable Tenants, reusable protections, a few explicit resources, narrow exceptions, and reviewers who can explain why each boundary exists. Review one proposed Tenant and remove any split that cannot be justified by people, devices, policy, administration, or retained-history access.
Tenant-profile questions
Does every employee need a separate DNS profile?
Usually not. Start with stable device purposes and shared risks. Create a narrower resource only when a real workflow needs a different rule, owner, review cycle, or evidence boundary.
Can a Tenant resource weaken an enforced policy?
No. A resource inside a Tenant may override that Tenant baseline where a narrower exception is justified. It cannot weaken an enforced policy, which takes precedence.
Does joining the account grant access to every Tenant?
No. Invitations add people to the account. After acceptance, assigned Tenant roles determine which Tenants, controls, and retained activity they can access.