Who is responsible for what
Cloud ERP security questions usually get answered with a certification list, which is not what a group IT reviewer is actually asking. The useful frame is the split of responsibility, because the boundary is where problems live.
| Layer | Owner |
|---|---|
| Physical datacentre, hardware, hypervisor | Microsoft |
| Platform patching, database backups, uptime | Microsoft |
| Identity and authentication (Entra ID) | You, on Microsoft's platform |
| Who has which permissions inside the application | You |
| What data you put in, and its accuracy | You |
| Which partners have administrative access | You |
Almost every real incident in cloud ERP sits in the bottom half of that table. Microsoft's side is well covered and rarely the weak point; access that was granted once and never reviewed is.
Where the data physically sits
Business Central Online runs in Microsoft datacentres, and the region is chosen when the environment is provisioned. For European groups the tenant is normally in an EU region; there are regions in the UK, North America, Asia-Pacific and elsewhere.
Three points that come up in group IT review and are worth having straight:
- The region is set at provisioning. Moving an environment between regions afterwards is possible but is a support process, not a setting. Decide before go-live.
- Backups stay in the same geography as the primary data.
- Support access may be global. Microsoft support engineers can be located anywhere; access to customer data is gated and logged, and there are controls that require explicit approval for each access. If your policy demands it, ask about those controls specifically rather than about residency alone.
For a group with a subsidiary in a country where the software provenance question is live, EU provisioning usually answers both the residency and the provenance question at once — the topic is covered from the other angle in your Ukrainian subsidiary runs 1C.
GDPR in practice
Business Central is a system of record containing personal data — employees, contacts, sometimes customers who are individuals. Three obligations translate into concrete configuration rather than policy documents.
Finding a person's data
A subject access request means locating everything about one individual. In an ERP that data is spread across contacts, employees, ledger entries and documents. Business Central has data classification and privacy tooling for this, but it only helps if fields were classified during implementation. Retro-fitting classification across a live system is slow.
Deleting it
The complication specific to ERP: financial records have statutory retention periods that override a deletion request. You cannot delete a posted invoice because the customer asked. The practical answer is separating personal identifiers from transactional records so the former can be anonymised while the latter stays intact — a design decision, made early or not at all.
Knowing who looked
Change logging records who modified which record. It is off by default for most tables and should be enabled selectively: customer and contact records, permission changes, and anything else your DPO would ask about. Enabling it everywhere inflates the database for little benefit.
Permissions: four layers
Access inside the application is restricted at four independent levels, and conflating them is why permission setups end up either leaky or unworkable.
- Objects — which pages and reports open at all.
- Actions — read, create, modify, delete, handled separately.
- Records — which rows are visible inside a page the user can open. Implemented through dimensions, so one piece of design work serves both reporting and security.
- Periods — which dates can be posted into. The cheapest control available and the most frequently skipped; a large share of unexplained reporting discrepancies are documents posted into a closed period.
Two organisational rules matter more than the configuration itself. Grant through roles rather than to individuals, or after twenty people you have twenty unique configurations nobody understands. And review permissions when someone changes job, because otherwise people accumulate access from every role they have ever held.
What your partner can see
Rarely asked, and it should be. Implementation partners typically hold delegated administrative access to the environment, which in practice means access to your data.
Reasonable questions before granting it:
- Which named individuals have access, and is it removed when they leave the partner?
- Is access permanent or requested per task?
- Does the partner work in production directly, or in a sandbox with a promotion process?
- What happens to their access when the engagement ends — and is that written down?
None of this implies distrust. It is the same review you would apply to any supplier with access to your finance system, and a serious partner has the answers ready. The wider selection criteria are in how to choose an implementation partner.
A checklist for IT review
- Which region is the environment provisioned in, and was that a deliberate choice?
- Is multi-factor authentication enforced for all users, including the partner?
- Are permissions granted through roles rather than individually?
- Are permission changes themselves logged?
- Are closed accounting periods actually locked?
- Were personal-data fields classified during implementation?
- Who at the partner has administrative access, and when was it last reviewed?
- Has restoring from backup been tested, not just configured?
- Is there a documented route to admin access if the current administrator is unavailable?
The last two are the ones that fail in practice. A backup nobody has restored is a file, and a single administrator is a continuity risk regardless of how good the platform underneath is.
Frequently asked questions
Where is Business Central data stored?
In Microsoft datacentres, in a region chosen when the environment is provisioned — EU, UK, North America, Asia-Pacific and others. Backups stay in the same geography. Moving regions afterwards is a support process rather than a setting, so it is worth deciding deliberately before go-live.
Is Business Central GDPR compliant?
The platform provides the tooling — data classification, privacy handling, change logging — but compliance depends on how you configure and operate it. The part that needs deciding early is separating personal identifiers from transactional records, because financial retention periods override deletion requests.
Can our implementation partner see our data?
Typically yes, through delegated administrative access. This is normal and necessary, but it should be reviewed like any supplier access: which named people, whether access is permanent or per-task, and what happens when the engagement ends.
How do we restrict what users can see?
Four independent layers: which pages open, which actions are permitted, which records are visible within a page, and which accounting periods accept postings. Record-level restriction runs on dimensions, so the design work serves reporting and security at the same time.
Does Microsoft support staff have access to our data?
Support engineers can be located globally and access is gated and logged. There are controls that require explicit customer approval for each access request. If your group policy is strict on this, ask about those specific controls rather than about data residency alone.
Are backups automatic?
Yes, on Business Central Online, with point-in-time restore. Worth noting separately that a restore should be tested rather than assumed — and that your own continuity plan should not depend on any single provider.