DPIA information pack

1. What this is, and what it is not

This page is the supplier information a DPIA needs. It is not a completed DPIA and we are not pretending otherwise. The DPIA is a statutory duty that sits with you as controller, and the two parts nobody else can do for you are the necessity and proportionality assessment and the judgement about risk to your particular data subjects.

What we can do is stop you having to extract the facts from us one email at a time. Everything below is checked against the running system rather than aspirational, and where the honest answer is unflattering it is written that way. If your DPO needs something that is not here, ask and we will add it to this page rather than answer only you, because the next school will need it too.

Questions to support@logicboks.com. A person reads it.

2. Do you actually need a DPIA for this?

Possibly not a full one, and it is worth saying so before you spend a week on it. A DPIA is required where processing is likely to result in a high risk to individuals. Building management telemetry usually is not: a flow temperature, a CO2 reading, a kilowatt hour and a valve position are facts about a building, not about a person, and if that is all you are sending then your screening will be short and the answer will be no.

It changes when the sensor identifies somebody. Screen carefully for these, because they are the ones that catch people out:

• Occupancy or motion sensing in a space used by ONE identifiable person. A desk sensor in a single office is attendance monitoring of a named member of staff, whatever it was installed for.
• Anything derived from access control or door events, where the event carries a card holder.
• Anything derived from cameras, including counts, because the source is personal data even when the output is a number.
• Special category inference. A sensor that reveals when a person uses an accessible washroom, or a prayer room, is processing data about health or religion no matter what the topic is called.
• Systematic monitoring of pupils, which brings the DfE's expectations and children's data into scope at once, and where the ICO's bar for a DPIA is low.

One that is specific to MQTT and catches almost everybody: the credential names, client identifiers and topic paths are chosen by YOU, and they reach our connection logs. A credential called "j.smith-office" or a topic "room/head-teacher/occupancy" puts a named person into our systems even when the payload is a number. If you want the shortest possible DPIA, name things after rooms and assets rather than people. It costs nothing at commissioning and cannot be undone afterwards.

3. What data actually reaches us

There are three buckets and they are worth keeping separate, because they have different answers.

• MESSAGE PAYLOADS. The broker moves them and does not store them. There is no message archive, no replay, no analytics over your telemetry, and no copy retained after delivery. If you need history you send it somewhere of your choosing, and that destination is yours to assess rather than ours. This is the single most important fact for your DPIA and it is why most of them come out short.
• CONNECTION METADATA. Which credential connected, from which IP, at what time, whether it was accepted, and which topics it subscribed to. This is a security log and it is genuinely necessary - it is how you find out that a credential is being used from somewhere it should not be. It is where customer-chosen names land, per the warning above.
• ACCOUNT AND BILLING DATA. The names, email addresses and billing details of the people who administer the account. For this bucket we are the controller, not your processor, and it is covered by the Privacy Policy rather than the Data Processing Agreement.

We do not profile, we do not make automated decisions about individuals, and we do not use anything you send for training, analytics or product development.

4. Sub-processors, and where the data physically is

In full, with locations, because "the cloud" is not an answer a DPO can put in a document:

• Hetzner Online GmbH - hosts the broker itself. The machine is in Helsinki, Finland. This is where your messages are actually transmitted.
• Supabase - the database and authentication behind the console. Data is held in the EU. This holds your account, clusters, credentials and connection logs.
• Lovable - hosts the console application and sends transactional email, using Mailgun's EU infrastructure for delivery.
• Cloudflare - sits in front of the console as CDN and DDoS protection, and terminates TLS for ayaimq.com. It sees request metadata for console traffic. It is NOT in the path of MQTT traffic, which goes directly to the broker in Helsinki on ports 8883 and 8884.
• Stripe Payments UK Limited - payments and invoicing. Stripe sees billing contact details only, never message payloads or connection logs.

Everything in the path of your message data sits in the EU or the UK. We will give you notice before adding or replacing a sub-processor so that you can object on reasonable grounds, which matters here because a change of location is a change to your DPIA.

A UK-only or region-specific deployment is available on the Dedicated plan, where the broker is a machine of your own and you choose where it stands. If data residency is a hard procurement requirement rather than a preference, that is the plan to ask about.

5. How long we keep things

• Message payloads: not retained at all. They are transmitted and gone.
• Connection and authentication logs: 30 days, then deleted by a scheduled job rather than by somebody remembering. Aggregate daily counts per cluster, which identify no individual, are kept longer so the console can draw a usage chart.
• The list of currently connected devices, which includes the IP a device is connected FROM, exists only while the session is open. It is live state rather than a log, and a device that disconnects leaves no row behind.
• Account records: for the life of the account, and deleted or anonymised after it closes, subject to the record-keeping we are legally required to do.
• Billing records: six years, because UK tax law requires it. This is one of the few places where we cannot delete on request, and your DPIA should record it as such rather than assume erasure is always available.

6. Security measures

The detail is on the Security page and this is the summary a DPIA needs: TLS on every path, per-tenant isolation enforced at the broker rather than by convention, per-device credentials with topic permissions scoped to least privilege, passwords hashed and revealed exactly once, key-pair authentication available for controllers so no shared secret sits in the field, administrative access gated behind two-factor authentication, and connection logs that make misuse visible.

Credentials are revocable instantly and independently, so a compromised device is a single revocation rather than a site-wide password change.

7. The risks we have NOT mitigated

A risk register that lists only solved problems is not a risk register, and a DPO who finds an unstated risk later will reasonably wonder what else was left out. So, plainly:

• SINGLE POINT OF FAILURE. On the shared plans there is one broker in one location with no failover. If it goes down, your messages do not flow until it is back. There is no binding uptime guarantee attached to those plans, and that is exactly why they cost a fraction of the alternatives. If continuity of the control system matters to your risk assessment, the mitigation is not on our side: it is that your BMS should degrade safely without the broker, which a well-designed system does anyway. The Dedicated plan is the tier where an availability commitment becomes possible.
• WE ARE A SMALL SUPPLIER. Logicboks is a real registered company with real building-controls engineers, and it is not a large one. Supplier viability belongs in your assessment. The mitigation we can offer is genuine: it is standard MQTT, so there is no lock-in and no proprietary format, and your devices would point at a different broker with a configuration change rather than a migration project.
• NO INDEPENDENT CERTIFICATION YET. We do not hold Cyber Essentials or ISO 27001 today. We are pursuing Cyber Essentials first because it is what schools actually ask for. We would rather tell you that than let you find out at the procurement stage, and if a certification is a hard requirement for you right now then we are not yet the right supplier.
• CUSTOMER-CHOSEN IDENTIFIERS. As set out in section 2, you control what names reach our logs, and we cannot prevent a personal name being used as a credential or topic. The mitigation is a naming convention at commissioning.

8. Data subject rights, and what happens in a breach

Because we do not retain message payloads, most rights requests about telemetry have a short answer: there is nothing held to access, rectify or erase. For connection logs and account data we will help you respond within your statutory deadline, and the Data Processing Agreement sets out the obligation formally.

We will notify you without undue delay after becoming aware of a personal data breach affecting your data, with enough detail for you to meet your own 72-hour obligation to the ICO. Security concerns go to support@logicboks.com.

We will not transfer your data outside the UK or EU, or add a sub-processor that would, without telling you first.

9. What we will sign, and what to ask for

A signed Data Processing Agreement is available on request, and the terms of it are published so your DPO can read them before any conversation rather than after. If your trust has its own data protection schedule or supplier questionnaire, send it and we will complete it.

Everything here is dated and we will keep it current. If it is more than a few months old when you read it and something looks wrong, write to support@logicboks.com and ask - out-of-date supplier information is worse than none, because it gets believed.