Guest WiFi logs: almost nobody is asking for them, and keeping them is a liability

The obligation most operators believe in has expired

This section describes the shape of the problem, not advice for your business, and it is deliberately specific about where each rule comes from so you can check it with a lawyer rather than take it from a software company.

Italy. The identification duty for public internet access points came from the 2005 anti-terrorism decree known as the Pisanu decree. It was extended repeatedly, lapsed at the end of 2011, and the 2012 simplification decree removed the authorisation and identification requirement. Since then there has been no general obligation on a hotel or a coworking space to identify WiFi users or retain their traffic.

Spain. The 2007 data retention law imposes a twelve-month retention duty — but on operators of publicly available electronic communications services and networks, the entities registered as such with the regulator. A property offering WiFi to its own guests as an ancillary part of the stay is generally not that, which is why the duty most portals cite does not reach it.

Germany. The direction of travel went the other way. The 2017 amendment to the Telemedia Act ended secondary liability for operators of open networks, and it explicitly removed the ability to require that an access provider register its users or protect the network with a password. The constraint there is on demanding identification, not on omitting it.

Across the EU. The Court of Justice has struck down general and indiscriminate retention of communications data more than once. Whatever a national rule says, "keep everything about everyone for a year in case someone asks" is the specific design the court has rejected.

Why every captive portal still asks for a document

If the obligation is largely gone, the persistence of the ID-scanning portal needs a different explanation, and it is not a mysterious one: for most vendors the portal is a marketing product. The identity, the email address, the device identifier and the dwell time are the value it captures. "It is a legal requirement" is simply the most effective way to explain the friction to an operator who would otherwise ask why their guests have to photograph a passport to read email.

That is a commercial argument in compliance costume. It can still be the right product for you — there are real reasons to want an authenticated network — but it should be judged as a marketing decision with a privacy cost, not as a duty you cannot refuse.

A log you did not need is a dataset you have to defend

Connection logs are personal data. Keeping them is not a neutral act of caution; it starts a set of obligations that outlast whatever prompted it:

• A lawful basis and a stated purpose. "In case the police ask" is not a purpose when no duty requires it.
• A retention period that is enforced. Not a policy document — a deletion routine that actually runs, and that someone can show running.
• An entry in your record of processing, and a defensible answer about who inside the business can read it.
• Access and erasure requests. Every log is in scope, which means you need to be able to find one guest's rows.
• Breach exposure. Four years of who connected from where is a more interesting target than your room rates.

There is a second, subtler cost. Consent collected at a captive portal is rarely freely given, because the alternative is no internet. Bundling marketing consent with network access is exactly the pattern regulators have criticised, and it contaminates the consent you may genuinely need for something else.

What Boris stores, and what it refuses to store

The design follows from the above. Boris keeps the credential and its link to the stay: which network, which booking, which holder, valid from when until when, whether the push to the provider succeeded. That is an operational record — it is what lets a credential be revoked when a booking is cancelled, and what explains why someone could get online at all.

What Boris does not have is a connection log. There is no local session table, by choice. Where a provider exposes session data — MikroTik can list active sessions, a Meraki network can return recent splash login attempts, and some providers expose nothing at all — Boris reads it live, for the screen you are looking at, and does not copy it into its own database.

The reasoning is the one above, applied honestly: data you hold is data you must govern, and an operational system should not quietly become the long-term archive of everyone's device history because a table was easy to add.

Designing a portal that is defensible

If you want an authenticated network — and there are good operational reasons, from abuse handling to keeping neighbours off it — the design that survives scrutiny looks like this:

1. Tie access to the stay, not to an identity document. A credential issued per booking, valid for the stay window, already answers "who was this" through the booking you were always going to keep.
2. Separate access from marketing. Network access must not depend on a newsletter checkbox; if you want the address, ask for it after the guest is online.
3. Set the retention period before launch, and make it as short as your actual purpose supports. Reversing this later means deleting data you already promised to keep.
4. Do not collect what you will not use. A document scan with no purpose is not extra safety, it is extra exposure.
5. Write down the answer you will give a court, and check that it matches what you store. If you cannot describe your own logging in two sentences, nobody in your business can comply with it.

"We do not have that" is a complete answer when it is true, and a far better position than discovering what you kept at the moment someone asks for it.