Design a Veilty profile by naming the devices, purpose, owner, and acceptable DNS outcome first. Place shared defaults in reusable baseline policy, reserve enforced policy for rules no Space or Tenant resource may weaken, and keep justified differences close to the affected resource. Then test both the DNS result and the real workflow before widening coverage.
Define the decision before the profile
A useful profile describes a stable group of resources, not a pile of convenient labels. Start with a sentence: “These devices need this domain outcome for this work, and this person reviews the decision.” A child homework device, a developer workstation, and a meeting-room screen have different purposes even when they share a network. The profile should survive a device replacement because its reason is the job, not the current hostname.
Write down the expected action before choosing controls. Is the goal to block a confirmed malicious domain, allow a required service, redirect a mistaken lookup, or observe an uncertain dependency? Begin with the least broad action that can answer the question. If the risk or dependency is unclear, collect a short, purpose-bound observation rather than enforcing a guess across every device. NIST uses current and target Organizational Profiles to identify and prioritize gaps; the same comparison is useful here at a smaller scale.1 Record today’s outcome, the intended outcome, and the smallest change between them.
| Decision | Write down | Warning sign |
|---|---|---|
| Purpose | The workflow or risk this profile owns | A vague label such as “restricted” |
| Population | Devices that genuinely share the outcome | Membership follows the org chart alone |
| Owner | The role responsible for review | Everyone can change it |
| Result | One expected allow, block, or redirect outcome | Success means “nothing complained” |
| Review | A date or operational trigger | Exceptions have no end point |
Draw account and access boundaries first
Separate account membership from shared policy access. Veilty invitations are account-scoped: invite a person to the account and wait for acceptance. Only then assign a role that grants access to a family Space or team Tenant. An invitation by itself does not reveal a Tenant, its controls, or its retained activity. This order makes the access decision explicit and prevents a broad account roster from silently becoming a policy-administration group.
Choose a Space or Tenant boundary when people, devices, rules, or retained history need to remain separate. A household can group shared responsibility and devices in a family Space. A department, client environment, or lab can use a team Tenant with its own roles and resources. Do not create a new boundary for every person. Split only when ownership, allowed access, operational purpose, or history visibility genuinely differs; otherwise one well-owned boundary is easier to understand and review.
Make reusable policies do shared work
Baseline and enforced policies are reusable across Spaces and Tenants, but they have different jobs. Baseline policy is the common starting point. A resource added within that Space or Tenant may override its baseline when a documented local workflow needs another result. Enforced policy is the non-negotiable layer: resources beneath it cannot weaken or bypass it. Keeping those meanings separate lets shared protection remain reusable without treating every preference as mandatory.
- List the domain outcomes nearly every in-scope resource needs and place only those in baseline policy.
- Identify the small set of protections that must not be weakened and justify each enforced decision.
- Attach the reusable baseline and enforced policies to the relevant Spaces or Tenants.
- Create profiles around stable device purposes, then add filters or rules only where those purposes differ.
- Record each exception’s domain, affected resource, owner, reason, evidence, and review trigger.
- Retest one representative member before applying a profile change to the rest of its population.
Avoid copying the same rule into many profiles. Repetition usually means the decision belongs in a reusable policy, while one unusual application dependency usually belongs closer to its resource. Also avoid putting a narrow allow in the baseline merely because it fixes an urgent ticket. That makes every resource inherit a dependency it does not have and hides the real owner of the exception.
Keep exceptions at the smallest resource
An exception should follow the resource that needs it. A display that contacts one vendor host does not justify allowing that host for every laptop. A developer profile may need package repositories that a finance profile never uses. Put the difference on the device or reusable profile that owns the workflow, and leave the Space or Tenant baseline intact for everyone else. If several resources accumulate the same justified difference, promote it to one governed profile rather than maintaining copies.
DNS has a firm visibility boundary. A resolver can evaluate a domain lookup and return a policy outcome, but it cannot read URL paths, page contents, typed searches, files, account actions, in-app chats, voice audio, or full browser history. A lookup may also come from prefetching, an embedded resource, or background software, so it is not proof of a person’s intent.2 Use browser, identity, endpoint, application, firewall, or network controls when the decision depends on information DNS does not carry.
Test policy and the real workflow
Test both sides of the proposed boundary. On one profile member, confirm the intended DNS response and complete the real task: sign in, load required data, submit work, update software, or receive a notification. On a resource outside the profile, confirm behavior did not change. Repeat through the normal office, home, mobile, VPN, or browser path because an application-specific resolver can take a different route from the system setting.
- Confirm the device is using the intended resolver and belongs to the expected profile.
- Test one domain that should receive the policy action and one that should remain available.
- Complete the business workflow instead of stopping at a successful DNS answer.
- Check an unaffected resource to catch an accidentally broad change.
- Record the approximate time, resource, path, expected result, observed result, and next review.
A failed workflow does not automatically prove that DNS policy caused it. Authentication, certificates, routing, application permissions, or an upstream outage may be responsible after resolution succeeds. Change one narrow variable at a time. If a temporary baseline override repairs the task, identify the precise dependency, move the exception to its owning resource, and verify that enforced policy still applies.
Review evidence without widening access
Retained Veilty history belongs to its Space or Tenant. Saved activity details and summaries are end-to-end encrypted with user-held keys, and a member can open them only where an assigned Space or Tenant role permits access. Account membership alone does not expose history. Live DNS requests still have to be processed by the resolver to produce an answer; encryption of retained history protects what is saved after that processing, not the live lookup from the resolver itself.3
Use that history to answer a named operational question, not to browse people’s habits. Review the shortest relevant window, confirm the domain and matching outcome, decide whether the profile owns the difference, and stop when the question is resolved. At each review, remove expired exceptions, merge copied rules, verify profile membership, and confirm that roles still match responsibility. Good architecture leaves fewer unexplained differences and fewer people with access than it started with.
Questions for a durable profile
Should every device have its own DNS profile?
No. Group devices that share a durable purpose, owner, policy outcome, and review cycle. Create a device-specific resource only when a verified workflow or risk needs different treatment.
Can a profile override an enforced Space or Tenant policy?
No. A resource may override its Space or Tenant baseline when a narrow difference is justified. Enforced policy takes precedence and cannot be weakened by a profile, device, filter, or rule attached beneath it.
Does an account invitation grant access to a team Tenant?
No. An invitation adds a person to the Veilty account. After acceptance, an assigned Tenant role determines which team Tenant, controls, and retained activity that member can access.
Put the first architecture into practice
Start with one Space or team Tenant and one representative profile. Name its purpose, members, owner, reusable baseline, enforced protections, and one real test. Invite responsible people to the account first, then grant only the roles they need. Move one copied exception to the smallest resource that owns it and set a review trigger. If this structure matches the way your team works, Veilty’s team DNS filtering page shows the public model without requiring a broad rollout.3