In brief
Auditors ask for access records, integrity evidence, role-based access, an audit trail and network segregation for your guest network. Here is the concrete evidence the box gives you for each.
The guest network is in scope
In businesses that hold an ISO 27001 certificate or go through customer audits, guest Wi-Fi is usually treated as a side topic. Auditors do not see it that way. The guest network shares physical infrastructure with the corporate network, is open to outsiders, and produces personal data. Those three properties put it in scope.
This article lists the headings auditors raise about guest Wi-Fi, in their own language, and shows the concrete evidence each one maps to in Hotspot-Box. The goal is to shorten your audit preparation.
The auditor's headings and where they land in the box
| Auditor's question | Evidence sought | Where it lives in the box |
|---|---|---|
| Who connected to the guest network, and when? | Access records | Verification detail, MAC, internal IP, session start and end; kept 730 days |
| How do you prove the records were not altered? | Integrity evidence | Daily SHA-256 hash chain + RFC 3161 timestamp; one-click verification in the panel |
| Who can access the records? | Role-based access | Panel roles; only an authorised role sees phone numbers, and sees them masked |
| What did administrators do? | Audit trail | Panel actions and automatic deletions are written to the audit trail |
| Is guest traffic separated from the corporate network? | Segregation | Guest network on its own VLAN; the box is the guest network's firewall |
| Are the records backed up? | Backup | A second copy of the archive goes off the box over SFTP/FTPS |
| Is the clock trustworthy? | Time synchronisation | NTP monitored with drift alarms; the box's clock is reported against the timestamp service |
| What happens to expired data? | Retention and disposal | Expired days are deleted automatically; the deletion is written to the audit trail |
Access records: "who and when"
Auditors usually sample: "Show me the records for this date." Each day's record file stands on its own in the box. It contains the guest's verification detail (the SMS-verified number stored encrypted, a coupon code or an e-mail), the device MAC address, the assigned internal IP, session start and end, and the NAT mapping where applicable. There are no visited sites and no content, which also counts in your favour under data minimisation.
Integrity evidence: "how do I know it was not changed?"
A record existing is not enough; you must be able to show it was not altered. The box takes the SHA-256 digest of each day's record file and chains it to the previous day's digest. The chain starts on the day the box is installed; nothing is signed retroactively. Each day's digest is sent to an RFC 3161 timestamp service; the service receives only the digest, never the records.
Evidence you can show the auditor: the report produced by the "verify" button in the panel and the exported ZIP archive. The archive holds day folders, line files, a manifest with the SHA-256 chain and the timestamp file. The auditor can verify the timestamp independently with openssl ts -verify; they do not have to trust our software.
Role-based access: "least privilege"
Auditors ask who can reach guest data and whether that matches job roles. Roles are defined in the panel. Only an authorised role sees guest phone numbers, and sees them masked. Technical staff can verify record integrity without ever seeing a number. Put that distinction into your access matrix as its own row.
Audit trail: "what did the administrators do?"
The access record describes the guest; the audit trail describes the administrator. Actions in the panel are kept as who, when and what. Automatic deletion of expired days appears here too. So when asked "do you enforce your 730-day retention policy", you answer by showing evidence of enforcement rather than the policy document.
Segregation: "can a guest reach my servers?"
The guest network runs on its own VLAN. The box is that network's firewall (pfSense based); guest traffic does not cross into the corporate network. Client isolation on the access points is recommended so guests cannot see each other either. The box does not replace your corporate UTM; your existing firewall stays, and the box takes over the guest segment. Evidence for the auditor: the VLAN plan, the box's interface diagram, and a failed attempt to reach the internal network from the guest network.
Third parties and data flow
Auditors ask "where does the data go". The answer is short:
- Records stay on the box, in your premises. They go neither to a cloud, nor abroad, nor to us.
- The timestamp service receives only digests.
- SMS goes straight from the box to the provider; the hotspot-box.com platform never sees a guest number. It only hands out API credentials and counts credits.
- Device telemetry carries no guest data.
Document that flow in one data-flow diagram. It is the document auditors appreciate most.
Pre-audit checklist
- Add the guest VLAN and the box's position to the network diagram.
- Enter the panel roles into your access matrix.
- Produce the integrity verification report for the last 30 days.
- Confirm that the SFTP/FTPS second copy is actually being written.
- Add the portal's privacy notice and the consent record to your document set.
- Show the alert channels (e-mail/Telegram/webhook) and recent alerts.
Deployment details are on the box and virtual appliance pages. For help preparing for an audit, contact us.
This article is for general information only and is not legal or audit advice.
This article is for information only and is not legal advice; confirm your obligations with your legal adviser.