Technische und organisatorische Massnahmen (TOMs)

• Physischer Serverstandort ausschliesslich im ISO 27001/27017/27018-zertifizierten Rechenzentrum von Exoscale in Zürich, Schweiz.
• Kein physischer Serverzugang durch Formsly-Mitarbeitende — Betrieb ausschliesslich über dedizierte virtuelle Maschinen via Exoscale-Konsole.
• Physische Zugangskontrolle zum Rechenzentrum obliegt Exoscale (biometrisch, Videoüberwachung, Mantraps gemäss ISO 27001 A.11).

• Zugang zur Produktionsinfrastruktur (Exoscale, Supabase, Infomaniak, Stripe) ausschliesslich über individuelle, passwortgeschützte Accounts.
• Zwei-Faktor-Authentifizierung (2FA) auf allen Admin-Zugängen aktiviert — Hardware-Token (YubiKey) oder TOTP je nach Dienst.
• YubiKey-Redundanz: Zwei Hardware-Token vorhanden (Primary + Backup), beide registriert. Backup physisch separat aufbewahrt.
• Kein geteilter Zugang; keine gemeinsam genutzten Credentials.
• SSH-Zugang zu VMs ausschliesslich mit Public-Key-Authentifizierung (keine Passwort-Logins erlaubt).
• Private SSH-Keys auf verschlüsseltem USB-Stick aufbewahrt, nicht in Cloud-Diensten gespeichert.
• Regelmässige Überprüfung aktiver Zugriffsrechte.

• Row-Level Security (RLS): Auf allen Datenbanktabellen ( profiles, forms, submissions, consent_audit, webhooks, form_key_shares, e2e_access_log, secure_transfers, transfer_files, transfer_access_tokens, transfer_key_shares, transfer_access_log ) erzwungen — mandantenübergreifende Datenzugriffe sind selbst bei Applikationsfehlern technisch ausgeschlossen.
• Application-Level Encryption (ALE): Alle Formulardaten (Submission Answers) sowie E-Mail-Adressen der Einsender werden vor dem Datenbankschreibvorgang mit AES-256-GCM verschlüsselt. Rohdaten sind in der Datenbank unleserlich.
• Least Privilege: API-Routen prüfen Authentifizierung und Autorisierung vor jeder Datenbankoperation.
• E2EE-Audit-Log: Zugriffe auf E2EE-Schlüssel werden in e2e_access_log mit User-ID, Zeitstempel und SHA-256-gehashetem IP-Hash protokolliert.
• E2EE erfordert 2FA: Aktivierung von E2EE ist technisch blockiert, solange kein TOTP-Faktor am Account registriert ist.
• Besonders schützenswerte Daten erfordern E2EE: Der «Besonders schützenswerte Daten»-Modus im Formular-Builder ist technisch deaktiviert, solange E2EE für das Formular nicht aktiv ist.

• In Transit: TLS 1.2/1.3 für alle HTTP/S-Verbindungen. HTTPS erzwungen.
• At Rest (Infrastruktur): Exoscale verschlüsselt VM-Disks nicht automatisch. Kompensation erfolgt durch Application-Level Encryption (siehe unten).
• Applikationsebene (ALE): AES-256-GCM, zufälliger 12-Byte-IV pro Verschlüsselungsvorgang, 32-Byte-Key als Umgebungsvariable auf dem Server (nicht in Git). Verschlüsselt werden Formulardaten und E-Mail-Adressen.
• E2EE Formulare (optional, ab Pro-Plan): ECDH P-256 + ECIES + AES-256-GCM. Schlüssel-Derivation: PBKDF2 (200'000 Iterationen). Der private Schlüssel verlässt den Browser des Nutzers nie. Formsly speichert ausschliesslich verschlüsselten Ciphertext (Zero-Knowledge).
• E2EE Dateitransfer: Gleiche Architektur wie E2EE-Formulare (ECDH P-256 + ECIES + AES-256-GCM). Empfänger muss ein Formsly-Konto mit aktiviertem E2EE besitzen. Automatische Löschung nach 7 Tagen.

• Formulardaten (Payload) verlassen die Schweiz nicht.
• Keine Weitergabe an Dritte ohne Weisung des Kunden.
• Optionale Webhook-Integrationen erfolgen ausschliesslich auf explizite Konfiguration des Kunden (HTTPS-only, HMAC-SHA256-signiert).
• Bei aktivierter E2EE sind Webhooks und E-Mail-Integrationen technisch deaktiviert — verschlüsselte Daten verlassen die Datenbank nicht.
• Drittintegrationsdienste (Webhooks, Zapier) nur bei explizitem Opt-in des Kunden.

• Zeitstempel aller Formulareinreichungen und Consent-Angaben werden unveränderlich gespeichert.
• Consent-Audit-Rows enthalten: Zeitstempel, Consent-Text-Snapshot, Policy-Version, SHA-256-Hash der IP-Adresse, User-Agent.
• IP-Adressen werden nie im Klartext gespeichert — ausschliesslich SHA-256-Hashes (nicht umkehrbar) in consent_audit und e2e_access_log — für Spam-/Missbrauchsabwehr.
• Edit-Token: Wird als SHA-256-Hash gespeichert. Der Klartext-Token wird ausschliesslich im Bestätigungs-E-Mail an den Einreicher übermittelt. Ein Angreifer mit DB-Zugriff kann keinen gültigen Edit-Link rekonstruieren.
• E2EE-Zugriffs-Logs für sicherheitsrelevante Schlüsseloperationen.

• Tägliche automatische Datenbank-Backups (Supabase Point-in-Time-Recovery + Exoscale-Snapshots).
• Backups AES-256-verschlüsselt, gespeichert auf Exoscale Object Storage (Schweiz).
• Automatische Löschung nach 30 Tagen (Datensparsamkeit auf Backup-Ebene).
• RTO: 24 Stunden / RPO: 24 Stunden.
• Monitoring: Exoscale-Server-Alerts (CPU, RAM, Disk) sowie Uptime Robot für HTTP(S)-Monitoring der Produktionsdomains im 5-Minuten-Takt; Alert per E-Mail bei Ausfall.
• Konfigurierbare automatische Datenlöschfristen pro Formular.

• Strikte logische Mandantentrennung auf Datenbankebene via RLS.
• Kunden haben keinen Zugriff auf Daten anderer Kunden — auch bei Applikationsfehlern technisch ausgeschlossen.
• Entwicklungs-/Testumgebung von Produktionsumgebung getrennt.
• Separate Supabase-Projekte und Umgebungsvariablen für Produktion und Entwicklung.

• Bearbeitung ausschliesslich auf dokumentierte Weisung des Kunden (Nutzung der Plattformfunktionen, AVV).
• AVV nach Schweizer Recht mit jedem Kunden standardmässig abgeschlossen (digitale Checkbox bei Signup, versionsbasierte Consent-Protokollierung in legal_acceptances-Tabelle).
• Alle Unterauftragsbearbeiter im AVV deklariert (Exoscale, Infomaniak, Supabase). Mit jedem besteht ein DPA.
• Sub-Processor-Liste wird bei Änderungen aktualisiert.

• Single-Admin-Prinzip: Einziger Zugriffsberechtigter ist Moritz Lauper. Keine Drittparteien mit dauerhaftem Produktionszugang.
• Patch-Management: Dependency-Security-Updates via regelmässigem Audit-Prozess innerhalb von 7 Tagen nach Bekanntwerden; kritische CVEs sofort.
• Incident Response: Dedizierter Incident-Response-Plan dokumentiert. Meldung an Kunden innerhalb von 72h, EDÖB-Meldung bei hohem Risiko innerhalb von 72h.
• Sichere Entwicklung: Input-Validierung auf allen API-Endpunkten, keine Secrets im Repository, non-root Docker-Betrieb, HMAC-signierte Webhooks, Content Security Policy (CSP) mit Nonce-basierter Script-Kontrolle.
• Datensparsamkeit: Keine Tracking-Cookies für Endnutzer, kein Einsatz von Drittanbieter-Analytics auf Formularebene.

Dieses Dokument entspricht dem tatsächlichen Implementierungsstand und kann Kunden sowie Behörden auf Anfrage zur Verfügung gestellt werden.