Last updated: 2 July 2026
This page explains how data flows through MusterHub, what your service is responsible for, and where we fit in. The answers depend on which deployment option you use, so we have covered both below.
MusterHub is available as a self-managed deployment, where you run your own server on your own Azure subscription, or as a managed hosting deployment, where we run a dedicated server for your service on our Azure account. The data protection picture is different for each.
If you provision and operate your own Azure instance, MusterHub's role is simple: we supply the software and you run it. Your data lives in your own Azure environment and never passes through ours.
The one exception is the initial routing lookup when a crew member first sets up the app. At that point, their email address passes through our central service so the app can find your server. That email address is not retained after the redirect. If you want a short written agreement covering that narrow activity, we can provide one.
If we host your server for you, we run a dedicated virtual machine in our Azure account on your behalf. That VM is isolated from all other services. No other MusterHub customer's data sits on the same database or storage volume, and there are no application-level links between services.
Your instance is hosted on Microsoft Azure (UK) infrastructure. Physical and environmental security is governed by Microsoft's ISO 27001 certified data centres, and your data remains in the United Kingdom.
In this arrangement, you are the data controller and MusterHub is your data processor for operational data. Article 28 of UK GDPR applies, which means we need a written Data Processing Agreement in place before processing begins. Contact us and we will arrange one.
In practice, that means:
As the Azure administrator for your hosted instance, we have the technical means to access the data on your server. We do not access it except when needed to maintain or support the service for you. If you want a record of any support access we carry out, we can provide that.
Our central service plays one narrow role: when a crew member first opens the app, they enter their email address and service code. The central service uses those details to find the address of your server and directs the app to it. After that initial connection, all communication goes directly between the app and your server. We have no ongoing access through the central service.
The email address used for the lookup is not retained after the redirect is complete.
Because you operate your own server and hold your staff's personal data, your service is the data controller and processor. Your responsibilities include:
Most of the above responsibilities remain with you as data controller. The main differences are:
Your data stays in your own Azure tenant. When you finish with MusterHub, you can decommission the server at your own pace. We can provide guidance on the process, but there is nothing to export or retrieve from our side, because we never held it.
When you leave, we will export your database in a portable SQL backup format and securely delete your data from our systems within 30 days of your departure date. We will confirm deletion in writing. If you need data in a different format, let us know before your end date and we will do what we can.
We release updates to the MusterHub platform and provide support to both deployment types. For managed hosting, we apply updates and patches on your behalf.
For self-managed services, if a support issue requires access to your server environment, that access should be explicitly authorised by you. Any such access would be temporary, logged, and limited to what is needed to resolve the issue. If you want a formal written agreement covering support access, contact us and we will arrange one.
Depending on your service type, a DPIA may be required before deploying MusterHub. We can provide technical architecture documentation to support that process. Contact us at privacy@musterhub.app.
For operating the central routing service, MusterHub uses one infrastructure provider:
As the data controller and processor for your own instance, your sub-processors typically include:
Your DPO should document these in your records of processing activities and check that appropriate agreements are in place with each provider.
As your data processor, MusterHub uses the following sub-processors to run your hosted instance:
Push notifications are delivered using APNs (Apple) and FCM (Google) credentials that you configure on your server. Push notification tokens are stored on your server and transmitted via Apple and Google infrastructure. For managed hosting, those credentials are stored in your instance's configuration and are not accessible to or shared with other services.
Wellbeing check-in responses are anonymised before storage. Individual responses are not linked to identifiable staff members.
Personal wellbeing journal entries are encrypted at rest using a service-specific key.
For self-managed services, that key lives in your Azure environment. Your Azure administrators can access it, but MusterHub cannot.
For managed hosting, that key lives in our Azure environment. Our Azure administrators have the technical means to access the key and, through it, the encrypted content. We do not access wellbeing journal content except where required to resolve a support issue you have explicitly authorised. If direct control over the wellbeing encryption key matters to your service, the self-managed deployment is the better fit.
For both deployment types:
For self-managed services:
For managed hosting:
If you have questions about the technical architecture, need documentation for a DPIA or procurement process, or want to discuss a Data Processing Agreement for managed hosting, get in touch at privacy@musterhub.app.