Security and privacy

The database and authentication run on Supabase in the eu-central-1 region (Frankfurt), inside the European Union. Transfer outside the EU is not part of the design.

One caveat, which we raise ourselves: the application itself, meaning the styling, the images and the JavaScript, is delivered over Vercel's global network. The roster data stays in Frankfurt.

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 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.

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 from an administrator at your own organisation; 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.

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.

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.

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.