Ask a managing director what their ERP is worth and they'll usually talk about licence fees. Ask them what a week without it would cost, and the answer gets a lot more interesting. No invoices go out. Nobody can see stock levels. Purchase orders stop. Month-end closing turns into a spreadsheet exercise that nobody trusts.  That is the real question behind moving SAP Business One to the cloud. It isn't whether the cloud is "secure" in some general sense. It's whether your business can get its financial and inventory data back, quickly and completely, after something goes badly wrong.  And sooner or later, something probably will. Bitkom asked German companies with ten or more employees about the past year, and 58% said a cyberattack had caused them real damage. Fewer of them feel ready, too. Only 43% now describe themselves as very well prepared, compared with 50% the year before. Look at Verizon's 2026 Data Breach Investigations Report and ransomware is involved in almost half of all confirmed breaches (48%, to be exact). The bill keeps climbing as well: IBM's latest figure for the average cost of a breach worldwide is USD 4.99 million, the highest it has ever recorded. 

Is SAP Business One Cloud safe from ransomware? 

Not in the sense of "it can't happen to us." Ransomware can hit any ERP, in the cloud or on a dusty server in the back office. What good hosting changes is how bad the damage gets. If the backups are locked away where attackers can't touch them, everyone logs in with a second factor, someone is actually watching for odd behaviour, and the recovery plan has been tried at least once, an attack becomes a bad week rather than a disaster. The word "cloud" on the contract doesn't do any of that for you. How the environment is built and run does. 

What Happens When a Ransomware Attack Disrupts Your ERP? 

Here's the odd thing. Attackers almost never break into the ERP first. They get in through something boring: a reused password, a well-written fake invoice email, a VPN box nobody got round to patching last month. That last route is now the most common one. Verizon's 2026 DBIR found exploited software flaws behind 31% of breaches, which put them ahead of stolen logins for the first time. Small firms get the worst of it, too. In the 2025 report, ransomware featured in 88% of SMB breaches. For large companies the figure was 39%.  What happens next is depressingly familiar. Picture a Friday evening. Someone has had quiet access to your network for a week or two and has spent that time looking around. By now they know which server runs your SQL Server or HANA database. They know where the attachments folder lives, and which accounts have admin rights. Before doing anything noisy, they go looking for your backups, because a company with working backups is a company that doesn't pay. Then they copy out what's worth selling or threatening to leak: customer lists, prices, bank details, payroll. Only after all that do they encrypt. They do it at 2 a.m. on a Saturday, when nobody's watching.  Monday morning is when you find out. Nobody can post an invoice, pick an order or book a delivery. Then the knock-on effects show up. Orders from the web shop pile up or vanish. EDI messages to your retail customers bounce. The banking add-on stops matching payments. By Wednesday the questions are different and much harder. What did they take? Who do we have to tell? And once the system is back, can we actually trust the numbers in it?  That third question catches a lot of companies out. Getting SAP Business One to start again is one thing. Being able to show your auditor, or the authorities under Germany's NIS2 law (in force since 6 December 2025), that the books are complete and correct is quite another. 

Are Cloud Backups Enough to Protect Financial and Inventory Data? 

Backups are essential. On their own, they aren't enough.  The problem is that attackers know exactly how much backups matter. Sophos studied almost 3,000 organisations hit by ransomware, and 94% said the attackers had tried to compromise their backups. Where the attempt worked, median recovery costs were around eight times higher. Recovery was slower too: just 26% of those organisations were fully back within a week, against 46% of those whose backups survived.  So the question for SAP B1 backup and recovery isn't "do we have backups?" It's "would our backups still be there, and still be clean, if someone had admin rights to our environment for three days?" To answer yes, a few things need to be true: 

• At least one copy is immutable. Nobody can change or delete it during the retention period, including an administrator and including the hosting provider's own staff. 

• Backups sit outside the production account, with separate credentials. If one admin password unlocks both production and the backup vault, you really only have one layer. 

• Everything is in scope, not just the company database. That means SBO-COMMON, the attachments folder, add-on settings, integration configuration and print layouts. If a restored database has no attachments and broken add-ons, finance still can't work. 

• Retention reaches back far enough. Attackers often sit in a network for weeks before they strike. If you keep only seven days of backups, every one of them may already be infected. 

What is the difference between ERP backup and disaster recovery? 

A backup is a copy of your data. Disaster recovery is the tested plan, infrastructure and people that turn that copy back into a working system: servers, licences, integrations, user access and validated data, within an agreed time. You can have excellent backups and still need two weeks to get back up and running. Backup is what you have; disaster recovery is what you can do with it. 

RPO vs RTO: How Much Data and Downtime Can Your Business Afford? 

These two acronyms appear in every hosting proposal. They are also the two numbers a managing director should agree on personally, because they are business decisions, not technical ones. 

Term	What it measures	The business question behind it
RPO (Recovery Point Objective)	The most data you can afford to lose, measured in time	If we roll back to the last good copy, how many hours of orders, postings and goods movements are gone?
RTO (Recovery Time Objective)	The longest you can afford to be without the system	How long can we go without invoicing, shipping or paying suppliers before it really hurts?

There's a catch that many SLAs skip. An RPO of 15 minutes only helps if the backup from 15 minutes ago is clean. If attackers were inside for two weeks, you may need to restore to a point before they arrived, then rebuild everything since from bank statements, shop orders and paper. That's why retention and malware scanning of backups matter as much as backup frequency. 

One attack, three very different weeks 

Let's make this concrete. The company below is made up, but anyone who has worked on SAP Business One projects will recognise it.  Picture a wholesale distributor with about 40 people working in SAP Business One every day. Orders come in through a web shop, and two big retail chains send theirs by EDI. On a Tuesday afternoon, at around two o'clock, the screens freeze. By quarter past, someone in accounts is reading a ransom note.  What happens next depends almost entirely on decisions made months earlier.  Version one: a nightly backup and not much else. The last good copy was taken at one in the morning. Everything since then is gone: thirteen hours of orders, deliveries and postings. That's bad, but it isn't the worst part. Nobody ever set up a place to restore into, so the servers have to be built from scratch. Then SAP Business One goes back on and each add-on is configured again, from memory in places. Realistically, the business is offline for three to five working days. When it does come back, someone still has to dig out every web shop order and EDI message from that Tuesday and type them in by hand. Version two: good backups, but no rehearsal. This company did spend money in the right place. Log backups run every 15 minutes and sit in a vault the attackers couldn't touch, so very little data is lost. The trouble is that nobody has ever actually done a full restore. The first day goes on hunting for licence keys, working out which firewall rules the shop connector needs, and finding the one person who knows the EDI password. They're back in about two days. The data survived, but two days of standstill still costs a great deal. Version three: immutable backups and a plan someone has practised. Here the provider already has a clean recovery environment waiting in a second region, and the team ran a full test six months ago. They pick the last backup they know is clean, restore it, then bring integrations and users back in an agreed order, working from a checklist they've already used. Users are working again by the end of the day. Finance spends a few hours checking balances and open items, and the data loss is measured in minutes. There's one caveat. That only holds if the attackers hadn't been sitting in the system for weeks before they struck. If they had, the clean point is further back, and even this company has some re-keying to do.

How quickly can SAP Business One be restored after an outage? 

It depends almost entirely on preparation. With immutable backups, a prepared recovery environment and a tested runbook, restoring SAP Business One within hours is realistic. Without them, it often takes several working days. The best predictor is when your provider last completed a full recovery test, and how long it actually took. 

What Should an ERP Disaster Recovery Test Include? 

Most companies we speak to have a disaster recovery plan. Ask when it was last tried out, though, and the room usually goes a bit quiet. A plan that has never been run is really just a hopeful document.  Restoring a database and seeing that it opens doesn't count as a test either. That's step one of about eight. A proper SAP Business One recovery test should happen at least once a year, and again after any big upgrade. Here's what we'd want to see in one.  Start by bringing the system back somewhere completely separate from production. In a real ransomware attack you can't trust the live environment, so the test shouldn't lean on it either. Then restore all of it. The company database is the obvious part, but SBO-COMMON, the attachments folder, add-ons, the licence service, print layouts and user permissions all have to come back too. Leave any of those out and finance still can't send an invoice.  Don't just grab the newest backup. Pretend the attackers got in three weeks ago and practise finding a restore point from before that date. In a real incident, that's often the hardest call to make.  Next come the integrations: the web shop, EDI, banking, payroll, the scanners in the warehouse. Reconnect them and check what happens to everything that queued up while the system was down. Do orders come through once? Twice? Not at all?  Then hand it over to the people who use it every day. Someone from finance should compare the trial balance, open items and stock values against figures they trust. IT can tell you the system is up. Only finance can tell you the numbers are right.  Keep a stopwatch running the whole time, from the moment someone says "this is a disaster" to the moment users are back at work. If that total is well over the RTO in your contract, you've learned something important. Far better to learn it in a test than with customers on the phone.  Test the people as well as the systems. Who actually declares the incident? Who rings the insurer? Who decides whether to notify the authorities? If you fall under NIS2, the first notification of a significant incident is due within 24 hours, which isn't long when nobody is sure whose job it is.  Finally, write up what went wrong, because something will. We've rarely seen a first test go perfectly, and that's fine. Finding the problems is the whole point.  One last piece of advice: get the test date written into the hosting contract, and go through the results at your regular service review. If a provider hesitates to commit to that, take note. 

Which Security Responsibilities Belong to the Hosting Provider? 

This is where misunderstandings get expensive. Moving SAP Business One to the cloud moves some responsibilities to your provider, but not all of them. Some stay with you whatever the contract says. Most disputes after an incident come down to an assumption about who was doing what.  The split below is typical for a managed SAP Business One Cloud service. Your contract should confirm each line, in writing.

Area	Usually the hosting provider	Usually your company	Often a separately priced service
Data centre, hardware, cloud platform	✓
Operating system and database patching	✓
SAP Business One version upgrades	Shared	Testing and sign-off	Sometimes
Daily backups with standard retention	✓
Immutable copies and long retention			✓
Standby environment in a second region			✓
Annual full DR test	Shared	Data validation	✓
Network firewall and secure remote access	✓
Multi-factor authentication	Provides it	Enforces it for every user
User accounts and authorisations		✓
Security of staff laptops and email		✓
24/7 security monitoring and response			✓
Staff awareness training		✓
Accuracy of business data		✓

Two items deserve extra attention. The first is multi-factor authentication. The provider can switch it on, but if users are allowed to opt out, or a shared admin account doesn't use it, the protection is hollow. The second is monitoring. Plenty of providers watch whether the server is up. Far fewer watch for suspicious logins, unusual data exports or someone quietly deleting backup jobs. Bitkom's 2026 findings point the same way: among German companies that had been successfully attacked, gaps in detecting security incidents, misconfigurations and weak identity and access management came up again and again as contributing causes. Encryption is the other one to pin down. Data should be encrypted at rest on the database and backup storage, and in transit between users and the server. Ask who manages the keys, and whether backups are encrypted with different keys from production.

Seven Questions to Ask Before Signing a Cloud Hosting Contract 

Take these into your next meeting with a provider. The answers, and how readily they come, will tell you most of what you need to know. 

1. What are the RPO and RTO, and are they written into the contract? "Best effort" isn't a number. Ask what happens, commercially, if a target is missed. 

1. Is at least one backup copy immutable, and who could delete it? The right answer is "nobody, not even us, until the retention period ends." 

1. Where do backups and the recovery environment live? Ask for the region and the legal entity. For most European SMEs, data should stay in the EU. The recovery site should not share credentials or a single point of failure with production. 

1. When did you last run a full recovery test for a customer like us, and how long did it take? Ask to see an anonymised test report. 

1. What exactly is monitored, by whom, and when? Find out whether anyone watches security events outside office hours or only uptime, and how quickly you'd be called. 

1. What's in the base price, and what costs extra? Get a line-by-line list for long retention, a standby environment, DR tests, after-hours incident response and help with forensics. 

1. What do you need from us during an incident? Ask who your named contacts are, what decisions you'll have to make, and how the provider supports NIS2 reporting and insurance claims. 

If you're comparing two or three providers, put the answers side by side in one table. The differences tend to jump out quickly. 

How Ingold Solutions Approaches SAP Business One Cloud Security 

Ingold Solutions is a Berlin-based SAP Business One partner with teams in Germany and India. We sell SAP Business One licences, implement the system, build SAP-certified add-ons, and host and support it, so the people running your hosting are the same people who know your configuration. That matters in a recovery. Rebuilding a bare system is the easy part. The hard part is getting your add-ons, integrations and layouts working again.  We host SAP Business One on Microsoft Azure, and we are upfront about what each service level includes. In broad terms: 

Included as standard in Ingold SAP Business One Cloud hosting 

• Managed Azure infrastructure, with operating system and database patching 

• Automated backups of company databases, SBO-COMMON and attachments [confirm frequency and retention] 

• Encryption of data at rest and in transit 

• Secure remote access with multi-factor authentication available to every user 

• Infrastructure and availability monitoring 

Available as additional or separately contracted services 

• Immutable backup copies and extended retention [confirm] 

• A standby recovery environment in a second Azure region, with an agreed RTO [confirm] 

• Scheduled full disaster recovery tests with a written report [confirm frequency] 

• Extended security monitoring and incident response support [confirm hours and scope] 

We'd rather you knew exactly where the line sits before you sign than discovered it during an incident. When we scope a hosting project, we start with the RPO and RTO your business actually needs. Then we design the backup and recovery set-up around those numbers, not the other way round.  Thinking about moving SAP Business One to the cloud, or not sure your current set-up would survive an attack? Talk to the Ingold Solutions team about a recovery review. We'll look at your backups, your recovery targets and your contract, and tell you plainly where the gaps are.