Fragt man einen Geschäftsführer, was sein ERP-System wert ist, spricht er meist über Lizenzkosten. Fragt man ihn dagegen, was eine Woche ohne dieses System kosten würde, wird die Antwort deutlich interessanter. Rechnungen können nicht mehr erstellt werden. Niemand hat einen verlässlichen Überblick über die Lagerbestände. Bestellungen bleiben liegen. Und der Monatsabschluss wird plötzlich zu einer mühsamen Arbeit mit Excel-Tabellen, deren Zahlen niemand so recht vertraut.  Genau darum geht es letztlich bei der Entscheidung für SAP Business One in der Cloud. Die entscheidende Frage ist nicht, ob die Cloud grundsätzlich „sicher“ ist. Viel wichtiger ist, ob ein Unternehmen nach einem schwerwiegenden Sicherheitsvorfall seine Finanz- und Bestandsdaten schnell und vollständig wiederherstellen kann.  Denn früher oder später kann es jedes Unternehmen treffen. Laut einer Befragung des Digitalverbands Bitkom unter deutschen Unternehmen mit mindestens zehn Beschäftigten haben 58 % im vergangenen Jahr durch Cyberangriffe einen tatsächlichen Schaden erlitten. Gleichzeitig fühlen sich immer weniger Unternehmen ausreichend vorbereitet. Nur noch 43 % schätzen sich als sehr gut auf Cyberangriffe vorbereitet ein, gegenüber 50 % im Vorjahr.  Auch der Data Breach Investigations Report 2026 von Verizon zeichnet ein deutliches Bild: Bei 48 % aller bestätigten Datenschutzverletzungen spielte Ransomware eine Rolle. Hinzu kommen steigende finanzielle Folgen. IBM beziffert die weltweiten Durchschnittskosten einer Datenschutzverletzung auf 4,99 Millionen US-Dollar – den bislang höchsten erfassten Wert. 

Ist SAP Business One Cloud vor Ransomware geschützt? 

Nicht in dem Sinne, dass ein Angriff ausgeschlossen wäre. Ransomware kann jedes ERP-System treffen – unabhängig davon, ob es in der Cloud oder auf einem Server im eigenen Unternehmen betrieben wird.  Professionelles Cloud-Hosting kann jedoch entscheidend beeinflussen, wie schwer die Folgen eines Angriffs ausfallen. Sind Backups so geschützt, dass Angreifer sie nicht manipulieren können, nutzen alle Anwender eine Multi-Faktor-Authentifizierung, werden verdächtige Aktivitäten überwacht und wurde der Wiederherstellungsplan bereits praktisch getestet, lässt sich der Schaden erheblich begrenzen.  Allein das Wort „Cloud“ im Hosting-Vertrag garantiert keinen dieser Schutzmechanismen. Entscheidend ist, wie die Umgebung aufgebaut, abgesichert und betrieben wird. 

Was passiert, wenn ein Ransomware-Angriff Ihr ERP-System lahmlegt? 

Das Erstaunliche ist: Angreifer verschaffen sich häufig gar nicht zuerst direkten Zugang zum ERP-System. Der Einstieg erfolgt oft über scheinbar alltägliche Schwachstellen: ein mehrfach verwendetes Passwort, eine täuschend echt formulierte E-Mail mit einer gefälschten Rechnung oder ein VPN-System, dessen Sicherheitsupdates seit Wochen ausstehen.  Gerade die letzte Variante spielt inzwischen eine besonders große Rolle. Laut dem Verizon DBIR 2026 waren ausgenutzte Software-Schwachstellen für 31 % der untersuchten Sicherheitsverletzungen verantwortlich. Damit lagen sie erstmals vor gestohlenen Zugangsdaten.  Kleine und mittlere Unternehmen sind besonders betroffen. Im Bericht von 2025 war Ransomware bei 88 % der Sicherheitsverletzungen in KMU beteiligt. Bei Großunternehmen lag der Anteil bei 39 %.  Was anschließend geschieht, folgt häufig einem ähnlichen Muster. Stellen Sie sich einen Freitagabend vor. Ein Angreifer hat sich bereits vor ein oder zwei Wochen unbemerkt Zugang zum Unternehmensnetzwerk verschafft. Seitdem hat er sich in Ruhe umgesehen.  Inzwischen weiß er, auf welchem Server die SQL-Server- oder HANA-Datenbank läuft. Er kennt den Speicherort der Anhänge und weiß, welche Benutzerkonten über Administratorrechte verfügen.  Bevor er auffällige Aktionen ausführt, sucht er nach den Backups. Denn ein Unternehmen, das seine Systeme zuverlässig wiederherstellen kann, ist deutlich weniger geneigt, Lösegeld zu zahlen.  Anschließend werden sensible Informationen kopiert, die sich verkaufen oder für Erpressungsversuche verwenden lassen: Kundenlisten, Preisvereinbarungen, Bankdaten und Gehaltsinformationen.  Erst danach beginnt die Verschlüsselung – beispielsweise an einem Samstag um zwei Uhr morgens, wenn niemand die Systeme aktiv überwacht.  Am Montagmorgen wird das Ausmaß sichtbar. Niemand kann Rechnungen buchen, Aufträge kommissionieren oder Lieferungen erfassen. Wenig später zeigen sich weitere Folgen: Bestellungen aus dem Onlineshop stauen sich oder gehen verloren. EDI-Nachrichten an Handelskunden werden nicht mehr verarbeitet. Das Banking-Add-on kann Zahlungseingänge nicht mehr zuordnen.  Spätestens am Mittwoch stehen ganz andere Fragen im Raum. Welche Daten wurden gestohlen? Welche Stellen müssen informiert werden? Und wenn das System wieder läuft: Können wir den Zahlen überhaupt noch vertrauen?  Gerade die letzte Frage wird häufig unterschätzt. SAP Business One wieder zum Laufen zu bringen, ist eine Sache. Gegenüber Wirtschaftsprüfern oder zuständigen Behörden nachweisen zu können, dass sämtliche Buchungen vollständig und korrekt sind, ist eine andere.  Das gilt insbesondere im Zusammenhang mit dem deutschen NIS2-Umsetzungsgesetz, das seit dem 6. Dezember 2025 in Kraft ist. 

Reichen Cloud-Backups aus, um Finanz- und Lagerdaten zu schützen? 

Backups sind unverzichtbar. Allein reichen sie jedoch nicht aus. Das Problem: Angreifer wissen genau, wie wichtig Datensicherungen für ein Unternehmen sind.  Sophos untersuchte knapp 3.000 Organisationen, die von Ransomware betroffen waren. 94 % berichteten, dass die Angreifer versucht hatten, ihre Backups zu kompromittieren.  War dieser Versuch erfolgreich, lagen die durchschnittlichen Wiederherstellungskosten auf Medianbasis etwa achtmal höher. Auch die Wiederherstellung dauerte länger: Nur 26 % dieser Unternehmen waren innerhalb einer Woche wieder vollständig betriebsbereit. Bei Organisationen, deren Backups unbeschädigt geblieben waren, lag dieser Anteil bei 46 %.  Bei der Datensicherung und Wiederherstellung von SAP Business One sollte die Frage deshalb nicht einfach lauten: „Haben wir Backups?“  Die entscheidende Frage ist:  „Wären unsere Backups noch vorhanden und unverändert, wenn ein Angreifer drei Tage lang Administratorzugriff auf unsere Umgebung gehabt hätte?“  Damit sich diese Frage mit Ja beantworten lässt, müssen mehrere Voraussetzungen erfüllt sein.  - Mindestens eine Sicherungskopie ist unveränderbar (immutable). Während der festgelegten Aufbewahrungsfrist darf niemand diese Kopie verändern oder löschen können – auch kein Administrator und kein Mitarbeiter des Hosting-Anbieters.  - Backups werden außerhalb der produktiven Umgebung gespeichert. Dafür müssen separate Zugangsdaten verwendet werden. Wenn dasselbe Administratorkennwort sowohl Zugriff auf die Produktivsysteme als auch auf den Backup-Speicher ermöglicht, besteht praktisch nur eine einzige Sicherheitsebene.  - Die Sicherung umfasst sämtliche relevanten Komponenten, nicht nur die Unternehmensdatenbank. Dazu gehören SBO-COMMON, der Ordner für Anhänge, Add-on-Einstellungen, Integrationskonfigurationen und Drucklayouts. Eine wiederhergestellte Datenbank ohne Anhänge und mit nicht funktionierenden Add-ons hilft der Finanzbuchhaltung nur begrenzt.  - Die Aufbewahrungsfrist reicht weit genug zurück. Angreifer halten sich mitunter wochenlang unbemerkt in einem Netzwerk auf. Werden Backups nur sieben Tage aufbewahrt, können bereits sämtliche vorhandenen Sicherungen kompromittiert sein. 

Was ist der Unterschied zwischen einem ERP-Backup und Disaster Recovery? 

Ein Backup ist eine Kopie Ihrer Daten. Disaster Recovery bezeichnet dagegen den getesteten Wiederherstellungsprozess einschließlich Infrastruktur, Verantwortlichkeiten und technischer Maßnahmen, mit dem aus dieser Kopie wieder ein funktionsfähiges System wird.  Dazu gehören Server, Lizenzen, Integrationen, Benutzerzugriffe und überprüfte Daten – innerhalb eines vereinbarten Zeitrahmens.  Ein Unternehmen kann hervorragende Backups besitzen und trotzdem zwei Wochen benötigen, um den Betrieb wieder aufzunehmen.  Ein Backup beschreibt also, welche Daten vorhanden sind. Disaster Recovery beschreibt, wie schnell und zuverlässig daraus wieder ein funktionierendes ERP-System wird. 

RPO und RTO: Wie viel Datenverlust und Ausfallzeit kann sich Ihr Unternehmen leisten? 

Diese beiden Abkürzungen tauchen in nahezu jedem Cloud-Hosting-Angebot auf. Gleichzeitig sind es zwei Kennzahlen, über die die Geschäftsführung selbst entscheiden sollte. Denn dahinter stehen keine rein technischen Fragen, sondern konkrete geschäftliche Risiken.

Begriff	Was wird gemessen?	Die entscheidende geschäftliche Frage
RPO (Recovery Point Objective)	Der maximal tolerierbare Datenverlust, ausgedrückt als Zeitraum	Wenn wir auf die letzte intakte Datensicherung zurückgreifen müssen: Wie viele Stunden an Bestellungen, Buchungen und Warenbewegungen gehen verloren?
RTO (Recovery Time Objective)	Die maximal tolerierbare Dauer eines Systemausfalls	Wie lange können wir ohne Rechnungsstellung, Versand oder Lieferantenzahlungen arbeiten, bevor erhebliche Schäden entstehen?

Dabei gibt es einen Punkt, den viele Service Level Agreements (SLAs) nicht ausreichend berücksichtigen. Ein RPO von 15 Minuten hilft nur dann, wenn die Datensicherung von vor 15 Minuten tatsächlich sauber ist.  Hatten Angreifer bereits zwei Wochen lang Zugriff auf das System, muss möglicherweise ein Wiederherstellungspunkt gewählt werden, der noch vor dem ersten Eindringen liegt.  Alle danach erfolgten Geschäftsvorgänge müssen anschließend anhand von Kontoauszügen, Onlineshop-Bestellungen oder Papierbelegen rekonstruiert werden. Deshalb sind die Aufbewahrungsdauer und die Malware-Prüfung von Backups ebenso wichtig wie die Häufigkeit der Datensicherung. 

Ein Cyberangriff, drei völlig unterschiedliche Verläufe 

Machen wir das Ganze anhand eines Beispiels greifbar.  Das folgende Unternehmen ist fiktiv. Wer bereits SAP-Business-One-Projekte begleitet hat, wird die Situation jedoch wiedererkennen.  Stellen Sie sich einen Großhändler vor, bei dem täglich rund 40 Mitarbeiter mit SAP Business One arbeiten. Bestellungen gehen über einen Onlineshop ein. Zwei große Handelsketten übermitteln ihre Aufträge zusätzlich per EDI.  An einem Dienstag gegen 14 Uhr reagieren die Systeme plötzlich nicht mehr. Eine Viertelstunde später entdeckt ein Mitarbeiter der Buchhaltung eine Lösegeldforderung auf seinem Bildschirm.  Wie es nun weitergeht, hängt fast vollständig von Entscheidungen ab, die Monate zuvor getroffen wurden. Szenario 1: Eine nächtliche Datensicherung – und kaum weitere Vorbereitung  Die letzte intakte Sicherung wurde um ein Uhr morgens erstellt. Damit sind sämtliche seitdem erfassten Daten verloren: 13 Stunden voller Bestellungen, Lieferungen und Buchungen.  Das ist bereits problematisch, aber noch nicht das größte Hindernis. Es wurde nie eine separate Wiederherstellungsumgebung eingerichtet. Deshalb müssen zunächst neue Server aufgebaut werden.  Anschließend wird SAP Business One installiert. Danach müssen sämtliche Add-ons erneut konfiguriert werden – teilweise aus dem Gedächtnis. Unter diesen Bedingungen ist ein Ausfall von drei bis fünf Arbeitstagen durchaus realistisch.  Wenn das System schließlich wieder läuft, müssen alle betroffenen Onlineshop-Bestellungen und EDI-Nachrichten vom Dienstag zusammengesucht und manuell nacherfasst werden.  Szenario 2: Gute Backups, aber kein einziger vollständiger Wiederherstellungstest Dieses Unternehmen hat grundsätzlich an den richtigen Stellen investiert.  Alle 15 Minuten werden Transaktionsprotokolle gesichert. Die Sicherungen befinden sich in einem geschützten Speicher, auf den die Angreifer nicht zugreifen konnten.  Der Datenverlust fällt deshalb sehr gering aus. Das Problem ist jedoch, dass noch nie eine vollständige Wiederherstellung durchgeführt wurde.  Der erste Tag vergeht damit, Lizenzschlüssel zu suchen, notwendige Firewall-Regeln für den Shop-Connector zu ermitteln und die einzige Person ausfindig zu machen, die das EDI-Passwort kennt.  Nach ungefähr zwei Tagen ist das System wieder verfügbar. Die Daten sind erhalten geblieben. Zwei Tage Betriebsstillstand verursachen trotzdem erhebliche Kosten.  Szenario 3: Unveränderbare Backups und ein praktisch erprobter Wiederherstellungsplan In diesem Fall hat der Hosting-Anbieter bereits eine saubere Wiederherstellungsumgebung in einer zweiten Azure-Region vorbereitet.  Sechs Monate zuvor wurde ein vollständiger Wiederherstellungstest durchgeführt. Das Team wählt die letzte nachweislich saubere Datensicherung aus, stellt die Systeme wieder her und aktiviert anschließend Integrationen und Benutzerzugriffe in einer vorher festgelegten Reihenfolge.  Dabei arbeitet es mit einer Checkliste, die bereits erfolgreich getestet wurde. Noch am selben Tag können die Mitarbeiter ihre Arbeit wieder aufnehmen.  Die Finanzbuchhaltung benötigt anschließend einige Stunden, um Salden und offene Posten zu überprüfen. Der Datenverlust beschränkt sich auf wenige Minuten.  Allerdings gilt auch hier eine wichtige Einschränkung. Wenn sich die Angreifer bereits seit Wochen im System aufgehalten haben, liegt der letzte saubere Wiederherstellungspunkt möglicherweise deutlich weiter zurück.  Dann müssen auch in diesem Szenario Geschäftsvorgänge nacherfasst werden. Wie schnell lässt sich SAP Business One nach einem Systemausfall wiederherstellen?  Das hängt vor allem von der Vorbereitung ab. Mit unveränderbaren Backups, einer vorbereiteten Wiederherstellungsumgebung und einem getesteten Notfallhandbuch kann eine Wiederherstellung innerhalb weniger Stunden realistisch sein.  Ohne diese Voraussetzungen dauert sie häufig mehrere Arbeitstage. Die aussagekräftigste Kennzahl ist deshalb nicht das theoretische Wiederherstellungsziel im Vertrag, sondern das Ergebnis des letzten vollständig durchgeführten Wiederherstellungstests. 

Was sollte ein Disaster-Recovery-Test für SAP Business One umfassen? 

Viele Unternehmen, mit denen wir sprechen, verfügen über einen Disaster-Recovery-Plan. Fragt man allerdings, wann dieser zuletzt praktisch getestet wurde, wird es häufig auffallend still.  Ein Plan, der noch nie erprobt wurde, ist letztlich nicht viel mehr als ein Dokument voller guter Absichten. Auch eine Datenbank wiederherzustellen und zu prüfen, ob sie sich öffnen lässt, reicht nicht aus. Das ist lediglich der erste von mehreren notwendigen Schritten.  Ein vollständiger Wiederherstellungstest für SAP Business One sollte mindestens einmal jährlich stattfinden – und zusätzlich nach größeren System-Upgrades.  Folgende Punkte gehören aus unserer Sicht dazu. 

1. Wiederherstellung in einer vollständig getrennten Umgebung

Zunächst muss das System an einem Ort wiederhergestellt werden, der vollständig von der produktiven Umgebung getrennt ist. Bei einem tatsächlichen Ransomware-Angriff kann man der bestehenden Infrastruktur nicht mehr uneingeschränkt vertrauen.  Ein realistischer Test darf deshalb nicht von ihr abhängig sein. 

2. Wiederherstellung sämtlicher ERP-Komponenten

Die Unternehmensdatenbank ist nur der Anfang. Auch SBO-COMMON, der Ordner für Anhänge, Add-ons, der Lizenzdienst, Drucklayouts und Benutzerberechtigungen müssen vollständig wiederhergestellt werden.  Fehlt eine dieser Komponenten, kann es passieren, dass die Finanzbuchhaltung trotz funktionierender Datenbank weiterhin keine Rechnungen versenden kann. 

3. Wiederherstellung eines älteren, nachweislich sauberen Datenstands

Verwenden Sie nicht einfach die neueste Datensicherung. Gehen Sie stattdessen davon aus, dass die Angreifer bereits vor drei Wochen in das Netzwerk eingedrungen sind.  Üben Sie, einen Wiederherstellungspunkt zu identifizieren, der vor diesem Zeitpunkt liegt. Im Ernstfall gehört genau diese Entscheidung häufig zu den schwierigsten Aufgaben. 

4. Prüfung sämtlicher Integrationen

Anschließend müssen die angebundenen Systeme wieder verbunden werden: 

• Onlineshop 

• EDI-Schnittstellen 

• Banking-Lösungen 

• Lohn- und Gehaltsabrechnung 

• Scanner und mobile Geräte im Lager 

Besonders wichtig ist die Frage, was mit den Transaktionen passiert, die sich während des Ausfalls angesammelt haben. Werden Bestellungen genau einmal übertragen? Werden sie doppelt verarbeitet? Oder gehen sie möglicherweise vollständig verloren? 

5. Fachliche Validierung durch die Anwender

Jetzt sind die Mitarbeiter gefragt, die täglich mit SAP Business One arbeiten. Ein Mitarbeiter aus der Finanzbuchhaltung sollte die Summen- und Saldenliste, offene Posten und Lagerbestandswerte mit verlässlichen Referenzdaten vergleichen.  Die IT-Abteilung kann bestätigen, dass das System technisch wieder läuft. Ob die Zahlen tatsächlich korrekt sind, kann dagegen nur die Fachabteilung beurteilen. 

6. Messung der tatsächlichen Wiederherstellungszeit

Während des gesamten Tests sollte die Zeit gemessen werden. Und zwar vom Moment, in dem der Notfall offiziell ausgerufen wird, bis zu dem Zeitpunkt, an dem die Anwender ihre Arbeit wieder aufnehmen können.  Liegt diese Zeit deutlich über dem vertraglich vereinbarten RTO, wurde eine wichtige Schwachstelle aufgedeckt. Besser bei einem Test als während eines echten Ausfalls, wenn bereits verärgerte Kunden anrufen. 

7. Prüfung der organisatorischen Abläufe

Nicht nur die Technik muss funktionieren. Auch die beteiligten Personen müssen wissen, was zu tun ist. Wer erklärt offiziell den Sicherheitsvorfall? Wer informiert die Versicherung? Wer entscheidet, ob Behörden benachrichtigt werden müssen?  Für Unternehmen, die unter NIS2 fallen, muss bei einem erheblichen Sicherheitsvorfall innerhalb von 24 Stunden eine erste Meldung erfolgen.  Das ist wenig Zeit, wenn zunächst geklärt werden muss, wer überhaupt zuständig ist. 

8. Dokumentation und Nachbereitung

Zum Abschluss sollten sämtliche Probleme dokumentiert werden. Denn Probleme wird es geben. Wir haben nur selten erlebt, dass ein erster vollständiger Wiederherstellungstest vollkommen reibungslos abläuft.  Das ist auch nicht schlimm. Schließlich besteht der Zweck des Tests gerade darin, Schwachstellen zu erkennen. och ein praktischer Hinweis: Lassen Sie den Termin für den Wiederherstellungstest vertraglich festhalten und besprechen Sie die Ergebnisse im Rahmen Ihrer regelmäßigen Servicegespräche.  Wenn ein Anbieter sich nicht auf eine solche Verpflichtung einlassen möchte, sollten Sie genauer nachfragen. 

Welche Sicherheitsaufgaben übernimmt der Cloud-Hosting-Anbieter? 

Hier können Missverständnisse teuer werden. Wer SAP Business One in die Cloud verlagert, überträgt bestimmte Verantwortlichkeiten an seinen Hosting-Anbieter.  Andere Aufgaben bleiben jedoch beim Unternehmen selbst – unabhängig davon, was im Vertrag steht. Viele Auseinandersetzungen nach einem Sicherheitsvorfall entstehen, weil beide Seiten davon ausgegangen sind, dass die jeweils andere eine bestimmte Aufgabe übernimmt.  Die folgende Übersicht zeigt eine typische Aufgabenverteilung bei einem Managed-Hosting-Service für SAP Business One Cloud. Die tatsächlichen Zuständigkeiten sollten in jedem Fall schriftlich im Vertrag geregelt sein.

Bereich	In der Regel Hosting-Anbieter	In der Regel Ihr Unternehmen	Häufig kostenpflichtige Zusatzleistung
Rechenzentrum, Hardware, Cloud-Plattform	✓
Updates für Betriebssystem und Datenbank	✓
Versions-Upgrades von SAP Business One	Gemeinsame Verantwortung	Tests und Freigabe	Teilweise
Tägliche Backups mit Standardaufbewahrung	✓
Unveränderbare Backups und längere Aufbewahrung			✓
Standby-Umgebung in einer zweiten Region			✓
Jährlicher vollständiger Disaster-Recovery-Test	Gemeinsame Verantwortung	Datenvalidierung	✓
Netzwerk-Firewall und sicherer Fernzugriff	✓
Multi-Faktor-Authentifizierung	Technische Bereitstellung	Verbindliche Nutzung durch alle Anwender
Benutzerkonten und Berechtigungen		✓
Sicherheit der Mitarbeiter-Laptops und E-Mail-Konten		✓
Sicherheitsüberwachung und Reaktion rund um die Uhr			✓
Sensibilisierung und Schulung der Mitarbeiter		✓
Richtigkeit der Geschäftsdaten		✓

Zwei Bereiche verdienen besondere Aufmerksamkeit. Der erste ist die Multi-Faktor-Authentifizierung (MFA).  Ein Hosting-Anbieter kann MFA technisch bereitstellen. Wenn Anwender die Funktion jedoch umgehen dürfen oder ein gemeinsam genutztes Administratorkonto ohne MFA betrieben wird, verliert diese Schutzmaßnahme einen erheblichen Teil ihrer Wirkung.  Der zweite Bereich ist die Sicherheitsüberwachung. Viele Anbieter prüfen, ob der Server erreichbar ist.  Deutlich weniger überwachen verdächtige Anmeldeversuche, ungewöhnlich große Datenexporte oder das unbemerkte Löschen von Backup-Aufträgen.  Die Bitkom-Ergebnisse von 2026 weisen in dieselbe Richtung: Bei deutschen Unternehmen, die erfolgreich angegriffen wurden, spielten Defizite bei der Erkennung von Sicherheitsvorfällen, Fehlkonfigurationen sowie Schwächen im Identitäts- und Zugriffsmanagement wiederholt eine Rolle.  Ein weiterer wichtiger Punkt ist die Verschlüsselung. Daten sollten sowohl im Ruhezustand – also in der Datenbank und im Backup-Speicher – als auch während der Übertragung zwischen Anwendern und Server verschlüsselt sein.  Fragen Sie außerdem, wer die Verschlüsselungsschlüssel verwaltet und ob für Backups andere Schlüssel verwendet werden als für die Produktivumgebung. 

Sieben Fragen, die Sie vor Abschluss eines Cloud-Hosting-Vertrags stellen sollten 

Nehmen Sie diese Fragen zu Ihrem nächsten Gespräch mit einem Hosting-Anbieter mit. Die Antworten – und die Bereitschaft, sie konkret zu geben – verraten viel über die Qualität des angebotenen Services. 

1. Welche RPO- und RTO-Werte werden garantiert und sind diese vertraglich festgelegt?

„Best Effort“ ist keine messbare Zusage.  Fragen Sie auch, welche vertraglichen oder finanziellen Konsequenzen entstehen, wenn die vereinbarten Ziele nicht erreicht werden. 

2. Ist mindestens eine Backup-Kopie unveränderbar und wer könnte sie löschen?

Die richtige Antwort lautet sinngemäß: Niemand – auch wir als Anbieter nicht, solange die festgelegte Aufbewahrungsfrist läuft. 

3. Wo befinden sich die Backups und die Wiederherstellungsumgebung?

Lassen Sie sich die Azure-Region und die verantwortliche juristische Einheit nennen. Für die meisten europäischen KMU ist eine Datenspeicherung innerhalb der EU sinnvoll.  Die Wiederherstellungsumgebung sollte weder dieselben Zugangsdaten noch einen gemeinsamen Single Point of Failure mit der Produktivumgebung besitzen. 

4. Wann wurde zuletzt ein vollständiger Wiederherstellungstest für einen vergleichbaren Kunden durchgeführt und wie lange hat er gedauert?

Bitten Sie um einen anonymisierten Testbericht. 

5. Was wird konkret überwacht, von wem und zu welchen Zeiten?

Klären Sie, ob außerhalb der Geschäftszeiten tatsächlich sicherheitsrelevante Ereignisse überwacht werden oder lediglich die Verfügbarkeit des Servers.  Fragen Sie auch, wie schnell Sie im Ernstfall informiert werden. 

6. Welche Leistungen sind im Grundpreis enthalten und welche kosten zusätzlich?

Lassen Sie sich eine detaillierte Aufstellung geben. Insbesondere für längere Backup-Aufbewahrungsfristen, eine Standby-Umgebung, Disaster-Recovery-Tests, Incident Response außerhalb der Geschäftszeiten und forensische Unterstützung. 

7. Welche Aufgaben müssen wir als Kunde während eines Sicherheitsvorfalls übernehmen?

Klären Sie, wer Ihre festen Ansprechpartner sind, welche Entscheidungen Ihr Unternehmen treffen muss und wie der Anbieter Sie bei NIS2-Meldungen sowie bei der Kommunikation mit Ihrer Cyberversicherung unterstützt.  Wenn Sie zwei oder drei Anbieter vergleichen, tragen Sie die Antworten am besten in einer gemeinsamen Tabelle zusammen. Die Unterschiede werden meist schnell deutlich. 

Wie Ingold Solutions die Sicherheit von SAP Business One Cloud gewährleistet 

Ingold Solutions ist ein SAP-Business-One-Partner mit Sitz in Berlin und Teams in Deutschland und Indien. Wir vertreiben SAP-Business-One-Lizenzen, implementieren das System, entwickeln SAP-zertifizierte Add-ons und übernehmen Hosting sowie Support.  Dadurch arbeiten die Mitarbeiter, die Ihre Hosting-Umgebung betreuen, eng mit den Teams zusammen, die Ihre SAP-Business-One-Konfiguration kennen.  Gerade bei einer Wiederherstellung ist das entscheidend. Ein Basissystem erneut aufzusetzen, ist vergleichsweise einfach. Die eigentliche Herausforderung besteht darin, sämtliche Add-ons, Integrationen und Drucklayouts wieder vollständig funktionsfähig zu machen.  Wir betreiben SAP Business One auf Microsoft Azure und legen transparent dar, welche Leistungen in den jeweiligen Servicepaketen enthalten sind.  Im Wesentlichen unterscheiden wir zwischen folgenden Leistungen:  Standardmäßig im SAP Business One Cloud Hosting von Ingold enthalten 

• Verwaltete Azure-Infrastruktur einschließlich Updates für Betriebssystem und Datenbank 

• Automatisierte Backups der Unternehmensdatenbanken, von SBO-COMMON und der Anhänge [Häufigkeit und Aufbewahrungsdauer bestätigen] 

• Verschlüsselung gespeicherter und übertragener Daten 

• Sicherer Fernzugriff mit verfügbarer Multi-Faktor-Authentifizierung für alle Anwender 

• Überwachung der Infrastruktur und Systemverfügbarkeit 

Als zusätzliche oder separat vereinbarte Leistungen verfügbar 

• Unveränderbare Backup-Kopien und verlängerte Aufbewahrungsfristen [bestätigen] 

• Standby-Wiederherstellungsumgebung in einer zweiten Azure-Region mit vereinbartem RTO [bestätigen] 

• Regelmäßige vollständige Disaster-Recovery-Tests mit schriftlichem Bericht [Häufigkeit bestätigen] 

• Erweiterte Sicherheitsüberwachung und Unterstützung bei Sicherheitsvorfällen [Servicezeiten und Leistungsumfang bestätigen] 

Uns ist wichtig, dass Sie bereits vor Vertragsabschluss genau wissen, welche Leistungen enthalten sind und wo zusätzliche Vereinbarungen erforderlich werden.  Nicht erst dann, wenn ein Sicherheitsvorfall eingetreten ist.  Bei der Planung eines Hosting-Projekts beginnen wir deshalb mit den RPO- und RTO-Werten, die Ihr Unternehmen tatsächlich benötigt.  Anschließend entwickeln wir ein darauf abgestimmtes Backup- und Wiederherstellungskonzept – nicht umgekehrt.  Sie denken darüber nach, SAP Business One in die Cloud zu verlagern, oder sind unsicher, ob Ihre bestehende Umgebung einem Cyberangriff standhalten würde?  Sprechen Sie mit dem Team von Ingold Solutions über eine Überprüfung Ihrer Wiederherstellungsstrategie.  Gemeinsam betrachten wir Ihre Backups, Ihre Wiederherstellungsziele und Ihre vertraglichen Vereinbarungen. Anschließend zeigen wir Ihnen offen, wo mögliche Sicherheitslücken bestehen.