Wie bindet man externe Systeme an ERP, CRM oder andere Unternehmenssoftware an?

Eine externe Anwendung lässt sich über einen Standardconnector, eine Programmierschnittstelle (API) oder eine Integrationsplattform mit einem ERP-, CRM- oder Buchhaltungssystem verbinden. Entscheidend ist jedoch nicht allein, ob Daten technisch übertragen werden können. Die Anbindung muss zuverlässig funktionieren, fachlich korrekte Informationen liefern und auch nach Softwareupdates, Personalwechseln oder Änderungen beim Drittanbieter beherrschbar bleiben.

Für Schweizer KMU wird diese Aufgabe besonders anspruchsvoll, wenn mehrere Anbieter beteiligt sind: das Unternehmen selbst, der ERP-Hersteller, ein Integrationspartner und beispielsweise ein externer Logistik-, Zahlungs- oder Treuhanddienstleister. Ohne klare Zuständigkeiten kann eine kleine Änderung an einer Schnittstelle einen gesamten Geschäftsprozess beeinträchtigen.

Eine tragfähige Integration beginnt deshalb mit einem Inventar bestehender Verbindungen, eindeutig definierten Datenflüssen und einer schriftlichen Schnittstellenspezifikation. Dazu kommen begrenzte Zugriffsrechte, überprüfbare Sicherheitsvorgaben und ein Wartungskonzept. So entsteht keine isolierte technische Verbindung, sondern ein kontrollierbarer Bestandteil der Unternehmensprozesse.

Warum Schnittstellen zu externen Systemen häufiger ausfallen als erwartet

Externe Schnittstellen fallen aus, wenn sich beteiligte Systeme verändern, Datenfelder unterschiedlich interpretiert werden oder niemand die gesamte Verbindung verantwortet. Besonders problematisch sind Fehler, bei denen Daten weiterhin übertragen werden, aber fachlich falsch ankommen. Solche Störungen bleiben häufig länger unbemerkt als ein vollständiger Verbindungsabbruch.

Eine Systemintegration verbindet nicht bloss zwei technische Endpunkte. Sie verknüpft unterschiedliche Datenmodelle, Geschäftsregeln, Berechtigungen und Betriebsprozesse. Ein ERP-Anbieter kann seine API aktualisieren, während die externe Partnerplattform weiterhin mit der bisherigen Struktur arbeitet. Auch geänderte Feldlängen, neue Pflichtfelder oder ein anderes Statusmodell können bestehende Abläufe beeinträchtigen.

Die Microsoft-Dokumentation zur API-Gestaltung und Versionierung beschreibt APIs als Verträge zwischen Diensten und ihren Nutzern. Rückwärtskompatibilität und kontrollierte Versionswechsel sind deshalb zentrale technische Voraussetzungen für wartbare Integrationen.

Im Betrieb lassen sich zwei Fehlerarten unterscheiden:

• Sichtbare Fehler: Eine Anfrage wird abgewiesen, eine Übertragung bricht ab oder ein Auftrag bleibt mit einer Fehlermeldung stehen.
• Stille Fehler: Ein Datensatz wird erfolgreich bestätigt, obwohl eine Kundennummer falsch zugeordnet, ein Betrag abgeschnitten oder ein Rechnungsstatus falsch interpretiert wurde.

Ein hypothetisches Beispiel: Eine externe Bestellplattform liefert nach einem Update einen zusätzlichen Rabattwert. Der bestehende Connector verarbeitet weiterhin die Bestellung, ignoriert jedoch dieses Feld. Die technische Übertragung erscheint erfolgreich, während der Rechnungsbetrag im ERP vom ursprünglichen Auftrag abweicht.

Solche Fehler lassen sich nicht allein anhand des HTTP-Statuscodes erkennen. Zusätzlich braucht es fachliche Plausibilitätsprüfungen, beispielsweise einen Abgleich von Auftragswerten, Datensatzanzahlen oder Zahlungsstatus.

Ein weiteres Risiko entsteht beim Softwarewechsel. Wird ein neues CRM eingeführt, aber die bestehende Verbindung zu einer Partnerplattform nicht inventarisiert, können Informationen weiterhin im Altsystem landen. Dadurch entstehen neue Dateninseln statt eines durchgängigen Prozesses.

Organisatorisch verschärft sich die Situation, wenn jeder Beteiligte nur seine eigene Komponente betreut. Der ERP-Anbieter bestätigt einen funktionierenden Endpunkt, der Integrator verweist auf die externe Plattform und die interne IT sieht lediglich fehlende Daten. Ohne End-to-End-Verantwortung bleibt die Ursache ungeklärt.

Die wichtigste Gegenmassnahme ist deshalb eine Kombination aus dokumentierten API-Abhängigkeiten, fachlichen Kontrollwerten und einer benannten Person, die den gesamten Datenfluss überwacht. Damit ist die Grundlage für eine klare Projektorganisation geschaffen.

Wie man eine externe Systemanbindung ohne unklare Verantwortlichkeiten plant

Eine externe Systemanbindung wird zuverlässig planbar, wenn vor Projektbeginn alle beteiligten Schnittstellen erfasst, die Verantwortlichkeiten schriftlich verteilt und die erwarteten Datenflüsse eindeutig spezifiziert werden. Dazu gehören technische Ansprechpartner, Zuständigkeiten für Datenmapping und Tests sowie ein Eskalationsweg für Störungen. Diese Vereinbarungen müssen über die Inbetriebnahme hinaus gelten.

Den Ausgangspunkt bildet ein Schnittstelleninventar. Darin werden bestehende und geplante Verbindungen mit Quell- und Zielsystem, Datenrichtung, technischer Betriebsart, verantwortlicher Stelle und geschäftlicher Kritikalität dokumentiert.

Für ein Schweizer KMU mit interner IT, ERP-Anbieter und externem Integrator kann eine einfache Verantwortlichkeitsmatrix bereits viele Unklarheiten beseitigen. Die konkrete Zuordnung hängt davon ab, welche Kompetenzen im Unternehmen vorhanden sind.

Eine Matrix allein genügt nicht. Die Schnittstellenspezifikation sollte Feldtypen, Pflichtwerte, zulässige Statuswechsel, Fehlercodes, Wiederholungsversuche und Regeln gegen doppelte Verarbeitung enthalten. Ebenso wichtig sind Testfälle für unvollständige Daten, Zeitüberschreitungen und Systemausfälle.

Im Vertrag mit dem Integrationspartner sollten Leistungsumfang, Dokumentationspflichten, Wartungszuständigkeit, Reaktions- und Eskalationswege, Änderungsverfahren sowie Übergabepflichten bei Vertragsende geregelt werden. Wer Updates des Drittanbieters bewertet und bezahlt, sollte ausdrücklich feststehen.

Ein praxistauglicher Eskalationspfad beginnt beim Fachbereich, der eine Abweichung meldet. Die verantwortliche IT-Stelle prüft Übertragungsprotokolle und ordnet den Fehler einem technischen oder fachlichen Bereich zu. Danach übernimmt der zuständige Anbieter oder Integrator die Bearbeitung, während eine benannte interne Stelle die Lösung bis zum erfolgreichen Nachtest verfolgt.

Erst wenn diese organisatorischen und fachlichen Anforderungen feststehen, lässt sich sinnvoll entscheiden, ob ein vorhandener Connector genügt oder eine individuelle API-Anbindung erforderlich ist.

Standardintegration oder individuelle API: Was passt zu komplexen Anforderungen?

Eine Standardintegration eignet sich für weitgehend unveränderte Geschäftsprozesse, unterstützte Softwareversionen und eine ausreichende Abdeckung der benötigten Datenfelder. Eine individuelle API-Anbindung wird sinnvoll, wenn besondere Datenstrukturen, komplexe Prozessregeln oder zusätzliche Integrationsschritte erforderlich sind. Die Entscheidung sollte sich an Funktionsumfang, Änderungsrisiken und langfristiger Wartbarkeit orientieren.

Standardconnectoren bieten häufig eine vorbereitete Verbindung zwischen bekannten Anwendungen. Dadurch entfallen Teile der technischen Entwicklung. Individuelle Integrationen können dagegen gezielt auf unternehmensspezifische Datenobjekte und Prozessabläufe abgestimmt werden.

Die folgende Entscheidungsmatrix hilft bei der technischen Vorauswahl. Sie beschreibt typische Eigenschaften, keine allgemeingültigen Produktgarantien.

Die eigentliche Prüfung beginnt beim Feldmapping. Wird beispielsweise eine Auftragsposition mit Projektcode, Kostenstelle, Steuersatz und mehreren Rabatten übertragen, muss der Connector jedes erforderliche Feld korrekt abbilden können. Eine erfolgreiche Demo mit Kundennamen und Rechnungsnummer reicht nicht aus.

Auch die Gesamtkosten sollten über die Einführung hinaus betrachtet werden. Relevant sind Lizenz- und Entwicklungskosten, Anpassungen nach Anbieterupdates, Fehlersuche, Testaufwand, Dokumentationspflege und die mögliche spätere Ablösung der Verbindung. Ohne konkrete Angebote und einen definierten Betrachtungszeitraum lässt sich daraus kein allgemeiner Kostenvorteil ableiten.

Eine individuell entwickelte API ist keineswegs automatisch flexibler. Sie bleibt an die technischen Möglichkeiten und Versionsentscheidungen des Drittanbieters gebunden. Werden Endpunkte abgeschaltet oder Authentifizierungsverfahren geändert, können umfangreiche Anpassungen erforderlich werden. Ein gut gepflegter Standardconnector kann solche Änderungen unter Umständen mit geringerem internem Aufwand auffangen.

Bei komplexeren Umgebungen kommt eine Integrationsplattform als zusätzliche Architekturvariante infrage. Sie kann Transformation, Überwachung und Fehlerbehandlung zentralisieren, schafft aber selbst eine weitere Komponente mit Kosten, Abhängigkeiten und Betriebsverantwortung.

Ein belastbarer Auswahltest sollte daher echte Geschäftsdaten in einer Testumgebung verarbeiten: neue Datensätze, Änderungen, Fehlerfälle, doppelte Übertragungen und einen simulierten Ausfall. Nicht allein die erfolgreiche Erstübertragung zählt, sondern die wiederholbare fachliche Korrektheit.

Unabhängig von der gewählten Technik braucht jede Verbindung ein eigenes Sicherheitskonzept. Besonders kritisch sind Zugänge, mit denen externe Systeme weitreichende Aktionen im ERP oder CRM ausführen können.

Welche Sicherheitsfehler bei Schnittstellen zu Drittanbietern entstehen?

Bei Drittanbieter-Schnittstellen entstehen Sicherheitsrisiken vor allem durch zu weitreichende Zugriffsrechte, unzureichend geschützte Zugangsdaten, fehlende Protokollierung und vergessene technische Konten. Besonders gefährlich sind Verbindungen, die produktive Unternehmensdaten mit dauerhaft gültigen Zugangsschlüsseln verarbeiten. Jede externe Anbindung braucht deshalb eigenständige Authentifizierungs-, Berechtigungs- und Überwachungskontrollen.

Eine externe Schnittstelle erweitert die Angriffsfläche eines Unternehmens. Werden ihre Zugangsdaten kompromittiert, kann ein Angreifer unter Umständen dieselben Funktionen verwenden wie die angebundene Anwendung. Wie gross der mögliche Schaden ist, hängt von den tatsächlich gewährten Berechtigungen, erreichbaren Systemen und zusätzlichen Sicherheitskontrollen ab.

Die OWASP API Security Top 10 von 2023 beschreibt unter anderem Risiken durch mangelhafte Authentifizierung, unzureichende Autorisierung, fehlerhafte Sicherheitskonfiguration und unvollständige API-Inventare. Auch die unsichere Nutzung fremder APIs gehört zu den dokumentierten Risikokategorien.

Im Unternehmensalltag verdienen insbesondere folgende Fehlkonfigurationen Aufmerksamkeit:

• Dauerhaft gültige API-Schlüssel: Zugangsdaten bleiben über lange Zeit verwendbar, obwohl keine geregelte Rotation oder Sperrung vorgesehen ist.
• Produktive Konten in Testumgebungen: Entwicklungs- und Testsysteme erhalten Zugriff auf echte Kunden-, Personal- oder Finanzdaten, obwohl dies für die Tests nicht notwendig wäre.
• Übermässige Berechtigungen: Ein Connector für den Abruf von Lagerbeständen erhält zusätzlich Schreib-, Lösch- oder Administrationsrechte.
• Ungeschützte Übertragungen: Ältere Anwendungen tauschen sensible Informationen ohne angemessenen Transport- oder zusätzlichen Anwendungsschutz aus.
• Unzureichende Zugriffsprotokolle: Nach einer Veränderung an Daten lässt sich nicht nachvollziehen, welcher technische Zugang die Aktion ausgelöst hat.
• Vergessene Dienstleisterkonten: Nach Abschluss eines Projekts oder Beendigung eines Vertrags bleiben Zugriffsmöglichkeiten bestehen.

Besonders bei Verbindungen zu Treuhändern, Lohnsystemen oder externen Finanzdienstleistern ist eine nachvollziehbare Dokumentation wichtig. Je nach Daten, rechtlichen Anforderungen und internen Kontrollvorgaben müssen Zugriffe, Änderungen und Übertragungen in angemessenem Umfang nachvollzogen werden können.

Dazu sollten Protokolle den betroffenen technischen Zugang, Zeitpunkt, ausgeführte Operation und das Verarbeitungsergebnis erkennen lassen. Sensible Inhalte und Zugangsschlüssel gehören dagegen nicht unkontrolliert in Logdateien. Aufbewahrungsfristen und Zugriffsrechte auf Protokolle müssen zum Schutzbedarf passen.

Als organisatorische Massnahme eignet sich beispielsweise ein quartalsweiser Zugriffsreview. Dabei gleicht die interne IT alle technischen Konten mit dem aktuellen Schnittstelleninventar ab. Nicht mehr benötigte Verbindungen werden deaktiviert, aktive Berechtigungen bestätigt und ausstehende Änderungen dokumentiert.

Diese Prüffrequenz ist eine mögliche betriebliche Sicherheitsmassnahme und keine allgemeine gesetzliche Vorgabe für jedes Schweizer KMU. Kritische Schnittstellen können häufigere Prüfungen erfordern, während weniger sensible Verbindungen anhand einer dokumentierten Risikobeurteilung anders behandelt werden können.

Zusätzlich sollten die Erkennung ungewöhnlicher Zugriffe, die Sperrung kompromittierter Zugangsdaten und das Vorgehen bei einem Sicherheitsvorfall vorab festgelegt werden. Dadurch wird aus einer Sammlung technischer Einzelmassnahmen ein kontrollierter Betriebsprozess.

Eine gut abgesicherte Verbindung benötigt weiterhin Wartung. Sicherheitskontrollen schützen nicht davor, dass eine fachlich überholte oder technisch nicht mehr unterstützte Schnittstelle den Geschäftsprozess beeinträchtigt.

Wann eine Drittanbieter-Schnittstelle angepasst oder ersetzt werden muss

Eine Drittanbieter-Schnittstelle sollte überprüft werden, sobald sich Datenbestände regelmässig unterscheiden, manuelle Korrekturen zunehmen oder der Anbieter wesentliche API-Funktionen verändert. Auch fehlende Dokumentation, veraltete Authentifizierungsverfahren und geänderte Geschäftsprozesse sind Warnsignale. Ob eine Reparatur genügt oder ein vollständiger Ersatz notwendig wird, hängt von Ursache und verbleibender technischer Unterstützung ab.

Ein einzelner Übertragungsfehler ist noch kein Grund, eine komplette Integration neu zu entwickeln. Entscheidend ist, ob der Fehler lokal begrenzt werden kann oder auf eine grundlegende Schwäche der Architektur hinweist.

Für die Diagnose helfen mehrere beobachtbare Indikatoren:

• Nach jeder Synchronisation müssen Datensätze manuell korrigiert werden.
• ERP und externe Plattform weisen wiederkehrende Abweichungen bei Beträgen, Status oder Stammdaten auf.
• Der Softwareanbieter kündigt die Abschaltung einer verwendeten API-Version an.
• Neue Geschäftsprozesse lassen sich mit dem bestehenden Datenmodell nicht mehr korrekt abbilden.
• Fehler werden nur noch durch undokumentierte Eingriffe einzelner Fachpersonen behoben.
• Der ursprüngliche Integrationspartner ist nicht mehr verfügbar und die technische Dokumentation fehlt.

Die passende Massnahme lässt sich anhand von drei Eingriffstiefen bestimmen.

Allgemeingültige Aufwandsspannen wären hier irreführend. Eine scheinbar kleine Mapping-Korrektur kann umfangreiche Prüfungen auslösen, wenn historische Buchungen betroffen sind. Umgekehrt kann ein technischer Neubau überschaubar bleiben, wenn die bestehenden Datenverträge sauber dokumentiert sind.

Vor einer Entscheidung sollte zunächst geprüft werden, ob der Fehler reproduzierbar ist, welche Daten betroffen sind und welche Anpassungen der Anbieter offiziell unterstützt. Anschliessend lassen sich Lösungsvarianten anhand von Entwicklungsaufwand, Betriebsrisiko und Auswirkungen auf abhängige Anwendungen vergleichen.

Besonders wichtig ist die Austauschbarkeit. Wenn eine Integration ausschliesslich über proprietäre Datenfelder und undokumentierte Sonderregeln funktioniert, wird ein späterer Anbieterwechsel erschwert. Dokumentierte Datenmodelle, klar abgegrenzte Transformationsregeln und exportierbare Konfigurationen können dieses Risiko reduzieren.

Auch das vorhandene Wissen muss regelmässig geprüft werden. Mindestens einmal jährlich kann die verantwortliche Stelle bestätigen, ob Architekturunterlagen, Zugangskonzepte, Testfälle und Kontaktpersonen noch aktuell sind. Die genaue Frequenz sollte sich nach Kritikalität und Änderungsdynamik richten.

Ein geplanter Ersatz sollte möglichst mit einer Testphase beginnen, in der alte und neue Ergebnisse anhand derselben Geschäftsfälle verglichen werden. Bei paralleler Verarbeitung muss verhindert werden, dass Aufträge, Rechnungen oder Zahlungen doppelt gebucht werden.

Viele Schwierigkeiten werden bereits bei der ursprünglichen Datenflussplanung angelegt. Wer führende Datenquellen und Änderungsrichtungen sauber definiert, reduziert spätere Abhängigkeiten und aufwendige Korrekturen.

Wie man den Datenfluss zwischen CRM, ERP und Buchhaltung plant

Der Datenfluss zwischen CRM, ERP und Buchhaltung wird pro Geschäftsobjekt geplant. Dabei legt das Unternehmen fest, welches System die massgebliche Datenquelle ist, wohin Informationen übertragen werden und wodurch eine Übertragung ausgelöst wird. Ebenso wichtig sind Konfliktregeln, Fehlerbehandlung und eine fachliche Prüfung, damit Kunden-, Auftrags- und Finanzdaten konsistent bleiben.

Statt einzelne Schnittstellen isoliert zu betrachten, sollte zuerst der gesamte Geschäftsprozess modelliert werden. Ein typischer Ablauf beginnt bei einer Kundenanfrage im CRM und führt über Offerte, Auftrag und Rechnung bis zum Zahlungseingang.

In einer hypothetischen Schweizer KMU-Architektur könnte das CRM Kundengespräche und Verkaufschancen verwalten, das ERP die Auftragsabwicklung übernehmen und die Buchhaltungssoftware die Finanzbuchungen führen.

Damit diese Rollen eindeutig bleiben, ist für jedes Datenobjekt die führende Datenquelle zu bestimmen. Eine mögliche fachliche Zuordnung sieht so aus:

Diese Rollenverteilung ist ein Planungsbeispiel. In einer konkreten Softwarelandschaft können andere Zuständigkeiten sachgerecht sein. Entscheidend ist die eindeutige Festlegung pro Objekt und erforderlichenfalls pro Feld.

Ein häufiger Konstruktionsfehler ist die unkontrollierte bidirektionale Synchronisation. Ändert ein Mitarbeitender die Rechnungsadresse im CRM und ein anderer dieselbe Adresse im ERP, können zeitversetzte Übertragungen die jeweils neueren Werte überschreiben.

Deshalb sollten Konfliktregeln festlegen, welches System für das jeweilige Feld massgeblich ist. Ist tatsächlich eine gemeinsame Bearbeitung erforderlich, braucht es zusätzlich Versionsinformationen, Konflikterkennung und einen definierten Entscheidungsprozess.

Auch das Übertragungsintervall ist bewusst zu wählen. Eine sofortige Synchronisation kann für Auftragsbestätigungen sinnvoll sein. Andere Daten können kontrolliert in periodischen Verarbeitungsläufen übertragen werden. Ausschlaggebend sind Aktualitätsbedarf, Fehlerfolgen und technische Möglichkeiten.

Für die Fehlerbehandlung benötigt jedes Objekt einen nachvollziehbaren Zustand. Wird eine Rechnung nicht angenommen, sollte sie als fehlgeschlagen erkennbar bleiben, ohne bei einem erneuten Versuch unkontrolliert mehrfach angelegt zu werden. Eindeutige Transaktionsreferenzen und geeignete idempotente Verarbeitung helfen, solche Doppelungen zu vermeiden.

In der Schweiz muss die Buchhaltungsanbindung ausserdem zur tatsächlich verwendeten Kontierungslogik passen. Bei Unternehmen, die einen Schweizer KMU-Kontenrahmen einsetzen, sind beispielsweise Kontenzuordnung, Steuerbehandlung und die fachlichen Anforderungen des Treuhänders oder der Revisionsstelle vor der Produktivsetzung abzustimmen.

Ein technischer Test mit erfolgreich übertragenen Datensätzen genügt daher nicht. Die Fachabnahme muss bestätigen, dass Geschäftsvorfälle auch buchhalterisch korrekt verarbeitet werden.

Steht der Datenfluss fest, lässt sich daraus unmittelbar ableiten, welche technischen Konten welche Daten lesen oder verändern dürfen. Diese Zuordnung bildet die Grundlage für minimale Zugriffsrechte.

Wie man das Prinzip der minimalen Rechte im Unternehmensalltag umsetzt

Das Prinzip der minimalen Rechte bedeutet, dass jede Person und jede technische Schnittstelle ausschliesslich die Berechtigungen erhält, die für ihre festgelegte Aufgabe erforderlich sind. Ein Connector zum Abruf von Rechnungen braucht beispielsweise keine Rechte zur Benutzerverwaltung. Berechtigungen sollten dokumentiert, regelmässig überprüft und bei veränderten Aufgaben oder Vertragsenden angepasst werden.

Für externe Systemanbindungen ist die praktische Umsetzung besonders wichtig, weil technische Konten häufig automatisiert und über längere Zeiträume verwendet werden. Werden sie mit allgemeinen Administrationsrechten eingerichtet, kann ein Fehler weit mehr Daten betreffen als für die eigentliche Integration notwendig wäre.

Ein Berechtigungskonzept beginnt deshalb bei den im Datenflussplan beschriebenen Operationen. Für jedes Systemkonto wird geprüft, ob es Daten lesen, erstellen, verändern oder löschen muss.

Eine einfache Rechte-Matrix kann so aussehen:

In der technischen Umsetzung sollten getrennte Dienstkonten verwendet werden, sofern das System dies unterstützt. So lässt sich eine Verbindung unabhängig von anderen Integrationen deaktivieren oder mit neuen Zugangsdaten ausstatten.

Wo eine API fein abgestufte Berechtigungen anbietet, sollten sie auf benötigte Ressourcen und Operationen beschränkt werden. Allgemeine Systemkonten mit uneingeschränktem Zugriff sind zu vermeiden, wenn eine engere Berechtigung möglich ist.

Ein praktischer Konflikt entsteht bei der Fehlersuche. Supportmitarbeitende benötigen gelegentlich vorübergehend zusätzliche Rechte, um eine Störung analysieren zu können. Dauerhafte Administrationsberechtigungen sind dafür keine angemessene Standardlösung.

Stattdessen kann ein kontrollierter Rechteerhöhungsprozess eingesetzt werden: Eine verantwortliche Person genehmigt den zusätzlichen Zugriff für einen dokumentierten Zweck. Die Berechtigung wird zeitlich begrenzt und nach Ablauf automatisch entzogen, sofern die technische Plattform dies unterstützt. Jede Erhöhung sollte nachvollziehbar protokolliert werden.

Minimale Rechte begrenzen ausserdem das mögliche Schadensausmass fehlerhafter Integrationen. Hat ein Connector nur Schreibzugriff auf einen bestimmten Datenbereich, kann ein fehlerhaftes Mapping andere Bereiche nicht unmittelbar über dieselben Berechtigungen verändern. Schäden innerhalb des freigegebenen Bereichs bleiben allerdings möglich.

Beim Wechsel eines Dienstleisters oder beim Offboarding von Mitarbeitenden müssen auch zugehörige technische Konten, Tokens und Berechtigungen überprüft werden. Die Rechte-Matrix ist deshalb ein laufend gepflegtes Betriebsdokument und kein einmaliges Projektartefakt.

Damit ist der technische Zugang abgesichert. Für sensible Unternehmensdaten muss zusätzlich der gesamte Weg der Informationen betrachtet werden, einschliesslich externer Speicherung, internationaler Datenübermittlungen und Löschung.

Wie man sensible Unternehmensdaten in einer vernetzten Softwarelandschaft schützt

Sensible Unternehmensdaten werden geschützt, indem jede Schnittstelle über den gesamten Datenweg abgesichert wird: von der Übertragung über die Verarbeitung und Speicherung bis zur Löschung. Dazu gehören Verschlüsselung, begrenzte Zugriffsrechte, nachvollziehbare Protokolle und vertragliche Vorgaben für Drittanbieter. Bei Personendaten müssen Schweizer Unternehmen zusätzlich die anwendbaren Anforderungen des Datenschutzgesetzes berücksichtigen.

Ein angemessenes Schutzkonzept beginnt mit einer Unterscheidung der betroffenen Informationen. Kunden- und Personaldaten, Lohninformationen, Geschäftsgeheimnisse und technische Betriebsdaten können unterschiedliche Risiken verursachen. Nicht für sämtliche Unternehmensinformationen gelten automatisch dieselben datenschutzrechtlichen Vorgaben.

Bei der Konzeption sollten mindestens vier Schutzebenen berücksichtigt werden.

• Übertragung: Daten müssen beim Austausch zwischen Systemen durch geeignete Transportverschlüsselung und sichere Authentifizierung geschützt werden.
• Zugriff: Das Zielsystem darf Informationen nur den erforderlichen technischen Konten und berechtigten Personen zugänglich machen.
• Nachvollziehbarkeit: Zugriffe, Übertragungsfehler und sicherheitsrelevante Änderungen müssen entsprechend dem Schutzbedarf protokolliert werden.
• Aufbewahrung und Löschung: Für temporäre Daten, Zwischenspeicher und Protokolle sind angemessene Aufbewahrungs- und Löschregeln festzulegen.

Gerade die Zwischenspeicherung wird bei Integrationsprojekten leicht übersehen. Eine externe Plattform kann Datensätze vorübergehend speichern, um fehlgeschlagene Übertragungen erneut zu versuchen. Dadurch entstehen zusätzliche Speicherorte, deren Schutz und Löschung geklärt werden müssen.

Für Schweizer Unternehmen ist das revidierte Datenschutzgesetz (revDSG) relevant, sofern Personendaten bearbeitet werden. Nach den Informationen des EDÖB zur Auftragsdatenbearbeitung bleibt das verantwortliche Unternehmen grundsätzlich für den Datenschutz zuständig, auch wenn es die Bearbeitung an einen externen Auftragsbearbeiter auslagert.

Deshalb sollte geprüft werden, welche datenschutzrechtliche Rolle ein externer Anbieter tatsächlich übernimmt. Nicht jeder Softwarelieferant ist automatisch Auftragsbearbeiter. Entscheidend sind die konkrete Tätigkeit, die verarbeiteten Informationen und die vertragliche Ausgestaltung.

Ist ein Dienstleister Auftragsbearbeiter, sind unter anderem seine sorgfältige Auswahl, angemessene Instruktion und erforderlichenfalls Überwachung relevant. Die vertraglichen Vereinbarungen müssen zur tatsächlichen Datenbearbeitung passen.

Besondere Aufmerksamkeit erfordern Bekanntgaben von Personendaten ins Ausland. Nach den schweizerischen Datenschutzregeln ist zu prüfen, ob der Empfängerstaat einen angemessenen Datenschutz gewährleistet oder ob andere gesetzlich zulässige Voraussetzungen und Schutzgarantien erforderlich sind.

Als mögliche Instrumente kommen unter bestimmten Voraussetzungen vertragliche Datenschutzgarantien oder anerkannte Standarddatenschutzklauseln infrage. Je nach Empfängerland und konkreten Umständen können zusätzliche technische Schutzmassnahmen notwendig sein. Eine Verarbeitung ausserhalb der Schweiz ist nicht grundsätzlich verboten; umgekehrt garantiert ein Serverstandort in der Schweiz allein noch keine vollständige datenschutzrechtliche Konformität.

Für die praktische Prüfung sollten Unternehmen die tatsächlichen Verarbeitungsstandorte, allfällige Unterauftragsbearbeiter, eingesetzten Schutzmechanismen, Zugriffsregelungen und Bedingungen bei Vertragsende kennen. Die datenschutzrechtliche Bewertung muss auf den konkreten Verhältnissen beruhen.

Ein Schutzkonzept muss allerdings auch die betriebliche Verfügbarkeit berücksichtigen. Werden notwendige Integrationen zu stark eingeschränkt, können Mitarbeitende versucht sein, Daten manuell über unkontrollierte Tabellen, lokale Dateien oder private Übertragungswege auszutauschen. Diese Ausweichlösungen können neue Risiken schaffen.

Deshalb sollten sichere und funktionsfähige Übertragungswege gemeinsam mit den betroffenen Fachbereichen gestaltet werden. Ein geregelter Notbetrieb kann beispielsweise festlegen, welche Informationen bei einem Schnittstellenausfall vorübergehend manuell verarbeitet werden dürfen und wie sie später kontrolliert nachgeführt werden.

Für eine erste Schutzanalyse eignet sich ein überschaubares Fragenmodell:

1. Welche Daten werden über diese Verbindung übertragen oder zwischengespeichert?
2. Wie sensibel sind diese Informationen und welche Folgen hätte ein Verlust oder eine Offenlegung?
3. Welche internen und externen Personen oder Systeme können darauf zugreifen?
4. Was geschieht bei einem Ausfall, einer fehlerhaften Verarbeitung oder einem unbefugten Zugriff?

Die dokumentierten Antworten machen Risiken sichtbar und helfen, technische sowie organisatorische Massnahmen zu priorisieren. Bei komplexen Personendatenbearbeitungen ersetzt diese einfache Prüfung jedoch keine gegebenenfalls erforderliche vertiefte datenschutzrechtliche Beurteilung.

Als nächster Schritt sollte für jede geschäftskritische Schnittstelle ein gemeinsamer Abnahmetermin mit IT, Fachbereich und gegebenenfalls Integrationspartner stattfinden. Dabei werden Datenfluss, Berechtigungen, fachliche Testfälle, Störungsverhalten und datenschutzrechtliche Anforderungen anhand der tatsächlichen Konfiguration überprüft. Erst nach dokumentierter Freigabe wird die Verbindung produktiv genutzt oder weiter ausgebaut.