Technische und organisatorische Maßnahmen

Anlage 1 zum Auftragsverarbeitungsvertrag · gemäß Art. 32 DSGVO
Stand: 2026-09-27 · Version 1.1

Auftragsverarbeiter:: DisplayMetric — Inhaber Kagan Yavuz
Anschrift:: Brühlstr. 40, 72555 Metzingen, Deutschland
Datenschutz-Kontakt:: datenschutz@displaymetric.de
Überprüfungsintervall:: alle 12 Monate

Die nachfolgend beschriebenen technischen und organisatorischen Maßnahmen werden vom Auftragsverarbeiter zur Erfüllung der Anforderungen aus Art. 32 DSGVO ergriffen. Sie gewährleisten ein dem Risiko angemessenes Schutzniveau hinsichtlich Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Verarbeitungssysteme.

Hinweis zur Unternehmensgröße: Der Auftragsverarbeiter ist ein Einzelunternehmer ohne Mitarbeiter. Maßnahmen, die typischerweise organisatorische Strukturen mehrerer Personen voraussetzen (z.B. Vier-Augen-Prinzip, Rollentrennung mehrerer Admins), entfallen entsprechend. Diese Konstellation wurde bei der Auswahl der Maßnahmen berücksichtigt — der Schutz wird durch starke technische Maßnahmen (2FA, Verschlüsselung, automatisierte Prozesse) kompensiert.

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

1.1 Zutrittskontrolle (Schutz vor unbefugtem Zutritt zu Verarbeitungsanlagen)

✓Server-Hardware: gehostet im Hochsicherheits-Rechenzentrum der Hetzner Online GmbH in Falkenstein/Sachsen, Deutschland. Zutrittskontrolle dort durch Hetzner gemäß ISO 27001 (Zertifikat liegt vor).
✓Edge-Geräte: physisch beim Verantwortlichen aufgestellt; Schutz vor unbefugtem Zutritt liegt im Verantwortungsbereich des Verantwortlichen.
✓Arbeitsplatz des Auftragsverarbeiters: Privatwohnung mit verschlossener Eingangstür. Arbeitsgerät (Mac-Notebook) wird bei Nichtnutzung mitgeführt oder in der Wohnung verwahrt.

1.2 Zugangskontrolle (Schutz vor unbefugter Nutzung der Systeme)

✓Server-Zugang ausschließlich über SSH mit Public-Key-Authentifizierung. Passwort-Login ist deaktiviert.
✓Privater SSH-Key liegt verschlüsselt auf dem persönlichen Notebook (Mac mit aktiver FileVault-Festplattenverschlüsselung) und auf dem Mobiltelefon (mit Biometrie- und Code-Sperre).
✓Notebook ist mit automatischer Bildschirmsperre nach Inaktivität geschützt.
✓CMS-Login mit E-Mail/Passwort und obligatorischer Zwei-Faktor-Authentifizierung (TOTP) für Administrator-Konten.
✓Passwörter werden ausschließlich gehasht (bcrypt mit Salt) gespeichert. Klartext-Passwörter sind weder in Logs noch in Backups vorhanden.
✓Rate-Limiting auf Login-Versuche (30 Requests/Minute pro IP via nginx).
✓Sitzungs-Tokens (NextAuth) sind HttpOnly, Secure, SameSite=Lax und kryptographisch signiert.
✓Edge-zu-Cloud-Authentifizierung über geräte-individuelle API-Schlüssel (Bearer-Token, 32-stellig hexadezimal). Pro Gerät ein Schlüssel mit Bindung an die device_id.

1.3 Zugriffskontrolle (Beschränkung auf befugte Daten)

✓Rollenbasiertes Berechtigungsmodell im CMS: Admin / Editor / Viewer mit unterschiedlichen Schreibrechten.
✓Multi-Tenant-Isolation auf Datenbankebene: Jede Tabelle mit personenbezogenen Daten enthält account_id-Filter. Alle SQL-Queries der Anwendung filtern explizit nach account_id; ein Tenant kann unter keinen Umständen die Daten eines anderen Tenants sehen.
✓PostgreSQL-Datenbank ausschließlich an localhost gebunden (kein direkter Zugriff von außen). Anwendungs-Datenbankuser hat ausschließlich CRUD-Rechte, keine Schema-Änderung.
✓Backup-Storage (Hetzner Storage Box) nur via SSH-Key zugänglich.
✓Audit-Log protokolliert alle Schreibzugriffe auf personenbezogene Daten mit Zeitstempel, User, Aktion und Entity.

1.4 Trennungskontrolle

✓Logische Trennung der Mandanten in einer gemeinsamen Datenbank über account_id. Die Trennung wird in jeder Anwendungs-Query erzwungen und ist Teil der Multi-Tenant-Architektur.
✓Trennung von Produktiv- und Test-Daten: Es existiert keine externe Test-Umgebung mit produktiven Daten. Tests laufen mit synthetischen Daten in lokalen Entwicklungsumgebungen.
✓Trennung von Anwendung und Datenbank: Die FastAPI- und Next.js-Anwendungen laufen mit eigenem Datenbank-User mit minimal erforderlichen Rechten.

1.5 Pseudonymisierung

✓Audience-Daten am Display entstehen ohne Identifizierung: Bilddaten werden im Arbeitsspeicher des Edge-Geräts ausgewertet und sofort verworfen (das Live-Bild der Vorschau nur während einer Freigabe, siehe 2.1; es wird weder gespeichert noch an die Cloud übertragen). Gespeichert und an die Cloud übertragen werden nur Daten ohne Bild und ohne Identität: Zählwerte, Ereignisse je Sichtung (u. a. Eintritt, Austritt, Verweildauer, Aufmerksamkeit, Zone, Bewegung) und Summen.
✓Die Software identifiziert niemanden und erkennt niemanden wieder; gespeichert werden weder biometrische Vorlagen noch Gesichtsmerkmale, Fotos oder Videos. Das Live-Bild der Vorschau (2.1) zeigt Gesichter und ist deshalb nur während einer Freigabe verfügbar.
✓Demografie (bei aktivierter Funktion): Altersgruppe und Geschlecht werden je Sichtung im Arbeitsspeicher des Edge-Geräts aus einem sofort verworfenen Gesichtsausschnitt geschätzt; je Sichtung höchstens fünf Einzelschätzungen zugleich, keine länger als fünf Sekunden.
✓Das Edge-Gerät gibt nur Summen über Abschnitte von mindestens 60 Sekunden und höchstens 15 Minuten aus, und nur ab fünf Sichtungen, von denen zwei desselben Abschnitts gleichzeitig im Bild waren. Die Grenzen sind im Gerät fest verankert; eine Konfiguration außerhalb wird auf die Grenze gesetzt. Bei geschätzter Altersgruppe unter 18 wird das Geschlecht verworfen und nicht gezählt.
✓Abschnitts-Summen werden nach 14 Tagen gelöscht (Gerät, Gateway, Datenbank; auf dem Gerät bei Übertragungsstörung spätestens nach 21 Tagen); das CMS zeigt nur Tages-Summen von Tagen mit mindestens 20 Sichtungen. Debug- und Systemprotokolle enthalten keine Schätzwerte; das Ereignisprotokoll des Geräts enthält nur die Abschnitts-Summen.

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

2.1 Weitergabekontrolle

✓Alle Datenübertragungen über öffentliche Netze sind TLS-verschlüsselt: Edge↔Cloud (TLS 1.3), Browser↔CMS (TLS 1.3), Cloud↔Backup-Storage (SSH/SFTP).
✓SSL-Zertifikate via Let's Encrypt mit automatischer Erneuerung.
✓HTTP-Strict-Transport-Security (HSTS) aktiviert mit max-age 31536000 (1 Jahr).
✓API-Endpoints für Edge-Geräte erfordern gültigen Bearer-Token.
✓Vorschau: Zum Einrichten (Blickrichtung, Ausschlusszonen, Kalibrierung), zur Kontrolle und zur Vorführung kann das Live-Kamerabild angezeigt werden, auf dem Gesichter zu sehen sind – über eine gesicherte Wartungsverbindung zum Gerät, als Service-Ansicht auf dem Bildschirm des Geräts, wenn sie im CMS eingeplant ist, und im lokalen Netz nur, wenn das am Gerät eingerichtet ist, mit einem zeitlich begrenzten Zugangs-Token aus dem Schlüssel des Geräts (Übertragung im lokalen Netz unverschlüsselt). In jedem Fall nur während einer Freigabe: standardmäßig aus, jede Freigabe endet nach höchstens 30 Minuten und kann erneut erteilt werden; nach dem Ende wird auch das letzte Bild verworfen. Vorschaubilder werden nicht gespeichert.

2.2 Eingabekontrolle

✓Vollständiges Audit-Log über alle datenmodifizierenden Aktionen im CMS (audit_log-Tabelle) mit Zeitstempel, User, IP-Adresse (beim Login), Aktion und betroffenen Entitäten.
✓Login-Versuche (erfolgreich und fehlgeschlagen) werden separat in login_attempts-Tabelle protokolliert.
✓Server-Logs (nginx, FastAPI, systemd-journal) erlauben forensische Nachverfolgung.

2.3 Auftragskontrolle (Schutz vor weisungswidriger Verarbeitung)

✓Auto-Update-Pakete für Edge-Geräte sind RSA-4096-signiert. Edge-Geräte verifizieren die Signatur vor Installation gegen einen im Image fest eingebauten Public Key.
✓Code-Änderungen werden ausschließlich vom Auftragsverarbeiter durchgeführt und über Git versioniert. Jede Code-Änderung ist nachvollziehbar.

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

3.1 Verfügbarkeitskontrolle

✓Hosting im Hetzner-Rechenzentrum mit redundanter Stromversorgung, USV, Klimatisierung und Brandschutz nach ISO 27001.
✓Anwendungs-Services (FastAPI, Next.js) laufen unter systemd mit automatischem Neustart bei Crash.
✓Monitoring von Service-Status; bei Ausfall E-Mail-Benachrichtigung an den Auftragsverarbeiter.
✓Firewall (ufw) lässt nur erforderliche Ports zu (22 SSH, 80 HTTP-Redirect, 443 HTTPS).

3.2 Wiederherstellbarkeit (Backup & Disaster Recovery)

✓Tägliche automatische Backups um 03:00 UTC: PostgreSQL-Datenbank (komprimiert), Asset-Storage (rsync), Konfigurationsdateien (tar+gpg).
✓Lokale Aufbewahrung: 7 Tage auf separatem Volume.
✓Off-Site Backup auf Hetzner Storage Box (separates Rechenzentrum, eigene Authentifizierung) mit 30 Tagen Aufbewahrung.
✓Konfigurations-Backups (mit RSA-Schlüsseln und .env-Files) sind AES-256-symmetrisch verschlüsselt. Passphrase wird ausschließlich extern in Passwort-Manager des Auftragsverarbeiters aufbewahrt.
✓Wiederherstellbarkeit wurde am 1. Mai 2026 erfolgreich getestet (DB-Restore, Configs-Decrypt, Off-Site-Download via SSH).
✓Disaster-Recovery-Anleitung dokumentiert und revisionssicher abgelegt.

3.3 Belastbarkeit

✓Skalierbares Hosting (Hetzner Cloud Server, vertikal aufrüstbar).
✓Datenbank-Partitionierung für große Tabellen (sessions, content_exposures, track_summaries) zur Performance-Erhaltung.
✓Rate-Limiting auf API-Endpoints zur Abwehr von Lastspitzen und Missbrauch.

4. Pseudonymisierung und Verschlüsselung (Art. 32 Abs. 1 lit. a DSGVO)

✓Datenübertragung: TLS 1.3 für alle externen Verbindungen.
✓Backup-Verschlüsselung: AES-256 für sensible Backup-Inhalte (Konfigurationen, Schlüssel).
✓Datei-Verschlüsselung am Arbeitsgerät: FileVault (AES-XTS-128) auf dem Mac-Notebook des Auftragsverarbeiters.
✓Passwort-Hashing: bcrypt mit individuellem Salt pro Datensatz.
✓Code-Signing: RSA-4096-Signaturen für Auto-Update-Pakete.
✓Audience-Daten ohne Bild und ohne Identität: In die Cloud gehen nur Zählwerte, Ereignisse je Sichtung und Summen – keine Bilder und keine Gesichtsmerkmale.

5. Auftragskontrolle (Art. 28 DSGVO)

✓Mit jedem Sub-Auftragsverarbeiter besteht ein schriftlicher Vertrag mit DSGVO-konformen Klauseln.
✓Verzeichnis aller Sub-Auftragsverarbeiter im AVV (Anlage zum AVV-Hauptdokument) gepflegt.
✓Bei Drittlandtransfer (Resend Inc., USA) Absicherung über EU-US Data Privacy Framework und ergänzende Standardvertragsklauseln.

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

✓Diese TOM-Liste wird mindestens alle 12 Monate überprüft und bei Bedarf aktualisiert.
✓Bei wesentlichen Änderungen am System (z.B. neue Sub-Auftragsverarbeiter, neue Datentypen) erfolgt eine außerordentliche Überprüfung.
✓Restore-Tests der Backups werden bei jeder Aktualisierung der Backup-Pipeline durchgeführt, mindestens jedoch alle 6 Monate.
✓Sicherheitsupdates des Betriebssystems (Ubuntu 24.04 LTS) werden regelmäßig eingespielt (mindestens monatlich).
✓Software-Dependencies werden auf bekannte Sicherheitslücken überprüft (npm audit, pip-audit).