Technische und organisatorische Maßnahmen

1. Vertraulichkeit (Art. 32 Abs. 1 lit. b DSGVO)

1.1 Zutrittskontrolle

Server­hosting in einem nach ISO/IEC 27001 zertifizierten Rechenzentrum eines deutschen Hosting-Anbieters mit elektronischer Zutritts­kontrolle, Videoaufzeichnung, Alarmierung und 24/7-Sicherheits­personal. Eine physische Zutritts­möglichkeit für Mitarbeitende des Plattform­betreibers besteht nicht.

1.2 Zugangskontrolle

• Passwordless Authentifizierung für Endbenutzer (Magic-Link & Einmalcode per E-Mail)
• Verwaltungs­zugriffe ausschließlich über SSH mit Public-Key-Authentifizierung
• Mehr-Faktor-Authentifizierung (2FA) verpflichtend für Berater- und Admin-Konten(TOTP via Authenticator-App zuzüglich Backup-Codes); für Mitglieder optional und empfohlen
• Brute-Force-Schutz durch Login-Limits, IP-Sperren bei Fehlversuchen
• Rate-Limiting auf API-Endpoints
• Automatischer Session-Logout nach Inaktivität
• IP-Whitelisting für Administrations­oberflächen aus festgelegten Firmen­netzen

1.3 Zugriffskontrolle

• Rollen- und Rechte­system (Mitglied, Berater, Admin) mit Trennung der Datenbestände pro Kanzlei (Mandanten­fähigkeit)
• Verschwiegenheits­verpflichtung aller Mitarbeitenden mitausdrücklicher Belehrung über die strafrechtlichen Folgen nach § 203 StGB sowie nach Art. 28 Abs. 3 lit. b DSGVO und entsprechend § 62a StBerG; Details siehe Anlage 3 zum AVV
• Need-to-Know-Prinzip bei internen Datenzugriffen
• Audit-Logaller administrativen und sicherheits­relevanten Aktionen mit Zeitstempel, Akteur, pseudonymisierter IP-Adresse und verkürztem User-Agent; Retention 12 Monate; getrennt von den normalen Webserver-Logs gespeichert
• Trennung zwischen Produktiv- und Test/Staging-Umgebung

1.3a Berechtigungs- und Zugriffskonzept für Administratoren

Administrative Zugriffe sind in drei voneinander getrennte Kategorien aufgeteilt; die Trennung ist organisatorisch und technisch abgesichert:

1. Technische Wartung (Datenbank-Migrationen, Deployment, Monitoring, Backup-Betrieb): erfolgtohne direkten Zugriff auf entschlüsselte Inhaltsdatender Kanzleien/Mitglieder. Alle Wartungstätigkeiten werden protokolliert.
2. Supportzugriffauf konkrete Inhaltsdaten: ausschließlich nach dokumentierter Anforderung der Kanzlei, beschränkt auf das anlassbezogen Erforderliche, vollständig im Audit-Log protokolliert (Zeitstempel, Akteur, betroffener Datensatz, Zweck) und auf Verlangen der Kanzlei nachweisbar.
3. Inhaltsbezogener Notfallzugriff (Break-Glass): ausschließlich bei akutem Sicherheitsvorfall oder zwingender Rechtspflicht. Erfolgt im Vier-Augen-Prinzip(zweite berechtigte Person gibt frei), vollständig protokolliert; die betroffene Kanzlei wird innerhalb von 72 Stunden nach Inanspruchnahme informiert.

• Persönliche Admin-Accounts ohne Account-Sharing; Pflicht-2FA (siehe 1.2)
• Trennung von Benutzerkonto und Sudo-/Privileg-Rolle
• Halbjährliche Berechtigungsreviews dokumentiert (siehe 4.5)

Reichweite der Aussage „kein Zugriff auf entschlüsselte Inhaltsdaten“:Bezieht sich auf die mit AES-256-GCM verschlüsselte Dateiablage (Belege, Dokumente, Identifizierungsdokumente). PostgreSQL-Inhalte (Stammdaten, Nachrichten, Aufgaben, Audit-Logs) sind derzeit nicht spaltenweise verschlüsselt; technische Wartung und Break-Glass-Zugriffe können diese im Klartext sehen. Schutzmaßnahmen: getrennte PostgreSQL-Rollen (Anwendungsrolle, Read-Only-Reporting-Rolle, Admin-Rolle); kein generischer SELECT-Zugrifffür reguläre Admins — DB-Dumps und Inhaltsabfragen nur im Break-Glass-Modus mit Vier-Augen-Freigabe und Protokollierung; alle Inhaltszugriffe auf die DB werden im Audit-Log und Server-Log dokumentiert. Geplante Maßnahme Q3/Q4 2026: spaltenweise Verschlüsselung oder LUKS-/dm-crypt-Volume-Encryption.

1.4 Trennungs­kontrolle

• Logische Mandanten­trennung (Kanzlei-Scope) auf Datenbank- und Anwendungsebene
• Cross-Tenant-Zugriffe sind technisch unterbunden und werden durch Tests abgesichert
• Eigene Verschlüsselungs­schlüssel pro Datei (Initialisierungs­vektor je Beleg)

1.5 Pseudonymisierung und Verschlüsselung

• Dateiablage:Verschlüsselung der gespeicherten Dokumente (Belege, Identifizierungsdokumente, Anhänge) mit AES-256-GCM (separater Initialisierungsvektor je Datei).
• Datenbank (Ist-Zustand — ehrliche Darstellung): Die PostgreSQL-Datenbank ist derzeit nicht spaltenweise verschlüsselt. Der Schutz der Datenbankinhalte erfolgt aktuell über: (a) Netzwerksegmentierung — die Datenbank ist ausschließlich im internen Docker-Netz erreichbar und nicht von außen zugänglich; (b) restriktive Datenbank-Zugangskontrolle nach dem Prinzip der minimalen Rechte (separate Rollen mit eigenen Passwörtern; Anwendungs-Konto ohne DDL-Rechte); (c) Betriebssystem-Härtung der Datenbank-Hosts; (d) GPG-AES-256-verschlüsselte Backups auf physisch getrennten Storage-Box-Sub-Accounts; (e) physische Sicherheit des Rechenzentrums (ISO/IEC 27001-zertifiziert).
• Geplante Maßnahme (Q3/Q4 2026): Prüfung und Einführung einer at-rest-Verschlüsselung auf Volume- bzw. Filesystem-Ebene (LUKS/dm-crypt) für die Datenbank-Volumes.
• Transport­verschlüsselung über TLS 1.2 oder TLS 1.3 nach Stand der Technik
• HTTP-Strict-Transport-Security (HSTS) konfiguriert mit max-age=31536000; includeSubDomains. Eine Preload-Submission an die Browser-HSTS-Preload-Liste ist vorgesehen, derzeit jedoch noch nicht aktiv.
• Datenbank­passwörter, API-Schlüssel und Tokens werden verschlüsselt abgelegt; SMTP-Passwörter ebenfalls verschlüsselt
• Reduzierung personenbezogener Bestandteile in Webserver-Logs: IPv4 wird auf /24, IPv6 auf /48 gekürzt; der User-Agent wird auf Produktfamilie und Major-Version verkürzt. Dies stellt einePseudonymisierung im Sinne von Art. 4 Nr. 5 DSGVOdar und keine vollständige Anonymisierung. Webserver-Log-Retention: 14 Tage.

2. Integrität (Art. 32 Abs. 1 lit. b DSGVO)

2.1 Weitergabe­kontrolle

• Datenübertragungen ausschließlich verschlüsselt (TLS) und nur an autorisierte Empfänger
• Drittlandtransfer:Keine Mandanten- und Geschäftsinhalte verlassen Deutschland. Ausnahmen technischer Natur: (a) optionale Web-Push-Benachrichtigungen über die Push-Dienste der Browser-Hersteller (Google LLC USA, Mozilla Foundation USA, Apple Inc. USA) — nur auf ausdrückliche Einwilligung der Nutzenden, mit Ende-zu-Ende-verschlüsselten Push-Payloads, Transfergrundlage Art. 49 Abs. 1 lit. a DSGVO bzw. EU-US Data Privacy Framework, sofern zertifiziert; (b) ACME-Zertifikatsausstellung durch Let’s Encrypt (Internet Security Research Group, USA) — verarbeitet ausschließlich öffentliche Domainnamen.
• Prüfung jedes Uploads auf Schad­software in Echtzeit (Echtzeit-Virenscan)
• Validierung von Datei­signaturen (Magic-Bytes), nicht nur browser­gemeldeter MIME-Typen
• Begrenzte Dateigrößen je Upload

2.2 Eingabe­kontrolle

• Audit-Log für Änderungen an Mitglieder­daten, Aufgaben, Belegen, Unterschriften, Steuer­daten und Konten
• Nachvollziehbarkeit, wer welche Änderung wann durchgeführt hat (mit IP-Adresse, User-Agent)
• Versions­historie wichtiger Datensätze, soweit fachlich erforderlich
• Vollständige Protokollierung von Anmelde­versuchen (erfolgreich und fehlgeschlagen)

3. Verfügbarkeit und Belastbarkeit (Art. 32 Abs. 1 lit. b und c DSGVO)

3.1 Verfügbarkeits­kontrolle

• Backup-Konzept:RPO ≤ 24 h (tägliche Vollsicherung), RTO ≤ 4 h. Retention: 14 tägliche, 8 wöchentliche und 6 monatliche Sicherungen. GPG-AES-256-verschlüsselte Backups in getrennten Storage-Box-Sub-Accounts, physisch getrennt von der Produktivumgebung.
• Restore-Tests vierteljährlich, dokumentiert.
• Redundante Strom- und Netzwerk­anbindung im Rechenzentrum (Verantwortung Hetzner)
• Externes Uptime-Monitoring mit Benachrichtigung der Bereitschaft
• DDoS-Schutz: Netzwerk-Ebene durch vorgelagerten Schutz des Hosting-Providers; Anwendungsebene durch Rate-Limits in nginx/Caddy.
• Schutz vor SQL-Injection:ausschließlich Prisma-ORM mit Parameter-Binding; keine String-Konkatenation in SQL-Statements.
• Schutz vor Cross-Site-Scripting (XSS): React Auto-Escaping; Content-Security-Policy mit default-src 'self' und ohne unsafe-inline.
• Schutz vor CSRF: SameSite=Strict in Authentication-Cookies, httpOnly-Cookies, getrennte API-Origin.
• Security-Header: HSTS, X-Frame-Options DENY, Referrer-Policy strict-origin-when-cross-origin, restriktive Permissions-Policy.
• Dependency-Scanning: npm audit im CI sowie GitHub Dependabot/Snyk (in Aufbau).
• Penetrationstest:Status — ein externer Penetrationstest ist für das zweite Halbjahr 2026 vorgesehen; bis dahin wird das System durch interne Code-Reviews und Vulnerability-Scans abgesichert.

3.2 Rasche Wiederherstellbarkeit (Art. 32 Abs. 1 lit. c DSGVO)

• Wiederherstellungs­konzept für Datenbank und Datei­speicher
• Dokumentierte Verfahren für Störungs­fälle
• Automatisierte Bereitstellung der Produktiv­umgebung aus Konfiguration (Infrastructure-as-Code)

4. Verfahren zur regelmäßigen Überprüfung (Art. 32 Abs. 1 lit. d DSGVO)

4.1 Datenschutz-Management

• Datenschutz­richtlinie und Schulung der Mitarbeitenden
• Führung eines Verzeichnisses von Verarbeitungs­tätigkeiten nach Art. 30 DSGVO
• Prüfung neuer Verarbeitungs­tätigkeiten auf Notwendigkeit einer Datenschutz-Folge­abschätzung (Art. 35 DSGVO)
• Zentrale Verwaltung von Auftrags­verarbeitungs­verträgen

4.2 Vorfall-Reaktions-Management

• Dokumentierter Prozess zur Erkennung, Eindämmung und Meldung von Datenschutz­verletzungen
• Meldepflicht innerhalb von 48 Stunden an den Auftraggeber gemäß AVV
• Forensik-Sicherung relevanter Logs

4.3 Datenschutz­freundliche Voreinstellungen (Privacy-by-Default)

• Restriktivste Datenschutz­einstellungen sind Standard
• Module werden nur freigeschaltet, wenn die Kanzlei sie aktiv aktiviert
• Mitgliedern werden nur die Funktionen angezeigt, für die ihre Kanzlei diese freigeschaltet hat
• Keine Cookies oder externen Ressourcen, die nicht zwingend für den Betrieb erforderlich sind
• Keine Drittanbieter­analyse-Tools (Google Analytics, Matomo o.ä.) im Produktiv­system

4.4 Datenschutz durch Technikgestaltung (Privacy-by-Design)

• Verschlüsselung sensibler Daten bereits beim Schreiben auf den Speicher
• Webserver-Logs reduziert um personenbezogene Bestandteile (IPv4 /24, IPv6 /48, verkürzter User-Agent) im Sinne einer Pseudonymisierung nach Art. 4 Nr. 5 DSGVO
• Auto-Lock der Sitzung nach Inaktivität
• Kein Speichern von Klartext-Passwörtern (Passwordless-Auth)
• Sichere Voreinstellungen aller Sicherheits­header (Content-Security-Policy, X-Frame-Options, Referrer-Policy etc.)

4.5 Vulnerability-, Patch- und Berechtigungsmanagement

• CVE-Scanswöchentlich auf Abhängigkeiten und Container-Images
• Patch-SLA:kritisch ≤ 72 h, hoch ≤ 7 Tage, mittel ≤ 30 Tage
• Berechtigungsreviewshalbjährlich (Mitarbeitende, Administratoren, technische Konten)
• Lieferanten-Reviewsjährlich (Auftrags­verarbeiter, kritische Open-Source-Komponenten)
• Notfall­übungen(Tabletop-Exercises) jährlich
• Incident-Runbooksdokumentiert (Erkennung, Eindämmung, Forensik, Kommunikation, Wiederherstellung)

4.6 NIS-2-Statuseinschätzung (Stand Mai 2026)

Das NIS-2-Umsetzungsgesetz(BSI-Gesetz n. F.) ist am 06.12.2025in Kraft getreten. Für die Steuer-Online MF GmbH wurde folgende Einschätzung getroffen:

• Einrichtungsart:digitaler Dienst / SaaS-Anbieter im Sinne § 28 BSI-G n. F.
• Mitarbeiterzahl: unter 50 (Kleinstunternehmen).
• Jahresumsatz/Bilanzsumme:unter den NIS-2-Schwellen (10 Mio. EUR / 10 Mio. EUR).
• Konzernbetrachtung:Steuer-Online MF GmbH ist eigenständige Gesellschaft; keine konsolidierte Konzernzurechnung, die die Schwelle überschreiten würde.
• Ergebnis:Nach aktueller Einschätzung nichtunter NIS-2-Umsetzungsgesetz (BSI-G n. F.) erfasst, weil keine der Schwellen erreicht wird und auch keine der besonderen Einrichtungsarten ohne Schwellenwertgrenze (z. B. qualifizierter Vertrauensdiensteanbieter, DNS, TLD-Registry) einschlägig ist.
• Datum der Prüfung:Mai 2026.
• Nächste Überprüfung: jährlich oder bei wesentlicher Veränderung (Umsatz/Mitarbeiterzahl, neue Einrichtungsart, gesetzliche Änderung).

Hinweis: Sollte die Steuer-Online MF GmbH künftig in den NIS-2-Anwendungsbereich fallen, werden Registrierung beim BSI nach § 28 BSI-G n. F., Risikomanagement nach § 30, Meldepflichten nach § 32 sowie Governance-Maßnahmen unverzüglich umgesetzt.

5. Löschung und Rückgabe von Daten

• Mitglieder können einen Export ihrer persönlichen Daten direkt über das Portal anfordern (Art. 20 DSGVO)
• Löschungs­anträge werden innerhalb der gesetzlichen Fristen umgesetzt, soweit keine Aufbewahrungspflicht entgegensteht
• Kryptografische Löschung (Crypto-Erase): Bei Anforderung wird der zugehörige Data Encryption Key vernichtet, was die zugehörigen Chiffrate unzugänglich macht. Ein physisches Überschreiben in Cloud-, SSD- oder Backup-Umgebungen wird nicht garantiert; siehe auch Backup-Retention.
• Archiv-Abgrenzung: KOSI Portal ist eine Transport- und Arbeitsplattform und kein revisionssicheres Archivim Sinne der GoBD oder § 147 AO. Die Erfüllung gesetzlicher Aufbewahrungspflichten (§ 147 AO, § 257 HGB, Berufsrecht) obliegt der Kanzlei bzw. Beratungsstelle und dem Mandanten in den jeweils dafür vorgesehenen Steuer- und DMS-Systemen.
• Daten werden im Portal nach Weisung der Kanzlei oder spätestens 12 Monate nach Abschluss des Steuerjahres aus der aktiven Datenhaltung gelöscht. Backups werden nach dem dokumentierten Backup-Zyklus überschrieben/ gelöscht; eine sofortige selektive Löschung aus unveränderlichen Backups ist technisch nicht zugesagt. Aus Backups wiederhergestellte Daten unterliegen den vertraglichen Lösch- und Aufbewahrungsregeln.
• Nach Vertragsende werden Daten gemäß AVV gelöscht oder zurückgegeben. Eigene gesetzliche Aufbewahrungspflichten des Auftragnehmers (z. B. Rechnungsbelege, Audit-Logs) bleiben unberührt.

6. Eingesetzte Sub-Auftrags­verarbeiter

Die aktuellen externen Sub-Auftrags­verarbeiter sind in der Anlage 2 zum AVV (Hetzner Online GmbH — Hosting; 1&1 IONOS SE — SMTP; seven communications GmbH & Co. KG — optionaler SMS-Versand) sowie in der Datenschutzerklärung aufgeführt.

Interne Verarbeitungssysteme der Steuersoft-Gruppe (Videoberatung, OCR-/Beleg-Erkennung, Zahlungs-Wrapper) werden auf eigener Infrastruktur in Deutschland betrieben und sind keine externen Sub-Auftragsverarbeiter.

Technische Drittkontakte ohne Mandantendatenzugriff: Im Rahmen der Ausstellung von TLS-Zertifikaten für die öffentlich erreichbaren Domains (ACME-Protokoll) findet ein technischer Kontakt zu Let’s Encrypt(Internet Security Research Group, USA) statt. Verarbeitet werden hierbei ausschließlich öffentlich auflösbare Domainnamen(z. B. kosi-portal.de) sowie der bei der Ausstellung erzeugte öffentliche Schlüssel. Eine Übermittlung von Mandanten- oder Geschäftsdaten findet nichtstatt; Let’s Encrypt ist daher kein Sub-Auftragsverarbeiterim Sinne von Art. 28 DSGVO.

Drittlandtransfers:Keine Mandanten- und Geschäftsdaten verlassen Deutschland. Im Rahmen der ACME-Zertifikatsausstellung mit Let’s Encrypt (USA) werden ausschließlich öffentliche Domainnamen verarbeitet.

7. Auditierung und Überprüfung

Die hier beschriebenen Maßnahmen werden regelmäßig sowie anlassbezogen überprüft und an aktuelle Bedrohungslagen, neue Sicherheits­standards und geänderte rechtliche Anforderungen angepasst. Wesentliche Änderungen werden dem Auftraggeber gemäß AVV § 4 in Textform mitgeteilt.

Der Auftraggeber hat das Recht zur Überprüfung dieser Maßnahmen nach Maßgabe des AVV § 8.

8. Änderungshistorie

• Mai 2026 — Initial­version anlässlich Go-Live von kosi-portal.de. Inhalte abgeleitet aus Sicherheits-Konfiguration des Produktiv­systems und vorhandener Privacy-Logging-Konvention.