Insights

AI impact assessment or DPIA: which one your organisation needs, and how to run it

By , Founder & Lead Advisor. . 12 minute read.

Two assessments circulate in conversations about responsible AI, and they are often confused. One is a Data Protection Impact Assessment, a DPIA, which the Data Protection Act 2017 requires before certain kinds of processing. The other is an AI system impact assessment, which ISO/IEC 42001 asks a certified organisation to perform and which ISO/IEC 42005 explains how to do. A managing director who hears both terms in the same meeting can reasonably ask three questions: which one is the law, which one do we actually need, and can we do it once rather than twice.

This guide answers those questions and then sets out a method a small team can complete in a working week. Paragraphs are labelled Legal requirement where they state what the Act requires, Best practice where they reflect the Data Protection Office’s guidance or the ISO standards, and Consultaix recommendation where they reflect our view.

This is general information, not legal advice. The Data Protection Office is the authority on the Act. Section numbers below were checked against the published text of the Act.

Definitions

Data Protection Impact Assessment

Legal requirement. Section 34(1) of the Data Protection Act 2017 provides that where processing operations “are likely to result in a high risk to the rights and freedoms of data subjects by virtue of their nature, scope, context and purposes, every controller or processor shall, prior to the processing, carry out an assessment of the impact of the envisaged processing operations on the protection of personal data”. That assessment is the DPIA. Its focus is the individual whose data is processed: the risk to their rights and freedoms, and the measures that reduce it. The Act specifies its minimum content in section 34(3) and links it to prior consultation with the Data Protection Office in section 35.

AI system impact assessment

Best practice. ISO/IEC 42001:2023, the international standard for an AI management system, is voluntary. An organisation that adopts it, whether or not it seeks certification, commits to assessing the potential consequences of its AI systems for individuals, groups and society, alongside the risks to the organisation itself. ISO/IEC 42005:2025, published in May 2025, is a guidance standard titled “AI system impact assessment”; it explains how to carry out that assessment and how it fits within the ISO/IEC 42001 management system. It is broader than a DPIA in two ways: it covers AI systems that process no personal data (a demand-forecasting model, for instance), and it looks beyond privacy to harms such as unfair or inaccurate outcomes, safety, and the organisation’s own operational, legal and reputational exposure.

The short version

A DPIA is a statutory instrument aimed at the person in the data. An AI system impact assessment is a management-system instrument aimed at the AI system and everyone it touches. Where an AI system processes personal data in a way likely to present high risk, the two overlap heavily, and that overlap is the opportunity.

Which one is a legal duty

Legal requirement. The DPIA. Section 34 makes it a duty of “every controller or processor” before high-risk processing, and section 22(2)(c) lists performing a DPIA among the measures every controller must adopt to demonstrate compliance. Section 35(2)(a) requires the controller or processor to consult the Office before processing where the DPIA indicates a high risk, section 35(3) empowers the Office to prohibit processing whose risks are insufficiently identified or mitigated, and section 35(5) requires the DPIA to be provided to the Office. Failing to carry out a required DPIA is a contravention of the Act; section 43(1) provides a general penalty for contraventions with no specific penalty of a fine of up to 200,000 rupees and up to five years’ imprisonment.

Best practice. The AI system impact assessment. No Mauritian law requires it. ISO/IEC 42001 is voluntary, and the FAIR Guidelines are non-binding: they state that they create no legal obligations, and they address public and private organisations alike, applied proportionately to size. For an FSC licensee or a bank, sector guidance may expect risk assessment of AI systems; that is a matter for the relevant regulator’s rules, not the Act. An organisation pursuing ISO/IEC 42001 certification will need to show impact assessments to its certifier, which makes the requirement contractual in effect once the standard is chosen.

Triggers for each

When a DPIA is required

Legal requirement. Section 34(2) lists the operations the duty covers: a “systematic and extensive evaluation of personal aspects relating to individuals which is based on automated processing, including profiling, and on which decisions are based that produce legal effects concerning the individual or significantly affect the individual” (34(2)(a)); processing on a large scale of special categories of personal data (34(2)(b)); systematic monitoring of a publicly accessible area on a large scale (34(2)(c)); and any other operation for which consultation with the Office is required (34(2)(d)).

Best practice. The Office’s published guidance on high-risk processing lists nine criteria and applies a rule of thumb: two or more criteria met means the processing is likely to be high risk and a DPIA is required; one criterion met, where the controller considers the processing high risk, means a DPIA is recommended. The criteria are evaluation or scoring including profiling; automated decision-making with legal or similar significant effects; systematic monitoring; sensitive or highly personal data; large-scale processing; matching or combining datasets; data on vulnerable persons; innovative use of new technology, for which the Office’s stated example is “Using Artificial Intelligence (AI) based systems”; and processing that prevents people from exercising a right or using a service. Because AI use is itself a criterion, an AI system on personal data usually needs only one further criterion, and profiling or scale is usually present, to fall within the DPIA duty on the Office’s method.

When an AI system impact assessment is expected

Best practice. Under ISO/IEC 42001 the trigger is the organisation’s own AI policy and risk criteria: an impact assessment is expected for AI systems the organisation develops, provides or uses, at the point of design or procurement and on significant change. The organisation may scope the depth of the assessment to the system’s significance. There is no statutory threshold; the discipline is that every AI system in scope of the management system is at least considered, and the reasons for a light-touch assessment are recorded.

Consultaix recommendation. Even without ISO/IEC 42001, we recommend a proportionate AI impact assessment for any system that influences decisions about people, produces content customers rely on, or replaces a control a person previously performed. That is a recommendation, not an obligation.

Can one document serve both?

Yes, provided it is built on the DPIA’s legal skeleton and extended, not the other way round.

Legal requirement. Whatever the document is called, it must contain the four elements section 34(3) requires: a systematic description of the processing and its purposes, including any legitimate interest relied on; an assessment of necessity and proportionality in relation to those purposes; an assessment of the risks to the rights and freedoms of data subjects; and the measures envisaged to address those risks, including the safeguards and security measures and mechanisms that demonstrate compliance with the Act. Where appropriate, the views of data subjects must be sought (section 34(4)). If the document goes to the Office under section 35, the Office will assess it against the Act, so those elements should be easy to find.

Best practice. The Office’s DPIA form (QMS 32) is organised in seven steps: general information; details of the project; details of the processing under nature, scope and context; necessity and proportionality; risk assessment scored by likelihood and severity; mitigation measures with residual risk; and documentation with sign-off by the person who carried out, reviewed and approved the assessment. The Office says the template is for guidance and that DPIAs are submitted online through its eDPO system. An assessment that follows the form’s structure will transfer into the online submission without rework.

Best practice. To serve as an AI system impact assessment in the ISO/IEC 42001 sense, the same document needs additional content that a DPIA does not demand: the AI system’s intended purpose and the contexts in which it will and will not be used; the data used to build and run it and known limitations; the affected parties beyond data subjects, such as staff whose work changes, customers who rely on outputs, and the organisation itself; harms other than privacy, including inaccurate or unfair outcomes, over-reliance and safety; risks to the organisation, such as legal, financial and reputational exposure; and the human oversight arrangements. ISO/IEC 42005 describes this content; the standard itself must be purchased, so this guide describes the categories rather than quoting it.

Consultaix recommendation. Keep one document with two labelled parts: Part A the DPIA, structured to the Office’s form; Part B the AI extension. Share one risk register, with each risk tagged as a risk to individuals, to other affected parties, or to the organisation. If the Office asks for the DPIA, send the whole document. If a certifier asks for the impact assessment, the same document answers.

Deciding which you need: the flow in prose

Start with the system, not the label. Describe what it does in one paragraph.

If the system processes no personal data at all, the DPIA duty does not arise. Consider a proportionate AI impact assessment if the system influences decisions, produces content people rely on, or replaces a human control. If it does none of those, a short note recording that judgement is enough.

If the system processes personal data, ask whether it evaluates or scores people, makes or drives decisions with legal or similarly significant effects, monitors people systematically, uses special categories or highly personal data, operates at scale, combines datasets, concerns vulnerable people, or prevents someone from exercising a right or accessing a service. AI use already counts as one criterion on the Office’s list. If any one of those further criteria applies, the Office’s method treats the processing as likely high risk and a DPIA is required before processing. If none applies but you judge the risk high, a DPIA is recommended. If the answer is genuinely low risk, record why and move on; section 31 security duties still apply regardless.

Where a DPIA is required, decide whether to extend it into a combined assessment. Extend it if the system influences decisions about people, if you intend to adopt ISO/IEC 42001, or if the system’s failure would harm the organisation in ways a privacy-only assessment would miss. For most decision-support AI on customer or employee data, the answer is to extend.

Finally, look at the residual risk after controls. If the DPIA indicates that high risk remains, section 35(2)(a) requires consultation with the Office before processing begins. Plan for that consultation in the project timeline rather than discovering it at go-live.

A one-week method for a small team

The method assumes a team of two or three: the business owner of the process, someone who understands the system technically (often the vendor’s contact), and the officer designated under section 22(2)(e) for data protection compliance. It produces a document that satisfies section 34(3), follows the Office’s form and carries the AI extension. The order matters more than the calendar.

  1. Scope (Day 1, morning). Name the system, the business process it sits in, the decision or output it produces, and what is in and out of scope. State whether you are the controller or a processor. Record why the assessment is being done: which section 34(2) operation or Office criteria apply. Decide whether this is a DPIA only or a combined assessment. Name the assessor, reviewer and approver now, because sign-off is easier to obtain when it was agreed at the start.
  2. Describe the system (Day 1, afternoon). In plain language, explain what the AI does, what it takes in, what it puts out, whether it recommends or decides, and where a person sits in the flow. Note the vendor, the hosting location, whether inputs are used for model training, and the retention of inputs and outputs. For the AI extension, add the intended purpose, known limitations, and the contexts in which the system should not be used. This step supplies the “systematic description” that section 34(3)(a) requires.
  3. Identify affected people (Day 2, morning). List the data subjects (applicants, customers, employees, third parties who appear in records) and, for the extension, other affected parties: staff whose role changes, customers who act on outputs, the organisation. Flag children and vulnerable persons. Decide whether and how to seek the views of data subjects, as section 34(4) requires where appropriate; for an internal tool a short consultation with a sample of affected staff is often proportionate, and for a customer-facing tool a review of complaints and feedback may be.
  4. Map the data (Day 2, afternoon). List the categories of personal data, their source, whether any are special categories under section 29, the lawful ground under section 28 for each purpose, where the data go (internally, to the vendor, abroad), how long they are kept, and how people are informed under section 23. A one-page data-flow diagram does most of the work. Check the transfer basis under section 36 for any data leaving Mauritius and the written contract terms under section 31(4) for any processor.
  5. Assess necessity and proportionality (Day 3, morning). Answer four questions in writing: what specific need the processing meets; why this processing, with this data, is necessary to meet it; whether a less intrusive means would work; and whether the benefit is proportionate to the intrusion. Confirm data minimisation: which inputs the model does not need. This is section 34(3)(b), and it is where weak projects usually fail honestly.
  6. Identify risks to individuals and to the organisation (Day 3, afternoon). For individuals, work through inaccuracy, unfair or discriminatory outcomes, lack of transparency, loss of control (including the section 38 right not to be subject to solely automated decisions), security and breach, excessive retention, and function creep. For the organisation, work through legal non-compliance, vendor dependence, model failure and over-reliance, reputational harm, and loss of the process if the system is withdrawn. Score each risk for likelihood and severity using the Office’s scales (frequent, occasional, unlikely; critical, moderate, insignificant) and derive an overall rating of high, medium or low.
  7. Decide controls (Day 4). For each medium and high risk, record the measure, its effect (eliminated or reduced) and the residual rating. Typical controls for AI: human review before any significant decision, with authority to override; a route for individuals to contest an outcome; a plain-language notice meeting section 23(2)(g); removal of unnecessary inputs; a contractual bar on vendor training; encryption and access control under section 31; retention limits; monitoring of outcomes for drift and disparity; staff training; and a kill switch and manual fallback. Where residual risk on any item remains high, plan the section 35 consultation.
  8. Record the decision and obtain sign-off (Day 5, morning). State the conclusion: proceed, proceed with conditions, consult the Office first, or do not proceed. Record who carried out, reviewed and approved the assessment, with dates, as the Office’s form requires. Add the assessment to the section 33 record of processing operations and, if the organisation has an AI register, to that too.
  9. Set the review date (Day 5, afternoon). Fix a review date, normally twelve months out, and list the events that trigger an earlier review: change of vendor or model, new data categories, new purpose, a complaint or incident, a change in the law or in Office guidance. Assign an owner for the review.

Template table

The table below can be pasted into a document and completed one row at a time. Rows marked DPA are needed to satisfy section 34(3) and the Office’s form; rows marked AI are the extension for ISO/IEC 42001 purposes.

Section Content to record Basis
1. Scope System name, process, decision or output, controller or processor role, reason for assessment (section 34(2) operation or Office criteria met), assessor, reviewer, approver DPA
2. System description Inputs, outputs, recommend or decide, human role, vendor, hosting location, training on inputs, retention DPA
2a. AI purpose and limits Intended purpose, known limitations, contexts of non-use, performance expectations AI
3. Affected people Data subjects by category; children or vulnerable persons; how views were sought DPA
3a. Other affected parties Staff, customers relying on outputs, the organisation, wider public AI
4. Data map Categories, sources, special categories (section 29), lawful ground per purpose (section 28), recipients, transfers abroad and section 36 basis, retention, notice under section 23 DPA
5. Necessity and proportionality Need, why necessary, alternatives considered, proportionality, minimisation DPA
6. Risks to individuals Risk, likelihood, severity, overall rating DPA
6a. Risks to other parties and the organisation Risk, likelihood, severity, overall rating AI
7. Controls Measure per risk, effect, residual rating; consultation with the Office if residual high DPA
7a. Human oversight Who reviews, with what authority, how individuals contest outcomes, monitoring of outcomes AI
8. Decision and sign-off Conclusion, names, designations, signatures, dates; entry in record of processing (section 33) DPA
9. Review Review date, trigger events, owner Best practice

Two common mistakes

Doing the DPIA after go-live. Section 34(1) says “prior to the processing”. A DPIA written after deployment is evidence of the contravention, not compliance with it.

Scoring everything low. The Office’s rule of thumb already presumes that AI plus one further criterion is high risk. The assessment should show how controls bring residual risk down, not deny that it was ever there.

Where Consultaix fits

Consultaix’s AI Governance Advisory helps organisations run their first combined assessment, set up the register and review cycle, and align the process with ISO/IEC 42001 where certification is the goal; the lead advisor is a certified ISO/IEC 42001 implementer. Where an organisation is unsure which of its AI uses engage the Act at all, the AI Readiness Assessment provides that inventory and scores governance as one of five dimensions before any assessment is attempted.

Sources