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, webhook_deliveries, form_forwarding_destinations ) 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 und Berufsgeheimnisse sind gesperrt: Über Formsly-Formulare dürfen weder besonders schützenswerte Personendaten nach Art. 5 lit. c DSG noch Daten erhoben werden, die einem Berufs-, Amts- oder Bankkundengeheimnis unterstehen (AGB Ziffer 5). Ist ein Formular als solches markiert, weist der Server jede Antwort ab. Eine Stichwortprüfung im Builder warnt zusätzlich, sobald Felder auf solche Datenkategorien hindeuten. Verschlüsselung hebt die Sperre nicht auf. Ausgenommen sind einzelne Bestandsverträge, für die zusätzlich E2EE aktiv sein muss.
• Durchleitungsmodus als einzige Ausnahme: Für Daten nach Art. 5 lit. c DSG (nicht für Berufs-, Amts- oder Bankkundengeheimnisse) kann der Kunde ein Formular in den Durchleitungsmodus setzen. Antwortinhalte werden dann nicht gespeichert, sondern unmittelbar an ein vom Kunden bestimmtes Ziel weitergeleitet. Durchgesetzt wird das durch einen Datenbank-Trigger, nicht nur im Anwendungscode: Ohne aktives, bestätigtes Ziel lässt sich ein solches Formular nicht veröffentlichen. Datei-Uploads und Terminbuchungen sind in diesem Modus ausgeschlossen, weil beide zwingend eine Speicherung erfordern.
• Zielbeschränkung Schweiz: Weiterleitungsziele für besonders schützenswerte Daten müssen in der Schweiz bearbeitet werden. Der Kunde bestätigt das ausdrücklich, zusätzlich weist ein Abgleich Ziele bekannter ausländischer Plattformen (Automations- und Chat-Dienste, Cloud-Funktionen) technisch ab. Der Abgleich ist ein Plausibilitätsindiz und kein Nachweis: Wo ein fremder Server tatsächlich bearbeitet, ist von aussen nicht feststellbar.
• Verschlüsselter Fehlschlag-Spool: Ist das Ziel nicht erreichbar, wird der Inhalt mit ECIES (P-256) an den öffentlichen Formularschlüssel verschlüsselt. Formsly kann ihn nicht lesen, der private Schlüssel liegt passwortgeschützt beim Kunden. Automatische Löschung nach 7 Tagen, unabhängig davon, ob der Kunde ihn abgeholt hat.

• 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. Für Formulare mit besonders schützenswerten Daten sind Ziele bekannter ausländischer Plattformen (unter anderem Zapier, Make, Slack) technisch ausgeschlossen.
• Vom Kunden bestimmte Weiterleitungsziele sind keine Unterauftragsbearbeiter von Formsly (AVV Ziffer 6c). Formsly verantwortet die Sicherheit des Übermittlungsvorgangs bis zur Übergabe; für die Bearbeitung beim Empfänger danach ist der Kunde verantwortlich.

• 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.
• 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.