What Your Guest WiFi Terms Should Actually Say

Every captive portal has a line of text and a checkbox near the bottom, and almost nobody reads it. That’s not a failure of the guest; it’s how every terms box on the internet works. But the box isn’t there to be read cover to cover. It’s there so that, at a specific moment, an identifiable person agreed to a specific thing, and you have a record of it. Most guest WiFi setups either leave that text as whatever the router shipped with, or paste in something borrowed from a website’s privacy policy that talks about cookies and browser sessions and has nothing to do with a phone connecting to WiFi in a lobby.

This isn’t legal advice, and your own advisor is the right person to sign off on the final wording. What follows is what the acceptance step is actually for, and what a plain, honest version of it contains.

The one mistake most setups make

Here’s the one worth fixing before anything else: bundling.

A lot of login screens have a single checkbox that says something like “I accept the terms and agree to receive offers and updates.” Ticking it is the only way to get online. That single tick is being asked to carry two completely different agreements: one about using the network, and one about being marketed to later.

Under the Digital Personal Data Protection Act, 2023, consent to collect and use someone’s personal data is supposed to be specific to a stated purpose, and a guest is supposed to be able to agree to one thing without being forced into another. A guest who only wanted internet has not meaningfully agreed to a marketing list just because the same tick was the only door available.

The fix is small and costs you almost nothing: the terms acceptance required to get online stays required, and the marketing opt-in becomes its own separate, optional tick. You will get fewer opt-ins. You will also get a marketing list where every number on it actually chose to be there, which is a better list to send anything to. Your WiFi login screen is a marketing channel covers what to do with that list once it exists; this is about collecting it cleanly in the first place.

What actually belongs in the text

Short and specific beats long and borrowed. A guest WiFi terms block only really needs to cover five things:

Who is providing this network. The actual business name of the property, not “the management.” If a guest ever needs to ask a question about their data, they need to know who they’re asking.

What you collect and why. A phone number or email, collected so the OTP login works and so the session can be tied to a real person. That’s it, in one sentence. If you’re also collecting something else, say that too.

How long you keep it. This is the field most properties have never actually decided, and it’s worth deciding deliberately rather than defaulting to forever. Session records exist partly so you can answer a question later if one is ever asked, so a real retention period is not zero, but “we keep everything indefinitely because nobody set a limit” isn’t a policy either. Pick a period, write it down, and confirm it against whatever rules apply to your specific business.

What isn’t allowed on the network. A short list, in plain words: no illegal downloads, no trying to reach other people’s devices, no reselling the connection. This is the part that gives you a clear basis for cutting off a session if you ever have to.

Who to contact. One email address or phone number that a guest can actually use.

That’s a screen of text, not ten pages. A guest who does decide to read it can finish it before their OTP arrives, which is a genuinely useful test to apply to your own wording.

What to leave out

Don’t promise a speed. A terms block that says “guests receive high-speed internet” is a commitment written into an agreement, and on a Saturday evening with a full lobby it may not be one you can keep. If you set per-guest speed and time limits, it’s fine and honest to say the connection is shared and limits apply.

Don’t claim monitoring you don’t do. Boilerplate copied from corporate network policies often says something like “all traffic is monitored and inspected.” On a normal guest network that is usually not true, and saying it commits you to a level of surveillance you neither perform nor want the liability for. Website blocking works at the DNS level without inspecting what guests are actually doing, which is both the more common setup and the more defensible one to describe.

Don’t ask for data you have no use for. A full name, a room number, a date of birth, and a home address on a cafe login screen is four fields of personal data you are now responsible for holding, in exchange for nothing. The rule of thumb is the same one the law is pointing at: collect what the login actually needs, and nothing decorative.

Where the record actually lives

The text is only half of it. The other half is that the agreement was recorded against a real, identifiable session, which is the same thing an OTP login is already doing for you. Is your guest WiFi login legal in India covers that identification side in full. Once identification is in place, the terms acceptance sits on top of it: this person, this number, this time, agreed to these terms.

And the data collected under that agreement should behave the way the agreement describes. If your terms say a guest’s number is collected for login, then hiding guest phone numbers from staff by default is the dashboard actually keeping that promise rather than a separate nice-to-have.

A reasonable place to start

If you have never touched this: open your own login screen on your own phone, read what it currently says, and check three things. Does it name your business? Does one tick do more than one job? Does it promise anything you’d be uncomfortable being held to?

Most properties find at least one of those three is off. Fixing them is a text edit and a second checkbox, not a project.