Data Processing Addendum

GuestPass Cloud, a Simple Technologies product. Version 1.0 — last updated 2026-09-22.

Draft pending legal review. These documents were written in-house and have not been reviewed by an attorney; Simple Technologies should have counsel review them before signing a paying customer.

This Addendum forms part of the Terms of Service between Simple Technologies ("Processor", "we") and the customer ("Controller", "you"). Where the two conflict on the processing of personal data, this Addendum wins.

1. Roles

You are the controller of the personal data you put into GuestPass Cloud and of the personal data your networks' guests provide. We are the processor, acting on your documented instructions.

If you are a managed service provider, you may be a processor for your own customers and we are then a sub-processor to you. Nothing here creates a relationship between us and your customers. You are responsible for having the authority to appoint us.

Your instructions are: the configuration you set in the product, the API calls you make, and this agreement. We will tell you if an instruction appears to us to breach applicable data protection law, and we will not process the data for our own purposes.

2. Subject matter, duration, nature and purpose

We process personal data to provide guest WiFi access management: issuing and redeeming vouchers and pre-shared keys, running captive portals, authorizing devices on controllers, taking guest payments on your Stripe account, producing reports, and supporting you. It lasts as long as your account does, plus the 30-day post-termination window in the Terms.

3. Categories of data subject and personal data

Data subjects: your staff and contractors who use the console; network guests; visitors to a block page.

Personal data:

• Staff: name, email address, password hash, authentication factors, session and sign-in records, IP address, audit records of their actions, support reports.
• Guests: device MAC address, access-point MAC address, network name, IP address, user-agent string, sign-in method and outcome, duration granted, and whatever the property chose to ask — which may include name, email address, mobile number, a location or booking reference, and free-text answers to up to twelve custom questions.
• Guest payments: amount, currency, status, Stripe session and payment-intent identifiers, device MAC address, network name and IP address. No card data. Payment card details are entered on Stripe's hosted checkout and never pass through or rest in GuestPass.
• Block page visitors: public IP address, and the block category returned by the customer's own Cisco Umbrella organization.

We do not require, and the product does not ask for, special-category data. A free-text custom question could be used to collect it. If you do that, you are the controller of that choice and you must have a lawful basis; tell us in advance, because we have not designed for it.

4. Confidentiality

Access to production systems is limited to Simple Technologies personnel who need it to operate and support the service, under confidentiality obligations that survive their engagement. Support staff can see tenant data through the internal domain console; that access is recorded in the audit log.

5. Security measures

These are the measures actually implemented. Details are on the Security page.

• Encryption in transit: all traffic is HTTPS, terminated by Cloudflare. The on-site bridge connects outbound over HTTPS and is authenticated with a per-site token.
• Encryption at rest of connected credentials: UniFi API keys, your Stripe secret key for guest payments, identity-provider client secrets, webhook signing secrets, RADIUS passphrases and Umbrella API secrets are encrypted with AES-256-GCM before they are written to the database, and decrypted only in the Worker at the moment they are used. They are never returned to the browser or the API. The encryption key is a Cloudflare Worker secret, held write-only outside the running Worker. It is one platform key, not a key per tenant — we say so rather than implying stronger separation than exists. Cloudflare additionally encrypts D1 and R2 storage at rest.
• Password storage: PBKDF2-HMAC-SHA256 at 600,000 iterations with a per-user random salt, which is OWASP's current recommendation for PBKDF2-SHA256. Hashes are versioned; anything written at the older 100,000-iteration work factor is re-hashed at the current one the next time that person signs in. Verification is constant-time.
• Other credential handling: emailed sign-in links are stored only as a hash and are single-use; passkey signature counters are kept so a cloned authenticator can be noticed; passkey challenges are spent server-side so an assertion cannot be replayed.
• Tenant isolation: every query is scoped to the organization, company or site the signed- in user is entitled to. It is logical isolation within one database, not separate databases per tenant.
• Audit log: administrative actions record the actor, their email, the target organization, company or site, the action, a detail and the source IP address.
• Session security: session cookies are HttpOnly, Secure and SameSite=Lax, with an expiry the organization sets. Responses carry a Content-Security-Policy, X-Frame-Options, X-Content-Type-Options and a referrer policy chosen so that tokens in reset and invitation URLs are not leaked to third-party sites.
• Optional stronger authentication: passkeys, authenticator-app 2FA, Cisco Duo MFA, and single sign-on through Cisco Duo SSO or another OIDC provider. An organization can require 2FA or require SSO-only sign-in.
• Resilience: Cloudflare D1 point-in-time restore covering the preceding 30 days; every deployment kept as a Cloudflare Worker version so the platform can be rolled back.
• Change management: features are gated behind release channels (alpha, beta, production) and a tenant that hits trouble can move to a steadier channel.

We have not obtained a SOC 2 report or an ISO 27001 certification and have not had a third-party penetration test. We will not claim otherwise, and we will tell you if that changes.

6. Sub-processors

You give general authorization for the sub-processors listed on the sub-processor page. Each is engaged under a written contract imposing data protection obligations no less protective than these.

We will give at least 30 days' notice before adding or replacing a sub-processor that processes your data. Account owners are notified by email and the page shows the change. If you reasonably object on data protection grounds within that period, we will work with you on an alternative; if there is none, you may terminate the affected part of the service without penalty for the unused remainder of your term.

7. International transfers

We are a United States company and our sub-processors operate internationally. Where personal data protected by the UK GDPR or the EU GDPR is transferred outside the UK or the EEA, the transfer relies on the European Commission's Standard Contractual Clauses, and the UK International Data Transfer Addendum for UK transfers, which the parties agree are incorporated into this Addendum by reference and completed as follows: you are the data exporter, we are the data importer, the module is controller-to-processor, the subject matter and categories are those in section 3, and the governing law and forum are those of the Standard Contractual Clauses.

Our principal sub-processors maintain their own transfer mechanisms; see the sub-processor page.

Counsel should confirm this clause and the completion of the Clauses before it is relied on for an EU or UK customer.

8. Assistance to you

Taking into account the nature of the processing, we will assist you with:

• responding to data subject requests — access, correction, deletion, restriction, objection and portability. The console lets you find and export guest and voucher records yourself; where it does not, ask us;
• your data protection impact assessments and any prior consultation with a regulator;
• your own security obligations, by giving you the information in this Addendum and on the Security page.

We will pass on to you, without responding to it ourselves, any request we receive directly from one of your guests or staff.

9. Personal data breach

If we become aware of a personal data breach affecting your personal data, we will notify you without undue delay and in any event within 72 hours of becoming aware of it, by email to the account owner and any security contact you have given us, with what we know: what happened, when, which categories and roughly how many records are affected, the likely consequences, what we are doing, and what we suggest you do. We will keep you updated as we learn more and we will not wait for a complete picture before the first notification.

Notifying regulators and data subjects is your decision as controller, and we will help you make it.

We do not currently operate a 24/7 security operations centre. Detection depends on our monitoring, our logs and reports we receive.

10. Deletion and return

On termination, and on request during the term, we will delete or return your personal data as described in the Terms: available for 30 days after termination, then deleted, with deletions persisting in Cloudflare's point-in-time restore window for up to a further 30 days. We keep what the law requires us to keep — principally billing records — and keep it protected.

11. Audit

We will make available the information necessary to demonstrate compliance with this Addendum and respond to your reasonable security questionnaires once per year, or more often if a regulator or a breach requires it. We do not currently have an audit report to offer in place of that. On-site audits are by agreement, at your cost, on reasonable notice, and must not disrupt other customers or expose their data.

12. Liability

Liability under this Addendum is subject to the limitation of liability in the Terms of Service.