Datenschutzerklärung
Diese Erklärung beschreibt, was die Anwendung tatsächlich tut. Jeder Punkt lässt sich im Code nachlesen. Was noch niemand entschieden hat, steht als offene Stelle und wird nicht behauptet.
Stand: 4. Oktober 202601Verantwortliche Stelle
- Firma
- STAIFIT GmbH
- Anschrift
- Bahnhofstrasse 12, 8001 Zürich
- Land
- Schweiz
- Adresse
- info@staifit.com
Die vollständigen Angaben zur Anbieterin stehen im Impressum. Auch dort sind die noch offenen Punkte gekennzeichnet.
Die für den Datenschutz verantwortliche Person ist zu benennen, samt einer Adresse, die tatsächlich gelesen wird. Ob eine Datenschutzberatung nach Art. 10 nDSG bestellt wird und ob es eine Vertretung in der EU nach Art. 27 DSGVO braucht, ist zu klären und hier einzutragen.
02Grundlagen
Diese Erklärung richtet sich nach dem revidierten Schweizer Datenschutzgesetz (nDSG) und, soweit die Bearbeitung in ihren Anwendungsbereich fällt, nach der europäischen Datenschutz-Grundverordnung (DSGVO).
Personendaten sind alle Angaben, die sich auf eine bestimmte oder bestimmbare Person beziehen. Dazu gehört in dieser Anwendung auch ein Pseudonym wie P-0147, denn die Anbieterin kann es zurückführen.
Die Rechtsgrundlagen je Bearbeitung, also Vertrag, berechtigtes Interesse oder Einwilligung, sind von einer Anwaltskanzlei zuzuordnen. Die Zuordnung hängt am Vertragswerk und nicht am Code, deshalb steht sie hier nicht.
03Die öffentliche Website
Die Website misst die Reichweite mit Google Analytics 4. Wie und wann, steht weiter unten unter Cookies und Reichweitenmessung. Werbenetzwerke, eine Einbindung sozialer Netzwerke und eine Profilbildung gibt es nicht.
Die beiden Schriften Archivo und IBM Plex Mono liegen als eigene Dateien auf dem Server. Es wird keine Schrift von Google Fonts oder einem anderen fremden Dienst geladen, dein Browser baut also keine Verbindung dorthin auf. Bilder gibt es keine, alle Zeichen und Kurven sind SVG oder CSS.
Zwei Formulare nehmen freiwillige Angaben entgegen. Die Warteliste auf der Startseite speichert Name, Firma und E-Mail-Adresse in der Tabelle waitlist_leads. Das Kontaktformular speichert nichts in einer eigenen Tabelle, es erzeugt eine Mail an ein Postfach der Anbieterin.
Beide Formulare sind ratenbegrenzt. Dafür wird die IP-Adresse der Anfrage gezählt, beim Kontaktformular auch die E-Mail-Adresse, zuerst im Arbeitsspeicher des Servers und danach in der Tabelle rate_limits, damit die Grenze für alle Instanzen des Servers gemeinsam gilt. Die Zeilen dort bleiben höchstens zwei Tage, siehe unter Konto, Anmeldung und Sitzung.
Der vorgelagerte Webserver schreibt ein Zugriffsprotokoll mit IP-Adresse, Zeitpunkt, aufgerufenem Pfad und Browserkennung. Welcher Weg der Auslieferung läuft (HOSTING_PATH in der Umgebung, vps oder hpanel) und wie lange diese Protokolle bleiben, ist festzulegen und hier einzutragen.
04Konto, Anmeldung und Sitzung
Ein Konto trägt Name, E-Mail-Adresse, Rolle und, bei einer Teamleitung, das zugeordnete Team. Es gehört immer zu genau einer Firma. Das Passwort wird nie gespeichert, sondern nur sein scrypt-Hash mit zufälligem Salz.
Nach der Anmeldung liegt die Sitzung in der Datenbank. Das Cookie trägt ausschliesslich eine zufällige Kennung, gespeichert wird davon nur der SHA-256. Zur Sitzung gehören Zeitpunkt der Anmeldung, letzte Aktivität, Ablauf sowie IP-Adresse und Browserkennung der Anmeldung. Die beiden letzten dienen dazu, eine fremde Anmeldung zu erkennen.
- Nach zwei Stunden ohne Anfrage endet die Sitzung.
- Nach sieben Tagen endet sie in jedem Fall, auch bei laufender Nutzung.
- Der Zeitpunkt der letzten Aktivität wird höchstens alle fünf Minuten neu geschrieben.
Eine Registrierung wird zehn Minuten lang offen gehalten, bis der sechsstellige Code aus der Mail bestätigt ist. Bis dahin liegen E-Mail-Adresse, Firmenname, Name und Passwort-Hash in der Tabelle registrations. Der Link zum Zurücksetzen des Passworts gilt sechzig Minuten, eine Einladung ins Cockpit vierzehn Tage. Auch diese Token stehen nur als Hash in der Datenbank.
Die Anmeldung führt ein Protokoll in der Tabelle auth_events: Erfolg, Fehlversuch, Sperre, Versand eines Codes, Passwortwechsel, Abmeldung, das Beenden anderer Sitzungen, angenommene Einladung, abgeschlossene Registrierung, Änderungen an Adresse, Authenticator-App und Ersatzcodes, der Rückfall der Authenticator-App auf den Code per Mail, ein verweigerter Aufruf von Cockpit, Dashboard oder Mailkatalog, Einladung, erneute Einladung, Wechsel von Rolle oder Team und Abschaltung eines Kontos durch die Administration, sowie das Schliessen der Firma und das Löschen einer Person, je mit E-Mail-Adresse, Konto, IP-Adresse und Browserkennung. Bei den Handlungen der Administration sind IP-Adresse und Browserkennung die der Administration, im Protokoll deines Kontos erscheinen sie nicht. Es dient dazu, eine fremde Anmeldung zu erkennen, die Anmeldung nach zehn Fehlversuchen in einer Stunde aus demselben Netz oder hundert aus beliebigen Netzen zu sperren, ein Konto nach zehn falschen Codes in einer Stunde, und dir auf Anfrage zu sagen, wer sich wann von wo angemeldet hat. Die jüngsten 50 Einträge zu deinem Konto siehst du auch selbst, unter Konto, Protokoll der Anmeldung. Wurde das Konto nach einer Abschaltung erneut eingeladen, beginnt die Liste dort. Die Einträge bleiben 24 Monate. Jede Änderung an Passwort, Adresse, App oder Ersatzcodes wird dir zudem an die bisherige Adresse gemeldet, ebenso, wenn eine Anmeldung mit Authenticator-App auf den Code per Mail zurückfallen musste, dann höchstens einmal je Kalendertag nach Weltzeit.
Die Grenzen der Anmeldung, des Codes, der Registrierung, des Passworts und seines Zurücksetzens, der Ersatzcodes, der Authenticator-App, der Einladung, des Kaufs, des Adresswechsels und der Bestätigung mit dem Passwort im Cockpit zählen in der Tabelle rate_limits, je E-Mail-Adresse, IP-Adresse oder Konto, in festen Zeitfenstern von höchstens einer Stunde. Dieselbe Tabelle zählt die Grenzen der öffentlichen Wege je IP-Adresse, also Assessment, Bild der Resultatmail, Warteliste, Kontaktformular, Wahl bei Cookies, Prüfung eines Zertifikats und Abmeldung von Erinnerungen, beim Assessment dazu je persönlichem Link, gespeichert nur als Hash, und die Arbeitsschritte im Cockpit je Konto. Dazu hält dieselbe Tabelle je Konto fest, dass die Mail zum Rückfall der Authenticator-App angestossen ist, für einen Kalendertag nach Weltzeit, und dass ein Massenabruf von Einzelresultaten dem Betrieb gemeldet ist, für eine Stunde. Die Meldungen an den Betrieb zählen dort ohne Personendaten. Die Zeilen bleiben höchstens zwei Tage und werden vom nächtlichen Lauf weggeräumt. Sie dienen allein dazu, Massenversuche abzuweisen und dieselbe Meldung nicht zu wiederholen.
05Cookies und Reichweitenmessung
Für den Betrieb nötig sind drei Cookies, keines mit einem Inhalt, der etwas über die Person aussagt. Dazu kommt das Cookie, das deine Wahl bei Cookies festhält, und, nach deiner Zustimmung, die Cookies der Reichweitenmessung.
- Sitzung
- Heisst __Host-session im Betrieb und session in der Entwicklung. Enthält nur eine zufällige Kennung. HttpOnly, Secure, SameSite Lax, Pfad /, Lebensdauer höchstens sieben Tage und zwei Stunden ohne Aufruf. Zweck: Angemeldet bleiben. Empfängerin: Nur die Anbieterin.
- Registrierung
- Heisst __Host-registration im Betrieb und registration in der Entwicklung. Enthält nur die Kennung der offenen Registrierung. HttpOnly, Secure, SameSite Lax, Pfad /, lebt zehn Minuten. Zweck: Die Registrierung offen halten, bis der Code bestätigt ist. Empfängerin: Nur die Anbieterin.
- Bestellung
- Heisst __Host-order im Betrieb und order in der Entwicklung. Enthält die Kennung der offenen Registrierung, das gewählte Paket, die Anzahl Lizenzen und einen eingegebenen Gutscheincode, keinen Betrag. HttpOnly, Secure, SameSite Lax, Pfad /, lebt zehn Minuten. Zweck: Die Bestellung auf der Preisseite offen halten, bis der Code bestätigt ist. Empfängerin: Nur die Anbieterin.
- Wahl bei Cookies
- Heisst staifit-consent, lebt ein Jahr, SameSite Lax, Pfad /. Trägt drei Schalter, die Fassung des Textes, den Zeitpunkt der Wahl und eine zufällige Kennung, sonst nichts. Nicht HttpOnly, weil das Skript im Browser die Wahl lesen muss. Zweck: Die Wahl festhalten und belegen. Empfängerin: Nur die Anbieterin.
- Reichweite
- Heisst _ga und _ga_ mit angehängter Kennung. Lebt bis zu zwei Jahre. Zweck: Wiederkehrende von neuen Besuchen unterscheiden. Empfängerin: Google Ireland Limited. Wird nur gesetzt, wenn du der Statistik zugestimmt hast.
Die ersten drei Cookies sind HttpOnly, JavaScript im Browser kommt also nicht an sie heran. Cookies für Werbung setzt die Website keine. Die Kategorie Marketing steht in den Einstellungen, es ist aber noch kein Werkzeug dafür eingebunden, ein Schalter auf ein bewirkt derzeit nichts.
Jede Wahl schreibt eine Zeile in unseren Nachweis: Die Kennung aus dem Cookie, den Zeitpunkt, die Fassung des Textes, die beiden Schalter und das Land der Anfrage. Keine Adresse, kein Konto, keine IP-Adresse. Die Zeile belegt, dass und wann gewählt wurde, und sie wird nach 24 Monaten gelöscht. Eine Ablehnung bleibt eine Ablehnung, auch wenn sich der Text der Karte ändert. Eine Zustimmung gilt nur für den Text, auf den sie sich bezog.
Die Reichweitenmessung läuft über Google Analytics 4, Kennung G-5FK21SCFZ9. Gemessen werden aufgerufene Seite, Verweisquelle, ungefährer Ort aus der gekürzten IP-Adresse, Gerätetyp und Browser. Die IP-Adresse wird von Google gekürzt und nicht gespeichert. Es gibt keine Zusammenführung mit einem Konto der Anwendung und keine Werbefunktionen, die Google-Signale sind aus.
Google Ireland Limited ist Auftragsbearbeiterin. Daten können dabei in die Vereinigten Staaten übermittelt werden. Grundlage ist der Angemessenheitsbeschluss der Europäischen Kommission für das EU-US Data Privacy Framework sowie, für die Schweiz, das Swiss-US Data Privacy Framework, ergänzt um die Standardvertragsklauseln.
Kommt deine Anfrage aus der EU, dem EWR oder dem Vereinigten Königreich, erscheint beim ersten Aufruf die Karte "Deine Wahl bei Cookies". Bis du gewählt hast, wird kein Skript für Statistik geladen und kein Cookie dafür gesetzt. Anderswo, also auch in der Schweiz, verlangt das Gesetz keine vorherige Zustimmung, dort beginnt die Messung sofort. Du kannst ihr jederzeit widersprechen: Der Eintrag "Cookies" im Seitenfuss öffnet die Einstellungen, ein Widerruf löscht die Cookies von Google.
Woher deine Anfrage kommt, entnehmen wir dem Land, das unser Server aus der IP-Adresse ableitet. Steht es nicht zur Verfügung, wertet dein Browser stattdessen seine eigene Zeitzone aus, etwa Europe/Zurich. Die IP-Adresse wird dafür nirgends gespeichert. Das Land steht allein im Nachweis deiner Wahl, siehe oben, damit belegt ist, nach welchem Recht die Karte erschien. Sagt keine der beiden Quellen etwas, erscheint die Karte.
Der Vertrag zur Auftragsbearbeitung mit Google und der Eintrag im Verzeichnis der Bearbeitungstätigkeiten sind abzuschliessen und hier zu bestätigen, bevor die Messung im Betrieb läuft. Ebenso die Aufbewahrungsfrist im Konto von Google, vorgesehen sind vierzehn Monate.
06Das Assessment
Die Firma legt die teilnehmenden Personen an. Zu einer Person gehören Name, E-Mail-Adresse, Team, Standort, Funktion, Status, der Zeitpunkt der Einladung, der Zeitpunkt des Abschlusses und ein festes Pseudonym, eine laufende Nummer ohne Bezug zum Team.
Der persönliche Link ersetzt die Anmeldung. Sein Token ist 192 Bit Zufall und wird nirgends gespeichert. In der Datenbank steht nur sein SHA-256, gebunden an Person und Erhebung, mit Ablaufdatum. Ein Token lässt sich deshalb weder erraten noch aus der Datenbank zurückrechnen. Ein abgelaufener und ein unbekannter Token bekommen bewusst dieselbe Antwort, damit sich Token nicht aufzählen lassen.
Erfasst werden die Antworten je Frage, das daraus gerechnete Resultat mit den vier Dimensionswerten Grundverständnis, Daten & Recht, Sicherheit und Effizienz sowie die Angaben zur Nutzung der abgefragten Werkzeuge. Der Fortschritt liegt serverseitig am gehashten Token, nicht im Browserspeicher.
Der Startschirm des Assessments nennt vor der ersten Frage, wer verantwortlich ist, wozu erhoben wird, wer was sieht, wie lange die Antworten bleiben und welche Rechte bestehen. Die Zahlen darin kommen aus der Erhebung der Firma.
Wer eingeladen ist und nicht abgeschlossen hat, erhält Erinnerungen im eingestellten Rhythmus. Jede Erinnerung trägt im Fuss und im Kopf der Mail einen Link, mit dem sich weitere Erinnerungen abbestellen lassen. Der Widerspruch wird an der Person vermerkt und gilt für den Scheduler wie für den Knopf im Cockpit. Die Einladung selbst und der persönliche Link bleiben.
07Wer was sieht
Die Rechte und die Firma werden bei jeder Anfrage auf dem Server geprüft, nie im Browser. Die Firma weist ihren Rollen zehn Berechtigungen in drei Gruppen zu. Drei Rollen sind eingebaut, dazu kommen die Teilnehmenden ohne Konto.
- Administration
- Sieht alle Einstellungen, Teilnehmenden und Zuteilungen sowie Einzelresultate inklusive Namen. Jeder Aufruf wird protokolliert.
- Auswertung
- Sieht das Dashboard und kann bis auf Einzelpersonen aufklappen. Jeder Aufruf wird protokolliert.
- Teamleitung
- Sieht das eigene Team bis auf Einzelpersonen und den Stand der Zuteilungen. Ohne zugeordnetes Team sieht sie nichts.
- Teilnehmende
- Sehen das eigene Resultat und die eigenen Module.
Die Listen im Dashboard kommen pseudonymisiert an den Browser. Klarnamen holt erst ein bewusster Schritt, und dieser Schritt schreibt je Person einen Eintrag ins Zugriffsprotokoll. Die Einzelsicht ist beim Aufruf deshalb ausgeschaltet.
Für aggregierte Gruppen gilt eine Datenschutzschwelle, gezählt in abgeschlossenen Durchläufen. Liegt eine gefilterte Gruppe darunter, liefert die Schnittstelle keine Werte, und dasselbe gilt, wenn der Rest der übergeordneten Gruppe darunter läge, damit sich niemand aus der Differenz zweier Gruppen herausrechnen lässt. Das entscheidet der Server, nicht die Oberfläche, eine Umgehung über den Browser gibt es also nicht. Der gedruckte Anhang der Auswertung führt je Erhebung ein anderes Kürzel, damit sich zwei Anhänge nicht Zeile für Zeile verketten lassen.
08Das Zugriffsprotokoll
Jeder Aufruf eines Einzelresultats wird festgehalten, mit Zeitpunkt, aufrufender Person, deren Rolle und der betroffenen Person. Protokolliert werden acht Vorgänge: Einzelresultat geöffnet, Antworten gelesen, Auswertung erzeugt, Modul zugewiesen, Angaben berichtigt, Auskunft erteilt, Daten gelöscht und Zugangslink eingelöst. Den letzten Eintrag schreibt der erste Aufruf jedes persönlichen Links, mit der Rolle Teilnehmende, er steht unter der Person. Das kann auch ein Mailprogramm sein, das Links vorab öffnet. Berichtigung, Auskunft und Löschung stehen je Teilnahme im Protokoll, auch wenn die Administration sie auslöst.
Das Protokoll verweist auf die betroffene Person nur über deren Kennung, ohne Fremdschlüssel. Wird die Person gelöscht, bleibt der Eintrag vollständig stehen. Das Protokoll darf keine Lücke haben, die Person darf trotzdem verschwinden.
Die Einträge des Zugriffsprotokolls bleiben 24 Monate. Das Protokoll kennt weder Änderung noch Löschung einzelner Zeilen, nur diesen Lauf nach der Frist.
09Aufbewahrung und Löschung
Die Firma stellt je Erhebung eine Aufbewahrungsfrist ein, zwölf, 24 oder 36 Monate, Vorgabe 24. Ist sie abgelaufen, gerechnet ab dem Ende der Erhebung, löscht ein nächtlicher Lauf die Einzelantworten, das persönliche Resultat, die erfasste Werkzeugnutzung und die Zugangstoken, und er ersetzt Name und Adresse der Teilnahme durch das Pseudonym. Die aggregierten Dimensionswerte, Frageanteile und Werkzeuganteile bleiben, damit die Verlaufskurve weiterläuft. Eine Frist ohne Löschung gibt es nicht.
Unabhängig davon räumt ein zweiter Lauf jede Nacht auf: Abgelaufene Sitzungen verschwinden sofort, verbrauchte oder abgelaufene Einmal-Token nach sieben Tagen, offene Registrierungen nach einem Tag, versendete Mails im Postausgang nach dreissig Tagen, wobei Inhalt und Betreff schon mit dem Versand gelöscht werden. Einträge der Warteliste, Zertifikate, der Nachweis der Wahl bei Cookies, das Zugriffsprotokoll und das Protokoll der Anmeldung bleiben 24 Monate. Abgeschaltete und nie angenommene Konten werden nach 24 Monaten anonymisiert. Jede Bestellung und jede Einlösung eines Gutscheins trägt IP-Adresse und Browserkennung des Kontos, das sie ausgelöst hat, als Prüfpfad der Buchhaltung. Nach 24 Monaten werden beide gelöscht, die Bestellung selbst bleibt mit Betrag, Konto und Zeitpunkt, wie es das Obligationenrecht für Belege verlangt.
Welche gesetzliche Mindestaufbewahrung für die Belege aus der Buchhaltung gilt, gehört von einer Anwaltskanzlei oder der Treuhand beantwortet und nicht hier geraten. Belege werden bis dahin nicht gelöscht.
10Wo die Daten liegen und wer sie bearbeitet
- Datenbank
- Ein Supabase-Projekt mit Postgres. Der Zugriff läuft ausschliesslich serverseitig über eine geprüfte TLS-Verbindung. Row Level Security ist auf jeder Tabelle eingeschaltet, und es gibt bewusst keine Richtlinie, die öffentlichen Zugriff erlaubt.
- Server
- Server bei Hostinger. Das Repository kennt zwei Wege: Ein VPS mit dem Node-Prozess der Anwendung hinter nginx, oder das Hosting im hPanel hinter LiteSpeed, die Website dort zusätzlich hinter dem CDN von Hostinger. Welcher Weg läuft, steht unten als offene Stelle.
- Mailversand
- SMTP über ein Postfach bei Hostinger. Jede Mail geht zuerst in den Postausgang der Datenbank und wird von dort zugestellt.
- Zahlung
- Stripe Payments Europe, Ltd., Dublin, Irland, für die Kaufstrecke. Stripe erhält Firma, Rechnungsadresse, E-Mail-Adresse der bestellenden Person und Betrag und verarbeitet die Kartendaten auf ihrer eigenen Seite. Stripe kann Daten an Stripe, Inc. in den Vereinigten Staaten übermitteln, gestützt auf das EU-US Data Privacy Framework, das Swiss-US Data Privacy Framework und die Standardvertragsklauseln.
- Datenlecks
- Beim Setzen eines Passworts gehen die ersten fünf Zeichen seines SHA-1 an Have I Been Pwned (Superlative Enterprises Pty Ltd, Australien), um zu prüfen, ob das Passwort aus einem bekannten Datenleck stammt. Das Passwort selbst verlässt den Server nie, und aus fünf Zeichen lässt es sich nicht zurückrechnen.
Weitere Empfänger gibt es nicht. Personendaten werden nicht verkauft und nicht für fremde Werbung verwendet.
Die vollständigen Firmennamen und Anschriften der Dienstleister, die Region des Datenbankprojekts (DATABASE_REGION in der Umgebung), der Weg der Auslieferung (HOSTING_PATH in der Umgebung, vps oder hpanel), der Standort der Server, die Verträge zur Auftragsbearbeitung und die Garantien für allfällige Übermittlungen ins Ausland sind einzutragen. Sie stehen nicht im Repository.
11Zahlung
Kartendaten werden nie entgegengenommen und nie gespeichert. Die Karte wird auf der von Stripe gehosteten Seite eingegeben, die Anwendung sieht sie nicht.
Zurück kommt nur, was der signierte Webhook von Stripe mitschickt. Gespeichert werden davon Kartenmarke, die letzten vier Ziffern, der Betrag und die Kennung der Zahlung. Kein Betrag kommt je aus dem Browser, die Rechnung entsteht auf dem Server.
Zur Bestellung gehören Firma, Anzahl Lizenzen, Paket und die daraus erzeugten Belege mit Rechnungsnummer und Referenz.
Verlängert sich ein Kauf mit Karte automatisch, bewahrt Stripe die Karte für die nächste Abbuchung auf, nicht wir. Bei uns liegen dazu nur die Kennungen bei Stripe für Kundin, Abo und Zahlungsmittel, die Kartenmarke und die letzten vier Ziffern. Wer die Anzahl ändert, kündigt oder die Kündigung zurücknimmt, steht mit der Kennung des Kontos und dem Zeitpunkt in einem Verlauf, zehn Jahre lang wie die Bestellung.
12Sicherheit
- Die Verbindung läuft über TLS, Aufrufe über http werden umgeleitet.
- Die Content Security Policy läuft ohne unsafe-inline und mit einem Nonce je Antwort.
- Die drei Cookies der Anmeldung und der Bestellung sind HttpOnly und im Betrieb Secure.
- Die Anmeldung verlangt Passwort und einen Code an die hinterlegte Adresse, neue Passwörter werden gegen bekannte Datenlecks geprüft.
- Jede Tabelle hat Row Level Security eingeschaltet und keine öffentliche Richtlinie.
- Token stehen ausschliesslich als SHA-256 in der Datenbank, Passwörter als scrypt-Hash mit mindestens zwölf Zeichen Vorgabe.
- Anmeldung, Zurücksetzen, Registrierung und die öffentlichen Formulare sind ratenbegrenzt.
- Ob es ein Konto zu einer Adresse gibt, verrät keine Antwort. Bekannte und unbekannte Adressen bekommen dieselbe Auskunft.
- Jede Abfrage prüft die Firma der Sitzung, und die Datenbank hält mit Verbund-Fremdschlüsseln dagegen.
Für Datensicherheitsverletzungen besteht ein Notfallplan mit Rollen, Erstmassnahmen und dem Meldeweg an die betroffenen Firmen, den EDÖB und die Aufsichtsbehörden nach DSGVO innert 72 Stunden. Sicherheitslücken lassen sich an die Adresse in /.well-known/security.txt melden.
Wie oft die Datenbank gesichert wird, wie lange die Sicherungen bleiben und auf welchen Zeitpunkt sie sich zurücksetzen lässt, hängt am Plan bei Supabase und an der Wiederherstellung auf einen Zeitpunkt (Point in Time Recovery). Beides ist festzulegen und hier einzutragen.
13Deine Rechte
Als betroffene Person stehen dir nach nDSG und, soweit anwendbar, nach DSGVO diese Rechte zu.
- Auskunft darüber, ob und welche Daten über dich bearbeitet werden.
- Berichtigung unrichtiger Daten.
- Löschung, soweit keine gesetzliche Pflicht zur Aufbewahrung entgegensteht.
- Einschränkung der Bearbeitung.
- Herausgabe oder Übertragung der Daten in einem gängigen Format.
- Widerspruch gegen eine Bearbeitung und Widerruf einer erteilten Einwilligung.
- Beschwerde beim Eidgenössischen Datenschutz- und Öffentlichkeitsbeauftragten oder, im Anwendungsbereich der DSGVO, bei einer zuständigen Aufsichtsbehörde.
Ein Wort an info@staifit.com genügt. Damit niemand fremde Daten erhält, fragen wir vor der Auskunft nach, ob du bist, wer du zu sein angibst.
Werden deine Daten von deinem Arbeitgeber in dieser Anwendung geführt, bestimmt er über Zweck und Umfang. Wir leiten dein Anliegen in diesem Fall an ihn weiter und sagen dir Bescheid.
Für Anliegen zum Datenschutz sollte ein eigenes Postfach eingerichtet und hier genannt werden. Bis dahin gilt die allgemeine Adresse.
14Änderungen
Ändert sich die Anwendung, ändert sich diese Erklärung mit. Der Stand steht oben. Es gilt die Fassung, die beim Aufruf auf dieser Seite steht.