Roster data, database and authentication in Frankfurt, storage in the EU
No patient data: Rondus holds the roster, not the work
Separation per organisation at database level, access per role, data processing agreement available
Roster data, database and authentication in Frankfurt, storage in the EU
No patient data: Rondus holds the roster, not the work
Separation per organisation at database level, access per role, data processing agreement available
Hosting
The database and authentication run at Supabase in Frankfurt, inside the EU. The application is delivered through Vercel's network, and the session check runs in the Vercel region nearest the user, also outside the EU. The roster data is stored in Frankfurt.
Encryption
Traffic between browser and application runs over TLS. Data is stored encrypted at Supabase.
Access
Every organisation sees only its own data, enforced at database level. Within that, the role decides what someone may do, and accounts are created only by invitation.
Backups and retention
Backups follow Supabase's retention periods. At the end of the agreement Rondus returns the data in a common format or deletes it, as you choose.
GDPR and data breaches
Rondus processes roster data, no patient data and no reasons for sick leave. In case of a breach we inform you without undue delay, with what you need for your own notification obligation.
Sub-processors
Supabase (database, Frankfurt) and Vercel (delivery) for everything, Resend for email; GitHub, Anthropic and the push services only for demo organisations and the Rondus team itself, never with patient data. The full list is below, with purpose, region and limit for each party.
There is a security dossier
For a hospital's information security officer and data protection officer there is a dossier of thirteen pages with thirteen chapters. It is not on this site as a download; you ask for it and we send it to you. You do not have to ask for what is already on this page.
What is in it:
- What this document covers
- Where the data sits
- Which personal data Rondus processes
- How customers are separated from one another
- Access and accountability
- Signing in, sessions and people leaving
- Availability, backup and recovery
- Continuity of the supplier
- How software reaches production here
- Standards and certification
- What we consider weak ourselves
- What we are doing about it
- Contact
The full text
Where the data sits
The database and authentication run on Supabase in the eu-central-1 region (Frankfurt), inside the European Union. For your organisation's roster data, transfer outside the EU is not part of the design.
Three sub-processors of the application are in the United States: GitHub, Anthropic and Resend. GitHub and Anthropic receive no data from a customer organisation. GitHub only receives reports from demo organisations and cards from the Rondus team, Anthropic only internal input from the team itself. Resend sends the invitations and password emails from Ireland, but keeps the logs and the data of sent emails in the United States, under the EU-U.S. Data Privacy Framework. For the push services of Apple, Google and Mozilla the region has not been measured; they only deliver notifications to the Rondus team, and cannot read their content. The limit for each party is listed under sub-processors.
Two caveats, which we raise ourselves. The application itself, meaning the styling, the images and the JavaScript, is delivered over Vercel's global network. And on every request Vercel's session check (the proxy) reads the session and the profile of the signed-in user, in the region nearest that user; that can be outside the EU, and Vercel offers no setting to restrict it. The roster data itself is stored in Frankfurt.
Which data, and which explicitly not
Rondus processes roster data about staff: name, email address, functiegroep, fte, role in the application, shifts, roster requests and recorded deviations.
Rondus processes no patient data. The application holds the roster of the rostering group, the group of specialists who share one rota, not the work itself. Reasons for sickness do not belong in it either: availability is available or not available.
The built-in help function uses no language model
The Rondus Gids answers questions from explanations written in advance, inside the user's own browser. No roster data, no name and no question reaches a language model or any other external service. That is enforced technically, not merely agreed.
We keep statistics on its use: the question asked (200 characters at most), which explanation was shown, whether an answer or a refusal followed, and a random session number. Account, name and organisation are not in it. The question is free text the user types, so we do not control what ends up in it, and those rows are readable by the administrators of Rondus. We clear them out periodically after twelve months. The Gids adds no sub-processor.
Access and separation
Each organisation's data is separated at database level (row level security): an organisation sees only its own data.
Within that, the role decides what someone may do: administrator, planner, trainer, staff member and a viewer role for the secretariat. Accounts are created only by invitation; there is no self sign-up. Rondus invites the first administrator of a new organisation; after that the administrators and planners of your own organisation invite, and a planner cannot create an administrator or a planner. Authentication runs through Supabase Auth.
When someone leaves, the administrator marks them inactive. Anyone without an active staff row lands on a screen saying their access has been withdrawn, at their next request. An access token already issued stays valid for an hour and a running session cannot be revoked retroactively, so the window is one hour at most.
Retention and deletion
Account data stays for as long as the customer relationship lasts. We delete data at the request of the controller, meaning your institution or rostering group. Backups follow Supabase's retention periods.
Two categories have no automatic retention period: the usage data that shows us which screens get used, and the audit log that holds the old and the new value of every roster change. Both grow with use, and we clear them out on request or periodically. We would rather say that than name a period nothing enforces.
At the end of the agreement we return the data in a common format or delete it, whichever you choose.
Data breaches
In the event of a personal data breach we inform the controller without undue delay, with the information you need for your own reporting duty towards the Dutch DPA and the people involved.
What we do not have
Rondus holds no ISO 27001 and no NEN 7510 certification. You would rather read that here than have to ask in the conversation that follows. What we can do: set out the measures above on paper, and cooperate with your own assessment.
Sub-processors
These are all the parties that process data in delivering Rondus: first those of the application, then those of this website only. We announce an intended change in advance, so you can object.
| Party | Purpose | Region | Limit |
|---|---|---|---|
| Supabase | Database, authentication and file storage of the application | eu-central-1, Frankfurt (EU) | Stores everything Rondus keeps: staff, rosters, requests and availability (without a reason). File storage holds only a screenshot attached to a report (2 MB at most) and attachments to internal input from the Rondus team. Such an attachment often shows a roster with initials; only the Rondus team can read it, and it is deleted after 90 days |
| Resend, mail service (SMTP) of Supabase Auth | Sending invitations, password resets and email address changes | Sent from Ireland (eu-west-1); logs and data of sent emails in the United States (EU-U.S. Data Privacy Framework) | Email address, name, organisation name and a one-time link only. No roster data. Sent from noreply@rondus.app with TLS enforced; opens and clicks are not tracked |
| Vercel | Hosting and delivery of the application and this website | Server functions in Frankfurt (EU); the session check (proxy) in 19 regions worldwide, also outside the EU; static files worldwide through the CDN | All traffic passes through it, so also what the application shows; beyond that the server logs. On every request the session check reads the session and the profile of the signed-in user, in the region nearest that user; those regions include some outside the EU, such as Washington and London. Vercel offers no setting to restrict this. Where the network terminates the encrypted connection has not been measured |
| GitHub | A report from "Vraag of meld" (ask or report) becomes a card on our board, and so does approved input from the team | United States | Only when "Vraag of meld" is switched on, and then only from demo organisations, by the Rondus team or a tester. It carries the report text, the kind of report, organisation name, role, page, rostering group id, period, view, version, screen size and the roster cell pointed at (its text and a staff id); not the screenshot. For approved input it carries the card in English, with labels, milestone and a link back to Rondus; not the original text, not the attachments and not their names. When the team changes the severity or withdraws an input, Rondus updates the card: a different label, or the reason without a name as a comment, after which the card is closed. Rondus also reads the board, the state of its own cards and each day what was finished; nothing of ours goes with that. No data from a customer organisation goes there |
| Anthropic | Claude turns internal input from the Rondus team into a draft card and translates it into English | United States | Internal input from the team itself only, never patient or illness data. Customers and staff do not use this function, and nothing from a customer organisation's roster goes with it. Attachments never go with it, not even their names, only how many there are. What does go: a description of Rondus built from its own code, and the numbers and titles of open cards on our board, to find duplicates |
| Push services of Apple, Google and Mozilla | Deliver a push notification to the phone or laptop of someone in the Rondus team: new input, an approval or a report from a customer | Not measured; the browser chooses the service, not Rondus | Only for someone in the Rondus team who switches it on. The service sees only the device address it issued itself and the time. The content (a title, a short line and the page) is end-to-end encrypted with the device's keys and unreadable to the service; for a report from a customer it holds the first line and the organisation name. Rondus has no agreement of its own with these services: they act for the maker of the browser |
| Resend | Sending the demo request to Rondus and the confirmation to the requester | Sent from Ireland (eu-west-1); logs and data of sent emails in the United States (EU-U.S. Data Privacy Framework) | For this website only the data from the demo form, no roster data. The same service sends the application's emails (see the mail service above) |
| Hostinger | Mailbox hallo@rondus.app, receives demo requests and email to Rondus | EU (Frankfurt) | This website and email to us only. No roster data |
| Google Analytics | Statistics for this website | EU and US (Data Privacy Framework) | This website only, and only after you click Accept in the cookie notice. No roster data |
Not in the table, and why. A staff member can have their own roster fetched by Google Calendar, Apple Calendar or Outlook; the staff member chooses that service, not Rondus, and only their own published roster with their meetings goes there. A monitoring service hears only when the weekly encrypted backup has succeeded, so that an alarm goes off when it does not; it receives no data, and which service it is has not been established yet. The source code of Rondus is hosted at GitHub; it contains no customer data.
Data processing agreement
A read-only version is on this site; you can print it or save it as a PDF. A signable copy is available on request: write to us and we will send it.
Read the data processing agreementWho the supplier is
Rondus B.V. in oprichting (in formation), established in the Netherlands. Rondus is supplied to businesses only, to institutions and rostering groups.
Contact
Questions about security, privacy or the data processing agreement reach the people who make Rondus, and you get a reply within two working days: security@rondus.app