DisplayMetric
Funktionen Branchen Hardware Über FAQ
Login
Start › Datenschutz› TOM
Rechtsdokument

Technische und organisatorische Maßnahmen.

Anlage 1 zum Auftragsverarbeitungsvertrag · gemäß Art. 32 DSGVO
Stand: 2026-05-02 · Version 1.0
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.

Übersicht

  1. Vertraulichkeit
  2. Integrität
  3. Verfügbarkeit und Belastbarkeit
  4. Pseudonymisierung und Verschlüsselung
  5. Auftragskontrolle
  6. Verfahren zur regelmäßigen Überprüfung

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 sind systembedingt pseudonym/anonym: Bilddaten werden im Arbeitsspeicher des Edge-Geräts ausgewertet und sofort verworfen. Es entstehen keine personenbeziehbaren Rohdaten — nur aggregierte Zahlen ohne Identifikationsmerkmale.
  • ✓Eine Re-Identifizierung von Passanten ist auch unter Aufwand technisch nicht möglich, da keine biometrischen Merkmale, Fotos oder Videos gespeichert werden.

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.

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.
  • ✓Anonyme Audience-Daten: bereits am Edge-Gerät durch Aggregation anonymisiert; eine Pseudonymisierung der Cloud-Daten ist daher technisch nicht erforderlich.

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).
Diese TOMs werden bei jeder substanziellen Änderung am System aktualisiert. Aktuelle Version stets unter /legal/tom/. Bei Fragen: datenschutz@displaymetric.de.

Stand: Mai 2026

← Zurück zur Startseite
DisplayMetric

Digital Signage mit KI-Audience-Analytics. Gebaut in Deutschland für deutsche KMU. DSGVO-konform, On-Device-KI, keine Cloud-Schwarzlöcher.

Gegründet von Kagan Yavuz · Made in Germany

Produkt

  • Funktionen
  • Branchen
  • Hardware
  • Preise
  • FAQ

Unternehmen

  • Über uns
  • Kontakt
  • CMS-Login

Rechtliches

  • Datenschutz
  • AVV
  • TOM
  • Impressum
© 2026 DisplayMetric · Made in Germany 🇩🇪
hello@displaymetric.de datenschutz@displaymetric.de
DisplayMetric
CMS Login
Funktionen Branchen Hardware Über FAQ
Direkt schreiben datenschutz@displaymetric.de