Data Residency in Mauritius: Where an Institution May Host, and What It Must Do First

There is no general rule in Mauritian law that personal data must stay on the island. What exists is a permission regime and a supervisory regime, and they are separate. The Data Protection Act 2017, read on 17 September 2026, tells any controller when it may send personal data out of Mauritius at all. The Bank of Mauritius Guideline on Use of Cloud Services, BOM/BSD 46 of September 2022, tells a financial institution what it must do before it deploys, wherever the data ends up. An institution that satisfies one and not the other has not finished.

B Hub Consulting is a management consultancy. It is not a law firm, it holds no Financial Services Commission licence, and nothing here is a legal opinion on your facts. What our Digital Transformation & AI practice is retained to do is the work between the two regimes: the materiality assessment, the architecture decision, the schedule of contract clauses to put to the vendor, and the exit plan.

Two rule sets, two different questions

The first question is whether the data may cross the border. That is answered by the Data Protection Act 2017 and applies to every controller in Mauritius, public or private, bank or not. The second question is whether the institution has satisfied its supervisor about how the arrangement is governed. That is answered by the Bank of Mauritius for the institutions it licenses, and it applies even when the data never leaves the island.

Confusing the two is the common failure. A project team that has found a lawful ground for transfer under section 36 has answered the data protection question and none of the supervisory one. A team that has built a careful vendor governance pack has answered the supervisory question and none of the transfer one.

What section 36 actually permits

Section 36 of the Data Protection Act 2017 is a list of grounds, not a prohibition. Personal data may be transferred outside Mauritius where one of them is met, and the first of them is the one most institutions rely on in practice.

• Appropriate safeguards with respect to the protection of the personal data.
• Explicit consent of the data subject, given after the subject has been informed of the risks of the transfer.
• Necessity for a contract with the data subject, or for steps taken at the data subject’s request before entering one.
• Public interest grounds established by law.
• Vital interests of the data subject, where the subject is unable to give consent.
• Compelling legitimate interests of the controller, where the transfer is limited in scope and the safeguards are demonstrated.
• Transfers from a public register, subject to the consultation conditions that attach to that register.

Two things follow that project teams routinely miss. Section 36(2) restricts register-based transfers so that they may not involve an entire dataset, and requires the status of the requesting party to be verified where the register provides for it. And a ground is not a filing: reliance on appropriate safeguards is a position the controller must be able to evidence, which in practice means the contract, the technical measures under section 31 and the record of how they were assessed.

Section 31 is the one that decides what those safeguards look like. It requires appropriate security and organisational measures against unauthorised access, alteration, disclosure, loss and destruction, and names pseudonymisation and encryption, resilience of systems, the ability to restore data in a timely way and regular testing of effectiveness. Section 25 sets the breach clock: the Commissioner is notified without undue delay and, where feasible, not later than 72 hours after the controller becomes aware.

What the Bank of Mauritius requires before a material deployment

Guideline BOM/BSD 46 of September 2022 governs the use of cloud services by the financial institutions the Bank licenses. Its obligations are procedural rather than architectural, which is why they are so often discovered late.

1. 01Assess materiality first. The guideline requires institutions to consider, as a minimum, the nature of the services, the potential impact on the institution and its customers, the cost as a share of operating costs, the difficulty of migrating to an alternative and the impact on earnings.
2. 02Notify the Bank at least 60 days before deployment. Financial institutions shall notify the Bank of the proposed deployment of material cloud services, and the notification shall be done at least 60 days before the proposed deployment.
3. 03Know the city and the country. Institutions shall be aware of the location, city and country, where their data will be hosted, and shall satisfy themselves that the data protection laws in the foreign jurisdiction are in line with Mauritian data protection law.
4. 04Get the audit right into the contract. The agreement must include the right of audit, including remote audit, by the Bank, the institution and its external auditors.
5. 05Document the exit before you sign. Comprehensive and well documented exit strategies are to be established and regularly reviewed, including agreed deletion processes and transferability of services.
6. 06Report incidents promptly. Institutions shall report promptly to the Bank any incident including unauthorised access or breach.

Financial institutions shall be aware of the location (city and country) where their data will be hosted.

The 60 day clock is the item that most often moves a go-live date. It runs from notification, not from the day the architecture was chosen, and a materiality assessment that has not been done is not a notification. Where an institution is outsourcing rather than consuming a cloud service, the older Guidelines on Outsourcing by Financial Institutions remain the reference point alongside it.

The decision this actually forces on the architecture

Read together, the two regimes do not require a Mauritian data centre. They require that the institution can say, and evidence, four things: where every copy of the data physically sits, on what ground it may be there, who may audit it, and how it would be brought back. Architectures fail those tests for reasons that have nothing to do with the primary database.

• Backups and replicas. A region chosen carefully for the production database, with backups replicating to a second region nobody assessed, is the most common finding.
• Managed services with their own footprint. Logging, monitoring, error reporting and email delivery each move data, often by default, and often to a different jurisdiction from the one in the contract.
• Support access. A vendor support engineer in a third country with production access is a transfer, whatever the hosting region says.
• Model inference. Where an AI feature sends customer text to an inference endpoint, the endpoint’s region is part of the answer to the location question, and so is whatever retention the vendor applies to it.
• Sub-processors. The contract with the vendor is not the whole chain, and the exit strategy has to work at the end of the chain rather than at the first link.

None of those is exotic. All of them are cheap to establish at design time and expensive to establish six weeks before a supervisory notification. This is the same pattern we described in AI consulting in Mauritius: the governance work is not the obstacle to the project, it is the part of the project that was scoped as an afterthought.

What is not published

Three things institutions ask us for do not exist in published form. There is no adequacy list naming the jurisdictions whose data protection laws Mauritius regards as in line with its own, so that judgement sits with the controller and must be reasoned and recorded. There is no published template for the section 36 appropriate safeguards position. And the Bank does not publish the outcomes of cloud notifications, so no institution can plan on a precedent set by another.

Where a question is not answered by published material, the honest planning assumption is the conservative one, documented as an assumption. An adviser who tells you a particular region is approved is describing an inference, not a published decision.

A test to run before the region is chosen

This takes an afternoon and is worth doing before the architecture is drawn rather than after. It is the same exercise we run at the start of a mandate.

1. 01List every store, not every system. Primary database, backups, object storage, logs, analytics warehouse, message queues, email and any inference endpoint. For each, write the city and the country.
2. 02Mark which stores hold personal data. Logs and support tickets usually do, and are usually the ones left off the list.
3. 03State the section 36 ground for each crossing. One sentence each, with the evidence you would show.
4. 04Apply the materiality factors. Nature of the service, impact on the institution and its customers, cost as a share of operating costs, difficulty of migration, impact on earnings. If the answer is material, start the 60 day clock in the project plan.
5. 05Ask the vendor for the audit and exit clauses in writing. Not the marketing page: the clause. Whether the Bank may audit remotely is either in the agreement or it is not.
6. 06Write the exit as a runbook. Who extracts the data, in what format, over how long, and what evidence of deletion the vendor provides.

An institution that can hand a supervisor that six-item pack is in a different position from one that can hand over an architecture diagram, and the difference costs very little if it is built in from the first week.

For the strategy and incentive context around AI projects in institutions here, read AI consulting in Mauritius, and for how a public body buys a system of this kind read buying complex systems under the Public Procurement Act. Our practice areas set out what we take on, the engagements page describes the mandates in anonymised form, and you are welcome to put the question to us.