A five-person team does not need enterprise tooling to remove some phishing risk. Route work-device lookups through protective DNS, begin with known malicious domains, and verify coverage on every network the team uses. Then give everyone the same response to urgent requests: stop, verify through a trusted channel, and report. DNS can refuse a dangerous destination; people and identity controls still have to judge the request.
Give every person the same pause rule
Phishing in a small company borrows ordinary work: a supplier invoice, shared document, password reset, or message that appears to come from the founder. The Federal Trade Commission advises people to verify suspicious requests using a phone number they already know is correct, keep systems updated, use email authentication, and alert colleagues.2 Those actions cover the part DNS cannot: deciding whether the request itself is real.
| Moment | Control | Owner |
|---|---|---|
| Before delivery | Email authentication and provider filtering | Mailbox administrator |
| Before connection | Protective DNS blocks a known malicious domain | Operations lead |
| Before approval | Call back through a trusted number | Every team member |
| After suspicion | Report, contain, reset, and review | Named incident lead |
Give each person one memorable rule: urgent requests change the channel. If an email asks for money, credentials, recovery codes, or a new bank account, contact the supposed sender through an address or number already on file. This catches attacks that use a legitimate domain, a compromised supplier account, a QR code, a phone call, or plain text with no link at all.
Add a checkpoint behind the click
NCSC describes protective DNS as a resolver that uses policy to prevent devices from visiting malicious domains, including phishing, malware-distribution, and command-and-control destinations.3 The resolver can refuse, redirect, or otherwise alter the answer when a requested domain matches threat intelligence. The browser then cannot make its normal connection through that name. This is low-friction because the decision occurs before page content loads.
- List the five work devices, their owners, operating systems, and normal networks. Include home Wi-Fi, coworking, travel, and mobile hotspots.
- Choose a protective profile limited to malware, phishing, scam, and known high-risk domains. Do not mix the first security rollout with productivity or lifestyle categories.
- Attach one non-critical endpoint first. Confirm that its DNS actually reaches the protected resolver before creating policy.
- Use a provider-owned safe test domain or documented test method. Never visit a live malicious address to prove that blocking works.
- Complete sign-in, invoicing, meetings, file sharing, source control, updates, and customer support from the pilot device.
- Expand to the other four devices only after the pilot passes. Retest away from the office so roaming coverage is evidence, not assumption.
- Name one person to review false positives and one backup who can make a narrow emergency exception.
Managed DNS products commonly follow the same operating sequence: connect an endpoint, verify that its queries arrive, apply security categories, and add narrower organizational rules only after the path works.4 The sequence is useful across providers because policy cannot protect a device whose queries take another path. Browser Secure DNS, a VPN, a private relay, or a manual resolver can send lookups elsewhere, so test the exact path each person uses.
Run a Friday-afternoon drill
Rehearse the moment when judgment is weakest: an urgent request near the end of the week. Send a clearly authorized, harmless exercise built around a fictional vendor change. The expected response is to pause, ignore the supplied contact details, verify through a trusted channel, and report the message. Tell the team the exercise is for practicing a sequence, not ranking people or collecting a failure score.
- If DNS blocks the exercise link, confirm the person also reports it rather than simply moving on.
- If the domain resolves, check whether the endpoint used the intended resolver before changing threat policy.
- If a person entered a password, revoke sessions, reset the credential, and review multifactor authentication immediately.
- If money or sensitive data was requested, follow the company approval and incident process even when the link was blocked.
Protective DNS does not read the email, page contents, search terms, in-app chats, voice audio, or full browser history. It may miss a newly created domain that has not been classified, an allowed file-sharing service, direct IP access, or traffic using another resolver. Endpoint security, browser protections, password managers, multifactor authentication, backups, updates, and human verification remain separate layers.
Measure friction, not surveillance
For the first week, record three outcomes: whether all five endpoints stay on the protected DNS path, whether essential work completes, and whether blocked requests produce a usable report. Aggregate counts are enough for routine review. A spike in blocks is a prompt to ask what changed, not evidence that a person behaved badly. Background apps generate DNS requests without a deliberate click.
When a block needs investigation, identify the endpoint, approximate time, requested domain, policy action, and rule. Open only the shortest relevant retained-history window. In Veilty, retained activity belongs to a Tenant and is available only to account members whose Tenant roles permit access. Saved details and summaries are end-to-end encrypted; the resolver still processes each live DNS request to answer it.
Avoid the two common shortcuts. First, do not allow an entire category because one supplier was misclassified; verify ownership and allow the smallest required domain. Second, do not block every newly observed or uncategorized domain on day one. Some providers expose aggressive risk categories, but even Zscaler warns that broad unknown-category blocking can have wide operational impact.5 A five-person company needs dependable work as well as protection.
Phishing questions for small teams
Can protective DNS stop every phishing link?
No. It can block a domain already identified as dangerous when the device uses the protected resolver. It cannot recognize every new domain, inspect the message, or prevent a person from disclosing information through an allowed service.
Should a tiny team inspect every DNS request?
No. Start with aggregate allowed, blocked, and redirected counts. Open a short window of retained Tenant activity only to answer a named incident or compatibility question, then stop when the answer is found.
What should happen after a phishing domain is blocked?
The person should report the message, preserve the sender and link without reopening it, and tell the team whether any password or approval was entered. A block is evidence to investigate, not proof that nothing else happened.
Try the pattern in one Veilty Tenant
Create one Veilty Tenant for the team, apply reusable baseline and enforced Tenant policies for malware and phishing protection, and attach a single pilot endpoint. Tenant resources may override the baseline policy when work requires a narrow exception, but never an enforced policy. Test the endpoint at work and away, then add the remaining devices. Review blocked requests after one week and keep only exceptions with an owner, reason, and review date.1