Technische und organisatorische Maßnahmen

Anlage 1 zum Auftragsverarbeitungsvertrag · Art. 32 DSGVO · Stand 2026-08-24

Entwurf — noch nicht freigegeben

Fassung 1.1 vom 2026-08-24. Die anwaltliche Fassung enthält Angaben, die nur Scaleyo selbst beantworten kann; sie sind im Text als zu ergänzen markiert und hier vollständig aufgeführt. Solange dieser Hinweis steht, ist der Text nicht veröffentlichungsfähig — freigegeben wird er über FREIGEGEBEN in lib/legal/stand.ts.

  1. Datenschutzerklärung §13: Zuständige Aufsichtsbehörde nach Sitz Hildesheim — Landesbeauftragte für den Datenschutz Niedersachsen? Name und Link ergänzen.
  2. Datenschutzerklärung §2: Firmierung und Anschrift stammen aus dem öffentlichen Impressum. Bestätigen, dass sie noch stimmen, und einen Datenschutzbeauftragten benennen, falls bestellt.
  3. Dienstleisterliste: Der Anwalt führt netcup UND Hetzner. Im Repo ist nur netcup belegt, Hetzner kommt nirgends vor. Welcher Anbieter betreibt die Produktivmaschine tatsächlich — und liegt daneben noch etwas bei einem zweiten?
  4. Dienstleisterliste und TOM 3.1: Die Sicherung läuft belegt nach AWS S3, Region eu-north-1 (Stockholm) — täglich 03:00, zuletzt fünf erfolgreiche Läufe hintereinander. Offen ist nur noch die Vertragsseite: Vertragsgesellschaft (Amazon Web Services EMEA SARL?) und AVV mit AWS.
  5. Datenschutzerklärung §7 und §8: Stripe-Vertragsgesellschaft (Stripe Payments Europe Ltd. in Irland?), Datenregion und Garantien für etwaige Drittlandzugriffe. Erst danach lässt sich §8 abschließend formulieren.
  6. Datenschutzerklärung §5.7: Mistral-Vertragsstand: AVV geschlossen? Verarbeitungsregion, Speicherdauer, Ausschluss der Nutzung zum Modelltraining — die Aussagen im Text hängen daran.
  7. Dienstleisterliste: Greenstein Designagentur betreibt Server, Coolify und den Mailversand (linuxsrv01.grnstn.de) mit Administrationszugriff. AVV zwischen scaleyo HR GmbH und Greenstein vorhanden? Ohne ihn fehlt die Grundlage für den wichtigsten Unterauftragnehmer.
  8. Datenschutzerklärung §9: Onboarding-Pläne leben unbefristet, bis der Eigentümer sie löscht. Ob abgeschlossene Pläne nach N Monaten anonymisiert werden, ist offen — siehe tasks/todo-onboarding.md.
  9. Datenschutzerklärung §3 und §5.9: Im Onboarding-Planer stellt ein Mitglied Beschäftigtendaten seiner eigenen neuen Mitarbeiter ein (Lebenslauftext, Ziele, Bewertung der Einarbeitung). Verantwortlicher dafür ist das Mitglied als Arbeitgeber, Scaleyo verarbeitet. Der bestehende AVV deckt nur das Recruiting-Modul ab — entweder auf den Onboarding-Planer erweitern oder die Rolle bewusst anders festlegen. Der Text sagt bis dahin nur, was tatsächlich passiert.
  10. AVV §13: Der AVV setzt deutsches Recht und Gerichtsstand Hildesheim. Prüfen, dass das zum Hauptvertrag passt — sonst widersprechen sich die Verträge.

1Vertraulichkeit (Art. 32 Abs. 1 lit. b DSGVO)

1.1Zutrittskontrolle

Anwendung, Datenbank und Datei-Uploads laufen in einem Rechenzentrum in Deutschland, die Sicherungen in einem Rechenzentrum in Schweden. Der physische Zutrittsschutz wird durch die jeweiligen Anbieter gewährleistet; Scaleyo betreibt keine eigenen Serverräume. zu ergänzen: Der Anwalt führt netcup UND Hetzner. Im Repo ist nur netcup belegt, Hetzner kommt nirgends vor. Welcher Anbieter betreibt die Produktivmaschine tatsächlich — und liegt daneben noch etwas bei einem zweiten?

1.2Zugangskontrolle

  • Für jedes Nutzerkonto individuelle Zugangsdaten; kein gemeinsam genutzter Zugang.
  • Passwörter werden nicht im Klartext gespeichert, sondern als bcrypt-Hash.
  • Sitzungen laufen über ein HMAC-signiertes Session-Cookie, in der Produktion mit HttpOnly, Secure und SameSite=Lax.
  • Serverseitige Sitzungslaufzeit von 30 Tagen; abgelaufene Sitzungen werden verworfen.
  • Zweitfaktor über zeitbasierte Einmalcodes (TOTP) mit Wiederherstellungscodes, je Konto aktivierbar.
  • fail2ban auf dem Server gegen automatisierte Anmeldeversuche.
Kein Single Sign-on über Drittanbieter
Die Anmeldung läuft ausschließlich über die Plattform selbst — es gibt keinen OAuth-, OIDC- oder SSO-Pfad und damit auch keine Anmeldedaten bei einem Identitätsanbieter. Der Zweitfaktor ist plattformeigen; er hängt nicht an der Konfiguration eines fremden Mandanten.

1.3Zugriffskontrolle

  • Zugriff auf Bewerberprofile, Bewerbungsunterlagen, Vakanzen und Feedback ausschließlich rollen- und berechtigungsbasiert.
  • Ein Kundenunternehmen sieht nur seine eigenen Vakanzen und Bewerberdaten.
  • Ein Kandidat existiert für den Kunden erst mit einer ausdrücklichen Freigabe — ohne sie ist er auch über die direkte Adresse nicht erreichbar.
  • Dateien werden nur über authentifizierte Routen mit Berechtigungsprüfung ausgeliefert; es gibt keinen öffentlichen Direktzugriff auf den Upload-Speicher.
  • Onboarding-Pläne sind ausschließlich für das anlegende Mitglied sichtbar, auch nicht für Administratoren.
  • Berechtigungen werden nach dem Need-to-know-Prinzip vergeben und regelmäßig überprüft.

1.4Trennungskontrolle

Daten verschiedener Kundenunternehmen sind über die Zuordnung von Nutzern, Firmen und Berechtigungen logisch getrennt. Zum Testen und Vorführen dienen dedizierte synthetische Konten unter der Domäne .test (RFC 2606) samt einer synthetischen Testfirma — echte Mitglieder- oder Kundendaten werden dafür nicht verwendet. Ein Administrator, der in ein Testkonto wechselt, wird durchgehend durch ein Banner darauf hingewiesen; der Wechsel und die Rückkehr werden protokolliert.

1.5Pseudonymisierung und Datenminimierung

  • Bewerberzeilen werden nach Ablauf der Aufbewahrungsfrist anonymisiert: Unterlagen, Belege, Bewertungsläufe und Protokoll werden gelöscht, die Zeile bleibt ohne Personenbezug für Kennzahlen stehen.
  • Im Onboarding-Planer wird die Lebenslaufdatei nach der Erzeugung des Plans gelöscht; nur der für die Planung benötigte Text bleibt.
  • Bewerberdaten und Bewerbungsdokumente werden nicht an den KI-Assistenten übermittelt.

2Integrität (Art. 32 Abs. 1 lit. b DSGVO)

2.1Weitergabekontrolle

  • Übermittlungen an Dienstleister erfolgen nur im Rahmen der dokumentierten Dienstleisterkette und der erteilten Weisungen.
  • Der Server erlaubt ausgehende Verbindungen nur an freigegebene Ziele (Egress-Firewall-Allowlist) — eine unbeabsichtigte Übermittlung an einen nicht vorgesehenen Dienst wird auf Netzwerkebene unterbunden.
  • Content-Security-Policy und weitere Sicherheitsheader in der Anwendung; Schriften und Skripte werden lokal ausgeliefert, es gibt keinen Abruf externer Ressourcen.
  • Drittlandübermittlungen oder Zugriffe aus Drittländern werden vor ihrem Einsatz datenschutzrechtlich bewertet.

2.2Eingabekontrolle

  • Datenschutzrelevante Handlungen im Recruiting- und Onboarding-Bereich werden mit handelnder Person, Zeitpunkt und Gegenstand protokolliert.
  • Jeder KI-Lauf wird mit Modellversion, Dauer und Kosten protokolliert — die Nachweispflicht für Hochrisiko-Anwendungen nach der KI-Verordnung.
  • Jeder Versand einer E-Mail wird mit Empfänger, Betreff, Inhalt und Status protokolliert.
  • Bewertungen tragen die Belegstellen, auf die sie sich stützen, und die Messlatte, an der gemessen wurde; Korrekturen bleiben nachvollziehbar.

3Verfügbarkeit und Belastbarkeit (Art. 32 Abs. 1 lit. b DSGVO)

3.1Verfügbarkeitskontrolle

Datenbank und Datei-Uploads liegen auf persistenten Datenträgern, die einen Neustart des Containers überdauern. Täglich um 03:00 wird eine Sicherung von Datenbank und Uploads erstellt und serverseitig verschlüsselt (AES-256) in einen S3-Speicher von Amazon Web Services in der Region eu-north-1 (Stockholm) geschrieben. Sicherungen älter als 35 Tage werden im selben Lauf gelöscht — ohne diese Grenze überdauerten personenbezogene Daten in den Sicherungen jede Löschfrist des Produktivsystems. zu ergänzen: Die Sicherung läuft belegt nach AWS S3, Region eu-north-1 (Stockholm) — täglich 03:00, zuletzt fünf erfolgreiche Läufe hintereinander. Offen ist nur noch die Vertragsseite: Vertragsgesellschaft (Amazon Web Services EMEA SARL?) und AVV mit AWS.

  • Automatische Sicherheitsupdates des Betriebssystems.
  • Egress-Firewall-Allowlist und fail2ban zum Schutz der Betriebsumgebung.
  • Aktivierte Sicherheitsmeldungen für Abhängigkeiten (Dependabot); gemeldete Schwachstellen werden nach Risiko priorisiert behoben.

Wiederherstellungstests werden nach dem Backup- und Notfallkonzept regelmäßig durchgeführt.

3.2Vorfälle und Eskalation

Für Sicherheitsvorfälle, Betriebsstörungen und Datenschutzverletzungen bestehen Melde- und Eskalationswege. Der Auftragsverarbeiter dokumentiert Vorfälle, ergreift Maßnahmen zur Eindämmung und unterstützt den Auftraggeber bei Bewertung und Bearbeitung — siehe AVV §8.

4Verfahren zur regelmäßigen Überprüfung (Art. 32 Abs. 1 lit. d, Art. 25 Abs. 1 DSGVO)

  • Regelmäßige Überprüfung der internen Prozesse, Berechtigungen, Dienstleister, Sicherheitsmaßnahmen und Löschroutinen; festgestellte Schwachstellen werden nach Risiko priorisiert behoben.
  • Löschung als laufender Vorgang, nicht als Handarbeit: tägliche Läufe setzen die Aufbewahrungsfristen für Bewerberdaten, KI-Läufe und das E-Mail-Protokoll durch. Jeder Lauf wird mit Zeitpunkt und Ergebnis protokolliert; ein ausgefallener Lauf wird in der Anwendung als überfällig ausgewiesen, statt unbemerkt zu bleiben.
  • Datenschutz durch Voreinstellung: die Plattform verarbeitet nur die für die jeweilige Funktion erforderlichen Daten; es gibt keine Analyse- oder Marketingwerkzeuge und keine externen Schriftquellen.
  • Keine Auftragsverarbeitung ohne Weisung: eindeutige Vertragsgestaltung, formalisiertes Auftragsmanagement, Auswahl und Vorabprüfung der Dienstleister, Nachkontrollen.
Die Maßnahmen entwickeln sich weiter
Der Auftragnehmer darf alternative, gleichwertige Maßnahmen umsetzen; das Sicherheitsniveau darf dabei nicht unterschritten werden. Wesentliche Änderungen werden dokumentiert und auf dieser Seite nachgeführt (AVV §3 Abs. 3).