FotavioZum AVV

ANLAGE Art. 32 DSGVO

Technische und organisatorische Maßnahmen.

Verbindliche Sicherheitsanlage zum Fotavio-AVV.

Für den Vertragsschluss veröffentlichte Fassung.

Version 2026-09-14.1 · SHA-256: 6157124e77d0a54e6e7966437d8cab208e4ed5177094bd17b80e0934ebfc9df9

1. Geltung und Sicherheitsorganisation

Anbieter ist Felix Häberle, Einzelunternehmen, Liesenstrasse 3, 10115 Berlin, Deutschland. Die Maßnahmen gelten risikobasiert für Fotavio und werden mindestens jährlich sowie nach erheblichen Änderungen überprüft. Zuständigkeiten für Datenschutz, Sicherheit, Vorfälle, Wiederherstellung und Provideränderungen sind benannt; Zugriffsberechtigte werden auf Vertraulichkeit verpflichtet.

2. Zugang und Administrationsschutz

  • passwortlose Anmeldung oder OAuth mit begrenzten Scopes und serverseitig begrenzten Sessions;
  • MFA für Provider- und Administrationskonten, getrennte Produktionsberechtigungen und regelmäßige Zugriffsreviews;
  • Secrets ausschließlich in verschlüsselten Secret-Stores, getrennt nach Zweck und Umgebung;
  • Widerruf kompromittierter Sitzungen und Schlüsselrotation nach Vorfällen;
  • verschlüsselte, gesperrte und aktuell gehaltene Betreiberendgeräte.

3. Berechtigungen und Mandantentrennung

  • Studio-, Projekt- und Familienbezug in fachlichen Datensätzen und Storage-Pfaden;
  • PostgreSQL Row Level Security, serverseitige Rollen- und Tenantprüfungen;
  • private Buckets und zeitlich begrenzte, gebundene Signed URLs statt öffentlicher Originale;
  • kein dauerhafter Support-Impersonationszugang; Break-glass nur begründet, befristet und protokolliert;
  • automatisierte Cross-Tenant- und Berechtigungstests vor Releases.

4. Eingabe-, Änderungs- und Weitergabekontrolle

  • append-only oder unveränderliche Auditnachweise für sicherheits- und datenschutzrelevante Aktionen;
  • Allowlist für Auditdaten; keine Tokens, Passwörter, vollständigen Zahlungsdaten oder unnötigen Bildinhalte in Logs;
  • Idempotenz und atomare Datenbankfunktionen gegen Doppelverarbeitung und inkonsistente Status;
  • minimierte Nachweise für E-Mail, Webhooks, Exporte, Freigaben und Löschung;
  • Endkunden- und Labor-Direct-Charges nutzen getrennte Datensätze, Accountzuordnungen und Idempotenzräume;
  • Connected Accounts werden nur aus serverseitig freigegebenen Laborzuordnungen übernommen; Webhook-Signatur und Account-Scope werden vor jeder Statusänderung geprüft;
  • Browser-Redirects setzen Zahlung, Application Fee, Refund oder Dispute nicht auf einen endgültigen Status; divergierende Event-Retries werden gesperrt und geprüft;
  • Provideränderungen werden vor produktiver Aktivierung geprüft und versioniert.

5. Transport- und Speicherschutz

  • TLS für Browser-, API- und Providerkommunikation;
  • providerseitige Verschlüsselung ruhender Daten und Backups;
  • Quarantäne und Datei-, Container- und Größenprüfung für Uploads;
  • Entfernung unnötiger EXIF-, GPS-, XMP-, IPTC-, Kommentar- und Textmetadaten vor Veröffentlichung;
  • vollständige Karten- und Bankdaten werden direkt von Stripe erhoben und nicht bei Fotavio gespeichert;
  • Labor-Checkout-Metadaten enthalten nur neutrale Auftrags-, SKU-, Mengen-, Kosten-, Steuer- und Belegreferenzen, keine Namen, Anschriften, Bilder, Codes oder Zahlungsmittel von Familien.

6. Verfügbarkeit und Wiederherstellung

  • versionierte Migrationen, Datenbankbackups und separater Schutz von Storage-Objekten;
  • idempotente Queue-, Retention- und Löschprozesse mit Wiederholungen und Healthchecks;
  • Wiederherstellung zunächst isoliert; Lösch- und Sperrlisten werden vor Produktivsetzung erneut angewandt;
  • regelmäßige Restore-, Rechte-, Incident-, Break-glass- und Tenant-Exit-Übungen;
  • Providerstörungen und Fehlzustände führen nicht zu einer unkontrollierten öffentlichen Freigabe.

7. Datenminimierung und Zweckbindung

  • projektbezogene Pflichtfelder, Rechtsgrundlage und Aufbewahrungsregel;
  • besondere Kategorien sind ohne gesonderte Prüfung und Freigabe gesperrt;
  • QR-/Barcodes zur Sequenzzuordnung, keine Gesichtserkennung oder biometrischen Templates;
  • Webhook- und Providerdaten werden nach Verarbeitung auf erforderliche Referenzen reduziert;
  • Produktionsdaten, B2B-Laborzahlung und Fotavio-Partnerabrechnung verwenden getrennte Tabellen, Exporte und Berechtigungen; ein Zahlungs- oder Fee-Ereignis gibt keine Produktion frei;
  • keine Werbepixel oder Marketinganalyse in Studio- und Familienbereichen.

8. Löschung und Aufbewahrung

Sessions bestehen höchstens 30 Tage; deaktivierte Accounts und Studioinhalte nach Vertragsende werden grundsätzlich innerhalb 30 Tagen aus aktiven Systemen entfernt. Auth- und Sicherheitslogs: 30 Tage; operative Ereignisse einschließlich inhaltsreicher Labor-Webhookdaten: höchstens 30 Tage nach erfolgreicher Verarbeitung; Nachrichteninhalte: 180 Tage; Empfänger-/Providerreferenzen werden nach 365 Tagen pseudonymisiert; Supportinhalte: 180 Tage; rollierende Backups: höchstens 30 Tage. Minimierte Charge-, Fee-, Refund- und Dispute-Referenzen bleiben nur für offenen Abgleich, Rechtsverteidigung oder gesetzliche Nachweise. Laborbelege und Fotavio-Partnerabrechnungen werden getrennt und gesperrt nach ihrer bestätigten gesetzlichen Frist aufbewahrt; Fotos und unnötige Kontaktdaten werden nicht allein wegen eines Belegs gespeichert.

9. Betroffenenrechte und Vorfälle

Tenantgebundene Workflows unterstützen Auskunft, Export, Berichtigung, Einschränkung, Widerruf und Löschung. Rechteinventare für Studio- oder Laboransprechpersonen schließen kontogebundene Checkout-, PaymentIntent-, Charge-, Fee-, Refund-, Dispute- und Belegreferenzen ein, ohne Daten anderer Studios oder Familien offenzulegen. Vorfälle werden mit Zeitachse, Systemen, Umfang, Folgen und Eindämmung dokumentiert; falsche Kinderfoto-Zuordnungen, Cross-Tenant-Zugriffe und falsches Connected-Account-Scoping besitzen eigene Eskalationspfade. Beim Studio- oder Labor-Exit werden neue Checkouts gesperrt, Berechtigungen und Credentials widerrufen und offene Vorgänge abgeglichen. Fotavio informiert den jeweils Verantwortlichen unverzüglich und unterstützt dessen Art.-33-/34-Bewertung.

10. Sichere Entwicklung und Wirksamkeitskontrolle

Reproduzierbare Installation, Review, Typecheck, Unit-, Browser-, SQL- und Edge-Tests, Dependency-Lock, Audit, CSP, Security-Header und Build-Allowlist sind Releasevoraussetzungen. Mindestens quartalsweise erfolgen Zugriffs- und Restorekontrollen, mindestens jährlich Incident-, Rechte-, Break-glass- und Tenant-Exit-Übungen. Feststellungen werden behoben und erneut getestet.