NIS2-Konformität & Informationssicherheitsrichtlinie

Sarama CRM-Plattform
Betreiberin: Angad Manik, Rebgasse 53, 4058 Basel, Schweiz
Verantwortliche Person: Angad Bank Manik, impact@angad.swiss
Plattform: sarama.angad.swiss
Stand: 21. August 2026

1. Zweck und Geltungsbereich

Diese Informationssicherheitsrichtlinie dokumentiert die Sicherheitsmassnahmen und Verfahren zur Vorfallreaktion der Sarama CRM-Plattform in Übereinstimmung mit der Richtlinie (EU) 2022/2555 (NIS2-Richtlinie), die am 16. Januar 2023 in Kraft trat und von den EU-Mitgliedstaaten bis zum 17. Oktober 2024 umzusetzen war.

Obwohl Angad Manik ein Schweizer Unternehmen ist und NIS2 nicht direkt unterliegt, wenden wir NIS2-konforme Sicherheitspraktiken an, weil:

• Wir Kunden in der EU bedienen, die NIS2 unterliegen können;
• NIS2 Art. 21 von Unternehmen verlangt, ihre Lieferketten abzusichern, einschliesslich Anbietern ausserhalb der EU;
• Die Anwendung von NIS2-Standards Sorgfalt demonstriert und die Compliance unserer Kunden unterstützt.

Diese Richtlinie deckt die Sarama CRM-Plattform und alle an ihrem Betrieb beteiligten Systeme, Daten und Prozesse ab.

2. Governance und Verantwortlichkeit

2.1 Managementverantwortung (NIS2 Art. 20)

• Verantwortliche Person: Angad Bank Manik (Einzelunternehmer) ist für die Informationssicherheit verantwortlich und genehmigt alle Sicherheitsrichtlinien.
• Sicherheitsüberprüfungen werden regelmässig und nach jedem bedeutenden Vorfall oder Architekturänderung durchgeführt.
• Diese Richtlinie wird mindestens jährlich überprüft und aktualisiert.

2.2 Risikomanagement-Ansatz (NIS2 Art. 21(1))

Wir verfolgen einen risikobasierten Ansatz für die Sicherheit, verhältnismässig zu unserer Grösse, der Art unserer Dienste und den potenziellen Auswirkungen von Vorfällen auf unsere Kunden.

3. Risikomanagement-Massnahmen (NIS2 Art. 21(2))

3.1 Risikobewertung und Richtlinien (Art. 21(2)(a))

Risikoregister (identifizierte Hauptrisiken):

3.2 Vorfallbehandlung (Art. 21(2)(b))

Siehe Abschnitt 5 (Vorfallreaktionsplan).

3.3 Geschäftskontinuität (Art. 21(2)(c))

• Datenbank-Backups: Verwaltet von Supabase (tägliche automatische Backups, Point-in-Time-Recovery für Pro-Pläne).
• Infrastruktur: Supabase Zürich-Region mit AWS-Infrastruktur.
• Datenexport: Kunden können jederzeit einen vollständigen Datenexport anfordern.
• Wiederherstellungsziel: Dienst innerhalb von 24 Stunden nach einem schwerwiegenden Vorfall wiederherstellen.

3.4 Lieferkettensicherheit (Art. 21(2)(d))

Unterauftragsbearbeiter und deren Sicherheitsniveau:

3.5 Sicherheit in Entwicklung und Wartung (Art. 21(2)(e))

• Schwachstellenmanagement: Abhängigkeiten vor Updates überprüft. Bekannte CVEs verfolgt.
• Sichere Programmierung: Parametrisierte Abfragen (via Supabase Client), Input-Bereinigung (DOMPurify), Output-Encoding.
• Code Review: Alle Änderungen vor der Bereitstellung geprüft.
• OWASP Top 10: In der Anwendung adressiert:
  • A01 Broken Access Control → Row-Level Security (RLS) auf allen Tabellen
  • A02 Kryptographische Fehler → AES-256-GCM, TLS 1.2+
  • A03 Injection → Parametrisierte Abfragen, kein rohes SQL von Benutzereingaben
  • A05 Sicherheits-Fehlkonfiguration → CSP-Header, keine CORS-Wildcard
  • A07 XSS → DOMPurify für HTML-Rendering
  • A09 Logging → Audit-Log für alle Datenoperationen

3.6 Wirksamkeitsbewertung (Art. 21(2)(f))

• Sicherheitsmassnahmen werden nach jeder wesentlichen Änderung oder jedem Vorfall bewertet.
• Penetrationstests und Red-Team-Übungen werden regelmässig durchgeführt.
• Ergebnisse werden dokumentiert und mit verfolgten Zeitplänen behoben.

3.7 Cybersicherheitsschulung (Art. 21(2)(g))

• Die verantwortliche Person hält ihr Wissen über Cybersicherheitsbedrohungen und Best Practices aktuell.
• Sicherheitsbewusstsein ist in die operativen Verfahren integriert.

3.8 Kryptographie (Art. 21(2)(h))

3.9 Zugriffskontrolle und Asset-Management (Art. 21(2)(i))

Authentifizierung:

• E-Mail-Verifizierungscodes, Passwort-Anmeldung, Passkeys und verknüpfte OAuth-Identitäten werden unterstützt.
• Supabase Auth prüft Passwörter mit einem Einweg-Hash; Sarama speichert oder zeigt keine Klartext-Kontopasswörter an.

Autorisierung:

• Isolation auf Organisationsebene via Row-Level Security.
• Rollenbasierte Zugriffskontrolle innerhalb von Organisationen (Owner, Admin, Member).
• Kontoebenen-Rollen (Owner, SDR, AE, CSM, SE, Member) mit granularen Berechtigungen.
• Mitgliedschaftsänderungen nur über RPCs (INSERT-Policy: WITH CHECK (false)).

3.10 Multi-Faktor-Authentifizierung (Art. 21(2)(j))

• Optionale TOTP-Zwei-Schritt-Verifizierung ist unter Login & Sicherheit verfügbar.
• WebAuthn-Passkeys sind auf unterstützten Browsern und Authentifikatoren als phishing-resistente, passwortlose Anmeldung verfügbar.

4. Sicherheit öffentlicher Endpunkte

Die Plattform stellt öffentliche (nicht authentifizierte) Endpunkte für Formulare und E-Mail-Tracking bereit:

5. Vorfallreaktionsplan (NIS2 Art. 21(2)(b), Art. 23)

5.1 Vorfallklassifizierung

5.2 Schritte der Vorfallreaktion

1. Erkennung & Triage (0–1 Stunde) — Umfang, betroffene Daten und betroffene Kunden identifizieren. Schweregrad gemäss obiger Tabelle klassifizieren.
2. Eindämmung (1–4 Stunden) — Betroffene Systeme oder Konten isolieren. Kompromittierte Zugangsdaten widerrufen. Betroffene Endpunkte bei Bedarf deaktivieren.
3. Benachrichtigung (innerhalb von 24 Stunden bei bedeutenden Vorfällen) — Betroffene Kunden per E-Mail benachrichtigen. Bei Verletzungen des Schutzes von Personendaten: Meldung an den betroffenen Kunden unverzüglich und in jedem Fall spätestens innerhalb von 48 Stunden nach Kenntniserlangung (AGB Ziff. 6.3 und 8.4(f)). Die 48 Stunden sind unsere äusserste Grenze gegenüber dem Kunden, nicht dessen eigene Frist von 72 Stunden nach Art. 33 Abs. 1 DSGVO gegenüber seiner Aufsichtsbehörde. Bei NIS2-relevanten Vorfällen: CSIRT innerhalb von 24 Stunden (Frühwarnung), vollständiger Bericht innerhalb von 72 Stunden.
4. Beseitigung & Wiederherstellung (1–7 Tage) — Ursachenanalyse. Schwachstellen beheben. Bei Bedarf aus Backups wiederherstellen. API-Schlüsselrotation für betroffene Kunden anordnen.
5. Post-Incident Review (innerhalb von 30 Tagen) — Lessons Learned dokumentieren. Risikoregister aktualisieren. Präventivmassnahmen umsetzen. Diese Richtlinie bei Bedarf aktualisieren.

5.3 NIS2-Meldefristen (Art. 23)

6. Compliance-Mapping

7. Überprüfung und Aktualisierung

Diese Richtlinie wird überprüft:

• Mindestens jährlich;
• Nach jedem bedeutenden Sicherheitsvorfall;
• Nach grösseren Architekturänderungen;
• Wenn nationale NIS2-Umsetzungsgesetze aktualisiert werden.

8. Kontakt

Für Sicherheitsanfragen oder zur Meldung einer Schwachstelle:

Angad Manik
Angad Bank Manik
Rebgasse 53, 4058 Basel, Schweiz
E-Mail: impact@angad.swiss

Für dringende Sicherheitsvorfälle, E-Mail mit Betreff: [SICHERHEITSVORFALL] — Sarama CRM

Letzte Aktualisierung: 21. August 2026