Tell guests who operates the network, that DNS filtering may block known security threats, whether DNS activity is retained, who may access retained records, and where to get help. Say plainly that DNS does not inspect page contents or messages. Add concise lawful-use expectations and link to complete privacy and access terms before connection.
Put the essential facts before guests connect
A useful guest Wi-Fi note sets expectations without becoming a wall of legal copy. Before a visitor joins, name the operator, the security purpose, what the control does, the activity-handling choice, and the support route. Keep those facts on the sign-in screen or beside the access instructions. A clearly labeled link can carry the complete terms, but it should not conceal important facts behind vague wording such as “monitoring may occur.” ICO guidance likewise recommends concise, transparent, intelligible, easily accessible information in plain language.2
- Operator: the organization providing the network and a contact for help.
- Purpose: basic visitor access protected against known malicious domains.
- Control: DNS requests may be allowed, blocked, or redirected under the guest security policy.
- Privacy: whether DNS activity is retained, for how long, and which authorized role may review it.
- Expectations: lawful use, no attacks or disruption, and responsibility for the visitor's own device.
State the technical limit beside the control: DNS filtering works on domain lookups and policy outcomes. It cannot inspect webpage paths or contents, search terms, files, in-app chats, voice audio, or full browser history. A lookup can come from background software, and it does not prove a person visited or endorsed a site. This distinction is more accurate and less alarming than saying all browsing is watched.
This notice is not the guest-privacy policy itself, a contractor monitoring notice, or a guide to meeting-room equipment. Contractors may use business systems under different authority and expectations; do not quietly reuse visitor wording for them. Have qualified counsel review requirements specific to the organization and location. Plain language improves notice, but it is not legal advice or automatic consent.
Use a notice people can read
A short starting draft is: “This guest network is provided by [organization]. DNS requests use a security policy that may block domains associated with malware, phishing, or other known threats. DNS filtering does not read page contents, searches, messages, or files. [We do not retain DNS activity / We retain DNS activity for X for security and support, accessible to Y]. Read [privacy and access terms]. For access or a suspected error, contact [route].”
Edit every bracket before publishing. If activity is not retained, do not imply that detailed historical review is available. If it is retained, name a real period, purpose, and authorized role rather than saying “as needed.” Avoid promising that every threat will be blocked: intelligence changes, applications can select another resolver, and DNS is one security layer. Do not call the network anonymous when a captive portal, access code, camera, booking system, or another service creates a separate identity record. DNS filtering itself is not identity tracking.
| Avoid | Prefer | Reason |
|---|---|---|
| We monitor all browsing | DNS requests use a security filter | Names the actual control |
| Unsafe content is prohibited | Known malicious domains may be blocked | Separates security from taste |
| Data may be stored as necessary | DNS activity is retained for X and accessible to Y | Makes the choice testable |
| Secure Wi-Fi | Guest access with DNS threat filtering | Avoids a guarantee |
| Contact IT | Email or visit a named support route | Gives visitors an action |
Match the note to reality
- Inventory the guest network, captive portal, resolver, identity fields, retention, and support route.
- Write one security purpose and remove language about unrelated employee or contractor controls.
- Choose whether DNS activity is retained; document access, duration, and deletion before describing it.
- Test the note on a phone and laptop before connection, including screen-reader and small-screen access.
- Use a harmless block-test domain and an ordinary allowed domain to confirm the statement matches behavior.
- Exercise the false-positive contact and time how long it takes to give a useful response.
- Review the wording after any policy, provider, captive-portal, or retention change.
The note must describe the guest path, not the intended configuration. A VPN, browser secure DNS, or device privacy feature may bypass the assigned network resolver; a captive portal may collect data separately. Record these limits in the full terms where material. Do not demand that visitors weaken device security merely to make filtering appear universal. Offer support or decline access when a device cannot use the supported path.
CISA frames protective DNS around preventing access to malicious infrastructure, which supports a narrow security explanation rather than a content-surveillance claim. Its guest-network guidance calls for informing guest users when their DNS traffic is routed through protective capabilities. Use those principles to align the note with the actual visitor service, while relying on qualified local review for the notice, lawful basis, and retention obligations that apply to the operator.34
Review the notice as a control
Assign one operational owner to compare the public wording with the live resolver and retention settings each quarter. Record the date, tester, device types, resolver result, safe block result, support result, and approved wording. Review aggregate failures before detailed activity. A note that says “security only” while broad categories are enabled is a policy failure, not a copy-editing issue.
Common mistakes include hiding the note after connection, copying an employee policy, using consent language nobody can decline, omitting retention, and treating an access code as proof of identity. Another is promising a precise exception without an owner. Give the visitor a practical route, investigate the exact hostname, and either repair a false positive narrowly or explain why the security decision remains.
Guest notice questions
Must the sign-in note contain the entire privacy policy?
No. Put the essential facts and an understandable consent or acknowledgement at connection time, then link to complete terms that guests can open before joining.
Should the note say browsing is monitored?
Not if the control is DNS filtering. Describe domain lookup processing and retention precisely; DNS does not reveal page contents, URL paths, messages, or a complete browsing history.
Is a notice enough to make any filtering acceptable?
No. A notice does not replace a legitimate purpose, proportionate policy, applicable law, network security, or a working support and exception process.
Align the notice with Veilty
When Veilty protects a guest resource, describe its actual policy and retention choice rather than generic monitoring. Reusable baseline and enforced policies can be assigned across Tenants; within this Tenant, a guest resource may override baseline policy for a justified exception but cannot override enforced policy. Test one endpoint, a harmless block outcome, and the support path. Retained activity belongs to the Tenant, is available only through permitted Tenant roles, and is end-to-end encrypted with user-held keys; the resolver still processes live DNS requests.1