During the first month, measure endpoint coverage, continuity of essential work, high-confidence security outcomes, false-positive handling, and response readiness. Capture a pre-rollout baseline, test on the networks people actually use, and make one evidence-based decision each week. Block volume alone is not success; dependable coverage and proportionate follow-through are.
Prove the path before counting blocks
Protective DNS sits in a chain: an endpoint must use the resolver, the resolver must apply the intended policy, the answer must produce the expected outcome, and the team must know what to do next. Measuring only the third link hides the most common rollout failures. A zero-block laptop may be perfectly safe, or it may be using browser Secure DNS, a VPN resolver, a mobile network, or stale configuration.
Measure in dependency order: prove that the intended endpoint reaches the resolver, identify the Tenant policy that decided the answer, verify the expected outcome, and confirm that someone can act on it. Dashboards differ, but no percentage or trend line can compensate for an endpoint that never used the protected path.
| Measure | Evidence | Healthy direction |
|---|---|---|
| Coverage | Tests from intended endpoints and networks | Every in-scope path is verified |
| Continuity | Completion of critical work journeys | No unexplained business breakage |
| Protection | High-confidence blocked outcomes by rule | Signals are explainable and actionable |
| Exceptions | Owner, reason, scope, and review date | Narrow, documented, and declining |
| Response | Time from signal to useful decision | Known owner and rehearsed next step |
Take a baseline before changing DNS: list intended devices, normal networks, critical services, current resolver path, and any known connectivity problems. Without that baseline, the team may credit DNS for an existing failure or overlook a gap that was present from day one.
Turn four weeks into four decisions
- Week one: prove resolver coverage on a pilot endpoint in the office, at home, and on a mobile hotspot. Use provider-owned safe tests, never live malicious domains.
- Week two: complete sign-in, email, meetings, updates, payments, file sharing, source control, and support workflows. Record breakage and narrow the deciding rule.
- Week three: rehearse one harmless security signal. Confirm who receives it, what evidence they inspect, and when endpoint or account response begins.
- Week four: review aggregate policy outcomes, false positives, bypass gaps, exception ownership, and unresolved actions. Decide what to keep, narrow, or remove.
CISA explains that protective DNS can prevent connections to malicious destinations and provide visibility that supports incident response.2 Measure both halves. A blocked request without an owner may be ignored; a notification without enough policy context may create noise. Record whether the team reached a useful decision, not merely whether an alert existed.
Do not combine the first security rollout with broad productivity categories. Begin with phishing, malware, scam, and command-and-control protections that have a clear risk rationale. Lifestyle or focus policies create different success measures and different conversations. Mixing them makes false-positive and trust signals difficult to interpret.
Build a small-team scorecard
- Coverage rate: intended endpoints with a current successful test on each normal network.
- Critical journey pass rate: approved work journeys completed without unexplained DNS failure.
- High-confidence outcomes: blocks or redirects tied to a named security policy, not every category.
- False-positive resolution time: elapsed time from a usable report to a verified narrow decision.
- Exception quality: exceptions with an owner, business reason, smallest required scope, and review date.
- Response completion: signals that reached the appropriate endpoint, identity, email, or incident follow-up.
- Reporting confidence: team members know how to report a block or suspicious message without fear of blame.
Give every count a denominator, time window, and decision. “Four of four pilot endpoints passed on every normal network this week” is useful; “coverage looks good” is not. “Two false positives were resolved within one workday” is useful; “support was responsive” is not. Keep the scorecard short enough that a founder can review it, assign every follow-up, and notice an unresolved item.
NCSC recommends understanding the service’s coverage, response handling, data arrangements, and deployment needs rather than treating protective DNS as a complete security control.3 DNS cannot inspect page content, search terms, messages, files, voice calls, or full browser history. It may miss direct IP traffic, alternate resolvers, or a brand-new malicious domain. Keep endpoint, identity, email, update, backup, and training measures on their own scorecards.
Investigate without over-collecting
Routine measurement should use aggregate allowed, blocked, and redirected outcomes. When a metric raises a named question, open the shortest relevant history window for the affected Tenant and endpoint. Confirm the resolver path and deciding rule before inferring risk. Close the review when the question is answered. Do not retain broad exports simply because the dashboard makes them available.
A weekly review should end in one of four decisions: no change, repair coverage, narrow a policy or exception, or begin incident follow-up. Assign an owner and due date. Avoid changing multiple categories at once; otherwise the next week’s measurements cannot tell you which decision helped.
First-month measurement questions
Is a rising block count a sign that protection improved?
Not by itself. It may reflect broader coverage, a noisier application, a category change, or repeated retries. Pair block counts with endpoint coverage, rule identity, false positives, and incident outcomes.
Should a small team set a target percentage of blocked traffic?
No universal percentage is meaningful. The right level depends on workloads, categories, and devices. Prefer targets such as complete intended coverage, tested response, narrow exceptions, and timely false-positive handling.
What should happen after the first month?
Keep a compact monthly review of coverage, protection outcomes, false positives, exceptions, and response lessons. Change policy only when evidence supports a specific improvement.
Review the first month in Veilty
In Veilty, create a Tenant for the team, apply reusable baseline and enforced Tenant policies, and attach one pilot endpoint. Verify it across normal networks before expanding. Review aggregate outcomes first; use Tenant roles to limit detailed retained-history access to a named need. Tenant resources may narrowly override baseline policy but never enforced policy. At month end, remove stale exceptions, record owners, and retest coverage.1