How Secure Should a SAP Business One Agency Make Your Cloud ERP?
Try It For Free

Blog

How Secure Should a SAP Business One Agency Make Your Cloud ERP?

By IngoldSeptember 21,2026
Moving SAP Business One to the cloud changes more than where the servers sit. Infrastructure, user access, backups and monitoring all move into a shared setup involving SAP itself, a hosting provider, the implementation partner and the business running the system. It's easy to assume that “cloud” means “secure”, but that assumption only holds if everyone involved understands exactly what they're responsible for. A SAP Business One agency might handle implementation, configuration, integrations, user access, ongoing maintenance or hosting, and the exact split changes from one contract to the next. Before signing with a SAP Business One agency, or renewing with your current one, it's worth having a clear answer to one question: what security controls should actually be in place, and who is accountable for each of them? Quick Answer: What Security Should a SAP Business One Agency Provide? 

Quick answer 

A SAP Business One agency should provide secure user authentication, role-based access control, infrastructure and network protection, encryption in transit and at rest, documented backups, tested disaster recovery, regular patching, monitoring and logging, secure integrations, data protection measures and a documented incident-response process. The exact division of responsibility depends on who hosts and manages the environment, so it belongs in the contract, not left to assumption. 
Security Area  What Should Be Defined?  Who May Be Responsible? 
User access  Authentication and permissions  Customer + agency 
Infrastructure  Server/network security  Hosting provider/agency 
Backups  Frequency, retention, restore process  Agency/hosting provider 
SAP authorisations  Role-based access  Customer + agency 
Integrations  API credentials and permissions  Agency 
Updates  Patch/update process  Agency/customer 
Monitoring  Logs, alerts, suspicious activity  Depends on contract 
Disaster recovery  Recovery procedures  Hosting provider/agency 

Why Does SAP Business One Cloud Security Need More Than a Password? 

SAP Business One isn't a single application protecting a single type of data — it's the operational core of a business, and different modules carry very different risks if access goes wrong. 

Financial and accounting data 

SAP Business One's accounting, banking, controlling and financial reporting modules hold some of the most sensitive information any business generates: the general ledger, accounts payable and receivable, banking details, invoices and financial reports. If access to these areas isn't properly controlled, the risk isn't just a data breach — it's the kind of exposure that can affect audits, tax filings and financial statements. 

Customer and sales data 

Customer management, sales opportunities, service management and sales reporting are all built into SAP Business One as integrated capabilities, which means customer master data, pricing history, service records and pipeline information sit inside the same system as everything else. Weak access controls here don't just risk a data protection issue; they can expose commercially sensitive relationships to people who have no business reason to see them. 

Inventory and purchasing data 

SAP Business One connects procurement, inventory, warehouse management and accounting into one continuous process, including real-time stock information. Supplier terms, purchasing history, warehouse locations and pricing data all sit within reach of anyone with the right, or wrong, level of access, which is exactly why authorisation design matters as much here as it does in finance. 

Who Is Responsible for SAP Business One Cloud Security? 

This is probably the most misunderstood part of any cloud ERP conversation. Security responsibility doesn't sit with one party. It's split across four, and the split is rarely identical from one deployment to the next. 

SAP's responsibility 

SAP is responsible for the security of the SAP Business One product itself: the core application code, the platform-level vulnerabilities SAP addresses through its own release cycle, and, where applicable, the security of SAP-operated cloud services. SAP does not automatically secure a third-party hosting environment, a partner's configuration choices, or how a customer sets up its own users and permissions. Those responsibilities sit elsewhere. 

Hosting provider's responsibility 

Where SAP Business One is hosted on infrastructure managed by a hosting provider, that provider typically covers physical data-centre security, the underlying network environment, virtualisation, server availability and, where contracted, infrastructure-level backups. This layer is about keeping the servers themselves running and physically secure. It doesn't extend to how the SAP Business One application is configured or who has access inside it. 

SAP Business One agency's responsibility 

Depending on the scope of the engagement, a SAP Business One agency is usually responsible for secure implementation and configuration, setting up user permissions, securing integrations, database and server administration, patch management, backup configuration, monitoring and documentation, and escalating security incidents when they occur. An agency with established credentials, such as SAP Silver Partner status, ISO 9001 certification and documented GDPR-aligned data handling procedures, tends to have these processes formalised rather than handled ad hoc, which is worth checking during due diligence. 

Customer's responsibility 

No agency can secure decisions that sit entirely with the customer. Approving who gets access, setting internal password and access policies, onboarding and offboarding employees promptly, reviewing privileges periodically, securing endpoints such as laptops, phones and remote connections, and reporting suspicious activity all remain the customer's job, regardless of how the hosting and implementation are structured.
Security Area  SAP  Hosting Provider  SAP B1 Agency  Customer 
Core product security patches  Primary  —  —  — 
Physical data-centre security  —  Primary  —  — 
Implementation & configuration  —  —  Primary  — 
Backup configuration  —  Shared  Shared  — 
Patch installation  —  —  Typically  Approves 
User access approval  —  —  —  Primary 
Internal password policy  —  —  —  Primary 
Integration security  —  —  Primary  — 
Monitoring & alerting  —  —  Shared  — 
Incident response coordination  —  —  Shared  Shared 
This is a general pattern, not a fixed rule. The actual split should always be confirmed in writing for each specific engagement. 

10 Security Controls to Expect From a SAP Business One Agency 

The list below isn't exhaustive, but it covers the controls that should come up in almost any conversation with a competent SAP Business One agency. If several of these are met with vague answers, that's worth noting. 

  1. Strong Authentication and Secure User Access

Every SAP Business One user should have their own individual login, not a shared account passed between colleagues and not a generic “warehouse” or “finance” credential used by several people. Shared logins make it impossible to know who actually did what inside the system, which becomes a real problem the moment something goes wrong. A properly configured environment should also enforce a reasonable password policy, offer multi-factor authentication where the deployment supports it, and treat remote access and administrator accounts with tighter controls than standard user accounts.  Should every SAP Business One user have their own login? Yes. Individual accounts are the baseline for any audit trail, and they're one of the first things worth checking in an existing environment.

  1. Role-Based Access and SAP Authorisations

Access should follow the principle of least privilege: people get what they need to do their job, and nothing more. Finance employees shouldn't automatically receive unrestricted system administration privileges, and warehouse staff shouldn't have access to modules they never touch. SAP Business One's authorisation system supports this kind of role-based structure, but it has to be deliberately configured; the default setup won't do this on its own. Sensitive financial transactions and administrative functions should sit behind tighter permissions, and access should be reviewed periodically rather than set once at go-live and left alone. 

  1. Secure Cloud Infrastructure and Network Configuration

Underneath the application layer, the infrastructure itself needs proper configuration: firewalls set up correctly, network segmentation between systems, administrative ports restricted rather than left open to the internet, remote administration secured, servers hardened, and production kept separate from test environments. Unused services should be removed rather than left running, since every open service is one more thing that needs to be patched and monitored.  Ask who can access the server: Who has administrator-level access to our SAP Business One cloud environment, and how is that access controlled and audited? If the answer is vague, that's a gap worth closing before go-live.

  1. Encryption for Data in Transit and at Rest

These are two different things, and it's worth understanding the distinction. Encryption in transit protects data as it moves, between a browser and the server, across APIs, through remote connections and integrations. Encryption at rest protects data where it's stored, in the database, in backup storage, and in other locations where business information sits when it isn't actively being used.  Worth asking: Is our SAP Business One data encrypted both while it's stored and while it's being transmitted? Not every deployment applies the same encryption configuration by default, so this is worth confirming rather than assuming. 

  1. A Documented Backup Strategy

“We take daily backups” isn't really an answer on its own. A properly documented backup strategy should cover how often backups run, where they're stored, how long they're retained, whether they're encrypted, whether copies are kept separate from the production environment, who can access them, and, critically, when the last successful restore was actually tested.  Backup is not the same as disaster recovery. A backup is a recoverable copy of data. Disaster recovery is the documented process and infrastructure used to actually restore business operations after a serious disruption. An agency that only talks about the former hasn't really answered the question.

  1. A Tested Disaster-Recovery Plan

Two figures matter here, and any SAP Business One agency should be able to discuss both without hesitation. 
Term  What It Means 
Recovery Time Objective (RTO)  How quickly service should be restored after a disruption. 
Recovery Point Objective (RPO)  How much recent data could potentially be lost, measured as time since the last usable backup. 
An agency that can only say the system is “backed up” hasn't given you an RTO or an RPO, which means there's no agreed standard for how fast, or how completely, the business gets back online. 

  1. Patch, Update and Vulnerability Management

An ERP environment can't simply be deployed and left alone. SAP Business One itself needs updates, as does the underlying database, the operating system, and any third-party components, add-ons or integration middleware connected to it. Each of these is a separate patching stream, and none of them should be ignored indefinitely.  Who is responsible for installing security updates? This needs an explicit answer in the contract or SLA rather than being left as an assumption on either side. Businesses sometimes only discover, after an incident, that neither party believed patching was their job.

  1. Secure SAP Business One Integrations

SAP Business One rarely operates in isolation. E-commerce platforms, CRM systems, payment providers, logistics tools, banking connections, document management systems, APIs and third-party add-ons all commonly connect into it, and each connection is a potential entry point if it isn't secured properly.  API credentials and secrets deserve particular attention: they shouldn't be hard-coded into scripts or configuration files, access should be restricted to what's necessary, credentials should be rotated periodically, and different services should use separate credentials rather than sharing one set across everything. Integration permissions should follow a simple principle: an integration should receive only the access it actually requires, nothing broader. 

  1. Logging, Monitoring and Auditability

Where technically available, login activity, failed authentication attempts, administrative actions, system errors, integration failures, unusual behaviour and infrastructure health should all be logged. But logging on its own doesn't provide security; someone actually has to review it.  Who reviews the logs? This is a genuinely useful question when comparing agencies, because plenty of environments generate logs that nobody looks at until after something has already gone wrong.

  1. Secure Employee Offboarding

This is a practical, often overlooked area. Accounts need to be handled properly whenever an employee leaves, an administrator changes role, an external consultant finishes a project, or a third-party supplier no longer needs access. A reasonable offboarding sequence looks like this: 
  1. Disable the account 
  1. Revoke remote access 
  1. Remove privileged permissions 
  1. Rotate any shared or API credentials the person had access to 
  1. Review what they accessed recently 
  1. Document that the process was completed 
Skipping any of these steps leaves a door open that's easy to forget about. 

How Should a SAP Business One Agency Protect Backups From Ransomware? 

Ransomware specifically targets backups, because an attacker who can encrypt or delete recovery copies removes the business's ability to recover without paying. A sound approach typically involves keeping backup copies separated from the production environment, restricting who can access backup storage, maintaining retention and versioning so a single corrupted backup doesn't wipe out the recovery point, using offline or logically isolated copies where appropriate, testing restores regularly, and actively monitoring for failed backup jobs rather than only noticing when a restore is actually needed.  No agency should describe any system as “ransomware-proof”; that's not a realistic claim for any environment. What's reasonable to expect is a documented, tested approach that reduces the risk and gives the business a real recovery path if the worst happens. 

How Does GDPR Affect SAP Business One Cloud Security? 

For businesses operating in Germany and across the EU, GDPR sits on top of every security decision made about SAP Business One, since the system holds personal data, including employee records, customer details and contact information, throughout its financial, sales and service modules. Relevant considerations include how personal data is accessed and by whom, data minimisation, retention periods, the role of processors and sub-processors, hosting location and any applicable data transfer arrangements, how incidents involving personal data are handled, and how deletion and retention are actually managed in practice.  For businesses in Germany specifically, backup and retention decisions also need to sit alongside GoBD requirements for proper financial record-keeping, which is one more reason retention policy shouldn't be treated as a purely technical decision.  This section is general information, not legal advice. GDPR compliance depends on the specifics of each business, and a data protection professional should be involved in any formal compliance assessment. 

Ask Where Your SAP Business One Data Is Hosted 

Before signing, it's worth establishing which country or region the data is hosted in, who the hosting provider is, where backup copies are stored, what transfer arrangements apply if data crosses borders, and who has access to the environment. These answers should be available without difficulty. If they aren't, that's worth treating as a warning sign. 

What Should Be Included in a SAP Business One Agency Security SLA? 

A security SLA should go well beyond an uptime percentage. It's worth looking for availability commitments, support hours, response times, defined severity levels, clearly assigned backup responsibility, recovery commitments (ideally with agreed RPO and RTO figures), a security incident escalation process, patching responsibility, monitoring arrangements, maintenance windows, disaster recovery provisions, and a documented process for exporting data if the business ever changes providers. 

What Happens After a Security Incident? 

A mature SLA should describe a process along these lines: Detection → containment → investigation → recovery → communication → remediation → review If an agency can't describe this sequence, or treats “we'll deal with it when it happens” as a sufficient answer, that's a gap worth raising before signing anything. 

15 Security Questions to Ask a SAP Business One Agency Before Signing 

  1. Where will our SAP Business One environment be hosted? 
  1. Who has administrator access? 
  1. How is privileged access controlled? 
  1. What authentication controls are available? 
  1. How are SAP authorisations configured? 
  1. How often are backups taken? 
  1. Where are backup copies stored? 
  1. How often are restores tested? 
  1. What are the agreed RPO and RTO? 
  1. Who installs security patches and updates? 
  1. How are third-party integrations secured? 
  1. What activity is logged and monitored? 
  1. What happens when an employee or consultant leaves? 
  1. What is the security-incident response procedure? 
  1. How can we retrieve our data if we change providers? 

Red Flags When Evaluating a SAP Business One Agency 

None of these should be treated as an automatic disqualifier on their own, but a pattern of vague answers across several of them is worth taking seriously. 
  • Unable to clearly document who is responsible for backups 
  • No defined restore-testing process, or no evidence that restores have ever been tested 
  • Unrestricted or poorly controlled administrator access 
  • Unclear or evasive answers about hosting arrangements 
  • No formal employee offboarding procedure 
  • No agreed incident escalation process 
  • Vague answers about who maintains integrations and third-party components 
SAP Business One Cloud Security Checklist 
Check  Verify 
Hosting  Provider and data location documented 
Authentication  Access controls defined 
Authorisations  Least-privilege roles configured 
Encryption  Protection requirements documented 
Backups  Frequency and retention defined 
Restore testing  Regular tests documented 
Disaster recovery  RPO/RTO agreed 
Patching  Ownership and schedule defined 
Integrations  Credentials and permissions secured 
Monitoring  Logging responsibilities established 
Offboarding  Access-removal procedure documented 
Incident response  Escalation process agreed 

Security Should Be Defined, Not Assumed 

Choosing a SAP Business One agency isn't only about implementation expertise, however important that is. It's also about knowing, in writing, who is responsible for access, infrastructure, backups, recovery, patching, integrations, monitoring and incident response, and having those responsibilities documented rather than assumed by either side.  If you're evaluating a new SAP Business One agency, or you simply want a clear picture of how your current cloud environment is actually secured, a structured security and readiness assessment is a more useful starting point than a generic sales conversation. Ingold Solutions GmbH — SAP Silver Partner, Microsoft Solutions Partner and ISO 9001–certified, delivering across Germany and India — can walk through exactly where responsibility sits across SAP, your hosting provider, your agency and your internal team, and flag the gaps worth closing before they become a problem. 

Frequently Asked Questions

SAP Business One can be run securely in the cloud, but security isn’t automatic just because the system is cloud-hosted. It depends on how authentication, access, encryption, backups and monitoring are configured by SAP, the hosting provider, the implementing agency and the customer together, and on whether those controls are documented and actually maintained over time.

Responsibility is shared across four parties: SAP for the core product, the hosting provider for physical infrastructure, the SAP Business One agency for implementation, configuration and integrations, and the customer for internal access policies and endpoint security. The exact split should be defined in the contract rather than assumed by any party.

Useful questions cover hosting location, administrator access, authentication controls, backup frequency and retention, restore testing, agreed RTO and RPO, patch responsibility, integration security, monitoring and logging, offboarding procedures, incident response, and how data can be exported if you change providers later.

Yes. SAP Business One’s authorisation system supports role-based access, allowing permissions to be configured by department, function and transaction sensitivity. This needs deliberate setup during implementation, since the default configuration doesn’t automatically apply least-privilege principles, so it’s worth reviewing during onboarding and periodically afterward. 

Backup frequency should reflect how much data the business can afford to lose, defined by the Recovery Point Objective (RPO). Many businesses back up daily at minimum, with more frequent backups for high-transaction environments. The agreed frequency, retention period and restore-testing schedule should all be documented rather than assumed. 

A backup is a recoverable copy of data. Disaster recovery is the broader, documented process and infrastructure used to restore business operations after a serious disruption, including agreed recovery time and recovery point objectives. Having backups doesn’t automatically mean a business has a tested disaster-recovery plan. 

In most engagements, yes; agencies typically need administrative or elevated access to implement, configure and maintain the system. This makes it important to understand exactly what level of access the agency holds, how that access is controlled and audited, and what happens to that access once the engagement ends or changes scope.

Integrations should use restricted, non-hard-coded API credentials that are rotated periodically, with separate credentials for each connected service rather than one shared set. Each integration should receive only the access and permissions it actually needs to function, following the same least-privilege principle applied to internal user accounts. 

This should be defined in the SLA before the relationship starts, not negotiated during an exit. A well-structured agreement includes a documented data export and handover process, covering how access is transferred, how credentials are rotated, and how the outgoing agency’s access is formally removed. 

Start with the checklist and questions covered in this article: confirm who holds administrator access, check when backups were last successfully restored, review whether access follows least-privilege principles, and ask for the agreed RTO and RPO. A structured security and readiness assessment can formalise this into a documented review.

Recent Posts

How Secure Should a SAP Business One Agency Make Your Cloud ERP?

September 21,2026

Your SAP Business One Agency Says You Need an Add-On. Do You Really?

September 21,2026

How Secure Is SAP Business One Cloud? A Practical Guide for SMBs

September 21,2026

 
 
 
 
  AUSGEZEICHNET  
 Google star 1Google star 2Google star 3Google star 4Google star 5 
 Basierend auf 6 Bewertungen 
  
 
 
 
 
 
 
 
  
 
 
 
 Gepostet auf Google Google 
 
 Rene Emser profile picture 
 
 
 Rene Emser 
 
 
 
 Google star 1Google star 2Google star 3Google star 4Google star 5Trustindex überprüft, ob die Originalquelle der Bewertung Google ist. 
Wir bei Hochzeitsrausch Brautmoden sind sehr zufrieden mit der Zusammenarbeit mit Ingold Solutions. Besonders hervorzuheben sind die schnelle Reaktionszeit und der freundliche Service. Ingold Solutions hat unsere WordPress- und Shopify-Seiten überarbeitet und wichtige Funktionen hinzugefügt, wie zum Beispiel eine Terminbuchungsfunktion. Auch die Migration unserer Geschäftsdaten in die Microsoft 365 Cloud verlief reibungslos und hat unsere Arbeitsabläufe spürbar verbessert. Durch die Integration von SAP Business One sind unsere Online- und Offline-Systeme jetzt optimal aufeinander abgestimmt. Wir können Ingold Solutions für ihre technische Expertise und maßgeschneiderten Lösungen uneingeschränkt empfehlen.
  
 
  
 
 
 
 Gepostet auf Google Google 
 
 Uwe L profile picture 
 
 
 Uwe L 
 
 
 
 Google star 1Google star 2Google star 3Google star 4Google star 5Trustindex überprüft, ob die Originalquelle der Bewertung Google ist. 
Die Kooperation mit der Ingold Solutions GmbH als unserem Lösungspartner für SAP Business One war für die MIP Consult GmbH eine äußerst positive Erfahrung. Ingold hat uns mit einem maßgeschneiderten Paket beliefert, das ihre umfassende Kenntnis unserer Anforderungen widerspiegelt. Ihr Team hat die SAP-Datenbank effizient konfiguriert, umfangreiche Schulungen angeboten und die Stammdaten sorgfältig hochgeladen, was einen reibungslosen Übergang ermöglichte. Die Implementierung des Multi-Banking-Systems zeugt weiter von ihrer fachlichen Kompetenz und ihrem Engagement für ganzheitliche Lösungen. Die Professionalität und Einsatzbereitschaft von Ingold haben unseren Übergang äußerst effizient gestaltet, und ihre kontinuierliche Unterstützung ist von unschätzbarem Wert. Wir können Ingold Solutions GmbH wärmstens empfehlen für Unternehmen, die erstklassige SAP-Lösungen und exzellenten Service.
  
 
  
 
 
 
 Gepostet auf Google Google 
 
 Dawid Telesinski profile picture 
 
 
 Dawid Telesinski 
 
 
 
 Google star 1Google star 2Google star 3Google star 4Google star 5Trustindex überprüft, ob die Originalquelle der Bewertung Google ist. 
Ingold Solutions GmbH hat für Numiartis eine effiziente Lösung entwickelt, die als B2B-E-Commerce-Portal und Online-Katalog dient und B2C-Bestellungen vereinfacht. Das verbesserte Design ermöglicht eine reibungslose Navigation und effiziente Kundenregistrierung, was zur Kundengewinnung beiträgt. Dank der Magento Open Source Plattform ist auch die Produkt-Navigation optimiert worden. Wir sind sehr zufrieden mit dem bedeutenden Beitrag von Ingold Solutions zur digitalen Erweiterung unseres Unternehmens.
  
 
  
 
 
 
 Gepostet auf Google Google 
 
 Attila Totos profile picture 
 
 
 Attila Totos 
 
 
 
 Google star 1Google star 2Google star 3Google star 4Google star 5Trustindex überprüft, ob die Originalquelle der Bewertung Google ist. 
Ingold Solutions proved to be an invaluable partner for Pyronova IS Deutschland GmbH during our recent implementation. Their team seamlessly configured our accounting system, and their expertise was evident as they provided a dedicated German accounting expert, ensuring precise setup tailored to our needs. Furthermore, Ingold's commitment to customization shone through as they worked on seamless and precise configuration of our accounting system within SAP Business One. This addon will undoubtedly elevate our financial operations. Their professionalism, expertise, and dedication to our project's success were exemplary. We highly recommend Ingold Solutions for their exceptional service and comprehensive support throughout our implementation process. Attila Totos Head of Finance Dep. Pyronova
  
 
  
 
 
 
 Gepostet auf Google Google 
 
 Thomas Schneider profile picture 
 
 
 Thomas Schneider 
 
 
 
 Google star 1Google star 2Google star 3Google star 4Google star 5Trustindex überprüft, ob die Originalquelle der Bewertung Google ist. 
Von Anfang an beeindruckte uns Ingold Solutions mit ihrer Umsetzung von SAP Business One. Sie erfüllten effizient unseren Bedarf an Benutzerlizenzen und integrierten diese in die robuste Infrastruktur von Cloudiax's Private Cloud. Unsere Entscheidung für das Standardpaket wurde dank Ingold Solutions' Geschäftsblueprint-Vorlage präzise umgesetzt, was zu einer perfekten Datenbankkonfiguration führte und unsere Betriebsstruktur optimierte. Ingold Solutions bot mit ihrer Expertise wertvolle Unterstützung. Ihr technisches Team sorgte nicht nur für die richtigen Änderungen, sondern integrierte sie auch nahtlos in die Cloudiax-Umgebung. Die von Ingold Solutions eingesetzten Technologien - von der Private Cloud in Cloudiax über SAP B1 mit HANA bis zum SAP Business One Standard Package - zeugen von einem durchdachten Ansatz, der auf betrieblichen Erfolg ausgerichtet ist. Absolut professionell, nur zu empfehlen! winwall GmbH
  
 
  
 
 
 
 Gepostet auf Google Google 
 
 Markus Beck profile picture 
 
 
 Markus Beck 
 
 
 
 Google star 1Google star 2Google star 3Google star 4Google star 5Trustindex überprüft, ob die Originalquelle der Bewertung Google ist. 
Schnelle und kompetente Umsetzung zu fairen Preisen mit fähigen Mitarbeitern. Danke
  
 
  
 
 
 
   
 
 Verifiziert von: Trustindex  
Das verifizierte Trustindex-Abzeichen ist das universelle Symbol des Vertrauens. Nur die besten Unternehmen können das verifizierte Abzeichen erhalten, die eine Bewertungsnote über 4.5 haben, basierend auf Kundenbewertungen der letzten 12 Monate. Mehr erfahren
Become a Partner Become a Partner