Compliance- & Sicherheits-Matrix (Schweizer Kontext)#

Querschnitts-Dokument, kein Fachmodul. Diese Matrix bündelt alle rechtlichen und sicherheitstechnischen Anforderungen an Caja aus Schweizer Sicht und ordnet jeder Anforderung eine konkrete technische Umsetzung in der App zu. Sie ist die normative Referenz, auf die sich die ## 8. Compliance-/Sicherheits-Hinweise-Abschnitte der einzelnen Module beziehen. Wo ein Modul „revisionssicher", „10 Jahre aufbewahren" oder „besonders schützenswert" sagt, ist hier das Wie definiert — verankert in den geteilten Kern-Entitäten (movements, audit_log, monthly_closings, storage_objects, contacts, kyc_scans, notifications).

Geltungsbereich & Haftungsabgrenzung. Caja ist ein operatives Vorsystem, kein Rechts- oder Steuerberater-Ersatz. Es speist die formale Buchhaltung (Treuhänder-Export), ersetzt aber weder den rechtsgültigen Jahresabschluss noch die finale MWST-Abrechnung noch eine juristische DSG-Prüfung. Punkte, die mit Treuhänder/Rechtsberatung final zu klären sind, sind als 🔲 markiert.

Datenschutz-Audit-Stand (2026-06-28). Die zentralen revDSG-Pflichten sind als Best-Practice-Defaults entschieden und in diesem Dokument instanziiert (jeweils ✅, finale juristische Abnahme durch revDSG-Spezialist ausstehend): EU-Datenregion verbindlich (Supabase Frankfurt eu-central-1, Vercel fra1; §4.4.2), DPA-Checkliste der Auftragsbearbeiter (§4.3), gepflegtes Bearbeitungsverzeichnis (Art. 12, §5), durchgeführte DSFA (Art. 22, §12) und Incident-Runbook (Art. 24, §11). Die Rechtsgrundlagen/Quellen sind als Markdown-Links zu den massgeblichen revDSG-Artikeln (Fedlex) und EDÖB-Leitfäden hinterlegt.

Rechtsträger: Dominicano Express GmbH (Schweiz), gegründet 2026, Familien-GmbH (Marcel = Geschäftsführer, Markus = Operations, Mariela = Administration, Arkys = Fahrer/Logistik). Geschäftstätigkeit: See-Fracht Schweiz → Dominikanische Republik. Daraus folgt unmittelbar ein Drittland-Datentransfer (CH → DR, Zoll-/Zustelldaten) plus die Nutzung von US-/EU-Auftragsverarbeitern (Supabase, Vercel, Resend, WhatsApp/Meta). Das OCR der Ausweisdaten läuft self-hosted auf eigener Proxmox-Infra (Entscheid 2026-06-28 Teil 3) → kein OCR-Auftragsbearbeiter und kein Drittland-/Cloud-Transfer der Ausweisbilder fürs OCR; der Drittland-Transfer betrifft damit nur noch Zoll-/Zustelldaten in die DR, nicht den OCR-Dienst.

0. Regulatorischer Rahmen — Überblick#

Schwellen-Hinweis (zu bestätigen): 🔲 Ob/ab wann MWST-Pflicht und Revisionspflicht (ordentliche Revision erst ab OR-820-Schwellen, sonst opting-out möglich) effektiv greifen, ist mit dem Treuhänder festzulegen. Caja ist so gebaut, dass beide ohne Schema-Migration aktivierbar sind.

1. OR 957–963b — Buchführung & Aufbewahrung (10 Jahre)#

Owner-Entitäten: movements (Ledger), storage_objects (Belege/Rechnungen), monthly_closings, audit_log.

Aufbewahrungs-Fristenmatrix (10-Jahres-Regel, konkret pro Objekt):

Konflikt-Hotspot (KYC) — entschieden: Ausweis-Rohbilder sind nicht zwingend Buchungsbeleg im Sinn von OR 958f — die Identifikation der Vertragspartei kann fristrelevant sein, das Lichtbild selbst unterliegt der revDSG-Minimierung. Caja trennt deshalb extrahierte Pflichtfelder (contacts.cedula_number, fristrelevant, OR-10-J soweit Buchungsbeleg) vom Rohbild + KYC-Detailfeldern (kyc-Bucket / kyc_scans). Geschäftsentscheid 2026-06-28: KYC-Daten (Rohbild + extrahierte Felder) werden max. 24 Monate nach der letzten Interaktion mit dem Kontakt gelöscht (siehe §4.6). Damit ist OE-11/F-21 entschieden; ein gesondertes Rechtsgutachten zur Frist ist nicht mehr nötig. Aussenwirkung: 46-datenschutz.md §8.

2. GeBüV — Revisionssichere, unveränderbare Aufzeichnungen#

Owner-Entitäten: audit_log (append-only Journal), monthly_closings (Periodensperre), Backup/Export-Infrastruktur.

GeBüV verlangt für elektronisch geführte Bücher: Integrität (Art. 3), Verfügbarkeit/Lesbarkeit über die ganze Frist (Art. 6), Dokumentation der Verfahren (Art. 4) und bei veränderbaren Datenträgern den Nachweis der Unveränderbarkeit durch technische Massnahmen (Art. 9) — inkl. Zeitstempel und lückenlosem Änderungsnachweis.

Unveränderbarkeits-Kern (zur Illustration, normativ aus Modul 8):

-- audit_log: niemand darf ändern/löschen — auch ADMIN/service_role nicht
revoke update, delete on public.audit_log from authenticated, anon, service_role;
create rule audit_log_no_update as on update to public.audit_log do instead nothing;
create rule audit_log_no_delete as on delete to public.audit_log do instead nothing;
-- Schreiben ausschliesslich via SECURITY DEFINER-Trigger fn_audit(),
-- RLS-SELECT nur für interne Rollen (is_internal()), Affiliate: kein Zugriff.

GeBüV-Grenze (ehrlich benannt): SQL-Rules + Grant-Entzug erfüllen die Unveränderbarkeit „durch technische Massnahmen" auf Applikations-/DB-Ebene. Ein Datenbank-Superuser (Supabase-Projekt-Owner mit direktem Postgres-Zugriff) könnte theoretisch tiefer eingreifen. Kompensierende Kontrollen: (a) Supabase-Service-Key/DB-Passwort streng zugriffsbeschränkt (nur Marcel), (b) WORM-/immutable Backups (§6) als unabhängige zweite Spur, (c) Supabase-eigenes Audit/Logging der Infrastruktur. 🔲 zu bestätigen, ob für die Revision eine zusätzliche externe Unveränderbarkeits-Bestätigung (z. B. periodischer Hash-Anker/Export-Siegel) verlangt wird.

3. MWSTG — Abrechnung, Methodenwahl, eVV/Einfuhrsteuer#

Owner-Entitäten: vat_rates (effektiv-datiert, active-Flag), movements.vat_code/vat_amount_chf, Treuhänder-/MWST-Export. Status: schema-ready, default inaktiv (vat_rates.active=false, Feature-Flag vat_enabled=false) → keine falschen Steuerkennzahlen vor Scharfschaltung.

MWST-Abgrenzung: Caja erzeugt MWST-Kennzahlen und -belege, reicht aber nichts bei der ESTV ein und ersetzt die fachliche Abrechnung des Treuhänders nicht. Methodenwahl (Saldo vs. effektiv) und der konkrete Saldosteuersatz sind Geschäfts-/Treuhänderentscheide (🔲), die Caja per Settings abbildet.

4. revDSG / DSG — Personendaten & besonders schützenswerte Ausweisdaten#

Owner-Entitäten: contacts (Parteien: Kunde/Lead/Lieferant/Affiliate/Empfänger-DR), kyc_scans + kyc-documents-Bucket (Ausweise = besonders schützenswert), storage_objects (is_sensitive), notifications (Kommunikationsdaten).

4.1 Daten-Klassifizierung#

4.2 Kern-Pflichten → Umsetzung#

4.3 Auftragsbearbeiter (Art. 9 revDSG) — Provider-Matrix#

Pflicht: Auftragsbearbeitung nur, wenn der Bearbeiter dieselbe Datensicherheit gewährleistet → Auftragsbearbeitungsvertrag (DPA/AVV) mit jedem Provider; Unterbeauftragung nur mit Genehmigung; Drittland nur mit Garantien (siehe §4.4).

DPA-Checkliste (zu zeichnen, Best-Practice-Default — finale juristische Abnahme ausstehend): Mit jedem externen Auftragsbearbeiter ist vor Produktivbetrieb ein Auftragsbearbeitungsvertrag (DPA/AVV) nach Art. 9 revDSG abzuschliessen. OCR entfällt (self-hosted, in-house — kein Auftragsbearbeiter).

• Supabase — Standard-DPA akzeptieren/gegenzeichnen; Region eu-central-1 fixieren; SCC für US-Mutterkonzern enthalten.
• Vercel — DPA gegenzeichnen; Functions-/Region EU; SCC enthalten.
• Resend — DPA gegenzeichnen; SCC (US) enthalten.
• Meta/WhatsApp (bzw. BSP wie Twilio/360dialog) — WABA-Terms + DPA; SCC (US) bzw. EU-BSP-Vertrag.
• Revolut Business — DPA/Datenschutzbestimmungen akzeptieren/gegenzeichnen.

4.4 Drittland-Transfer (Art. 16–18 revDSG)#

4.5 Affiliate-Mandantentrennung (Datenschutz-relevant)#

Ein Affiliate ist datenschutzrechtlich ein Externer → er darf keine fremden Personen-/Finanzdaten sehen. Technisch hart über RLS: current_affiliate_id()-Helfer + Policies stellen sicher, dass ein Affiliate ausschliesslich seine vermittelten Sendungen/Offerten/Abrechnungen sieht (kein Kunden-Gesamtzugriff, kein Finanz-Gesamtzugriff, kein audit_log- und kein kyc-Zugriff). Beispiel-Policy siehe Modul 8 §3.12.

4.6 KYC-Aufbewahrung — das DSG ⇄ OR-Spannungsfeld (Löschkonzept)#

✅ Entschieden (Geschäftsentscheid 2026-06-28, löst OE-11 / F-21): Die KYC-Aufbewahrungsfrist für Rohbild und extrahierte Felder beträgt max. 24 Monate nach der letzten Interaktion mit dem Kontakt; danach Löschung. Das bestimmt den kyc-retain_until-Default als last_interaction_at + 24 Monate (rollierend — jede neue Interaktion verschiebt das Lösch-Datum). Rechtsgrundlage: Zweckbindung/Verhältnismässigkeit nach revDSG; die Bearbeitung selbst stützt sich auf die Einwilligung im Onboarding-Vertrag (Ausweisbearbeitung + Auslandtransfer + OCR) sowie auf Vertragserfüllung. Ein gesondertes Rechtsgutachten zur Frist ist damit nicht mehr nötig. Abgrenzung OR: Soweit eine KYC-Information zwingender Buchungsbeleg ist (z. B. Identität der Vertragspartei auf einem Beleg), gilt dort weiterhin die 10-Jahres-Frist (§1.4); das ist eine andere Schicht als das Ausweis-Lichtbild. Querverweise: OCR §8.1 (Open Point 6) und Design §8.1 ziehen denselben Entscheid nach; Aussenwirkung in 46-datenschutz.md §8.

5. Bearbeitungsverzeichnis (Art. 12 revDSG) — gepflegtes Verzeichnis#

✅ Instanziiert (Best-Practice-Default, finale juristische Abnahme ausstehend). Dominicano Express GmbH führt dieses Verzeichnis der Bearbeitungstätigkeiten als Verantwortliche nach Art. 12 revDSG. Caja liefert die technischen Fakten aus dem Schema; die laufende Pflege (neue Bearbeitungen, geänderte Empfänger) liegt bei der GmbH (RACI §10). Pflicht-Begründung: Die KMU-Ausnahme nach Art. 24 DSV (< 250 Mitarbeitende) entfällt, sobald umfangreich besonders schützenswerte Daten bearbeitet werden — KYC-Ausweisdaten sind genau das; das Verzeichnis wird daher konservativ unabhängig vom Volumen geführt.

Kopfangaben (Art. 12 Abs. 2 lit. a):

Bearbeitungstätigkeiten (Art. 12 Abs. 2 lit. b–e + DSV): Spalten = Zweck · Betroffene Personen · Datenkategorien · Empfänger · Auslandtransfer (+ Garantie) · Aufbewahrung · Rechtsgrundlage.

Allgemeine TOM (techn./org. Massnahmen, für alle Bearbeitungen): RLS deny-by-default, AES-256 at-rest, TLS 1.2+ in-transit, passwortlose Auth + 2FA/MFA (Entra/TOTP), private Buckets + kurzlebige Pre-Signed URLs, append-only Audit, Backup/PITR + WORM-Cold-Storage, RTO/RPO (§6, §8).

Pflege-Hinweis: Jede neue Tabelle/jeder neue Provider, der Personendaten berührt, ist als Zeile zu ergänzen (Review-Gate analog RLS-Policy-Pflicht, §8.2). Querverweis Drittland-Garantien §4.4, Auftragsbearbeiter §4.3.

6. Aufbewahrung, Löschkonzept, Backup & RTO#

6.1 Lösch-Guard (OR-Aufbewahrung schlägt DSG-Löschung, solange Frist läuft)#

DSG-Löschbegehren und OR-Aufbewahrung können kollidieren. Caja löst das deterministisch: ein Lösch-/Lifecycle-Job darf ein fristrelevantes Objekt nie vor retain_until löschen.

-- Konzept-Guard: blockt Löschung fristrelevanter Storage-Objekte vor Fristablauf.
create or replace function public.fn_guard_retention()
returns trigger language plpgsql security definer set search_path = public as $$
begin
  if old.retain_until is not null and old.retain_until > current_date then
     raise exception 'Objekt % unterliegt Aufbewahrung bis % (OR 958f) — Löschung blockiert.',
       old.id, old.retain_until using errcode = 'P0001';
  end if;
  return old;
end; $$;
-- KYC-Rohbild (is_sensitive, kein Buchungsbeleg): retain_until = last_interaction_at + 24 Monate
-- (Entscheid 2026-06-28, rollierend). Lifecycle-Job löscht NACH Fristablauf (revDSG-Zweckbindung),
-- der Guard schützt es bis dahin wie jedes fristrelevante Objekt; Audit-Eintrag der Löschung bleibt.

6.2 Löschkonzept je Objektklasse#

Anonymisierung statt Löschung dort, wo OR-Frist und DSG-Löschwunsch kollidieren: Personenbezug im Kontakt entfernen, die buchhalterische Bewegung (betragsmässig, fristrelevant) bleibt erhalten. So sind beide Pflichten erfüllbar.

6.3 Backup & Recovery (GeBüV Art. 6 — Verfügbarkeit über die Frist)#

7. Buchhaltungs-Abgrenzung (was Caja ist — und was nicht)#

8. Sicherheits-Querschnitt (technische Härtung)#

9. Konsolidierte offene Punkte (🔲 zu bestätigen)#

10. Compliance-Verantwortlichkeiten (RACI, knapp)#

R = Durchführung, A = Rechenschaft, C = beizuziehen, I = informiert. Operative Tagesarbeit (Buchungen, Scans, Sendungen) erzeugt die Compliance-Artefakte automatisch (Auto-Posting → movements, Mutation → audit_log, Beleg → storage_objects); die menschliche Verantwortung konzentriert sich auf Abschluss, Freigaben und die rechtliche Pflege (Verzeichnis, DPAs, Datenschutzerklärung).

11. Incident-Runbook — Meldung Datensicherheitsverletzung (Art. 24 revDSG)#

✅ Ausformuliert (Best-Practice-Default, finale juristische Abnahme ausstehend). Operatives Runbook für eine Verletzung der Datensicherheit (unbefugter Zugriff/Verlust/Offenlegung von Personendaten) nach Art. 24 revDSG und dem EDÖB-Leitfaden zur Meldung von Datensicherheitsverletzungen. Kern-Regel: Meldung an den EDÖB „so rasch als möglich", wenn die Verletzung voraussichtlich zu einem hohen Risiko für die Persönlichkeit oder die Grundrechte der betroffenen Personen führt. Anders als die DSGVO kennt das revDSG keine fixe 72-Stunden-Frist — Massstab ist das Ausmass der Gefährdung (je grösser, desto schneller). Meldeportal: databreach.edoeb.admin.ch.

Rollen: Incident-Lead = Marcel (GF/ADMIN) (R/A), Beizug Rechtsberatung (C) bei Risiko-Einstufung/Meldung, Mariela (I).

11.1 Schritt-für-Schritt#

11.2 Risiko-Triage (Hilfsmatrix — „voraussichtlich hohes Risiko"?)#

Default bei Unsicherheit: Im Zweifel eher melden und Rechtsberatung beiziehen. Verschlüsselung at-rest (AES-256) ist ein risikomindernder Faktor, entbindet aber nicht automatisch von der Meldung, wenn Schlüssel/Zugang ebenfalls betroffen sein könnten.

Selbstbelastungs-Schutz (Art. 24 Abs. 6): Eine Meldung an den EDÖB darf in einem Strafverfahren gegen die meldepflichtige Person nur mit deren Einverständnis verwendet werden — die Meldepflicht schafft also kein Selbstbelastungsrisiko und ist ohne Zögern zu erfüllen.

Auftragsbearbeiter (Art. 24 Abs. 3): Auftragsbearbeiter (Supabase/Vercel/Resend/Meta/Revolut) müssen Dominicano Express eine Verletzung „so rasch als möglich" melden → diese Pflicht ist in den DPAs (§4.3) sicherzustellen; danach läuft obiges Runbook.

12. Datenschutz-Folgenabschätzung (DSFA) — KYC-Ausweisbearbeitung (Art. 22 revDSG)#

✅ Schwellenprüfung durchgeführt + DSFA erstellt (Best-Practice-Default, finale juristische Abnahme ausstehend). Grundlage: Art. 22 revDSG und die DSFA-Information des EDÖB.

12.1 Schwellenprüfung (ist eine DSFA nötig?)#

Eine DSFA ist erforderlich, wenn eine Bearbeitung voraussichtlich ein hohes Risiko für Persönlichkeit/Grundrechte mit sich bringt. Art. 22 Abs. 2 nennt als Regelbeispiel u. a. die umfangreiche Bearbeitung besonders schützenswerter Personendaten.

➡️ Ergebnis: DSFA erforderlich (vorsorglich bejaht — Best-Practice-Default).

12.2 Beschreibung der Bearbeitung (Art. 22 Abs. 3)#

KYC-Onboarding: Kunde übermittelt Ausweis (WhatsApp/Upload) → self-hosted OCR extrahiert Pflichtfelder → Speicherung in kyc_scans/kyc-Bucket (Supabase EU) → für Zoll/Empfänger-Matching genutzt; zollrechtlich nötige Felder werden in die DR bekanntgegeben. Details: 11-whatsapp-ocr.md, Verzeichnis §5 (V2).

12.3 Risikobewertung & Massnahmen#

12.4 Befund & EDÖB-Konsultation (Art. 23)#

✅ Gesamtbefund: Nach Umsetzung der Massnahmen ist das Restrisiko nicht mehr hoch. Damit ist keine Vorabkonsultation des EDÖB nach Art. 23 revDSG erforderlich (diese wäre nur bei verbleibend hohem Restrisiko trotz Massnahmen nötig; alternativ entfällt sie ohnehin, wenn eine Datenschutzberatung konsultiert wurde). Die DSFA ist lebend zu halten und bei wesentlichen Änderungen (z. B. Wechsel zu Cloud-OCR, neuer Empfänger, massive Volumensteigerung) zu aktualisieren. Finale juristische Abnahme durch revDSG-Spezialist ausstehend.