Data processing agreement

Agreement under Art. 28 GDPR · version 1.4, 11 October 2026 · Deutsche Fassung

When you need this: only if you use BrowserDesk through our relay — then we process data on your behalf. If you run the relay yourself there is no processing on your behalf; the data stays with you and you do not need this agreement (see section 2).

1Parties and conclusion

The controller (“you”) is you as the customer. The processor (“we”) is Martin Stemplinger, Ilztalstraße 5, 94116 Hutthurm, Germany, info@browserdesk.de.

This agreement supplements the terms of use and applies as soon as you request it in text form and we confirm it — an e-mail is enough. On request we will also sign it. In case of conflict this agreement prevails over the terms of use as far as the processing of personal data is concerned.

2Subject matter and duration

The subject matter is the processing of personal data arising when BrowserDesk is operated through our relay: brokering remote connections, providing the administration console, the web client and the update feed.

Not covered is self-hosting. If you run the relay via Docker, as a Windows service or as a Linux package, we process none of this data; it stays solely on your systems. What remains reachable from us is the update feed, whose retrieval creates the usual server logs on our side — we process those as a controller, not on your behalf.

The agreement runs for as long as we process on your behalf and ends with the usage relationship.

3Nature, purpose, categories of data and data subjects

Nature and purpose: collecting, storing, transmitting and deleting the data listed below, solely to provide the agreed service and to secure its operation. We do not process the data for our own purposes — no advertising, no profiling, no sale of data.

Category	Content
Device data	Name, platform, version, tags, first and last check-in, device certificate, inventory data from collector scripts
Session data	Target device ID, IP addresses of both sides, start and end. Picture, input and files of the session are not stored (recordings excepted, see below). How they are protected in transit depends on the path (Annex 1, “Confidentiality in transit”).
Log data	Hash-chained audit log: time, acting person, tenant, device, action and its details, for some events (such as sign-ins and quick codes) the IP address; device logs; script runs with their parameters — only parameters of the type “secret” are masked, all others are stored in clear text
Consent	Consent granted per capability, person and validity period
Accounts	User name, role, password only as a salted hash (PBKDF2)
Recordings	Screen previews and session recordings. Automatically only if you switch this on for a device (off by default). Independently of that, a technician can start a recording during a running session; the controlled device then shows a notice that a recording is running (program version 20261006.8 or later). Only recordings “to the console” are kept on the relay; a local recording is saved by the technician on their own computer — it stays with you, not with us.
Voice and sound	Voice (microphone) and the device's sound during a session — only if the participants want it, the microphone at the supported device only after a consent prompt there; encrypted between the endpoints, not stored, not recorded; the audit log only notes who consented and when
Feedback	Bug reports and suggestions from the app (text, stated device ID, IP address, on request diagnostics and a log excerpt) — stored on the relay; they reach us as the vendor only on your instruction (forward per report), then without device ID and IP address; from then on we process them for product improvement under our own responsibility

Categories of data subjects: your staff and agents who use BrowserDesk or whose devices are supported; persons present at a supported device on your behalf. Special categories under Art. 9 GDPR are not covered; if your use nevertheless places them in a recording, that is your responsibility.

4Instructions

We process the data only on your documented instructions. Instructions comprise this agreement, the terms of use and your settings in the console — such as retention periods, consent, and switching preview and recording on or off. Further instructions are to be given in text form to info@browserdesk.de.

If we consider an instruction unlawful, we will say so and may suspend its execution until you confirm or change it.

5Our obligations

Processing exclusively within the European Union; no transfer to third countries.
Confidentiality: access only for persons bound to confidentiality and familiar with the requirements of the GDPR.
Implementing and maintaining the measures in Annex 1 (Art. 32 GDPR).
Assisting you with your obligations under Art. 32 to 36 GDPR as far as possible and reasonable.
Keeping a record of the processing carried out for you (Art. 30(2) GDPR).
A data protection officer is not required by law; the contact is Martin Stemplinger at the address above.

6Your obligations

You remain responsible for the lawfulness of the processing, in particular for the legal basis of the remote access.
You inform the data subjects and involve — where required — the works council and the data protection function, especially before switching preview or recording on.
You choose retention periods and consent settings as your purposes require.
You notify us without delay of misuse or lost credentials.

7Technical and organisational measures

The measures in Annex 1 apply. We may develop them further as long as the level of protection does not fall. We will notify material reductions in advance.

8Sub-processors

You consent to the use of the sub-processors listed in Annex 2. We bind them contractually to at least the level of protection of this agreement.

We will notify a change or an addition of sub-processors at least four weeks in advance in text form. You may object within two weeks on important data protection grounds; if no agreement is reached, you may terminate the usage relationship as at the date the change takes effect.

9Data subject rights

If a data subject approaches us with a request for access, rectification or erasure, we refer them to you and inform you without delay. We assist you in fulfilling such requests — access, rectification, erasure, restriction and portability — and provide the data in a common format on request. Simple requests are handled at no extra cost; where the effort is substantial we agree remuneration in advance.

10Personal data breaches

If we become aware of a breach of the protection of personal data, we will inform you without delay, at the latest within 24 hours of becoming aware — describing the incident, the categories of data affected, the likely consequences and the measures taken. Notifying the supervisory authority and the data subjects is your task; we supply the information needed for it.

11Evidence and audits

We demonstrate compliance with this agreement by information in text form and by presenting the measures in Annex 1. On request we will complete a questionnaire.

If that is not a sufficient basis for you, you may request an on-site audit — announced with reasonable notice, during business hours, without disrupting operations and without access to other customers’ data. Audits by third parties require their commitment to confidentiality. No ISO 27001 certification and no SOC 2 report exist.

12Deletion and return

After the usage relationship ends we delete the data processed for you within 30 days, unless a statutory retention duty applies. On request we will provide it beforehand in a common format. Backups expire within the retention cycle (at most 14 backups). We confirm deletion in text form on request.

13Liability and final provisions

Art. 82 GDPR applies. Otherwise the liability rules of the terms of use apply. Changes to this agreement require text form. German law applies; the place of jurisdiction is Passau as far as legally permissible. If a provision is invalid, the remainder stays in force.

A1Annex 1: technical and organisational measures

State of the measures described here: 11 October 2026.

Area	Measure
Confidentiality in transit	TLS 1.3 and 1.2 to the relay (older versions are disabled), certificate from a public certification authority. On the direct path and via TURN, picture and input are encrypted between the endpoints (DTLS/SRTP); there the relay at most forwards encrypted packets. If a network blocks these paths, the relay carries the session itself (relay mode): if both sides run program version 20261010.19 or later, the frames are encrypted between the endpoints in that case too (ECDH P-256, AES-256-GCM). From version 20261012.1 the device signs this key exchange with a device-held identity whose private key never leaves the device; the viewer verifies the signature, remembers the fingerprint and warns if it changes — so a relay interposed later is detected, and the relay operator cannot read along even in relay mode. With an older counterpart, and always with the client for Windows XP/7, the frames are protected in relay mode only by TLS on the way to the relay and pass through the relay unencrypted; a program from 20261010.19 onwards shows the state (encrypted and verified, encrypted, or unencrypted) during the session.
Device authentication	Mutual proof by device certificate (mTLS); certificates revocable; can be enforced per tenant.
Passwords	Stored only as a salted hash (PBKDF2); never in clear text — device access passwords included.
Access control	Roles for viewing, controlling and administering; separation by tenant; four-eyes approval for critical devices.
Accountability	Hash-chained audit log, so later changes become detectable; session and script logs.
Consent by default	Preview, automatic recording and pre-login access are off by default and are enabled per device or tenant. A recording that a technician starts during the session is shown on the controlled device. The microphone at a supported device opens only after a consent prompt on that device, per session — no setting can allow it in advance; sound is never recorded.
Availability	Nightly database backup on the server retaining the last 14; service restart after a crash. An additional backup outside this server (for example by e-mail) is currently not set up; if it is set up, then only encrypted.
Separation	Tenant separation in the database; separate accounts for administration and use.
Storage limitation	Session data and device logs are deleted automatically after 30 days; server logs are overwritten after 14 days. The hash-chained audit log is not trimmed automatically; it is kept for the duration of the usage relationship (afterwards section 12).
Organisation	Server access via SSH with a key pair; access to customer data only where required for operation or fault finding, and only by the processor himself (Martin Stemplinger).
Data minimisation	Session content is not stored (recordings excepted); script parameters of the type “secret” are stored masked, all others appear in clear text in the history of the script run — passwords and other secrets therefore belong only in parameters of the type “secret”.
Sign-in	Second factor (TOTP, each code valid only once) for console accounts on a voluntary basis and for members of a tenant, where it can be made mandatory per tenant — except the relay operator’s emergency sign-in. Sign-in throttling per network address and per account (20 failed attempts in 5 minutes). Console sessions end after 8 hours. Programmatic access (API tokens) with a mandatory expiry of at most 365 days, revocable at once, stored only as a hash (SHA-256). Sign-in via OIDC or LDAPS and account provisioning via SCIM 2.0 are available.
Network and device limits	The console and control of a tenant’s devices can be limited to trusted networks (address ranges); “control only from the own tenant” can be switched on. On the device, its administrator can block functions (remote console, shell, scripts, run as another user) with a local lock — the relay cannot lift that lock.
Keys	Secrets on the relay (such as credentials for sending e-mail and for the payment service) are stored encrypted; the key ring for them is wrapped with a key of its own (AES-256-GCM). A backup of these keys is only ever created encrypted with a passphrase.

A2Annex 2: sub-processors

Company	Service	Location
IONOS SE, Elgendorfer Straße 57, 56410 Montabaur, Germany	Server (virtual server running relay and database)	Germany
IONOS SE, Elgendorfer Straße 57, 56410 Montabaur, Germany	E-mail delivery (notifications, replies to enquiries)	Germany

We currently use no further sub-processors. In particular no analytics, advertising or content delivery services are used.

This English text is provided for convenience. In case of doubt, the German version prevails.