Privacybeleid

Rostr is een online SaaS-platform voor personeelsplanning. Organisaties gebruiken Rostr onder meer om:

• medewerkers te beheren (naam, contactgegevens, functie, team, locatie, rol);
• roosters en diensten te plannen en te publiceren;
• verlof en afwezigheid vast te leggen en te beoordelen;
• gewerkte uren in te dienen, te beoordelen en goed te keuren;
• dienstruilen aan te vragen en goed te keuren;
• meldingen (notificaties) uit te sturen bij relevante gebeurtenissen;
• rapportages op te bouwen uit de bovenstaande gegevens;
• teams en meerdere locaties gescheiden te beheren.

De eigenaar van een bedrijf kan optioneel een abonnement afsluiten via Stripe. Rostr biedt daarnaast Google-inloggen als authenticatie-optie naast inloggen met e-mailadres en wachtwoord.

Deze verklaring beschrijft hoe persoonsgegevens worden verwerkt bij het gebruik van Rostr. Ze geldt voor:

• eigenaren die een bedrijf op Rostr aanmaken en beheren;
• managers en teamleiders die binnen dat bedrijf een deel van het personeel of de planning aansturen;
• werknemers die via Rostr hun rooster inzien, verlof aanvragen, uren indienen of dienstwissels afhandelen;
• personen die per e-mail zijn uitgenodigd voor een bedrijf en het proces van registreren nog niet hebben afgerond.

De verklaring dekt uitdrukkelijk niet: gegevens die je werkgever buiten Rostr om verwerkt, of gegevens die je op andere systemen deelt.

Rostr is een B2B-platform. Voor een groot deel van de personeelsgegevens die in Rostr terechtkomen — bijvoorbeeld wie welke dienst draait, welk verlof is aangevraagd of welke uren zijn ingediend — bepaalt jouw werkgever (of het bedrijf waarvoor je werkt) waarom die gegevens binnen de organisatie worden vastgelegd en gebruikt. Rostr levert de softwaredienst waarmee die verwerking mogelijk wordt gemaakt.

Voor bepaalde eigen activiteiten van Rostr kan de juridische rol anders liggen. Denk daarbij aan:

• accountbeveiliging (onder andere inlogpogingen, sessiebeheer, re-authenticatie);
• support-vragen die je ons rechtstreeks stuurt;
• facturatie richting het bedrijf via onze betaalprovider;
• misbruikpreventie en foutopsporing;
• interne technische administratie van het platform.

De definitieve juridische rolverdeling — waaronder de vraag wie voor welk deel verwerkingsverantwoordelijke of verwerker is — wordt vóór de commerciële lancering formeel vastgelegd, in overleg met de werkgevers die Rostr gebruiken. Deze verklaring is daarom een conceptversie en beweert niet dat Rostr altijd verwerker is of altijd verwerkingsverantwoordelijke.

De volgende categorieën zijn gebaseerd op de datamodellen die vandaag daadwerkelijk in de code aanwezig zijn.

A. Account- en identificatiegegevens — e-mailadres, naam, gebruikers-ID, rol (owner / manager / teamlead / employee), authenticatieprovider (wachtwoord of Google), wachtwoord-hash (uitsluitend als je met wachtwoord bent geregistreerd), refresh-tokens voor sessiebeheer en tijdstip van accountaanmaak.

B. Werk- en organisatiegegevens — bedrijf, locatie-ID, team-ID, functie / job title (optioneel), afdeling (optioneel), rol binnen Rostr, uren-per-week volgens contract (indien ingevuld door de werkgever), en voor managers/teamleiders de scope van locaties en medewerkers die zij mogen aansturen.

C. Contact- en profielgegevens — voor zover door de gebruiker of werkgever ingevuld: telefoonnummer, geboortedatum, profielfoto (avatar), noodcontact, taalvoorkeur en display-thema (light / dark / system).

D. Roostergegevens — per dienst worden datum, begintijd, eindtijd, pauze (indien van toepassing), locatie, team, gekoppelde medewerker (of "open shift" als er nog geen medewerker aan hangt), rol-label, notities en publicatiestatus (draft of published) vastgelegd, plus een aanmaakmoment.

E. Urenregistratie — per ingediende urenregel worden de shift-ID, de daadwerkelijke start- en eindtijd, een optionele notitie, de status (submitted / approved / rejected) en de manager-opmerking bij goed- of afkeuring vastgelegd.

F. Verlof en afwezigheid — per verlofaanvraag worden de start- en einddatum, het type (vakantie, ziek, persoonlijk, onbetaald of overig), een optionele niet-medische administratieve reden (vrije tekst, alleen voor verloftypes anders dan ziek), de status (pending / approved / rejected), de manager-opmerking, de aanvrager en de aanmaaktijd vastgelegd. Voor ziek slaat Rostr geen vrij tekstveld op; alleen dát iemand ziekmeldt en over welke periode. Zie ook sectie 8.

G. Dienstruilen — per ruilverzoek worden de aanvrager, de betrokken dienst, eventueel een specifieke doel-medewerker, een optioneel bericht, de status (pending / accepted / declined / approved / cancelled) en het tijdstip van de laatste beslissing vastgelegd.

H. Meldingen — per notificatie worden de ontvanger, een titel, een optionele body-tekst, het type, een eventuele link naar de app, de gelezen/ongelezen-status en het aanmaakmoment vastgelegd. Als je web-pushmeldingen hebt aangezet, bewaren we ook de push-abonnementsgegevens (endpoint plus versleutelingssleutels van de browser) die nodig zijn om jouw toestel te bereiken.

I. Rapportagegegevens — Rostr slaat rapportages niet apart op. Ze worden op het moment van opvragen samengesteld uit bestaande operationele gegevens (rooster, uren, verlof).

J. Technische en beveiligingsgegevens — beheeracties (bijvoorbeeld het aanmaken of verwijderen van een medewerker, het goedkeuren van uren, het exporteren van gegevens, het aanvragen of annuleren van een bedrijfsverwijdering) worden vastgelegd in een auditlog met tijdstip, uitvoerder, actietype en doel. Voor gevoelige acties zoals exports geldt daarnaast een rate limit met een in-memory teller (drie downloads per uur per gebruiker).

K. Abonnement en betaling — als de owner een abonnement afsluit, bewaart Rostr op de bedrijfsrecord de Stripe klant-ID en de Stripe abonnements-ID. De invoer en verwerking van kaartgegevens gebeurt bij Stripe zelf; Rostr slaat geen volledige kaartnummers, CVC-codes of andere ruwe betaalgegevens op.

Afhankelijk van de functionaliteit komen gegevens uit één of meer van de volgende bronnen:

• Jij als gebruiker — registratie, profiel bewerken, verlof aanvragen, uren indienen, notificatievoorkeuren aanpassen.
• De werkgever of eigenaar — bedrijfsinstellingen, de aangemaakte accounts, de uitnodigingen, de rolverdeling en de privacy-instellingen.
• Managers en teamleiders — roosterinvoer, goedkeuring van uren, beslissingen op verlof- en dienstruilverzoeken.
• Het uitnodigingsproces — als je door een owner of manager per e-mail wordt uitgenodigd, staan je rol, locatie en team meestal al klaar voordat je zelf inlogt.
• Automatisch tijdens gebruik van de app — auditlogregels, gelezen/ongelezen-status van meldingen, sessiegegevens.
• Google — als je met je Google-account inlogt, ontvangen we in ieder geval je e-mailadres, naam en (indien beschikbaar) profielfoto vanuit de Google-sessie.

Rostr gebruikt persoonsgegevens voor de volgende doeleinden:

• het aanmaken en beheren van je gebruikersaccount;
• authenticatie via wachtwoord of Google, plus sessie- en tokenbeheer;
• het bepalen van rollen en toegangsrechten binnen je bedrijf;
• het koppelen van medewerkers aan hun bedrijf, locatie en team;
• roosterplanning en publicatie van diensten;
• verlof- en afwezigheidsbeheer;
• urenadministratie (indiening, controle, goedkeuring);
• dienstruilen tussen medewerkers;
• notificaties in de app en, indien geactiveerd, via web push;
• rapportages en overzichten voor de werkgever;
• abonnements- en factuurverwerking via Stripe (voor de owner);
• support en klantcontact;
• beveiliging, foutopsporing en misbruikpreventie;
• auditbaarheid van beheer- en privacygevoelige acties;
• het exporteren van persoons- of bedrijfsgegevens op verzoek;
• het uitvoeren van account- of bedrijfsverwijderingen.

Rostr verkoopt geen persoonsgegevens en gebruikt ze niet voor advertentie- of marketingprofielen.

Rostr en de organisatie achter Rostr moeten vóór de commerciële lancering per verwerking een juridische grondslag vaststellen. Deze concepttekst gaat daarop vooruit en formuleert daarom richtinggevend in plaats van definitief.

Personeelsgegevens die je werkgever via Rostr verwerkt. Voor deze verwerkingen bepaalt jouw werkgever (of het bedrijf waarvoor je werkt) waarom die gegevens nodig zijn en welke toepasselijke juridische grondslag geldt (bijvoorbeeld arbeidsovereenkomst, personeelsadministratie of wettelijke verplichting). Rostr levert daarvoor de softwaredienst volgens de uiteindelijk vast te leggen juridische rolverdeling.

Verwerkingen waarvoor de organisatie achter Rostr zelf doeleinden bepaalt. Denk aan facturatie richting het bedrijf, accountbeveiliging, support, misbruikpreventie en interne technische administratie van het platform. Voor deze verwerkingen zijn afhankelijk van de context grondslagen als de uitvoering van een overeenkomst, een wettelijke verplichting of een gerechtvaardigd belang mogelijk relevant. De definitieve grondslag per verwerking wordt vóór de commerciële lancering juridisch getoetst.

Google Sign-In. Google Sign-In is optioneel; gegevens worden alleen via deze route ontvangen wanneer je zelf voor Google-inloggen kiest. Welke juridische grondslag hier definitief bij past — bijvoorbeeld uitvoering van een overeenkomst, toestemming of een andere grondslag — wordt vóór de commerciële lancering gevalideerd. Toestemming wordt niet gebruikt als standaardgrondslag voor alle verwerkingen binnen Rostr.

Informatie dat iemand ziek is, verdient extra bescherming. Rostr kent een administratieve afwezigheidscategorie "ziek" (naast vakantie, persoonlijk, onbetaald en overig). Voor een normale ziekmelding heeft Rostr geen diagnose, oorzaak, behandeling, medicatie of symptomen nodig.

Bij het type ziek is het vrije reden-tekstveld in de verlofaanvraag verborgen; in plaats daarvan verschijnt een uitleg dat je hier geen medische details hoort in te vullen. Server-side negeert Rostr bovendien een eventueel meegestuurd vrij tekstveld bij dit type, zodat medische informatie ook via een omweg niet in het systeem terechtkomt.

Rostr is geen medisch dossier en vervangt geen bedrijfsarts of arbodienstverlener. De correcte afhandeling van ziekmeldingen — inclusief eventuele communicatie met een bedrijfsarts, arbodienst of loondoorbetalingsproces — ligt bij de werkgever. Rostr is daar geen partij bij.

De zichtbaarheid van gegevens binnen een bedrijf hangt af van drie dingen: je rol, de bedrijfsinstellingen en de individuele privacy-overrides die de owner voor jou heeft ingesteld.

• Owner — breedste rechten binnen het bedrijf; kan onder meer bedrijfsinstellingen, rechten, abonnement en de account- of bedrijfsverwijdering beheren.
• Manager — alleen volgens de toegewezen scope (locaties, teams, medewerkers) en de rechten die de owner heeft ingesteld. Managers zien buiten hun scope geen operationele gegevens.
• Teamlead — helpt een team beheren binnen de grenzen die owner of manager instelt. Een teamlead ziet niet automatisch alle medewerkers of alle locaties.
• Employee — ziet vooral het eigen rooster, verlof, uren, notificaties en beperkte informatie over collega's afhankelijk van de bedrijfsinstellingen.

De Privacy Matrix legt per veld vast wie het standaard mag zien. Denk aan velden zoals e-mailadres, telefoonnummer, geboortedatum, functie, afdeling of profielfoto. De owner kan daarnaast per medewerker individuele privacy-overridesinstellen: bijvoorbeeld "telefoonnummer standaard alleen voor managers, maar deze specifieke medewerker wil zijn/haar nummer wel voor collega's zichtbaar maken". De zichtbaarheid wordt server-side afgedwongen, niet alleen in de UI.

Op basis van de huidige technische configuratie worden persoonsgegevens onder meer verwerkt via de volgende externe diensten:

• Hosting / infrastructuur — Rostr draait op de door Emergent beheerde container-infrastructuur.
• Database — de operationele gegevens worden opgeslagen in een MongoDB-instantie die binnen dezelfde infrastructuur wordt gedraaid.
• Stripe — voor abonnementen en betalingen door de owner. Kaartgegevens worden bij Stripe ingevoerd en verwerkt; Rostr bewaart alleen de Stripe klant-ID en abonnements-ID op de bedrijfsrecord.
• Emergent-managed Google Sign-In — voor gebruikers die met hun Google-account willen inloggen. Bij een succesvolle Google-login ontvangt Rostr in ieder geval e-mailadres, naam en (indien beschikbaar) profielfoto.
• Emergent-managed e-mailproxy — voor transactionele e-mails, zoals uitnodigingsmails en accountgerelateerde mails. Deze mails worden verzonden via een door Emergent beheerde Resend-integratie.
• Web Push — Rostr heeft een eigen VAPID-sleutelpaar en stuurt push-notificaties rechtstreeks vanaf de eigen backend naar de browser-push-endpoints. Push-abonnementsgegevens worden per gebruiker in Rostr opgeslagen.

Diensten die nog niet live zijn — bijvoorbeeld externe documentopslag — worden hier bewust niet vermeld. Zodra er iets aan deze lijst verandert, wordt deze verklaring bijgewerkt.

De precieze regio waarin Rostr wordt gehost, en de regio's waarin de gebruikte externe diensten hun infrastructuur draaien, worden vóór de commerciële lancering formeel vastgelegd. Rostr streeft ernaar de verwerking zoveel mogelijk binnen de EU/EER te houden.

We doen op dit moment geen absolute uitspraak zoals "alle gegevens blijven binnen Nederland" of "alle gegevens blijven binnen de EU", omdat dat afhankelijk is van infrastructuurkeuzes en contractuele afspraken die nog niet definitief zijn. Zodra hier duidelijkheid over is, wordt dat concreet in deze verklaring beschreven, inclusief eventuele doorgiftewaarborgen.

Onderstaande tabel beschrijft hoe Rostr op dit moment technisch met bewaartermijnen omgaat. Daarna volgt kort het verschil met wettelijke bewaarplichten die op de werkgever kunnen rusten.

De bovenstaande termijnen zijn de standaard-retentie die Rostr technisch afdwingt of ondersteunt. Op de werkgever kunnen daarnaast wettelijke bewaarplichten rusten (bijvoorbeeld voor loon- of urenadministratie). Waar dat het geval is, prevaleren die wettelijke termijnen — de verantwoordelijkheid voor het naleven daarvan ligt bij de werkgever.

Je kunt je eigen account verwijderen vanuit je profiel. De flow is als volgt:

1. Je start het verzoek in je profiel.
2. Je moet je huidige wachtwoord opnieuw invoeren om het verzoek te bevestigen (re-authenticatie). Bij Google-only-accounts gebeurt de check op basis van de bestaande sessie.
3. Je e-mailadres wordt vervangen door een intern systeemadres (deleted-{id}@rostr.local) en je naam wordt vervangen door "Verwijderde medewerker". Dit is pseudonimisering, geen volledige anonimisering: de {id} blijft een interne referentie waaraan historische bedrijfsrecords gekoppeld kunnen zijn.
4. Je persoonlijke velden — telefoon, profielfoto, geboortedatum, noodcontact, persoonlijke notities en notificatievoorkeuren — worden op null gezet.
5. Je wachtwoord-hash wordt volledig uit de record verwijderd.
6. Alle refresh-tokens van je account worden ingetrokken; je wordt effectief uitgelogd op alle apparaten.
7. Je notificaties en eventuele web-push-abonnementen worden verwijderd.
8. Historische bedrijfsrecords — bijvoorbeeld uren die je hebt ingediend of diensten waarop je was gepland — kunnen behouden blijven voor de administratie van je (voormalige) werkgever. Ze blijven gekoppeld aan je gepseudonimiseerde profiel en worden niet aan een andere medewerker gekoppeld.
9. De verwijderactie wordt vastgelegd in het auditlog.

Uitzondering: als je als enige actieve owner in een bedrijf staat, kun je je eigen account niet zomaar verwijderen. In dat geval moet eerst het eigenaarschap worden overgedragen (nog toe te voegen functionaliteit) of het bedrijf worden verwijderd, zodat er nooit een bedrijf zonder owner overblijft.

Alleen de owner van een bedrijf kan het bedrijf verwijderen. De flow is:

1. De owner start de verwijdering vanuit de instellingen.
2. De owner moet ter bevestiging de exacte bedrijfsnaam intypen en, indien er een wachtwoord is, opnieuw het wachtwoord invoeren.
3. Het bedrijf krijgt de status deletion_state = pending met een geplande einddatum 30 dagen in de toekomst.
4. Vanaf dat moment blokkeert Rostr alle normale tenanttoegang met een HTTP 423-response en de code tenant_inactive. Alleen accountflows, exports en het annuleren of aanvragen van de verwijdering blijven bereikbaar, zodat gebruikers hun gegevens nog kunnen exporteren of het proces kunnen terugdraaien.
5. Binnen de 30 dagen kan de owner het verzoek annuleren; het bedrijf keert dan terug naar de normale actieve status.
6. Na afloop van de 30 dagen komt het bedrijf in aanmerking voor definitieve verwijdering volgens de verwijderprocedure van Rostr. Deze definitieve verwijdering wordt niet automatisch geactiveerd op de exacte einddatum, maar loopt via een beheersproces.

A. Mijn gegevens downloaden — GET /api/gdpr/export/me.zip. Vanuit je profiel haal je een ZIP-bestand op met alleen je eigen persoonsgegevens. De ZIP bevat:

• profile.json — persoonlijke velden van je account (naam, e-mailadres, taal, thema, telefoon, geboortedatum, noodcontact, functie, afdeling, locatie/team-ID en notificatievoorkeuren);
• shifts.json — de diensten waarop je was ingepland;
• leave.json — je verlofaanvragen;
• swaps.json — dienstruilverzoeken waar je bij betrokken bent;
• timesheets.json — je urenregistraties;
• notifications.json — meldingen die aan jou zijn gericht;
• _manifest.json — een korte notitie over de export.

De export bevat géén wachtwoord-hashes, refresh-tokens, sessie-secrets of andere secrets, en géén persoonsgegevens van andere medewerkers. Personal exports zijn beperkt tot drie downloads per uur per gebruiker.

B. Bedrijfsgegevens exporteren — GET /api/gdpr/export/company.zip. Alleen owners kunnen deze export uitvoeren. De ZIP bevat:

• company.json — de bedrijfsrecord (zonder secrets);
• locations.json, teams.json — vestigingen en teams;
• users.csv — een beperkte kolomlijst per medewerker (id, naam, e-mailadres, rol, locatie/team-ID en deleted_at indien van toepassing);
• shifts.csv, leave.csv, swaps.csv — de operationele gegevens;
• invitations.csv — verstuurde uitnodigingen;
• audit.csv — de auditlogregels van de laatste 12 maanden;
• _manifest.json.

Ook hier: géén wachtwoord-hashes, refresh-tokens of andere secrets. Bedrijfsexport is eveneens beperkt tot drie downloads per uur per bedrijf.

Op grond van de privacywetgeving heb je in beginsel de volgende rechten. Deze rechten zijn niet absoluut: ze kunnen worden beperkt door wettelijke bewaarplichten van de werkgever, door de rechten en vrijheden van anderen of door aantoonbare gerechtvaardigde belangen.

• Informatie — je hebt recht op duidelijke informatie over hoe Rostr en je werkgever met je gegevens omgaan. Deze verklaring is daar een onderdeel van.
• Inzage — de meeste eigen gegevens zijn direct in de app zichtbaar; met de personal export haal je een gestructureerd overzicht op.
• Correctie — veel eigen velden (naam, telefoon, geboortedatum, voorkeuren) kun je zelf aanpassen in je profiel. Voor gegevens die je werkgever over jou vastlegt (bijvoorbeeld functie of team) kun je bij je werkgever aankloppen.
• Verwijdering — je kunt je account verwijderen (zie sectie 13). Historische bedrijfsrecords kunnen behouden blijven.
• Beperking en bezwaar — waar toepasselijk kun je vragen om de verwerking te beperken of bezwaar maken tegen bepaalde verwerkingen. Deze verzoeken worden per geval beoordeeld.
• Dataportabiliteit — waar toepasselijk kun je een machineleesbare export vragen; voor je eigen gegevens is dat de personal export.
• Klacht bij toezichthouder — je hebt het recht een klacht in te dienen bij de bevoegde privacytoezichthouder. In Nederland is dat de Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl).

Voor personeelsgegevens die je werkgever via Rostr verwerkt, is die werkgever in veel gevallen het eerste aanspreekpunt voor de uitoefening van deze rechten. Rostr ondersteunt jou en je werkgever waar we kunnen (bijvoorbeeld met exports en accountverwijdering), maar treedt niet in de plaats van je werkgever bij vragen die primair over de arbeidsrelatie gaan.

Rostr neemt op dit moment geen besluiten uitsluitend op basis van geautomatiseerde verwerking of profilering die je juridisch of anderszins aanzienlijk treffen. Roosters worden door managers of teamleiders vastgesteld en gepubliceerd; verlofaanvragen en uren worden door mensen beoordeeld; individuele privacy-overrides worden door de owner ingesteld.

Automatische processen die wel bestaan — bijvoorbeeld het tijdgestuurd verwijderen van auditregels na 24 maanden — hebben geen effect op individuele beslissingen over personen.

In je browser gebruikt Rostr:

• HTTP-only cookies voor authenticatie — een access_token- en refresh_token-cookie (beide HttpOnly + Secure) om je ingelogd te houden. Deze cookies zijn niet uitleesbaar vanuit JavaScript.
• Een csrf_token-cookie — bewust wél leesbaar zodat de app een matchende X-CSRF-Token-header kan meesturen bij state-wijzigende verzoeken. Deze token bevat geen persoonsgegevens en geen sessiegeheim.
• localStorage — uitsluitend voor voorkeurgegevens die de app snel nodig heeft, zoals taalinstelling (rooster.lang), thema (rostr.theme), "welkom-onboarding gezien", "wat is nieuw gezien", de dashboard-widgetconfiguratie en de dismiss-status van de install-banner. Je access- en refresh-token worden hier bewust niet in bewaard.
• sessionStorage — voor de tijdelijke intent en payload tijdens het inloggen met Google, en voor "welkom-scherm al getoond in deze sessie".

Er is op dit moment geen tracking-, marketing- of advertentiecookie in gebruik en geen third-party analytics-integratie in de app. Als daar in de toekomst iets aan verandert, wordt deze verklaring bijgewerkt en zullen we — waar wettelijk vereist — toestemming vragen.

Rostr heeft onder meer de volgende maatregelen ingericht:

• Authenticatie via wachtwoord (met bcrypt-hashing) of via Emergent-managed Google Sign-In.
• Rolgebaseerde rechten (Owner, Manager, Teamlead, Employee) die server-side worden afgedwongen op elke relevante API-route.
• Tenant-isolatie: een gebruiker in bedrijf A kan geen gegevens van bedrijf B zien of opvragen.
• De Privacy Matrix en individuele privacy-overrides om zichtbaarheid van velden per rol en per medewerker fijn te sturen.
• Rate limiting op gevoelige acties, bijvoorbeeld maximaal drie personal exports per uur per gebruiker en drie bedrijfsexports per uur per bedrijf.
• Re-authenticatie via wachtwoord bij destructieve acties zoals account- of bedrijfsverwijdering.
• Auditlogging van beheeracties met een technische bewaartermijn van 24 maanden.
• Wachtwoord-hashes, refresh-tokens en andere secrets worden nooit meegeleverd in exports; het serialisatiepad strip deze velden expliciet.

Rostr claimt geen formele beveiligingscertificeringen die niet zijn afgegeven (zoals SOC 2 of ISO 27001) en gebruikt geen termen als "bank-level security" of "100% veilig". Wanneer daar in de toekomst iets in verandert, wordt deze verklaring bijgewerkt.

Als Rostr bij de verwerking van klantgegevens optreedt als verwerker en een beveiligingsincident constateert, informeert Rostr de betreffende klant/verwerkingsverantwoordelijke volgens de toepasselijke afspraken zonder onnodige vertraging. De klant beoordeelt vervolgens eventuele meldplichten richting toezichthouder en betrokkenen; Rostr ondersteunt daar waar we kunnen.

Voor incidenten rond gegevens waarvoor de organisatie achter Rostr zelf verantwoordelijk is (bijvoorbeeld accountbeveiliging of factuurgegevens), beoordeelt Rostr zelf de eventuele meldplicht.

Rostr claimt uitdrukkelijk geen 24/7 security operations center of vaste responstijden. De volledige, formele incident- en datalekprocedure — inclusief interne verantwoordelijkheden, escalatie en communicatie-templates — wordt vóór de commerciële lancering vastgelegd samen met de juridische review.

Vragen over deze privacyverklaring, je gegevens, een export of accountverwijdering kun je sturen naar rosterhelp@gmail.com. Voor algemene informatie over Rostr kun je terecht bij info.roster@gmail.com. Andere adressen — bijvoorbeeld op @rostr.eu of een functionaris voor gegevensbescherming — worden pas gecommuniceerd zodra die daadwerkelijk zijn aangemaakt en bevestigd.

Rostr kan deze privacyverklaring aanpassen wanneer functionaliteit verandert of wanneer wet- en regelgeving daarom vraagt. De datum bovenaan de pagina geeft aan wanneer de tekst voor het laatst is bijgewerkt.