When a contractor leaves, revoke unneeded account membership and assigned Tenant roles separately, retire DNS resources associated with their work, transfer justified exceptions, and remove work DNS settings from their devices. Test that required services still resolve while former resources no longer receive policy. Retain activity only for a documented purpose and period.
Offboard the DNS control plane, not only the login
A contractor can disappear from the identity directory while their old device entry, resolver token, narrow allow rule, troubleshooting access, or named ownership remains. Those leftovers confuse future investigations and may keep a policy path alive. Treat DNS as one workstream in the wider exit process: the account, sessions, application permissions, device trust, secrets, physical equipment, and client data each still need their own owner.
The DNS review has a deliberately narrow goal: prove that the departing person and their devices no longer control or receive team DNS policy, without deleting rules the remaining team still needs. This is different from a contractor onboarding notice. The question is not how to explain filtering; it is how to retire assignments and transfer accountable ownership.
Build a contractor exit inventory
Begin from the contract record, not from a list of recent DNS requests. Record account membership and invitation state separately from assigned Tenant roles, then list endpoints, company-managed devices, any approved personal-device arrangement, resolver configuration, project resources, exceptions the contractor requested or owned, support cases, and the expected end date. An account invitation adds a person to an account; only a later Tenant role grants access to that Tenant. CISA recommends disabling accounts when they are no longer needed; the same lifecycle discipline should extend to DNS assignments and credentials.2
| Item | Exit action | Evidence of completion |
|---|---|---|
| Account membership | Revoke when no other account work remains | Account sign-in no longer succeeds |
| Assigned Tenant role | Remove access to each affected Tenant | Tenant resources and history are unavailable |
| Assigned endpoint | Retire, unassign, or transfer to a named owner | Inventory has no orphan |
| Personal device DNS | Remove only the work configuration | Personal resolver state is restored |
| Project exception | Delete or reapprove with a new owner | Rule has a purpose and review date |
| Retained activity | Keep only under the stated policy | Access and deletion dates are known |
Do not infer ownership from a hostname in activity. DNS requests may be generated by background services, and shared devices can represent several people. DNS can show domain lookups and allow, block, or redirect outcomes; it cannot read page contents, search terms, chats, voice audio, or full browser history. Use the access and endpoint inventory as authority, with activity only for a named troubleshooting need.
Remove access in a safe order
- Confirm the end time, exit owner, affected projects, and whether the device is company-owned or personal.
- Transfer any shared policy, documentation, and exception ownership before disabling the contractor account.
- Remove assigned roles from every affected Tenant; revoke account membership separately when no other account work remains.
- Retire contractor-only DNS endpoints and resolver credentials; reassign a shared endpoint only to a named owner.
- Remove work DNS configuration from a personal device without erasing unrelated personal network settings.
- Delete contractor-only exceptions; independently reapprove any rule the team still needs at the narrowest scope.
- Apply the retention rule to saved activity and close temporary troubleshooting visibility.
- Run the post-exit tests and attach the result to the offboarding record.
Avoid deleting shared rules before ownership is understood. A hostname allowed for a contractor may support a production integration used by others. Conversely, do not keep a broad allow rule because its purpose is unclear. Recreate a justified rule with a current owner and review date rather than inheriting ambiguous history. Apple documents that managed DNS settings can be delivered as a device-management payload; remove the organization-owned payload through the same management path instead of manually changing unrelated settings.3
Prove the contractor boundary is gone
Use two perspectives. From an authorized team endpoint, verify essential project services and one harmless provider-owned blocked test domain. This catches accidental deletion of shared policy. Separately, confirm the retired endpoint or credential cannot retrieve team policy and that the former account cannot enter the Tenant. Never ask the departed contractor to visit a live malicious domain, and never use a public DNS result alone as proof that application access is revoked.
- Check that no rule, endpoint, or exception is owned by a disabled identity.
- Confirm company equipment is recovered, reset, or reassigned under the device process.
- Test office and roaming resolver paths used by the remaining team.
- Close temporary detailed-activity access when verification ends.
- Record unresolved dependencies with an active employee owner and deadline.
Common mistakes are disabling only email, deleting an endpoint before transferring a shared exception, leaving a resolver credential on a personal device, keeping detailed lookups indefinitely, or assuming a failed DNS lookup proves every session is closed. The exit is complete only when each control reports its own result and the DNS inventory has no stale ownership.
Make the review repeatable for the next departure. Add DNS resources and exceptions to the standard exit ticket, require a second person to confirm shared-rule ownership, and sample the inventory after the deadline. A concise completion note should name what was revoked, what was transferred, what evidence remains under retention, and who accepted each unresolved dependency. That record is more useful than a screenshot of a quiet activity chart.
Contractor offboarding questions
Should the team delete every DNS record associated with a contractor?
No. Remove access and unnecessary assignments promptly, but follow the documented retention policy for legitimate security, support, contractual, or legal needs. Do not keep detailed activity merely because storage is available.
Can a contractor exception be transferred to an employee?
Only after a new owner confirms the business need, exact hostname, scope, and review date. Reassigning an exception silently preserves risk without preserving accountability.
Does removing DNS configuration revoke application access?
No. DNS configuration and application identity are separate controls. Revoke sessions, credentials, Tenant roles, application access, and device trust through their owning systems as well.
Close contractor resources in Veilty
In Veilty, treat account membership and Tenant access as different controls. Invitations are account-scoped and do not grant Tenant access; assigned Tenant roles provide that access afterward. Remove the contractor’s roles from every affected Tenant, then revoke account membership if no other work remains. Retire associated Tenant resources and review contractor-owned exceptions. Reusable baseline and enforced policies can apply across Tenants. Inside a Tenant, a resource may override its baseline policy for justified work, but cannot override enforced policy. Retained activity belongs to the Tenant, is available only through permitted Tenant roles, and is end-to-end encrypted with user-held keys, while the resolver still processes live DNS requests. Managed BYOD support is planned for enterprise use, so a current Veilty offboarding plan should cover supported work resources rather than promise personal-device management.1