🇲🇺Data Protection Act 2017
A GDPR-style law with a strong local accountability spine
Mauritius' Data Protection Act 2017 is designed to strengthen the control and personal autonomy of data subjects over their personal data. It is not a narrow privacy notice law. It creates a full accountability framework covering registration, lawful processing, controller and processor duties, security, breach notification, special categories of personal data, children's data, high-risk processing, cross-border transfers, data subject rights and enforcement.
The Act is especially important for businesses that treat Mauritius as a financial, technology, outsourcing or regional operations hub. Its structure will look familiar to organisations used to GDPR-style compliance, but its local features matter: the Data Protection Office, the Commissioner, the Data Protection Register, prior authorisation and consultation, and the specific transfer rules under section 36.
Who the Act covers — and why establishment matters
The Act applies to processing of personal data wholly or partly by automated means. It also applies to non-automated processing where the personal data forms, or is intended to form, part of a filing system. This means that compliance is not limited to databases or software systems; structured manual records can also be covered.
The Act binds the State, and each Ministry or Government department is treated separately for its purposes. It applies to controllers and processors established in Mauritius where personal data is processed in the context of that establishment. It also applies to controllers and processors not established in Mauritius where they use equipment in Mauritius for processing personal data, other than merely for transit through Mauritius. Such controllers or processors must nominate a representative established in Mauritius.
The Act does not apply to exchanges of information between Ministries, Government departments and public sector agencies where the exchange is required on a need-to-know basis, or to processing by an individual in the course of purely personal or household activity. These exclusions should be read narrowly. Ordinary business processing, employment processing, customer databases, vendor platforms and digital services are not household activity merely because they are small or informal.
Controllers, processors and the registration layer
A controller is a person or public body that, alone or jointly with others, determines the purposes and means of processing personal data and has decision-making power over that processing. A processor processes personal data on behalf of a controller. A data subject is an identified or identifiable individual.
The Act creates a registration framework for controllers and processors. The Commissioner keeps the Data Protection Register, which is available for inspection. Registration is not a decorative formality. It is part of the Mauritian compliance architecture and sits alongside the substantive processing duties. Organisations should treat registration status, certificate terms, renewal, and changes in particulars as operational compliance items.
The register matters because it gives the regulator and the public visibility over processing actors. A controller or processor that maintains good internal documentation but ignores registration risk is leaving a visible compliance gap.
The processing principles — the Act's baseline standard
Section 21 requires every controller or processor to ensure that personal data is processed lawfully, fairly and transparently; collected for explicit, specified and legitimate purposes; not further processed incompatibly with those purposes; adequate, relevant and limited to what is necessary; accurate and kept up to date; kept in identifiable form only as long as necessary; and processed in accordance with data subject rights.
These principles are the foundation of the Act. They determine whether collection is lawful, whether reuse is permitted, whether retention is justified, whether accuracy controls are adequate and whether rights requests can be honoured. They should be embedded into product design, HR systems, customer onboarding, marketing databases, vendor contracts and record-retention policies.
The most common failure point is treating the principles as generic statements. In practice, each principle must be converted into a control. Purpose limitation becomes purpose mapping. Data minimisation becomes field-level collection discipline. Accuracy becomes update and correction workflows. Storage limitation becomes retention schedules. Rights compliance becomes a request-handling system.
Controller duties — accountability must be demonstrable
Section 22 requires every controller to adopt policies and implement appropriate technical and organisational measures to ensure and demonstrate that personal data is processed in accordance with the Act. That phrase — ensure and demonstrate — is the heart of the accountability model.
The measures include appropriate security and organisational measures, a record of processing operations, data protection impact assessments where required, compliance with prior authorisation or consultation requirements, and designation of an officer responsible for data protection compliance issues. This means that a controller cannot rely only on consent wording or a website privacy policy. It must be able to show how compliance is built into its systems.
The controller must also verify the effectiveness of those measures. Policies that are not tested, incident plans that are not rehearsed, and processing records that are not updated will not satisfy the spirit of section 22. Accountability is not a document archive; it is a working compliance system.
Collection notices and consent — transparency at the point of collection
Section 23 limits collection to lawful purposes connected with the controller's function or activity, and only where collection is necessary for that purpose. When collecting personal data directly from a data subject, the controller must inform the data subject of key matters, including the controller's identity and contact details, the purpose of collection, intended recipients, whether supplying the data is voluntary or mandatory, the right to withdraw consent, the rights of access, rectification, restriction, erasure and objection, and the existence and logic of automated decision making where applicable.
Section 24 places the burden of proving consent on the controller. Consent must be freely given, specific, informed and unambiguous, shown by a statement or clear affirmative action. The data subject has the right to withdraw consent at any time. In deciding whether consent was freely given, the Act looks at whether a contract or service was made conditional on consent to processing that is not necessary for that contract.
This makes bundled consent risky. If a service requires consent to unrelated marketing, profiling or data sharing that is not necessary for the service, the organisation may struggle to prove that consent was freely given.
Breach notification — 72 hours where feasible
Where there is a personal data breach, section 25 requires the controller to notify the Commissioner without undue delay and, where feasible, not later than 72 hours after becoming aware of it. If notification is delayed beyond that time, reasons for the delay must be provided. A processor that becomes aware of a breach must notify the controller without undue delay.
The notification must describe the nature of the breach, including where possible the categories and approximate number of data subjects and records concerned, provide contact details of the data protection officer or other contact point, and recommend measures to address the breach and mitigate adverse effects.
Section 26 adds a data subject communication duty where the breach is likely to result in a high risk to the rights and freedoms of the data subject. The communication must be in clear language and explain the breach and relevant recommendations. Communication may not be required where appropriate technical and organisational measures, such as encryption, render the affected data unintelligible to unauthorised persons.
A foreign SaaS provider begins serving Mauritian clients and uses cloud infrastructure and support tools that process customer and employee data through equipment connected to Mauritius. The provider assumes that because it has no incorporated company in Mauritius, the Act does not apply. That is a risky assumption. Section 3 reaches controllers and processors not established in Mauritius where they use equipment in Mauritius for processing personal data, other than for transit. The provider may need a representative established in Mauritius, registration analysis, transfer controls, breach processes and a local accountability record.
Special categories of personal data and child data
The Act defines special categories of personal data broadly. They include data relating to racial or ethnic origin, political opinion or adherence, religious or philosophical beliefs, trade union membership, physical or mental health or condition, sexual orientation, genetic data, biometric data uniquely identifying a person, offences or alleged offences, related proceedings and sentences, and other personal data the Commissioner may determine to be sensitive.
Special-category data needs heightened care because misuse can cause serious harm and because the legal bases for processing are narrower and more closely scrutinised. Health platforms, HR systems, financial institutions, schools, insurers, biometric access systems and investigation workflows should identify these categories separately rather than hiding them inside a general personal data inventory.
Section 30 deals specifically with personal data of a child. Organisations processing children's data should build age-aware notice, consent and safeguarding mechanisms. Treating a child user like an adult data subject is rarely adequate.
Security, prior checks and records of processing
Section 31 addresses security of processing. Controllers and processors should implement appropriate technical and organisational measures having regard to risks, including unauthorised access, accidental loss, destruction or damage. Security is therefore not only an IT issue; it is part of lawful processing.
Section 32 requires prior security checks in relevant circumstances, and section 33 requires records of processing operations. These records are important because they help demonstrate who is processing what, for what purpose, on what legal basis, with which recipients, with which transfers, and under which retention or security controls.
A strong Mauritius compliance file should therefore include a processing inventory, security measures, processor arrangements, breach logs, transfer assessments, DPIAs where applicable, and records of rights requests.
High-risk processing — DPIAs, prior authorisation and consultation
Part V deals with processing operations likely to present risk. Section 34 requires a data protection impact assessment where processing is likely to result in a high risk to the rights and freedoms of data subjects. The assessment should identify processing operations, evaluate necessity and proportionality, assess risk, and set out measures to address those risks.
Section 35 creates a prior authorisation and consultation layer. Where processing is likely to present high risks by virtue of its nature, scope or purpose, the controller or processor may need to consult the Data Protection Office. If the Office considers that the intended processing does not comply with the Act, particularly because risks are insufficiently identified or mitigated, it may prohibit the intended processing and propose remedial measures.
This is a significant operational requirement. High-risk projects should not be launched first and documented later. Biometric deployments, large-scale monitoring, profiling, AI-driven decisions, health data platforms and sensitive-data analytics should be screened before implementation.
Transfers outside Mauritius — safeguards first
Section 36 permits transfer of personal data outside Mauritius only where a statutory transfer ground applies. A controller or processor may transfer data where it has provided the Commissioner proof of appropriate safeguards, where the data subject has given explicit consent after being informed of possible risks due to the absence of safeguards, or where the transfer is necessary for specific purposes such as contract performance, public interest, legal claims, vital interests, or limited compelling legitimate interests.
The compelling legitimate interests route is deliberately narrow. The transfer must not be repetitive, must concern a limited number of data subjects, and the controller or processor must assess all circumstances and provide the Commissioner proof of appropriate safeguards. Transfers from public registers are also addressed separately.
This means that cross-border transfer governance cannot be limited to a line in a privacy policy. Organisations should document the destination, recipient, categories of data, purpose, transfer ground, safeguards, and whether Commissioner-facing proof is required.
Data subject rights — access, automated decisions, erasure and objection
Part VII gives data subjects practical control rights. These include the right of access, rights relating to automated individual decision making, rights to rectification, erasure and restriction of processing, and the right to object.
The right to erasure is triggered in important situations: where data is no longer necessary for the purpose for which it was collected, where the data subject withdraws consent and there is no other legal ground, where the data subject objects and there are no overriding legitimate grounds, or where the personal data has been unlawfully processed. Where data has been made public, the controller must take reasonable steps to inform third parties processing that data about the erasure request.
The right to object is especially important for direct marketing. Where personal data is processed for direct marketing, including related profiling, the data subject may object, and the data must no longer be processed for that purpose. This requires marketing suppression systems, not merely unsubscribe language.
Offences, enforcement and compliance audits
The Commissioner can investigate complaints, require information, issue preservation orders, serve enforcement notices, seek assistance, and exercise powers of entry and search through authorised officers. The Act also allows compliance audits and provides for codes, guidelines and certification.
Section 42 creates offences for unlawful disclosure of personal data by controllers and processors, unauthorised access followed by disclosure, and offering to sell personal data obtained in breach of the Act. Section 43 provides a general penalty where no specific penalty is provided: a fine not exceeding 200,000 rupees and imprisonment for a term not exceeding five years. The Court may also order forfeiture of equipment or prohibit acts to stop a continuing contravention.
The enforcement model is therefore both administrative and criminal. Organisations should treat compliance as a management responsibility, not as an IT checklist.
Section 3 — Application: binds the State; covers automated processing and structured non-automated filing systems; applies to controllers and processors established in Mauritius and certain non-established actors using equipment in Mauritius.
Sections 4–13 — Data Protection Office, Commissioner functions, investigations, information powers, preservation orders, enforcement notices and authorised officer powers.
Sections 14–20 — Registration of controllers and processors and the Data Protection Register.
Section 21 — Processing principles: lawfulness, fairness, transparency, purpose limitation, minimisation, accuracy, storage limitation and rights compliance.
Section 22 — Controller duties: policies, technical and organisational measures, records, DPIAs, prior authorisation or consultation, and designation of a data protection compliance officer.
Sections 23–24 — Collection duties and consent: notice requirements, burden of proof, withdrawal and freely given consent assessment.
Sections 25–26 — Breach notification to the Commissioner and communication to affected data subjects where high risk exists.
Sections 29–30 — Special categories of personal data and personal data of children.
Sections 31–35 — Security of processing, prior security checks, processing records, DPIAs, prior authorisation and consultation.
Section 36 — Transfers outside Mauritius: safeguards, explicit consent after risk disclosure, specific necessity grounds and limited legitimate interest transfer route.
Sections 37–41 — Data subject rights: access, automated decision making, rectification, erasure, restriction, objection and exercise of rights.
Sections 42–43 — Unlawful disclosure offences and general penalties.
The Mauritius DPA is a full accountability statute. Your compliance work should begin with controller-processor mapping and registration, then move into privacy notices, records of processing, security measures, DPIAs, breach procedures, transfer assessments, rights workflows and direct marketing suppression. The organisations that do this well will be able to prove compliance before the Data Protection Office asks for it. The organisations that rely only on a privacy policy will struggle when a breach, access request, cross-border transfer review or audit arrives.