Guest WiFi Policy: Which Lines Actually Get Enforced

A guest WiFi policy is the short set of rules a venue publishes about its guest network. It covers who may use it, for how long, at what speed, and what the venue does with the contact details collected at login. Most published policies mix two very different kinds of line. Some lines describe a setting that the network actually enforces, such as a login requirement, an opening-hours schedule, a per-guest speed limit, or a block on a named website. Others are only statements of intent, such as a ban on illegal downloads, which nothing on a small guest network checks or can check. Writing a useful policy is mostly a matter of knowing which line is which, then making sure every enforceable line matches the setting that backs it. A policy that promises a limit nobody configured is worse than no policy, because staff will quote it to guests.

What is a guest WiFi policy, actually?

It is an operations document. That is the part templates get wrong.

A policy has two readers. The first is the guest, who sees a line or two on the login screen and taps through. The second is your own staff, six weeks later, when a guest at the desk asks why their WiFi stopped at eleven at night. The policy is what the staff member reads out. If it says something the network does not do, the staff member is now arguing with a guest about a rule that does not exist.

So the useful test is not “does this sound thorough.” It is “if a guest asks me to prove this, can I point at a setting?”

Which lines does a dashboard actually enforce?

Here is the split, for the lines that show up in almost every guest WiFi policy. The middle column is the honest answer, not the marketing one.

Policy line	Enforced by a real setting?	What backs it
“You must sign in before using this network”	Yes	The login method you turn on: OTP by phone, WhatsApp or email, or a voucher code
“WiFi is available from 8am to 11pm”	Yes	A weekly opening-hours schedule, set per location
“Each guest gets up to 20 Mbps”	Yes	A per-guest speed limit, chosen per location
“One login covers up to three devices”	Yes	A device limit per login, so extra devices do not multiply one guest’s share
“Sessions end after four hours”	Yes	A session time limit, separate from the speed limit
“Staff cannot see your phone number”	Yes	Guest contact details hidden by default from roles that do not need them
“Gambling and adult sites are blocked”	Partly	Domain-level blocking, which a guest running their own VPN or DNS can route around
“Do not download copyrighted material”	No	Nothing on the network inspects this
“Do not use this network for illegal activity”	No	A rule, not a control

Six of those nine rows are a setting you can point at on a screen. One works, but only up to a point. Two are sentences.

Why the “partly” row matters most

The website-blocking row is the one that causes arguments, because it is half true and reads as fully true. Blocking a domain works, and it works on hardware a small property already owns. It is not a guarantee. What DNS-based blocking can and cannot do covers the mechanism and the limits in full. For the policy, the fix is one word: write “blocked” if you mean the default guest experience, and say so plainly rather than promising something absolute.

Why the speed and time rows are worth writing down

These are the lines guests actually notice, and the ones staff get asked about. A policy that states the real number is far easier to defend than a vague “fair use” sentence. Time and speed limits explains what each of those limits does, and why the device limit matters more than most venues expect. Set them first, then write the line.

Which lines are only words?

Two kinds, and they are worth separating.

Rules nothing on the network can check

“No illegal activity.” “No copyright infringement.” “No commercial use.” A guest network does not read traffic, and the honest version of that is covered in the blocking post above. These lines are still worth publishing, but understand what they are: a statement of what the network is for, not a control.

Rules that could be a setting, but were written as a plea

“Please be considerate of other users.” “Do not stream heavily during busy hours.” “Please do not occupy a table all day on the WiFi.”

Every one of those is a limit somebody decided not to configure. A speed limit, a session time limit, or an opening-hours schedule turns each of them into a rule the network applies to everyone the same way, without a staff member having to notice a problem first. If a line in your draft policy is asking guests to behave, check whether a setting could simply decide it instead.

Does an unenforceable line still belong in the policy?

Yes, usually. Two reasons.

It tells a guest what the network is for, which is genuinely useful. And it gives staff something to point at when they need to cut someone off. A rule nobody automated can still be a rule you apply by hand.

What it must not do is sit in the same paragraph as the enforced lines, phrased identically, so that nobody can tell them apart. Keep the automatic rules and the manual ones in separate sections. Your own staff are the people who benefit most.

Where does the policy text actually have to live?

On the login screen, at minimum in summary, with the full text one tap away. That is the only place every guest reliably looks.

Two practical constraints. First, most guests never read it, so the summary line has to carry the whole meaning on its own. Second, if you collect a phone number or email at login, the wording of the consent request is not a free choice. India’s Digital Personal Data Protection Act, 2023 requires that a request for consent be presented in clear and plain language. It also requires that the person be given the option to read that request in English, or in one of the languages listed in the Eighth Schedule to the Constitution (Ministry of Electronics and Information Technology).

That is a drafting constraint on your text, not something any WiFi product satisfies for you. A portal that can show the login screen in more than one language makes the multi-language part practical. It does not write the policy, and it does not make one correct. This is a plain summary, not legal advice, and your own advisor is the right person to review the wording you publish. What Indian rules expect from a guest WiFi login walks through the identification side of the same question.

How do you write one without starting from a template?

Backwards from the settings, not forwards from someone else’s document.

Step one: write down what is actually configured

Open your access rules and read off the real values. Opening hours. Speed limit. Device limit. Session and idle limits. Which sites are reachable without logging in. Which devices skip the login screen. This takes ten minutes and produces most of the policy.

Step two: turn each setting into one sentence a guest understands

“20 Mbps per guest” becomes “everyone gets up to 20 Mbps, so one large download does not slow the room down.” Keep the number. Numbers are what make a policy checkable, and vague wording is what makes it arguable.

Step three: add the few rules nothing enforces, in their own section

Label them honestly. “Rules we ask you to follow” reads differently from “limits the network applies,” and that difference is the entire value of the document.

Step four: add what happens to the contact details

One or two sentences. What you collect, why, and who inside the venue can see it. If your dashboard already hides guest numbers from staff who do not need them, say so. It is a real answer to a question guests rarely ask out loud. Hiding guest phone numbers by default covers how that works in practice.

What a policy does not do

It does not stop anything by itself. A published rule is not a control. Writing the rule down changes nothing about the traffic.

It also does not replace the settings. If the network has no speed limit configured, a policy sentence about fair use changes nothing about what happens when forty people connect at once. The policy is the description. The settings are the network.

The version worth publishing is the short one that matches reality: every enforced line backed by a screen you can point at, every unenforced line sitting in its own section where nobody mistakes it for a control. Write that, and the document stops being a formality and starts being the thing your front desk reaches for.