The owner of the affected business process should approve a DNS security exception, while a security or operations reviewer checks that the technical change is no broader than necessary. The requester should not approve their own request. Record the business reason, exact domain, affected devices, expiry or review date, and verification result. That creates accountable access without turning every false positive into a permanent hole.
Give each exception two kinds of ownership
A blocked domain can interrupt payroll, design, support, or a supplier portal. The person who understands that workflow is best placed to say whether access is genuinely required. They are the business owner. A second person should examine the DNS change: whether the requested hostname is correct, which devices need it, whether a narrower rule works, and how the result will be tested. In a three-person company those roles may be held by the founder and an operations lead; they should still be named separately in the record.
This split prevents two common failures. A technical administrator should not decide alone whether a supplier is essential, and a requester under deadline pressure should not choose the broadest allow rule. Ownership is not bureaucracy for its own sake. It makes the exception explainable when a colleague asks why it exists six months later.
| Field | Owner | Useful evidence |
|---|---|---|
| Business need | Process owner | Task blocked and required destination |
| Technical scope | Operations or security reviewer | Exact domain, devices, and current policy |
| Verification | Requester and reviewer | Required task works; protective test still blocks |
| Lifecycle | Process owner | Expiry, review date, and removal result |
Decide when an exception is appropriate
Start by reproducing the failure from one affected device. Confirm that the device uses the intended resolver and that the policy outcome, rather than a browser warning, certificate problem, identity failure, or supplier outage, caused the interruption. A DNS allow rule cannot repair those other failures. Ask the service owner for its official domains when possible instead of copying a long list from an old forum post.
- Use an exception when a required, verified domain is falsely classified or intentionally restricted by a broader rule.
- Correct the underlying policy when many legitimate services in the same category are blocked.
- Use a separate test environment when a developer needs to examine untrusted infrastructure.
- Decline the request when the destination is unnecessary, cannot be verified, or would defeat a required control.
Protective DNS is one security layer. CISA describes it as filtering DNS queries to prevent connections to known malicious infrastructure.2 An exception removes that domain-level decision for its defined scope; it does not certify the website. Keep endpoint security, browser protections, strong authentication, updates, backups, and staff reporting in place.
Approve the smallest workable change
- Write the blocked task and name its business owner.
- Confirm the block from one device and capture the rule that produced it.
- Verify the destination through the supplier or another trusted channel.
- Allow the exact required domain rather than an entire category or broad wildcard.
- Limit the change to the exact resources inside the Tenant that need the workflow, where Tenant baseline policy permits an exception.
- Set an expiry or a dated review and name the person responsible.
- Test the required task, then test a harmless provider-supplied blocked domain to confirm protection still works.
- Tell affected staff what changed and where to report another problem.
Wildcards deserve particular caution because one suffix can contain unrelated applications, user-generated content, or infrastructure operated by different parties. If a service genuinely needs several hostnames, add only the documented set and verify them one at a time. Do not allow a top-level domain or disable a threat category merely to make one application load.
Give urgent requests the same minimum record rather than bypassing approval entirely. The reviewer can authorize a short-lived exact-domain change, note the incident or customer task it supports, and schedule a next-business-day review. If nobody can verify the destination or test the remaining protection, use a safer workaround until they can. Speed should shorten the exception lifetime, not erase ownership or technical checks.
Close the loop after approval
Review temporary exceptions when the work ends, not only at a distant quarterly meeting. Remove the rule, repeat the relevant test, and close the record. For longer-lived access, ask the business owner whether the service is still used, whether its domains changed, and whether a narrower rule is now possible. Monitor aggregate policy outcomes first; inspect detailed retained activity only for a named troubleshooting or security purpose and a limited time window.
DNS evidence has strict limits. A resolver can record that a device requested a domain and whether policy allowed, blocked, or redirected it. It cannot read page contents, search terms, in-app chats, voice audio, or full browser history. A request also does not prove a person intentionally visited a site because applications make background lookups. Use the evidence to verify policy, not to invent a story about an employee.
Exception ownership questions
Can the founder approve every exception?
A founder can own the process in a very small company, but the approver should understand the affected workflow and seek a technical scope check. As the team grows, delegate business ownership while keeping one documented method.
How long should a DNS exception last?
Use the shortest period that covers the work. A one-off migration may need hours or days; a required supplier domain may need a longer review interval. Every exception should have a review date even when it has no automatic expiry.
Does an allowed domain mean its content is safe?
No. DNS policy acts on the domain lookup, not the safety of every page, file, account, or message behind that domain. Endpoint, browser, identity, and staff-reporting controls still matter.
Make the exception accountable in Veilty
In Veilty, place normal protection in reusable, Tenant-scoped baseline policy and reserve Tenant-scoped enforced policy for rules members must not override. Have the process owner approve a narrow exception on only the affected Tenant resources where baseline policy permits it; enforced policy remains decisive. Verify both the required domain and a harmless blocked test. Invitations happen at account scope and do not themselves grant Tenant access; an assigned Tenant role governs access afterward. If retained activity is enabled, saved Tenant activity is end-to-end encrypted and available only through permitted Tenant roles; the resolver still processes live requests to answer them.1