Cloud ERP Security: ISO 27001, Hosting Location & Backup

First things first: you don't judge cloud ERP security by the marketing promise of "bank-grade safety" but by six verifiable building blocks – certifications like ISO 27001 and BSI C5, the data residency location of the servers, encryption in transit and at rest, a tested backup and disaster recovery concept, a binding SLA with a guaranteed availability figure, plus clean access protection via multi-factor authentication. If any one of these blocks is missing, the risk is real – from business interruption to a GDPR breach. This article shows you which evidence to request before signing and which questions belong in your requirements spec. Legally binding assessments of data processing are best clarified with your data protection officer when in doubt.

Certifications: ISO 27001 and BSI C5

Certificates are the fastest way to gauge a provider's security maturity objectively – provided you check not only whether one exists, but what it covers.

Reading ISO 27001 correctly

ISO 27001 is the international standard for information security management systems (ISMS). It attests that the provider systematically records risks, defines controls and has them regularly reviewed by an accredited audit body. Important: ask to see the scope. A certificate that only covers corporate headquarters but not the operation of your ERP data center is of little help to you. Check the issue date, the certifier and whether the operation of the ERP platform is explicitly within scope.

BSI C5 and further evidence

The C5 criteria catalogue (Cloud Computing Compliance Criteria Catalogue) from the German Federal Office for Information Security (BSI) is the more meaningful proof for cloud services in the German-speaking market. Unlike a plain certificate, a C5 attestation delivers an audit report at test depth "Type 2", which demonstrates the effectiveness of controls over a period of time – not just their existence on a single reference date. SOC 2 reports can additionally be relevant for internationally hosted solutions, as can regular penetration tests by independent third parties. Ask specifically for the date of the last pentest and whether the findings were remediated.

Server location and data residency

Where your data physically resides determines the legal situation. Data residency refers to the geographic storage location – for DACH companies, a data center in the EU (ideally Germany, Austria or another EU country) is the safe default. The reason lies in the GDPR: as soon as personal data – customers, suppliers, employees – is transferred to a third country outside the EU, you need a valid legal basis, such as standard contractual clauses.

There are two points you should always check:

• Primary and backup location. Some providers host production in the EU but replicate backups to other regions. Both locations must fit your compliance requirements.
• Data processing agreement (DPA). A clean data processing agreement is mandatory for every SaaS ERP. It governs subprocessors, instruction rights and the notification chain in case of incidents.

A plain "yes" to the question "Do you host in the EU?" is not enough – get the region and DPA in writing. If you want to dig into the hosting basics, you'll find them in the glossary under hosting.

Encryption: in transit and at rest

Good encryption works at two points. In transit, TLS (at least 1.2, better 1.3) protects the connection between browser, app and server – recognizable by HTTPS. At rest, the data is stored in encrypted form on the storage media, typically with AES-256. This second layer is the one providers like to keep quiet about in marketing: only if the data at rest and the backups are also encrypted do they remain unreadable in the event of physical theft or a compromised storage system.

Additionally ask about key management – who manages the keys, how are they rotated, and is there an option for customer-managed keys for particularly sensitive industries. For the audit-proof storage of documents, audit-proof retention is added on top of encryption: data must remain traceable and unalterable, which is a matter for GoBD-compliant archiving.

Backup and disaster recovery

A backup is the copy of your data; disaster recovery is the tested plan to bring operations back up after an outage. The two belong together – a backup that cannot be restored when it matters is worthless.

Understanding RPO and RTO

Two metrics from the RPO/RTO concept should appear in your contract:

An RPO of 24 hours means: in the worst case you lose a day's worth of bookings, orders and documents. For an active ERP, that is often too much – clarify whether shorter intervals are possible.

Geo-redundancy and recovery

Serious providers replicate data across multiple, geographically separate locations (high availability), so that the failure of one data center does not mean the end. What is decisive, however, is the documented and rehearsed recovery plan. Have them confirm that restore drills take place and are logged – a backup that has never been restored is an unproven assumption.

SLA and availability

The Service Level Agreement (SLA) contractually defines the assured availability. A figure like "99.9%" sounds good but means roughly 8.8 hours of downtime per year. Whether that is a lot or a little depends on your business – a pure office operation tolerates more than an online retailer whose order processing runs around the clock.

Watch for these details in the fine print:

• What counts as downtime? Planned maintenance windows are often excluded from the availability calculation.
• Response time vs. resolution time. A fast response is of little use without a committed resolution time.
• Consequences of a breach. Are there service credits – or just a non-binding promise?

These points belong in the contract negotiation, not on the product slide. A structured ERP consulting engagement helps tailor SLA clauses realistically to your needs, instead of accepting standard values unchecked.

MFA and access protection

Most real-world incidents don't start with a breached data center but with a stolen password. That's why multi-factor authentication is the single most effective protection for your cloud ERP: even if a login is stolen, the attacker lacks the second factor. Check whether MFA can be enforced for all users – not just offered as an option.

On top of that comes a clean roles and permissions concept: each user only gets the permissions they need (least privilege). For larger organizations, single sign-on via your own identity provider is practical and improves security. And a complete audit trail that records who changed what and when is the prerequisite for traceability in the event of an audit.

Cloud ERP security: your pre-signing checklist

Ask the provider for this evidence specifically before you sign:

• Certificates with scope: ISO 27001 and/or C5 attestation, issue date, certifier.
• Server location in writing (primary and backup) plus a ready-to-sign DPA.
• Encryption at rest and in transit, including backup encryption.
• Backup concept with RPO, RTO, retention period and a documented restore test.
• SLA with a concrete availability figure, a definition of downtime and a credit rule.
• MFA enforceable for everyone, plus a roles/permissions concept and audit trail.

This list fits into any requirements spec. Afterwards, compare the systems in the ERP directory and via the comparison, targeting these security criteria specifically – not just feature scope and price. A solidly hosted cloud ERP shifts a large part of operational security to the provider, but it does not release you from your duty to choose carefully.

Conclusion

Cloud ERP security is verifiable if you demand the right evidence. ISO 27001 and C5 prove security maturity, an EU server location with a DPA holds the GDPR baseline, encryption protects data in motion and at rest, a tested backup and disaster recovery concept secures recovery, a robust SLA defines availability, and MFA closes the largest single risk. Take these six building blocks into your requirements spec as hard selection criteria and have each point confirmed in writing – and when it comes to the legal assessment of data processing, work through it together with your data protection officer when in doubt.