Technische und organisatorische Maßnahmen (TOMs)
LightPalmMedia GmbH — Plattform Sunvault
gemäß Art. 32 DSGVO
|
|
| Dokument |
Anlage 2 zum AVV mit Firmenkunden (01_AVV_Auftraggeber_Sunvault.md) |
| Version |
1.2 |
| Stand |
2026-08-03 |
| Klassifikation |
Vertraulich — intern / für Auftraggeber im Rahmen des AVV |
| Verantwortlich |
LightPalmMedia GmbH, Margot-Kalinke-Straße 3, 80939 München |
| Kontakt Datenschutz |
info@lightpalmmedia.de · Telefon +49 89 4132 44 6 99 |
| Freigabe |
siehe Abschnitt 12 und Anleitung 03a_TOMs_Freigabe_Anleitung.md |
Diese TOMs beschreiben die von LightPalmMedia GmbH („Auftragnehmer“) getroffenen technischen und organisatorischen Maßnahmen zum Schutz personenbezogener Daten, die im Rahmen der SaaS-Plattform Sunvault im Auftrag von Firmenkunden („Auftraggeber“) verarbeitet werden. Sie dienen der Gewährleistung eines dem Risiko angemessenen Schutzniveaus gemäß Art. 32 DSGVO (Vertraulichkeit, Integrität, Verfügbarkeit, Belastbarkeit sowie Verfahren zur regelmäßigen Überprüfung).
Die Maßnahmen unterliegen dem technischen Fortschritt. LightPalmMedia darf adäquate Alternativen umsetzen, sofern das hier dokumentierte Schutzniveau nicht unterschritten wird. Wesentliche Änderungen werden dokumentiert und dem Auftraggeber gemäß AVV mitgeteilt.
Hinweis zur Abgrenzung: Physische Sicherheit der Rechenzentren und der dortigen Basisinfrastruktur liegt bei den Unterauftragsverarbeitern (insbesondere Hetzner Online GmbH, Impossible Cloud GmbH). LightPalmMedia steuert und verantwortet die Anwendungssicherheit, Mandantentrennung, Zugriffssteuerung, Konfiguration, Backups der Applikationsdaten sowie den Umgang mit Unterauftragsverarbeitern. Die TOMs der Unterauftragsverarbeiter gelten ergänzend (Hetzner: archive/Hetzner_TOM.pdf / AVV-Anlage 2; Impossible Cloud: DPA).
0. System- und Verarbeitungsübersicht
| Schicht |
Ist-Stand |
Ort |
| API / Backend |
Hetzner Cloud (Cloud Server) |
Falkenstein, Deutschland |
| Primärdatenbank |
PostgreSQL |
Hetzner Cloud, Falkenstein |
| Objektspeicher |
Impossible Cloud S3-kompatibel (CE) |
EU / Central Europe |
| Authentifizierung Staff |
Lokales Auth (Argon2id, JWT Access, gehashte Refresh-Tokens in Postgres) |
Hetzner / EU |
| Kundenportal / Signatur |
Zeitlich begrenzte Portal-Zugänge, signierte PDFs |
App + Impossible Cloud |
| Mandantenmodell |
Multi-Tenant SaaS (Company-/Tenant-Scope) |
Anwendungslogik |
Verarbeitete Datenkategorien und Betroffenenkreise: siehe AVV Anlage 1. Unterauftragsverarbeiter: siehe 05_Unterauftragsverarbeiter.md (AVV Anlage 3).
1. Vertraulichkeit (Art. 32 Abs. 1 lit. b DSGVO)
1.1 Zutrittskontrolle (physisch)
Regelt, wer physischen Zugang zu Räumen/Systemen erhält, in denen personenbezogene Daten verarbeitet oder gespeichert werden.
| Maßnahme |
Umsetzung |
| Kein eigener RZ-Betrieb durch LightPalmMedia |
✓ — produktiv nur bei geprüften EU-Anbietern |
| Physische RZ-Sicherheit Hetzner |
✓ — elektronische Zutrittskontrolle, Video, Besuchermanagement u. a. gemäß Hetzner-TOMs (archive/Hetzner_TOM.pdf) |
| Physische Sicherheit Object Storage |
✓ — gemäß Impossible-Cloud-DPA / Anbieter-TOMs |
| Büro / Home-Office LightPalmMedia |
Beschränkter Personenkreis; keine produktiven Kundendatenbanken dauerhaft auf Entwickler-Laptops ohne betriebliche Notwendigkeit |
| Secrets / Zugangsdaten |
Nicht in Quellcode-Repositories; keine Weitergabe von persönlichen Zugangsdaten |
1.2 Zugangskontrolle (Systeme / Authentifizierung)
Regelt, wer sich an Systemen anmelden darf.
| Maßnahme |
Umsetzung |
| Staff-Login (Übergang) |
Firebase Authentication; Passwörter nicht im Klartext bei LightPalmMedia gespeichert |
| Staff-Login (Ziel / teilweise vorhanden) |
Lokales Auth: Argon2id-Passwort-Hashes, JWT Access-Tokens (HS256), Refresh-Tokens gehasht (SHA-256) in Postgres; Revoke/Logout |
| Passwortpolitik |
Keine Klartextspeicherung; Mindestanforderungen im Rahmen des jeweiligen Auth-Backends; nach Local-Auth-Cutover Passwortpolitik/Rate-Limits weiter härten |
| MFA Staff |
Geplant nach Auth-Cutover (Evaluation); Hetzner-Kundenkonto: 2FA-Option des Anbieters nutzen |
| Administrative Serverzugänge (SSH) |
Nur autorisierte Personen; schlüsselbasiert; kein Shared-Password-Root-Alltag |
| Cloud-/Provider-Konsolen |
Individuelle Accounts bzw. dokumentierte Zugänge; starke Authentifizierung |
| Secrets (DB, S3, JWT, Fernet) |
Nur serverseitige Umgebungskonfiguration; nicht im Client/Frontend |
| Kundenportal |
Getrennt von Staff-Accounts; projektbezogene, zeitlich begrenzte Zugänge (Token) für Endkunden (Signatur/Dokumente) |
| Protokollierung von Anmeldungen |
Login-/Session-relevante Ereignisse soweit technisch implementiert (u. a. IP/User-Agent bei Refresh-Tokens im Local-Auth) |
1.3 Zugriffskontrolle (Berechtigungen)
Regelt, was ein Nutzer nach erfolgreichem Zugang sehen, ändern oder ausführen darf.
| Maßnahme |
Umsetzung |
| Rollen-/Rechtekonzept |
role_key / Permissions je Firmenmandant in Sunvault |
| Mandantenbezogene Autorisierung |
Jeder Request prüft Company-/Tenant-Zugehörigkeit; kein Cross-Tenant-Zugriff |
| Need-to-know Support |
LightPalmMedia-Mitarbeiter nur soweit zur Leistungserbringung erforderlich; Vertraulichkeitsverpflichtung |
| Kundenportal-Rechte |
Auf Projekt/Dokument/Signaturprozess beschränkt; getrennt von Staff-Rechten |
| Provider-Zugriffe |
S3-Keys, DB-Credentials und Admin-Zugänge nur für Betriebsaufgaben; minimale Rechte |
| Ausscheiden / Rollenwechsel |
Zugänge unverzüglich entziehen bzw. anpassen |
1.4 Datenträgerkontrolle
| Maßnahme |
Umsetzung |
| Keine unkontrollierte Weitergabe von Datenträgern mit Kundendaten |
✓ |
| Produktive Datenhaltung |
Server/Volumes bei Hetzner; Objekte bei Impossible Cloud — keine produktiven Kundendatenbanken auf persönlichen USB-Medien |
| Entsorgung / Löschung |
Löschung/Sperrung gemäß AVV § 8 und Weisung; Datenträgervernichtung ggf. über Anbieterprozesse |
| Entwicklergeräte |
Disk-Verschlüsselung des Betriebssystems empfohlen; Screen-Lock; keine unverschlüsselten DB-Dumps in ungesicherten Cloud-Syncs |
1.5 Trennungskontrolle
| Maßnahme |
Umsetzung |
| Logische Mandantentrennung |
Company-Scope in DB und Anwendungslogik |
| Object-Storage-Pfade |
Objektschlüssel / Prefixes je Company; geplante Trennung Media- vs. Legal-Docs-Bucket |
| Umgebungen |
Getrennte Credentials und Buckets für Development/Staging vs. Production (mindestens anstreben / wo vorhanden einhalten) |
| Zweckbindung |
Verarbeitung nur im Rahmen des AVV/Hauptvertrags; keine Nutzung von Kundendaten zu eigenen Marketingzwecken von LightPalmMedia |
1.6 Pseudonymisierung und Verschlüsselung
| Maßnahme |
Umsetzung |
| Daten in Transit |
TLS/HTTPS zwischen Clients und Backend |
| Daten at rest (Infrastruktur) |
Verschlüsselung gemäß Anbieter (Hetzner Volumes / Impossible Cloud SSE, soweit vom Dienst bereitgestellt) |
| E-Mail-Zugangsdaten Kunden |
SMTP-/IMAP-Passwörter serverseitig mit Fernet-Schlüssel verschlüsselt (soweit E-Mail-Modul genutzt) |
| Passwort-Hashes |
Argon2id (lokales Auth auf Hetzner/Postgres) |
| Refresh-Tokens |
Nur gehasht in der Datenbank (Local Auth) |
| Pseudonymisierung |
Soweit fachlich sinnvoll (z. B. interne IDs statt Klartext in Logs); vollständige Pseudonymisierung aller CRM-Daten nicht Primärziel der Applikation |
2. Integrität (Art. 32 Abs. 1 lit. b DSGVO)
2.1 Weitergabekontrolle
| Maßnahme |
Umsetzung |
| Übertragungswege |
Ausschließlich verschlüsselte Verbindungen (TLS) für App/API |
| Keine unverschlüsselte DB-Übergabe an Dritte |
✓ |
| Unterauftragsverarbeiter |
Nur mit AVV/DPA; siehe 05_Unterauftragsverarbeiter.md |
| Export an Auftraggeber |
Maschinenlesbarer Export im Rahmen AVV § 8; gesicherte Übergabe |
| E-Mail-Versand |
Im Auftrag des Auftraggeber über konfigurierte SMTP-Wege; Inhalt unter Kontrolle des Auftraggebers |
2.2 Eingabekontrolle
| Maßnahme |
Umsetzung |
| Nachvollziehbarkeit wesentlicher Aktionen |
Anwendungs-/Serverlogs (u. a. Login, Dokumentenerstellung, Signatur-Accept), soweit implementiert |
| Verantwortung für Dateneingabe |
Primär beim Auftraggeber (Staff) bzw. Endkunden im Portal; LightPalmMedia steuert technische Protokollierung |
| Signaturvorgänge |
Speicherung von Signaturdatum/-ort und Signaturabbild bzw. signed PDF |
| Änderungsnachweise |
Dokumentenmetadaten und Object-Keys in der DB; Storage-Versioning wo aktiviert |
2.3 Dokumenten- und Signaturintegrität (Sunvault-spezifisch)
| Maßnahme |
Umsetzung |
| Signierte PDFs |
Speicherung im Object Storage (EU); Referenz (Pfad/URL/Key) in Postgres |
| Unveränderlichkeit (Ziel) |
Getrennter Legal-Bucket; Object Lock / WORM-ähnliche Aufbewahrung für finale/signierte PDFs (Roadmap, noch nicht durchgängig aktiv) |
| Media vs. Legal |
Geplante Bucket-Trennung: Arbeitsmedien vs. rechtlich relevante Dokumente |
| Manipulationsschutz Portal |
Zeitlich begrenzte Token; getrennte Auth vom Staff-Bereich |
3. Verfügbarkeit und Belastbarkeit (Art. 32 Abs. 1 lit. b, c DSGVO)
3.1 Infrastruktur und Netzwerksicherheit
| Maßnahme |
Umsetzung |
| Hosting |
Professioneller EU-Anbieter (Hetzner Cloud Falkenstein) mit redundanter Netzanbindung gemäß Anbieter |
| Object Storage getrennt vom App-Server |
Impossible Cloud CE — Ausfall des App-Servers vernichtet nicht automatisch die Objekte |
| Firewall / Portfreigaben |
Nur erforderliche Ports; SSH und Admin-Zugänge beschränkt |
| DDoS / Netzschutz |
Basismaßnahmen des Cloud-Anbieters; zusätzliche Absicherung auf App-Ebene (Rate-Limits geplant/teilweise) |
| Dependency- und Security-Updates |
Im Rahmen der Wartung des Backends |
3.2 Backup und Wiederherstellung
| Maßnahme |
Umsetzung |
| Postgres-Backups |
Regelmäßige Backups (Skript/Job); Aufbewahrung begrenzt; Zugriff beschränkt |
| Object Storage |
Redundanz/Versioning gemäß Anbieter und Bucket-Konfiguration; eigene Backup-/Sync-Strategie ergänzend empfohlen |
| Wiederanlauf |
Dokumentierte Deploy-Pfade; Wiederherstellung aus Backup mindestens jährlich testen |
| Backup-Retention |
Rollierend; Details im Betrieb dokumentieren; nach Vertragsende Löschung inkl. Backups gemäß AVV § 8 (innerhalb der dort genannten Fristen) |
3.3 Monitoring und Incident-Response
| Maßnahme |
Umsetzung |
| Betriebsüberwachung |
Monitoring/Fehlertracking nur soweit konfiguriert und datensparsam |
| Sentry o. ä. |
Nur wenn produktiv aktiv — dann als Unterauftragsverarbeiter führen und AVV abschließen |
| Incident-Response |
Interne Eskalation; unverzügliche Information betroffener Auftraggeber gemäß AVV (Ziel intern: schnellstmöglich, idealerweise unter 24 h nach Bekanntwerden) |
| Meldeunterstützung |
Unterstützung des Auftraggebers bei Art. 33/34 DSGVO mit verfügbaren Informationen |
4. Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung (Art. 32 Abs. 1 lit. d DSGVO)
| Maßnahme |
Umsetzung |
| TOMs-Review |
Mindestens jährlich oder bei wesentlichen Infrastruktur-/Architekturänderungen |
| Freigabe durch Geschäftsführung |
Siehe 03a_TOMs_Freigabe_Anleitung.md |
| Unterauftragsverarbeiter |
Prüfung vor Einsatz; Aktualisierung Anlage 3 / Kundeninformation mit Widerspruchsfrist |
| Privacy by Design / Default |
Mandantentrennung, Need-to-know, minimale Secrets im Client, zeitlich begrenzte Portal-Tokens |
| Security-Updates |
Laufende Pflege von Dependencies und Server-Härtung |
| Auth-Migration |
Fortlaufende Ablösung Firebase Auth → Local Auth (06_Auth_Migration_Plan.md) |
| Penetrationstests |
Bei Wachstum oder auf Kundenanforderung planen (derzeit nicht als feste jährliche Pflicht dokumentiert) |
| Audit-Unterstützung |
Audits durch Auftraggeber gemäß AVV § 3 Abs. 5 |
5. Organisation und Personal
| Maßnahme |
Umsetzung |
| Vertraulichkeitsverpflichtung |
Mitarbeiter mit Datenzugang werden auf Vertraulichkeit und Datenschutz hingewiesen/verpflichtet |
| Sensibilisierung |
Datenschutz-/Sicherheitshinweise bei Tätigkeitsaufnahme und bei wesentlichen Änderungen |
| Clean Desk / Screen-Lock |
Am Arbeitsplatz üblich |
| Getrennte Accounts |
Keine Weitergabe persönlicher Zugangsdaten |
| Ausscheiden |
Zugänge unverzüglich entziehen |
| Externe (falls eingesetzt) |
Nur mit Vertraulichkeitsvereinbarung und im erforderlichen Umfang |
6. Auftragskontrolle (gegenüber Unterauftragsverarbeitern)
| Maßnahme |
Umsetzung |
| Schriftliche AVVs/DPAs |
Hetzner und Impossible Cloud archiviert unter archive/ |
| Google Firebase Auth |
Nur übergangsweise; Google DPA/SCC dokumentieren bis Exit |
| Weisungsbindung |
Unterauftragsverarbeiter nur im Rahmen der Kundenverträge; keine Nutzung der Kundendaten zu eigenen Zwecken der Unterauftragsverarbeiter |
| Standort |
Primär EU/EWR (Hetzner DE, Impossible Cloud CE); Drittlandbezug nur soweit in Anlage 3 ausgewiesen |
| Änderungsprozess |
Vor Wechsel/Ergänzung: interne Freigabe → Vertrag → Listen/VVT/TOMs aktualisieren → Kundeninfo |
Nachweise (Auszug):
archive/Hetzner_AVV_LightPalmMedia_2026-08-02.pdfarchive/Hetzner_TOM.pdfarchive/ImpossibleCloud_DPA-2025-06.pdfarchive/ImpossibleCloud_DPA_Annahme_LightPalmMedia.md
7. Spezifische Maßnahmen der Sunvault-Fachlogik
| Thema |
Maßnahme |
| Multi-Tenant PV-SaaS |
Autorisierung prüft Company-Zugehörigkeit je Request |
| CRM / Projekte / Belege |
Speicherung in Postgres (EU); Dokumente als Objekte in Impossible Cloud |
| Signaturportal |
Zeitlich begrenzter Portal-Zugang; getrennte Token; Speicherung Signaturmetadaten + signed PDF |
| Dokumente |
Object-Paths/Keys in DB; Abruf über autorisierte API |
| E-Mail-Modul |
Zugangsdaten verschlüsselt (Fernet); Versand im Auftrag des Auftraggeber |
| Löschung |
Auf Weisung / nach Vertragsende gemäß AVV § 8 (Exportfrist, Löschfrist inkl. Backups) |
| Logs |
IP/User-Agent bei Refresh-Tokens (Local Auth) — Zweck Missbrauchserkennung; Ziel-Retention Staff-Auth-Logs ≤ 90 Tage, sofern kein Incident |
| Authentifizierung |
Local Auth dokumentiert; Firebase aus Anlage 3 entfernt |
8. Risiken, Lücken und Roadmap (Transparenz)
| Risiko / Lücke |
Maßnahme / Status |
| Drittlandtransfers |
Derzeit keine; Verarbeitung in EU/EWR (Hetzner, Impossible Cloud) |
| Object Lock noch nicht durchgängig aktiv |
Empfohlen für Legal-Bucket mit signierten/finalen PDFs |
| MFA für Staff |
Nach Auth-Cutover evaluieren und einführen |
| Formale Penetrationstests |
Bei Wachstum / auf Kundenanforderung planen |
| Getrennte Prod/Staging-Buckets |
Soweit noch nicht vollständig: nachziehen |
| Sentry o. ä. |
Nur mit UAV-Eintrag und Vertrag, falls produktiv |
9. Bezug zu Art. 32 DSGVO (Mapping)
| Anforderung Art. 32 |
Primäre Abschnitte dieses Dokuments |
| Vertraulichkeit |
§ 1 |
| Integrität |
§ 2 |
| Verfügbarkeit |
§ 3 |
| Belastbarkeit |
§ 3 |
| Wiederherstellbarkeit |
§ 3.2 |
| Verfahren zur regelmäßigen Überprüfung |
§ 4 |
| Risikoangemessenheit |
Gesamtdokument + § 8 |
10. Dokumentenlenkung und Versionierung
| Version |
Datum |
Änderung |
| 1.0 |
2026-08-02 |
Erstfassung |
| 1.1 |
2026-08-02 |
Wesentliche Erweiterung (Hetzner-ähnliche Kontrollkategorien, Systemübersicht, Datenträgerkontrolle, Signaturintegrität, Mapping Art. 32, Freigabeprozess) |
Aktuelle Arbeitsfassung: dieses Markdown im Repo.
Freigegebene Kundenfassung: signiertes PDF gemäß 03a_TOMs_Freigabe_Anleitung.md.
11. Mitgeltende Unterlagen
01_AVV_Auftraggeber_Sunvault.md — AVV; Anlage 2 verweist auf diese TOMs03a_TOMs_Freigabe_Anleitung.md — interne Freigabe durch die Geschäftsführung04_VVT_Sunvault.md — Verzeichnis von Verarbeitungstätigkeiten05_Unterauftragsverarbeiter.md — Anlage 306_Auth_Migration_Plan.md — Firebase → Local Autharchive/Hetzner_TOM.pdf — TOMs des Unterauftragsverarbeiters Hetznerarchive/ImpossibleCloud_DPA-2025-06.pdf — DPA Object Storage
12. Freigabe intern (Geschäftsführung)
Mit der Unterzeichnung bestätigt die Geschäftsführung der LightPalmMedia GmbH, dass diese TOMs (Version und Stand laut Dokumentenkopf) den aktuell umgesetzten bzw. verbindlich geplanten Maßnahmen für Sunvault entsprechen und als Anlage 2 zum AVV mit Auftraggeber freigegeben werden.
|
|
| Dokument |
Technische und organisatorische Maßnahmen (TOMs) — Sunvault |
| Version |
1.1 |
| Stand |
2026-08-02 |
| Firma |
LightPalmMedia GmbH |
| Feld |
Eintrag |
| Ort, Datum |
_______________________________ |
| Name |
_______________________________ |
| Funktion |
Geschäftsführung |
| Unterschrift |
_______________________________ |
Elektronische Bestätigung (E-Mail der Geschäftsführung mit ausdrücklicher Freigabe von Version/Stand) ist der handschriftlichen Unterschrift gleichwertig, sofern die E-Mail und das freigegebene PDF unter docs/compliance/archive/ abgelegt werden.
Nächste planmäßige Überprüfung: spätestens 2027-08-02 oder früher bei wesentlichen Änderungen (siehe Freigabe-Anleitung).
Mit Bestätigung der Checkboxen bei der Registrierung gelten die TOMs
als Anlage zum AVV.
