Technische und Organisatorische Maßnahmen (TOMs)

Version: 1.0 Stand: April 2026 Gilt für: HireSift SaaS-Plattform, betrieben durch S&C Holding GmbH, Wien (FN 366123t) Rechtsgrundlage: Art. 32 DSGVO

Dieses Dokument beschreibt die technischen und organisatorischen Maßnahmen, die HireSift zum Schutz personenbezogener Daten gemäß Art. 32 DSGVO umsetzt. Es ist Anlage 1 zu jedem Auftragsverarbeitungsvertrag, den HireSift mit einem Kunden schließt.

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

1.1 Zutrittskontrolle (physischer Zugang)

HireSift betreibt keine eigenen Rechenzentren. Die gesamte Produktionsinfrastruktur läuft bei folgenden Cloud-Anbietern mit zertifizierten Rechenzentren innerhalb der EU:

• Vercel Inc. — Serverless Hosting, Region fra1 (Frankfurt am Main, Deutschland). Unterliegt AWS-Zertifizierungen (ISO 27001, SOC 1/2, C5).
• Supabase / AWS — Datenbank und Datei-Storage, Region eu-central-1 (Frankfurt am Main). AWS ISO 27001, SOC 1/2/3, C5.
• Google Cloud Platform — Vertex AI, Region europe-west4 (Saint-Ghislain, Belgien). ISO 27001, SOC 1/2/3, C5.

Zutrittskontrolle zu diesen Rechenzentren ist vollständig durch die jeweiligen Anbieter-Sicherheitsprogramme abgedeckt (24/7-Überwachung, Zutrittskarten, biometrische Zugangskontrolle, Besucherprotokolle). HireSift hat keinen physischen Zugang zu den Servern.

1.2 Zugangskontrolle (Systemzugang)

• Authentifizierung für Kunden: via Clerk Inc. (DPF-zertifiziert). Starke Passwortanforderungen, optional 2FA/TOTP. Sessions sind JWT-basiert mit kurzer Lebensdauer.
• Authentifizierung für Admin-Zugänge (HireSift-Mitarbeiter): separater cookie-basierter Login mit Supabase Auth, eigene hiresift_admins-Tabelle, manuelle Freischaltung.
• Service-Credentials (Supabase Service Role, GCP Service Account, Stripe Secret Key, etc.): ausschließlich in Vercel Environment Variables gespeichert, verschlüsselt at-rest, nicht in Git, nicht im Client-Bundle.
• Produktions-Git-Zugriff: GitHub Organization mit 2FA-Pflicht für alle Mitglieder.

1.3 Zugriffskontrolle (Daten-Zugriff innerhalb des Systems)

• Multi-Tenant-Isolation: Jeder Datensatz (hiresift_candidates, hiresift_jobs, hiresift_criteria, etc.) trägt eine org_id als Mandanten-Diskriminator. Jede Datenbank-Abfrage filtert zwingend auf die org_id des angemeldeten Benutzers. Kein Cross-Tenant-Read über die Anwendungsschicht möglich.
• Prinzip der minimalen Rechte: Anwendungscode verwendet den Supabase Service Role Key ausschließlich serverseitig in API-Routen. Der Browser erhält nur den Anon Key, der ohne authentifizierten Kontext keine Daten lesen oder schreiben kann.
• Administrative Zugänge: nur zwei HireSift-interne Admin-Accounts haben Vollzugriff auf alle Organisationen. Jede Admin-Aktion wird in den Server-Logs von Vercel mit Zeitstempel und User-ID protokolliert.
• Roadmap: Einführung von Postgres Row Level Security (RLS) als Defense-in-Depth auf DB-Ebene ist geplant; aktuell erfolgt Isolation anwendungsseitig.

1.4 Trennungskontrolle

• Kundendaten sind logisch über org_id getrennt, aber physisch in derselben Supabase-Datenbank. Diese Multi-Tenant-Architektur ist Branchenstandard für SaaS und wird durch die in 1.3 beschriebene Org-Scoping-Logik durchgesetzt.
• Produktions-, Staging- und Entwicklungsumgebungen sind vollständig getrennte Supabase-Projekte und Vercel-Deployments.

1.5 Pseudonymisierung

• Bewerberdaten werden für die Anzeige im Recruiter-Dashboard nicht pseudonymisiert, weil Recruiter sie mit Klarnamen benötigen.
• Bei der Übermittlung an die KI-Analyse (Vertex AI) werden alle CV-Inhalte als Teil des Prompts übertragen. Google Cloud speichert diese Daten nicht und verwendet sie nicht zum Modelltraining (vertraglich zugesichert in den Vertex AI Service Terms).
• Für interne Produkt-Analytics (Mixpanel EU) werden ausschließlich Recruiter-IDs und Event-Metadaten (Klicks, Pageviews) verarbeitet, keine Bewerberdaten.

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

2.1 Weitergabekontrolle / Transportverschlüsselung

• Transportweg: Alle Verbindungen (Browser → Vercel, Vercel → Supabase, Vercel → Vertex AI, Vercel → Clerk, Vercel → Stripe) erfolgen ausschließlich via TLS 1.2 oder höher (HTTPS). HTTP-Zugriffe werden per 301/HSTS auf HTTPS umgeleitet. HSTS-Header mit max-age=63072000 aktiv.
• Externe Übertragungen (Kundenupload, E-Mail-Versand) erfolgen ebenfalls ausschließlich über TLS-gesicherte Kanäle.

2.2 Eingabekontrolle

• Jede schreibende API-Aktion (Create, Update, Delete auf hiresift_*-Tabellen) wird serverseitig validiert: der Handler prüft, ob der angemeldete Benutzer Mitglied der betroffenen Organisation ist.
• Vercel-Logs protokollieren alle API-Requests mit Zeitstempel, User-ID (via Clerk), Pfad und HTTP-Status-Code. Diese Logs werden für 30 Tage aufbewahrt.

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

3.1 Verfügbarkeitskontrolle

• Vercel Serverless Functions skalieren automatisch horizontal. SLA: 99.99 % monatliche Verfügbarkeit gemäß Vercel Enterprise-Bedingungen.
• Supabase (verwaltetes AWS RDS Postgres) bietet 99.9 % SLA mit automatischer Hochverfügbarkeit über Multi-AZ in eu-central-1.
• Google Cloud Vertex AI bietet 99.9 % SLA in europe-west4.

3.2 Wiederherstellbarkeit (Backup & Restore)

• Supabase Automated Backups: tägliche vollständige Backups, die 7 Tage aufbewahrt werden (Standardplan). Point-in-Time-Recovery (PITR) für bis zu 7 Tage verfügbar.
• Manuelle Backups: Ein Cron-Job unter /api/cron/backup erstellt zusätzlich tägliche Exports kritischer Tabellen.
• Restore-Prozess: Wiederherstellung einzelner Tabellen via Supabase Dashboard oder pg_restore. Vollständiger Restore in unter 4 Stunden möglich.
• Testintervall: Restore-Fähigkeit wird halbjährlich durch einen geprüften Restore in eine Staging-Umgebung verifiziert.

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

4.1 Änderungsmanagement

• Jede Code-Änderung wird über Git versioniert, über GitHub Pull-Requests reviewt (sofern Team vorhanden — aktuell Solo-Founder, daher Selbst-Review
  • dokumentierte Commit-Historie) und automatisch über Vercel deployed.
• Datenbank-Migrationen liegen in supabase/migrations/ als SQL-Dateien, werden versioniert und nachverfolgbar angewendet.
• Dependency-Updates werden monatlich geprüft; sicherheitsrelevante Updates (npm audit high/critical) innerhalb von 7 Tagen eingespielt.

4.2 Incident-Response

• Siehe separater Incident Response Plan (in Vorbereitung, docs/legal/incident-response-plan.md).
• Meldung an österreichische Datenschutzbehörde (DSB) innerhalb von 72 Stunden bei meldepflichtigen Vorfällen gemäß Art. 33 DSGVO.
• Benachrichtigung betroffener Personen bei hohem Risiko gemäß Art. 34 DSGVO.

4.3 Mitarbeiterverpflichtung

• Alle Personen mit Zugang zu Produktionsdaten werden nach Art. 28 Abs. 3 lit. b DSGVO schriftlich auf die Vertraulichkeit verpflichtet.
• Aktuell ist S&C Holding GmbH ein Ein-Personen-Unternehmen; mit Einstellung weiterer Mitarbeiter wird eine interne Datenschutz-Richtlinie implementiert.

5. Löschung und Rückgabe von Daten

• Löschfristen und -prozesse sind im separaten Löschkonzept dokumentiert (in Vorbereitung, docs/legal/loeschkonzept.md).
• Nach Vertragsbeendigung: produktive Löschung innerhalb von 30 Tagen, Backup-Löschung innerhalb weiterer 60 Tage (90 Tage gesamt).
• Soforteige Löschung auf schriftliche Anfrage möglich.
• Rückgabe der Daten in maschinenlesbarem Format (JSON-Export) auf Anfrage.

6. Unterauftragsverarbeiter

Eine vollständige Liste der eingesetzten Unterauftragsverarbeiter mit Verarbeitungsort, Zweck und rechtlicher Grundlage des Transfers findet sich in der separaten Anlage docs/legal/subprocessor-list.md.

Die Einbindung neuer Unterauftragsverarbeiter wird dem Kunden rechtzeitig vor Wirksamkeit mitgeteilt. Der Kunde hat das Recht, der Einbindung zu widersprechen.

Dokumentenhistorie: