ISMS & TOM – Guventa

Informationssicherheits-Managementsystem (ISMS) und Technische und organisatorische Maßnahmen (TOM)

Version 1.1 | Stand FEB 2026

Geltungsbereich: Organisationsweit für Guventa, einschließlich Website, Plattformbetrieb, Integrationssysteme und interne Produktivitätsprozesse

0. Zweck, Einordnung und Verhältnis zu anderen Dokumenten

(1) Dieses Dokument beschreibt das ISMS von Guventa sowie die technischen und organisatorischen Maßnahmen (TOM) zur Sicherstellung eines angemessenen Schutzniveaus, insbesondere im Sinne von Art. 32 Datenschutz-Grundverordnung (EU) (DSGVO).
(2) Dieses Dokument ergänzt die AGB Version 1.1, die Acceptable Use Policy (AUP) Version 1.1, den Auftragsverarbeitungsvertrag (AVV) Version 1.1, die Datenschutzerklärung Version 1.1, die Cookie- und Tracking-Richtlinie Version 1.1 sowie das Subprocessor Register (Governance Version 1.1).
(3) Guventa verfolgt einen risikobasierten Sicherheitsansatz, orientiert an anerkannten Industriestandards und Best Practices (z. B. ISO 27001 als Referenzrahmen), ohne dass hierdurch eine formale Zertifizierung zugesichert wird.
(4) Rechtsgrundlagen: Deutschland: Bundesdatenschutzgesetz (DE) §64 BDSG Europäische Union: Datenschutz-Grundverordnung (EU) Artikel 32 DSGVO Schweiz: Bundesgesetz über den Datenschutz (CH) Artikel 8 DSG Vereinigtes Königreich: UK GDPR (UK) Article 32

1. ISMS-Überblick (Governance)

1.1 Sicherheitsziele

(1) Vertraulichkeit: Schutz personenbezogener Daten und sensitiver Informationen vor unbefugtem Zugriff.
(2) Integrität: Schutz vor unbefugter Veränderung sowie Sicherstellung der Nachvollziehbarkeit sicherheitsrelevanter Aktionen.
(3) Verfügbarkeit: Sicherstellung einer angemessenen Betriebsfähigkeit, Resilienz und Wiederherstellbarkeit im Rahmen der Leistungsvereinbarungen und Provider-Abhängigkeiten.
(4) Belastbarkeit: Fähigkeit, Störungen zu erkennen, zu begrenzen und in angemessener Zeit wiederherzustellen.

1.2 Rollen und Verantwortlichkeiten

(1) ISMS-Verantwortung: Guventa benennt eine verantwortliche Stelle für Informationssicherheit und Datenschutzkoordination, die Richtlinien pflegt, Risikoanalysen koordiniert, Maßnahmen priorisiert und die Umsetzung überwacht.
(2) Zugriffsbefugnisprinzip: Zugriffe werden rollenbasiert und nach dem Need-to-Know-Prinzip vergeben; administrative Tätigkeiten werden protokolliert.
(3) Subprozessor-Management: Auswahl, Bewertung, Vertragsabsicherung und laufende Überwachung erfolgen nach dem Subprocessor Register; systemkritische Subprozessoren sind technisch nicht selektiv ausschließbar.

1.3 Risikomanagement

(1) Guventa führt risikobasierte Bewertungen durch, insbesondere bei Änderungen an Infrastruktur, Integrationen, sicherheitsrelevanten Features und beim Einsatz neuer Subprozessoren.
(2) Risikoanalysen dokumentieren: Assets, Bedrohungen, Eintrittswahrscheinlichkeiten, Auswirkungen, bestehende Kontrollen, Restrisiko und Maßnahmenplan.
(3) Vor produktiver Verbindung externer Systeme zwischen Guventa- und kundenseitig gehosteten Diensten ist eine Risikobewertung erforderlich, sofern dies im Leistungsumfang vorgesehen oder aufgrund der Risikoqualität erforderlich ist.

1.4 Dokumentations- und Änderungsmanagement

(1) Änderungen an sicherheitsrelevanten Konfigurationen (z. B. Auth, Berechtigungen, Logging, Datenflüsse, Integrationen) erfolgen kontrolliert und nachvollziehbar.
(2) Relevante Richtlinien und Anlagen (ISMS, TOM, Subprocessor Register) werden versioniert; wesentliche Änderungen werden im Rahmen der Vertragslogik angekündigt.

2. Technische Sicherheitsmaßnahmen (TOM) – Kernkontrollen

2.1 Zutrittskontrolle

(1) Rechenzentrums- und Serverzugang wird durch die jeweiligen Hosting- und Infrastrukturprovider nach deren Standards kontrolliert; Guventa nutzt ausschließlich EU-Hosting über Hetzner für eigene Server.
(2) Physische Zutrittskontrolle zu eigenen Guventa-Räumlichkeiten erfolgt nach organisatorischer Verfügbarkeit; kritische Systeme sind primär cloudbasiert betrieben und physisch durch Provider abgesichert.

2.2 Zugangskontrolle und Authentifizierung

(1) Zugriff auf zentrale Systeme erfolgt über individuelle Nutzerkonten; gemeinschaftliche Logins sind untersagt, soweit technisch und organisatorisch durchsetzbar.
(2) Multi-Factor Authentication (MFA) wird für administrative Konten und sicherheitsrelevante Systeme verpflichtend eingesetzt, soweit technisch verfügbar.
(3) Passwortanforderungen: Mindestlänge, Komplexität, keine Wiederverwendung; Passwortmanager-Nutzung ist verpflichtend empfohlen für administrative Konten.
(4) Sitzungs- und Zugriffszeiten werden angemessen begrenzt; inaktive Sessions werden abgemeldet, soweit technisch verfügbar.

2.3 Berechtigungskonzept und Mandantentrennung

(1) Rollen- und Rechtekonzepte: Zugriff erfolgt nach minimal erforderlichen Rechten (Least Privilege).
(2) Mandantentrennung: Plattformdaten werden mandantenfähig verarbeitet; administrative Eingriffe erfolgen nachvollziehbar und zweckgebunden.
(3) Supportzugriffe (inkl. Extendly) erfolgen nur, soweit erforderlich, und werden organisatorisch begrenzt; Zugriffe werden protokolliert, soweit technisch verfügbar.

2.4 Verschlüsselung und Kryptographie

(1) Transportverschlüsselung: HTTPS/TLS für Webzugriffe und API-Kommunikation, soweit technisch verfügbar.
(2) Speicherung: Verschlüsselung at rest wird dort genutzt, wo Provider/Plattform dies bereitstellen; für Guventa-eigene Systeme wird Verschlüsselung nach Stand der Technik eingesetzt, soweit technisch und wirtschaftlich angemessen.
(3) Schlüsselmanagement: API-Keys, Tokens und Secrets werden getrennt von Quellcode gespeichert; Secrets werden in sicheren Umgebungen verwaltet.

2.5 Protokollierung, Monitoring und Nachvollziehbarkeit

(1) Sicherheitsrelevante Ereignisse werden protokolliert, insbesondere: Admin-Logins, Rechteänderungen, sicherheitsrelevante Konfigurationsänderungen, ungewöhnliche Zugriffsmuster, kritische Fehlerereignisse.
(2) Monitoring ist risikobasiert und indikatorbasiert; Guventa schuldet keine laufende inhaltliche Kontrolle von Kampagnen oder Einwilligungsnachweisen, reagiert jedoch auf technische/statistische Auffälligkeiten gemäß AUP und AGB.
(3) Consent-Logging: Ab dem 25. Februar 2026 wird die Consent-Entscheidung zentral auf EU-Infrastruktur (Hetzner) protokolliert und zur Nachweisführung bis zu drei Jahre gespeichert, soweit erforderlich.

2.6 Datensicherung und Wiederherstellbarkeit

(1) Backup-Strategie für Guventa-eigene Systeme: regelmäßige Datensicherungen, Wiederherstellungstests nach Risikolage und Change-Zyklen.
(2) Plattformdaten innerhalb HighLevel/LeadConnector folgen den jeweiligen Providermechanismen; Guventa kann Backups/Exports im Suspendierungsfall vertraglich ausschließen, soweit vereinbart.
(3) Wiederherstellungsziele (RTO/RPO) sind abhängig von Systemkomponente und Provider; eine Garantie für Drittanbieter-Verfügbarkeit wird nicht zugesichert.

2.7 Schwachstellenmanagement und Patch-Prozesse

(1) Systeme werden regelmäßig aktualisiert; kritische Sicherheitsupdates werden priorisiert.
(2) Sicherheitslückenhinweise werden bewertet; bei hohem Risiko werden kurzfristige Maßnahmen umgesetzt (z. B. Deaktivierung, WAF-Regeln, Konfigurationshärtung).

2.8 Secure Configuration und Hardening

(1) Standard-Hardening für Guventa-eigene Server: Firewall-Regeln, minimaler Service-Footprint, restriktive Ports, administrative Zugänge nur über gesicherte Verfahren.
(2) Cloudflare kann als Edge-Schutzschicht eingesetzt werden (WAF, DDoS, Rate-Limits), sofern Guventa Systeme direkt über Cloudflare betreibt.

2.9 Datenminimierung und Zweckbindung

(1) Guventa verarbeitet Daten nur im erforderlichen Umfang für Plattformbetrieb, Support, Abrechnung und Sicherheit.
(2) Analyse- und Marketing-Technologien sind consent-gebunden; ohne Einwilligung erfolgt keine Aktivierung nicht notwendiger Tracking-Technologien, soweit technisch steuerbar.

3. Organisatorische Sicherheitsmaßnahmen (TOM) – Prozesse

3.1 Vertraulichkeit und Mitarbeiterschulung

(1) Mitarbeitende und Auftragnehmer werden auf Vertraulichkeit verpflichtet; Zugriff erfolgt nach Rolle und Bedarf.
(2) Sensibilisierung: regelmäßige Security-Basics (Phishing, Passwortmanager, MFA, Datenminimierung, Incident-Meldung).

3.2 Incident Response und Datenschutzverletzungen

(1) Guventa betreibt einen Incident-Prozess zur Erkennung, Eindämmung, Analyse und Nachbereitung sicherheitsrelevanter Ereignisse.
(2) Meldungen an Verantwortliche erfolgen gemäß AVV, unverzüglich und fristorientiert; die Meldung an Behörden/Betroffene obliegt dem Verantwortlichen.
(3) Forensik/Containment kann temporäre Maßnahmen erfordern (Kill-Switch, Funktionssperre, API-Block, Rate-Limits).

3.3 Change- und Release-Management

(1) Änderungen an produktiven Systemen werden dokumentiert, risikobasiert geprüft und möglichst außerhalb kritischer Betriebszeiten umgesetzt.
(2) Rollback-Strategien werden nach Systemkritikalität vorgesehen.

3.4 Lieferanten- und Subprozessor-Management

(1) Subprozessoren werden anhand Risiko, Vertragslage und Sicherheitsstandards ausgewählt; Nachweise wie ISO 27001/SOC 2 werden berücksichtigt, sofern verfügbar.
(2) Drittlandtransfers werden nach Mechanismen abgesichert: DPF nur sofern zertifiziert, andernfalls SCC + TOM.
(3) Systemkritische Abhängigkeiten werden transparent dokumentiert; selektiver Ausschluss ist technisch ggf. nicht möglich.

3.5 Zugriff auf Kundendaten im Support

(1) Zugriff auf Kundendaten erfolgt nur, soweit zur Leistungserbringung erforderlich; Supportzugriffe werden organisatorisch begrenzt.
(2) Erweiterte Unterstützungsleistungen (Sonderexporte, Sonderanalysen, DSFA-Unterstützung über Standard hinaus) sind kostenpflichtig und bedürfen gesonderter Vereinbarung.

4. KI-spezifische Sicherheits- und Datenschutzkontrollen (No-Train, Retention, Governance)

4.1 Grundsatz No-Train und Retention-Minimierung

(1) Guventa verfolgt das Prinzip „No-Train“: KI-Dienste werden soweit vertraglich und technisch angeboten so genutzt und konfiguriert, dass Eingaben und Ausgaben nicht zum Training allgemeiner Modelle verwendet werden.
(2) Retention wird minimiert; für HighLevel-native KI gilt eine Zero-Data-Retention-Logik gemäß Anbieterzusage, Marketplace/Addons sind hiervon ausgenommen.
(3) KI-Provider und die jeweils relevanten Parameter (Training/Retention/Scope) sind im Subprocessor Register dokumentiert.

4.2 Datenminimierung und Schutz sensibler Inhalte

(1) KI-Eingaben und Ausgaben werden auf das erforderliche Minimum begrenzt; Geheimhaltungsinhalte, Zugangsdaten, Tokens und API-Keys dürfen nicht in KI-Prompts verarbeitet werden.
(2) Kundendetails werden nur verarbeitet, soweit hierfür eine Rechtsgrundlage besteht und die Nutzung im Projekt-/Leistungsumfang vorgesehen ist.

4.3 Menschliche Kontrolle und Output-Use

(1) KI-Ausgaben werden als Assistenz betrachtet; verbindliche Entscheidungen werden durch natürliche Personen getroffen.
(2) Bei KI-gestützter externer Kommunikation gelten Kennzeichnungs- und Einwilligungsanforderungen gemäß AUP.

5. TOM-Anlage nach Art. 32 DSGVO (Mapping)

5.1 Maßnahmen zur Vertraulichkeit

(1) Zugriffskontrolle durch Rollen/Rechte, MFA, Need-to-Know, getrennte Admin-Konten.
(2) Transportverschlüsselung (TLS), sichere Secret-Verwaltung, Logging sicherheitsrelevanter Zugriffe.
(3) Vertraulichkeitsverpflichtung, Supportzugriff organisatorisch begrenzt.

5.2 Maßnahmen zur Integrität

(1) Protokollierung von Admin-Aktionen, Konfigurationsänderungen, sicherheitsrelevanten Ereignissen.
(2) Change-Management, Vier-Augen-Prinzip soweit organisatorisch möglich bei kritischen Änderungen.
(3) Schutz vor unbefugter Veränderung durch Berechtigungskonzept und Härtung.

5.3 Maßnahmen zur Verfügbarkeit und Belastbarkeit

(1) Backup/Wiederherstellungsprozesse für Guventa-eigene Systeme; providerabhängige Resilienz für HighLevel/LeadConnector.
(2) DDoS/WAF/Rate-Limits über Cloudflare, soweit eingesetzt.
(3) Incident-Prozess, um Störungen zu erkennen und zu begrenzen; Kill-Switch gemäß AUP.

5.4 Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung

(1) Regelmäßige Review-Zyklen: Subprozessor-Review, Rechte-Review, TOM-Review, Incident-Postmortems.
(2) Risikobewertungen bei wesentlichen Änderungen und neuen Integrationen.
(3) Dokumentation von Maßnahmen und Nachweisen im Rahmen der Governance.

6. Daten-Lifecycle, Export und Suspendierung (technisch-organisatorisch)

(1) Daten-Lifecycle folgt den vertraglichen Regeln (AGB/AVV): Soft-Suspendierung, Aufbewahrung bis zu 90 Tage, anschließende Löschung; Add-ons können nach 30 Tagen getrennt/gekündigt werden.
(2) Während Suspendierung besteht kein Anspruch auf Backup/Export durch Guventa; Kunden sind für rechtzeitige Exporte verantwortlich, soweit Funktionen verfügbar sind.

7. Kontakt für Sicherheitsmeldungen

(1) Sicherheits- oder Datenschutzmeldungen können an [email protected] gerichtet werden; für dringende Sicherheitsvorfälle kann Guventa zusätzlich einen dedizierten Incident-Kanal benennen.