Die Entscheidung SaaS vs. On‑Premise wird in vielen Organisationen erst dann wirklich kritisch, wenn Compliance‑ und Datenhoheitsanforderungen konkret werden: Wo liegen die Daten? Wer hat administrativen Zugriff? Wie wird ein Audit bestanden, ohne dass man sich auf Annahmen verlässt? Und wie kommt man im Zweifel wieder heraus, ohne monatelange Migrationsprojekte unter Zeitdruck?
In der Praxis ist „Cloud oder nicht“ selten die eigentliche Frage. Entscheidend ist, ob das gewählte Betriebsmodell Ihre Anforderungen an Rechtskonformität, Nachweisbarkeit (Audit), Risikosteuerung und betriebliche Beherrschbarkeit erfüllt – über den gesamten Lebenszyklus, nicht nur beim Go‑Live. Dieser Beitrag liefert einen belastbaren Entscheidungsrahmen, der IT‑Leitung, Compliance, Security, Einkauf und Geschäftsführung auf eine gemeinsame Bewertungslogik bringt. Der Fokus liegt auf Umsetzbarkeit, Verantwortlichkeiten und dokumentierbaren Kontrollen.
Begriffe klären: Datenhoheit, Datenresidenz und Shared Responsibility
Datenhoheit meint nicht nur „die Daten liegen bei uns“. Gemeint ist die Fähigkeit, die Nutzung von Daten durchzusetzen: Zugriffe zu steuern, Schlüssel zu kontrollieren, Löschungen nachweisbar auszulösen, Exporte zu ziehen, und bei Konflikten (z. B. behördliche Anfragen) handlungsfähig zu bleiben. Datenresidenz ist enger: sie beschreibt, in welcher Region oder in welchem Land Daten gespeichert und verarbeitet werden.
Bei SaaS wird häufig mit dem Konzept Shared Responsibility gearbeitet: Anbieter und Kunde teilen sich Verantwortlichkeiten. Das ist kein Marketingbegriff, sondern muss in Kontrollen übersetzt werden. Typisch: Der Anbieter verantwortet die Plattform (Rechenzentrum, Basis‑Security, Patching der SaaS‑Applikation), der Kunde verantwortet Identitäten, Rollen, Datenklassifizierung, Berechtigungen, Konfiguration und korrekte Nutzung. Bei On‑Premise liegt die Verantwortung fast vollständig bei Ihnen – dafür sind Nachweise und Eingriffsrechte maximal in Ihrer Hand.
Warum „Compliance“ ohne Audit-Perspektive nicht reicht
Viele Anforderungen sind erst dann erfüllt, wenn sie prüfbar sind: durch interne Revision, externe Auditoren, Kunden‑Audits oder Behörden. Entscheidend ist, ob Sie folgende Fragen sauber beantworten können:
- Welche Kontrollen existieren? (z. B. Zugriffskontrolle, Protokollierung, Schlüsselverwaltung, Backup/Restore)
- Wie werden Kontrollen umgesetzt? (Konfiguration, Prozesse, Verantwortliche)
- Wie wird Wirksamkeit nachgewiesen? (Logs, Reports, Testprotokolle, Change‑Nachweise)
- Wie wird auf Abweichungen reagiert? (Incident‑Prozess, Eskalation, Korrekturmaßnahmen)
Ein SaaS‑Anbieter kann viele Nachweise liefern (z. B. SOC‑Berichte), aber nicht automatisch die für Ihr Unternehmen relevanten. Umgekehrt kann On‑Premise theoretisch alles abdecken, scheitert aber in der Praxis an personellen Kapazitäten, Prozessreife oder fehlender Dokumentation. Der Entscheidungsrahmen muss also beides abbilden: Kontrollierbarkeit und tatsächliche Betriebsfähigkeit.
SaaS vs. On‑Premise: Die wichtigsten Entscheidungsdimensionen
Statt einer pauschalen Pro/Contra‑Liste bewährt sich eine Bewertung entlang stabiler Dimensionen. Jede Dimension wird am Ende in Anforderungen übersetzt, die Sie in RFP, Vertrag und Betrieb verankern können.
1) Datenklassifizierung und Schutzbedarf als Startpunkt
Ohne Datenklassifizierung führen Diskussionen über SaaS vs. On‑Premise zu Bauchentscheidungen. Eine pragmatische Klassifizierung (z. B. öffentlich / intern / vertraulich / streng vertraulich) reicht, wenn sie konsequent genutzt wird. Wichtig ist, den Schutzbedarf festzulegen: Vertraulichkeit, Integrität, Verfügbarkeit und Nachvollziehbarkeit (Audit Trail).
Praxisregel: Je höher der Schutzbedarf, desto stärker müssen technische Kontrolle (z. B. Schlüsselverwaltung) und organisatorische Kontrolle (z. B. Berechtigungsprozesse) ausgeprägt sein. Das kann SaaS erfüllen – aber nur, wenn die angebotenen Mechanismen zu Ihrem Modell passen.
2) Zugriff, Admin-Rechte und Mandantentrennung
In SaaS‑Umgebungen ist die kritischste Frage häufig nicht „kann der Anbieter Daten sehen?“, sondern wer kann unter welchen Bedingungen administrativ eingreifen. Dazu zählen Support‑Zugriffe, Notfallzugänge, Subprozessoren und das interne Berechtigungsmodell des Anbieters. Mandantentrennung (Multi‑Tenancy) ist bei SaaS üblich. Sie ist nicht per se unsicher, aber sie erfordert nachvollziehbare technische und organisatorische Trennung sowie klare Zusicherungen zu Test‑, Staging‑ und Produktionsumgebungen.
On‑Premise bietet Ihnen maximale Kontrolle über Admin‑Zugänge – das bedeutet aber auch, dass Sie MFA, Privileged Access Management (PAM, also kontrollierte Admin‑Zugänge mit Protokollierung) und Härtung tatsächlich betreiben müssen. Ohne diese Maßnahmen ist „On‑Premise“ nicht automatisch sicherer.
3) Verschlüsselung und Schlüsselmanagement (KMS, BYOK, HYOK)
Verschlüsselung ist nur dann ein Datenhoheitsargument, wenn das Schlüsselmanagement passt. Ein paar Begriffe, die in Beschaffungsgesprächen oft fallen:
- KMS (Key Management Service): Dienst zur Verwaltung kryptografischer Schlüssel, inklusive Rotation und Zugriffsregeln.
- BYOK (Bring Your Own Key): Sie liefern den Schlüssel, der Anbieter nutzt ihn in seiner Infrastruktur, oft unter Ihrer Kontrolle bezüglich Rotation/Deaktivierung.
- HYOK (Hold Your Own Key): Schlüssel verbleiben in Ihrer Umgebung; der Anbieter kann ohne Ihre Mitwirkung nicht entschlüsseln. Das ist technisch anspruchsvoller und nicht in jedem SaaS verfügbar.
Für Compliance ist zentral: Wer kann Schlüssel aktivieren, rotieren und sperren? Und: Welche Daten sind wie verschlüsselt? (at rest, also gespeichert; in transit, also übertragen; ggf. clientseitig). On‑Premise erlaubt typischerweise volle Kontrolle, verlangt aber reife Prozesse (Rotation, Backup der Schlüssel, Recovery‑Szenarien).
4) Logging, Audit Trail und Beweissicherung
Auditierbarkeit steht und fällt mit Logs: Wer hat wann welche Daten angesehen, geändert, exportiert oder gelöscht? Für viele Regime (internes Kontrollsystem, Datenschutz, Sicherheitsstandards) brauchen Sie nachvollziehbare Ereignisketten. Bei SaaS ist wichtig, ob Sie Rohdaten (z. B. Admin‑Events) exportieren können und wie lange sie vorgehalten werden. Bei On‑Premise ist wichtig, dass Logging nicht nur „aktiviert“ ist, sondern zentral ausgewertet und manipulationsarm gespeichert wird (Write‑Once‑Read‑Many‑Prinzip oder revisionssichere Ablage).
Für die Beschaffung ist eine konkrete Frage entscheidend: Kann das System Logs in Ihr SIEM (Security Information and Event Management, zentrale Sicherheitsauswertung) liefern, inklusive ausreichender Detailtiefe und stabiler Schnittstellen?
5) Datenresidenz, Subprozessoren und grenzüberschreitende Transfers
Datenschutz- und Branchenvorgaben verlangen häufig Klarheit darüber, wo verarbeitet wird und wer daran beteiligt ist. Bei SaaS ist die Subprozessoren‑Kette zentral: Hosting, Support, Monitoring, Incident‑Response, E‑Mail‑Provider, Ticketing‑Systeme. Sie brauchen Transparenz, Änderungsprozesse und Widerspruchsmöglichkeiten. On‑Premise minimiert diese Kette, ersetzt sie aber durch eigene Dienstleister (z. B. Wartung, Rechenzentrum, Managed Services) – die müssen vertraglich und organisatorisch ebenfalls sauber eingebunden werden.
6) Business Continuity: Backup, Restore, RTO/RPO, Krisenbetrieb
Compliance und Datenhoheit betreffen auch Verfügbarkeit. Zwei Kennzahlen sollten in jeder Entscheidung auftauchen:
- RPO (Recovery Point Objective): maximal tolerierbarer Datenverlust in Zeit (z. B. 15 Minuten).
- RTO (Recovery Time Objective): maximal tolerierbare Wiederanlaufzeit (z. B. 4 Stunden).
SaaS kann hier stark sein, aber Sie müssen prüfen, was vertraglich zugesichert ist: Backup‑Frequenz, Restore‑Tests, regionale Ausfälle, Abhängigkeit von Identitätsdiensten, Support‑Reaktionszeiten im Major Incident. On‑Premise kann exakt auf Ihre RTO/RPO optimiert werden – kostet aber Planung, Hardware‑Redundanz, regelmäßige Restore‑Tests und belastbare Runbooks.
7) Change- und Patch-Management als Compliance-Faktor
Bei SaaS erfolgen Änderungen oft kontinuierlich. Das ist gut für Sicherheitsupdates, kann aber Risiken für Validierung, Schnittstellen und Fachprozesse erzeugen. Compliance-relevant wird es, wenn Sie Änderungen nachvollziehen und bewerten müssen: Welche Releases kommen? Gibt es Release Notes? Gibt es Vorankündigungen? Können Funktionen deaktiviert oder „gepinnt“ werden?
Bei On‑Premise steuern Sie Patches und Releases selbst. Das reduziert Überraschungen, erhöht aber die Gefahr, dass Updates liegen bleiben. In Audits ist „wir hätten patchen können“ keine Entlastung, wenn bekannte Schwachstellen monatelang offen sind.
Regulatorische Anforderungen in eine umsetzbare Prüflogik übersetzen
Unabhängig davon, ob Sie sich an ISO‑Standards, Branchenanforderungen oder regulatorischen Rahmenwerken orientieren: Entscheidend ist die Übersetzung in prüfbare Anforderungen. Beispiele für häufige Treiber (ohne Anspruch auf Vollständigkeit):
- Datenschutz (z. B. DSGVO): Auftragsverarbeitung, Löschkonzepte, Betroffenenrechte, technische und organisatorische Maßnahmen.
- NIS2: Managementverantwortung, Sicherheitsmaßnahmen, Meldeprozesse, Lieferkettenrisiken.
- DORA (Finanzsektor): ICT‑Risikomanagement, Resilienztests, Drittanbietersteuerung, Exit‑Planung.
- Branchenspezifische Audits: Nachweise zu Zugriffen, Change‑Management, Incident‑Handling, BCM.
Wichtig für „Approvvigionamento“: Diese Treiber gehören nicht als Buzzwords in ein RFP, sondern als konkrete Kontrollanforderungen mit Nachweisen, Verantwortlichkeiten und Prüfrechten.
Entscheidungsrahmen: Von Anforderungen zu einer belastbaren Auswahl
Der folgende Rahmen funktioniert als Ablauf, der sich in Beschaffung, Governance und Projektplanung integrieren lässt. Er zwingt dazu, offene Punkte früh zu klären – bevor Vertrag und technische Architektur Fakten schaffen.
Schritt 1: Minimum Controls definieren (nicht verhandelbar)
Definieren Sie eine Liste von Mindestkontrollen, die unabhängig vom Betriebsmodell gelten. Beispiele:
- MFA für alle administrativen Zugänge; Rollenprinzip mit Least Privilege (minimal notwendige Rechte).
- Nachvollziehbarer Audit Trail für kritische Aktionen (z. B. Berechtigungsänderungen, Exporte, Löschungen).
- Definierte Datenresidenz oder begründete Abweichung mit Transfer‑Kontrollen.
- Verschlüsselung in Transit und at Rest; dokumentiertes Schlüsselmanagement inkl. Rotation.
- Backup/Restore‑Konzept mit regelmäßigen Restore‑Tests und klaren RTO/RPO.
- Incident‑Prozess mit Meldefristen, Kontaktpunkten und forensischer Unterstützung.
Diese Minimum Controls sind der Kern Ihrer Compliance‑Position. Wenn ein Anbieter (oder Ihre eigene On‑Prem‑Organisation) sie nicht erfüllen kann, ist die Diskussion beendet oder es braucht eine formale Risikoakzeptanz auf Managementebene.
Schritt 2: Kontroll-Mapping und Verantwortlichkeiten (RACI) festlegen
Für jedes Kontrollziel sollten Sie festlegen, wer Responsible (ausführend), Accountable (rechenschaftspflichtig), Consulted (einbezogen) und Informed (zu informieren) ist. Gerade bei SaaS entstehen Lücken, wenn alle davon ausgehen, „der Anbieter macht das schon“.
Typische RACI‑Stolperfallen sind Identitätsmanagement (SSO, also Single Sign‑On), Berechtigungsverwaltung, Datenexporte, Löschanforderungen, Schlüsselentscheidungen und Log‑Aufbewahrung. Diese Punkte sollten Sie als eigene Zeile in Ihrer Matrix führen.
Schritt 3: Evidenzplan für Audits erstellen
Ein Evidenzplan ist eine Liste von Nachweisen, die Sie auf Knopfdruck liefern können. Beispiele:
- Konfigurationsauszug zu MFA/SSO und Admin‑Rollen
- Protokoll eines Restore‑Tests (Datum, Umfang, Ergebnis, Abweichungen)
- Change‑Freigaben für sicherheitsrelevante Anpassungen
- Liste der Subprozessoren inkl. Änderungsverlauf
- Auszug aus SIEM‑Events für kritische Aktionen (Reduktion auf notwendige Daten)
Wichtig: Planen Sie die Evidenzen so, dass sie auch dann verfügbar sind, wenn der SaaS‑Tenant gesperrt ist oder On‑Prem‑Systeme im Incident isoliert werden.
Schritt 4: Exit-Strategie und Portabilität als Pflichtkapitel
Compliance und Datenhoheit enden nicht beim Betrieb, sondern beim Ausstieg. Ein Exit‑Plan ist mehr als „wir können exportieren“. Er umfasst:
- Datenexport: Formate, Vollständigkeit (inkl. Metadaten, Audit Trails), Frequenz, Automatisierung.
- Identitäten und Berechtigungen: Wie werden Rollen, Gruppen, Berechtigungsstrukturen migriert oder nachgebaut?
- Schnittstellen: Welche Integrationen hängen am System (ERP, DMS, IAM, BI)? Wie wird umgestellt?
- Fristen: Wie lange bleiben Daten nach Kündigung verfügbar? Wie erfolgt nachweisbare Löschung?
- Abhängigkeiten: Proprietäre Workflows, Datenmodelle, Reports, Automationen.
Wenn diese Punkte nicht vertraglich und technisch abgesichert sind, entsteht Vendor Lock‑in nicht als „Gefühl“, sondern als konkreter Migrationsstau.
Checkliste für Beschaffung (RFP): SaaS vs. On‑Premise auditierbar vergleichen
Die folgende Checkliste ist bewusst so formuliert, dass sie in ein RFP, in eine Due‑Diligence‑Liste oder in ein internes Bewertungssheet übernommen werden kann.
A) Daten und Datenschutz
- Welche Datenkategorien werden verarbeitet? Gibt es Funktionen für Datenklassifizierung/Labeling?
- Wo erfolgt Verarbeitung und Speicherung (Regionen)? Gibt es eine verbindliche Zusicherung zur Datenresidenz?
- Wie werden Subprozessoren offengelegt? Gibt es Vorankündigung, Widerspruch, Ausstiegsrechte?
- Wie werden Löschanforderungen umgesetzt und nachgewiesen (inkl. Backups, Replikate, Logs)?
- Unterstützt die Lösung Betroffenenrechte (Auskunft, Löschung, Export) in praktikabler Frist?
B) Sicherheit und Zugriffskontrolle
- Unterstützung für SSO (z. B. SAML/OIDC) und MFA, inkl. Admin‑Zugängen und API‑Zugängen?
- Rollenmodell: Least Privilege, Custom Roles, getrennte Admin‑Rollen, Break‑Glass‑Konten (Notfallzugang) mit Protokollierung?
- Verschlüsselung: in transit/at rest; Optionen für BYOK/HYOK; Schlüsselrotation; Auditierbarkeit von Schlüsselaktionen?
- Netzwerk- und Zugriffsbeschränkungen: IP‑Allowlisting, Private Connectivity, Tenant‑Isolation?
C) Audit, Logging und Nachweise
- Welche Audit‑Logs sind verfügbar (Admin‑Aktionen, Datenzugriffe, Exporte, Auth‑Events)?
- Wie lange werden Logs vorgehalten und können sie exportiert werden (SIEM‑Integration)?
- Welche unabhängigen Prüfberichte sind verfügbar (z. B. SOC‑Berichte) und in welcher Aktualität?
- Wie wird Change‑Management dokumentiert (Release Notes, Wartungsfenster, Rückrolloptionen)?
D) Betrieb, Resilienz und Support
- Definierte RTO/RPO, Backup‑Frequenz, Restore‑Tests, Nachweisführung?
- Incident‑Response: Ansprechpartner, Eskalation, Meldefristen, forensische Unterstützung, Post‑Mortems?
- SLA: Verfügbarkeit, Supportzeiten, Reaktionszeiten, Priorisierung, Entschädigungslogik?
- Abhängigkeiten: IAM‑Provider, E‑Mail‑Zustellung, DNS, API‑Rate‑Limits, Wartungsfenster?
E) Exit, Portabilität, Vertragsende
- Standardisierte Exporte (Daten + Metadaten + Audit Trail), dokumentiert und regelmäßig testbar?
- Fristen und Bedingungen bei Kündigung: Datenzugang, Export, Löschung, Kosten?
- Unterstützung bei Migration: technische Dokumentation, Schnittstellenstabilität, Migrationsfenster?
Vorlagenbausteine: Mindestanforderungen als Policy-Text
Damit Anforderungen nicht nur „im Kopf“ existieren, hilft ein kurzer, kopierbarer Policy‑Baustein. Er ist absichtlich generisch gehalten und muss an Ihre Organisation angepasst werden.
POLICY: Auswahl und Betrieb von SaaS- und On-Premise-Lösungen mit Schutzbedarf „vertraulich“ oder höher
1. Identität & Zugriff
- Administrativer Zugriff erfordert MFA und ist personenbezogen (keine geteilten Konten).
- Rollen und Berechtigungen folgen dem Least-Privilege-Prinzip und werden mindestens quartalsweise rezertifiziert.
- Notfallzugänge (Break-Glass) sind dokumentiert, zeitlich begrenzt und vollständig protokolliert.
2. Daten & Schlüssel
- Daten werden in Transit und at Rest verschlüsselt.
- Schlüsselmanagement ist dokumentiert (Rotation, Sperrung, Recovery). Wo möglich, sind kundenseitig kontrollierte Schlüssel zu bevorzugen.
3. Logging & Audit
- Sicherheitsrelevante Ereignisse (Auth, Admin-Aktionen, Exporte, Löschungen) sind revisionssicher protokolliert.
- Logs sind exportierbar und werden zentral korreliert (SIEM oder äquivalent).
4. Resilienz
- RTO/RPO sind festgelegt und durch regelmäßige Restore-Tests nachgewiesen.
- Incident-Prozesse (Meldung, Eskalation, Kommunikation) sind vertraglich und organisatorisch geregelt.
5. Exit
- Datenexport und Löschung bei Vertragsende sind technisch möglich, dokumentiert und vertraglich zugesichert.
- Der Exit-Plan wird vor Vertragsabschluss bewertet und mindestens jährlich überprüft.Kosten und Risiko realistisch bewerten: TCO trifft Compliance-Aufwand
Die Kostenfrage wird oft auf Lizenzkosten reduziert. Für Compliance‑ und Datenhoheitsanforderungen ist jedoch entscheidend, wie viel Aufwand in Kontrollen und Nachweisführung steckt. Typische Kostenblöcke:
- SaaS: Lizenzen, Zusatzmodule (Security/Compliance), SIEM‑Anbindung, Datenexport/Backup‑Optionen, Enterprise‑Support, Vertrags- und Auditaufwände, ggf. Kosten für kundenseitige Verschlüsselungsoptionen.
- On‑Premise: Hardware/Virtualisierung, Storage/Backup, Netzwerksegmente, Härtung, Patch‑Fenster, 24/7‑Bereitschaft, Monitoring/SIEM, Personalaufwand für Betrieb und Dokumentation, Wiederherstellungstests, Lifecycle‑Management.
Ein häufiger Fehler: On‑Premise wird mit vorhandenen Teams „kostenfrei“ gerechnet, SaaS dagegen als „teuer“ empfunden. In Audits zählt aber, ob Betrieb und Dokumentation tatsächlich erfolgen. Wenn On‑Premise bedeutet, dass Patches, Schlüsselrotation oder Restore‑Tests aus Kapazitätsgründen ausfallen, wird das Compliance‑Risiko schnell zum Managementthema.
Typische Entscheidungsmuster und sinnvolle Hybrid-Optionen
Die Praxis kennt selten Schwarz‑Weiß. Häufig entstehen robuste Modelle durch Kombinationen:
- SaaS mit strenger Identitäts- und Datenkontrolle: SSO/MFA verpflichtend, restriktives Rollenmodell, SIEM‑Export, klare Subprozessoren‑Regeln, vertraglich fixierte Datenresidenz.
- On‑Premise für Kernprozesse mit hohem Schutzbedarf: wenn Datenhoheit und Integrationsnähe dominieren und Sie die Betriebsreife besitzen.
- Hybrid: sensible Daten bleiben on‑prem (z. B. in einer internen Datenhaltung), SaaS liefert Workflow/UX; Schnittstellen werden so gebaut, dass Datenminimierung und Pseudonymisierung möglich sind.
Für die Beschaffung ist wichtig: Hybrid ist kein Ausweg aus Verantwortung, sondern erhöht die Integrations‑ und Governance‑Komplexität. Dafür kann es Datenflüsse so schneiden, dass Compliance‑Risiken sinken.
Entscheidungsvorlage: Scoring-Modell mit Risikoakzeptanz
Für Gremienentscheidungen hilft ein einfaches Scoring, das nicht vorgaukelt, alles sei exakt messbar. Bewährt ist eine Skala 0–3 je Dimension (0 = nicht erfüllt, 3 = voll erfüllt) plus Pflichtkriterien. Dimensionen, die bei Compliance/Datenhoheit typischerweise gewichtet werden:
- Datenresidenz und Subprozessoren‑Kontrolle
- Schlüsselhoheit (BYOK/HYOK) und Verschlüsselungsnachweise
- Auditierbarkeit (Logs, Reports, unabhängige Prüfberichte)
- Identity & Access (SSO/MFA/PAM‑Fähigkeit)
- BCP/DR (RTO/RPO, Restore‑Nachweise)
- Exit‑Fähigkeit (Export, Löschung, Portabilität)
- Betriebsfähigkeit (Ressourcen, Skills, Runbooks, Monitoring)
Wichtig ist der letzte Schritt: Wenn ein Modell gewählt wird, obwohl einzelne Dimensionen nicht ausreichend erfüllt sind, braucht es eine dokumentierte Risikoakzeptanz mit Maßnahmenplan, Owner und Termin. Ohne diese Disziplin wird „SaaS vs. On‑Premise“ später zum Streit über Verantwortlichkeiten.
Schlussfazit: Die richtige Wahl ist die, die Sie nachweisbar beherrschen
SaaS vs. On‑Premise ist keine Glaubensfrage, sondern eine Frage der beherrschbaren Kontrollen. SaaS kann Compliance und Datenhoheit gut unterstützen, wenn Identität, Logging, Subprozessoren‑Steuerung, Schlüsselmanagement und Exit‑Planung sauber geregelt sind. On‑Premise kann maximale Daten- und Kontrollhoheit liefern, verlangt aber Reife in Betrieb, Dokumentation, Patch‑Disziplin und Wiederherstellungstests.
Wenn Sie den hier beschriebenen Rahmen nutzen – Minimum Controls, RACI, Evidenzplan und Exit‑Kapitel – bekommen Sie eine Entscheidung, die nicht nur beim Einkauf gut klingt, sondern auch im Audit und im Krisenfall trägt.
Für dieses Thema sind auch Compliance-Anforderungen wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.