Archived version
GControl privacy notice
Exactly what leaves your instance and reaches us, taken from the wire protocol rather than described in general terms.
This is the current version. It is kept here under a fixed address so it can be cited and compared. The live document is the same text.
Two different questions
GControl runs on your infrastructure. For everything it does there — the applications, their data, their users — you are the controller and we process nothing. We have no access to your systems and no visibility into them.
But GControl talks to us, and what it sends is a small amount of information about your installation and, in one configurable case, about your administrators. That is what this notice is about. For it, the controller is Gelhaus Solutions, Eichenwald 3, 49624 Löningen, Germany, egelhaus@ennogelhaus.de.
What we do with it once it arrives, and the account you hold with us, are covered by the GPlatform Control privacy notice. That is a separate service and a separate document.
The shape of the connection
Every call is initiated by your instance. There are no inbound connections into your network, ever — which is why a command is delivered as a field in the answer to your heartbeat rather than pushed to you.
An instance that never enrols sends nothing at all. Standalone operation is a first-class mode, not a degraded one.
What is sent when you enrol
Your licence document, or a pairing code and its confirmation, or an enrolment token. The GControl version and the API range it supports. A label you chose for the instance. The stamp ledger the instance already holds and its ratchet position, so facts that accumulated before we ever met it are not lost.
What the heartbeat carries
This is the documented payload. Anything not in it does not leave your instance.
About the instance: its identifier, the GControl version, which protocol features this build understands, the catalogue and allowlist versions it has, the public half of the key it signs app leases with, the current emergency state.
About each application: its id, version, manifest reference, the ids and versions of installed modules, its condition, a health report, its at-rest mode, and whether it holds a licence seat.
Counts, not identities. A number of end users the application can see, together with an opaque fingerprint of the datastore it counted them in, so replicas can be de-duplicated. A number and a fingerprint, never identities. No end-user data leaves the application, let alone your network.
Usage aggregates. Daily totals the broker has already folded, sent as today's bucket plus the last few closed days. The declared aggregates and nothing else — the readings behind them stay on your instance, where you can see them before we can, and what travels is the same number your screen shows.
Chain heads. The head hash of your audit chain and of your stamp ledger, for anchoring. Head hashes, not entries: anchoring proves the chain has not been rewritten without telling us what is in it.
Command results. The outcome of anything you let us ask for. Small, structured, and never containing application user data.
Health values are filtered against what the application declared in its manifest before they get this far, and are kept for 90 days.
Diagnostics, which are off
Diagnostics are opt-in and off by default, recorded per instance with who turned them on, and revocable. The absence of a consent record means off, so a failed write can never quietly enable sharing.
When on, they carry an error rate, a slow-request rate, and fingerprints of stack traces — hashes, not traces. No paths, no arguments, no data.
The one place your people can appear
audit.tail is a read verb, and read verbs are on by default. It returns recent rows of your audit log: the sequence number, the time, the action, the display name of whoever did it, the subject, and the row hash.
It deliberately does not return the IP address or the user id, both of which your local audit entry does store. So what can reach us is an administrator's display name and what they did — not where they were, and never your application end users.
If you would rather that did not leave, switch audit.tail off. It is your allowlist and the software will not turn it back on.
backup.status returns labels, timestamps, sizes and outcomes, and how many datastores a job covers — never which ones, never backup contents, and never a destination credential.
Support sessions and shells
Where you approve a support session, we see what its scope allows for as long as it lasts, and your side enforces the expiry. Where you separately approve a shell, what happens in it is written to a transcript on your instance. We do not receive that transcript.
The key we hold
We generate and hold the private half of your instance's lockdown key, in Vault, one per instance. Our database holds the public half and a path — never the material. It exists so a sealed instance can be recovered, and it moves only during an unseal after a person has verified the requester out of band.
Why we may do this
Providing the licensed software and the services attached to it is performance of a contract, Art. 6(1)(b) GDPR.
Licence enforcement, counting seats and usage, the integrity of the audit anchors and the security of the service are legitimate interests under Art. 6(1)(f): the interest is in the software being used as licensed and in an incident being reconstructible afterwards.
Diagnostics are consent, Art. 6(1)(a), given per instance and withdrawable.
How long
Instance, licence and entitlement records are kept for as long as the licence and afterwards as the record of it. Health samples are kept 90 days. Meter buckets are kept as the billing and usage record. Audit anchors are kept for the integrity of the chain they anchor. Diagnostics stop arriving the moment consent is withdrawn.
Who else touches it
Hosting on servers rented from IONOS SE (Germany) and Contabo GmbH (Germany, being wound down), and on our own hardware in Germany. All in the EU, no transfer to a third country. No analytics service and no advertising network.
Your rights
Access, rectification, erasure, restriction, portability and objection, as in the general privacy policy. An informal email is enough.
You may complain to a supervisory authority; the competent one here is Die Landesbeauftragte für den Datenschutz Niedersachsen, Prinzenstraße 5, 30159 Hannover.
Version identifier
gcontrol-privacy-2026-09-06
Content hash, SHA-256
cac42537855c640b1a704f213e76f702fac0b491afa2de1c94c0f080b96cc3cd