Data protection for M&E: Kenya's DPA 2019 and the GDPR

This page describes the two instruments as enacted; it is not legal advice, and organisations should take their own advice on how the law applies to their processing.

Why M&E data is personal data

Data-protection law attaches to personal data — information relating to an identified or identifiable natural person [1][3]. Almost everything an M&E system touches qualifies: beneficiary registers with names and ID numbers; phone numbers collected for follow-up surveys; GPS coordinates of homesteads; photographs from field visits; survey datasets whose combination of village, age, sex and occupation identifies respondents even with names removed; feedback and complaints logs (see feedback and complaints mechanisms). Identifiability is the test, and it is assessed against the data in combination, not field by field.

Both instruments then mark out a higher-risk tier. Kenya’s Act defines sensitive personal data broadly — including data revealing a person’s health status, ethnic or social origin, conscience, belief, genetic data, biometric data, sex, and also property details, marital status and family details including names of children, parents and spouses [1]. The GDPR’s special categories (Article 9) cover racial or ethnic origin, political opinions, religious beliefs, trade-union membership, genetic and biometric data, health, and sex life or orientation [3]. The Kenyan list is notably wider than the European one — a household asset register or a marital-status field sits in Kenya’s sensitive tier — a difference programmes reporting under both regimes should not assume away [1][3]. Health, protection and gender-based-violence programming should treat most of its individual-level data as falling in the higher tier of whichever regime applies.

Kenya’s Data Protection Act, 2019: the essentials for M&E

The Act (No. 24 of 2019) gives effect to the privacy right in Article 31(c) and (d) of the Constitution of Kenya and establishes the Office of the Data Protection Commissioner (ODPC) as supervisory authority [1][2]. The provisions an M&E practitioner meets most often:

• Roles. The Act regulates data controllers (who determine the purpose and means of processing) and data processors (who process on a controller’s behalf) [1]. An NGO running its own M&E system is typically a controller; a data-collection firm or hosting provider engaged for it is typically a processor. The Act provides for registration of controllers and processors with the ODPC, with thresholds and exemptions prescribed under it [1][2].
• Principles (s.25). Personal data must be processed lawfully, fairly and transparently; collected for explicit, specified and legitimate purposes; adequate, relevant and limited to what is necessary; accurate and kept up to date; and not kept in identifiable form longer than necessary. The principles also require that personal data not be transferred outside Kenya except as the Act allows [1].
• Data-subject rights (s.26). The people in an M&E dataset have rights to be informed of the use to which their data will be put, to access their data, to object to processing, and to correction and deletion of false or misleading data [1]. A survey respondent asking “what did you record about me, and who sees it?” is exercising a statutory right, and the organisation needs a working answer.
• Lawful basis (s.30). Processing requires the data subject’s consent or another basis the Act specifies — including performance of a contract, compliance with a legal obligation, protection of vital interests, a task carried out in the public interest, and legitimate interests [1]. Consent under the Act must be express, unequivocal, free, specific and informed — which aligns with, but is distinct from, the ethical consent described under ethics and consent: a study can satisfy ethics and still lack a documented lawful basis, or vice versa.
• Sensitive data (ss.44–46). Sensitive personal data attracts additional conditions before it may be processed [1].
• Impact assessment (s.31). Where a processing operation is likely to result in high risk to rights and freedoms, the controller is required to carry out a data protection impact assessment before processing [1] — a new individual-level database covering vulnerable populations is the paradigm M&E case.
• Transfers outside Kenya (ss.48–49). Transfer of personal data outside Kenya is conditioned on safeguards — including proof of appropriate security and protection in the destination, or the data subject’s consent, among the grounds the Act sets out — with stricter treatment for sensitive data [1]. Donor reporting systems, global information systems and cloud hosting located abroad all sit under these provisions.
• Breach (s.43). Where personal data has been accessed or acquired by an unauthorised person and there is a real risk of harm to the data subject, the controller must notify the Data Commissioner within seventy-two hours and communicate with the affected data subject as the Act prescribes [1].

GDPR touchpoints for internationally funded programmes

A programme operating in East Africa can find the GDPR relevant through several doors: an EU-established funder, partner or headquarters acting as controller or joint controller of programme data; processing carried out in the context of an EU establishment (Article 3(1)); or, less commonly for M&E, offering services to or monitoring people in the EU (Article 3(2)) [3]. When it applies, its architecture will feel familiar from the Kenyan Act — the two share a design lineage — and the practical mapping is close rather than identical [1][3]:

• Principles and bases (Articles 5–6) parallel ss.25 and 30: lawfulness, purpose limitation, minimisation, accuracy, storage limitation, integrity and confidentiality; consent plus five other lawful bases.
• Special categories (Article 9) parallel the sensitive-data provisions, with the scope difference noted above.
• DPIAs (Article 35) parallel s.31 for high-risk processing.
• Transfers (Chapter V) parallel ss.48–49: adequacy decisions, appropriate safeguards such as standard contractual clauses, and narrow derogations.
• Breach (Articles 33–34): notification to the supervisory authority without undue delay and where feasible within seventy-two hours (unless the breach is unlikely to result in risk), and communication to data subjects where the risk is high [3].

For a programme answering to both regimes at once, the workable posture is a single set of controls designed to the stricter requirement in each area, with the mapping documented — rather than two parallel compliance theatres.

Practical M&E hygiene

The controls below are ordinary M&E craft; they also happen to be how the legal principles land in practice.

• Minimisation at form design. The cheapest compliance is the field never collected. Each identifying field on an instrument should justify itself against a named use; “might be useful” is the anti-pattern the minimisation principle exists to kill [1][3]. This belongs in the same design review as everything else under questionnaire design.
• Pseudonymisation for analysis. Split the identifier map from the analysis dataset: analysts work on coded records; the key linking codes to identities lives separately, under stricter access. Both instruments treat this kind of measure as risk reduction, not as an exit from the law — pseudonymised data with a retained key remains personal data [3].
• Small-cell suppression in reporting. Disaggregated tables can identify: the one woman with a disability in a named village is identifiable the moment her row is published. Suppress or aggregate small cells before publication — the disaggregation trade-offs are discussed under baselines, targets and disaggregation.
• Retention schedules. “Keep everything forever” violates the storage-limitation principle in both instruments [1][3]. A workable schedule states, per dataset: retention period and its justification (donor audit requirements are a legitimate one), the destruction or anonymisation method, and the owner who executes it.
• Consent language alignment. The consent script is where ethics and law meet: it should establish the ethical consent described under ethics and consent and deliver the statutory notice — what is collected, for what purpose, who it is shared with, how long it is kept, and the rights the person holds [1][3].

Cross-border realities

Three recurring situations put the transfer provisions in play. Donor-mandated systems: results and sometimes beneficiary-level data flow into funder systems hosted abroad — the transfer needs a ground under ss.48–49 (and, where the GDPR applies to the recipient side, Chapter V), and the data-sharing or grant agreement is where the safeguards are recorded [1][3]. Cloud hosting: where the servers sit determines whether routine storage is itself a transfer; hosting location and safeguards belong in the processor agreement, and are part of platform due diligence (see M&E information systems). Sharing with government systems: reporting identifiable data into national systems is processing with its own lawful basis and, ideally, a written data-sharing agreement specifying purpose, security and onward-use limits. In all three, the instrument of record is a signed agreement — not an email thread.

Breach response basics

Both instruments assume breaches will happen and regulate the response. The Kenyan Act’s duty triggers on unauthorised access or acquisition carrying a real risk of harm: notification to the Data Commissioner within seventy-two hours, and communication to the affected person [1]. The GDPR’s Articles 33–34 run a comparable risk-based clock [3]. What that presupposes operationally: the organisation can detect a breach (access logs, custody records for paper), knows who decides and who notifies, and has documented even the breaches it judged below the threshold — the documentation duty outlives the incident [1][3]. A lost field tablet, an email to the wrong list, a stolen bag of consent forms: each is a rehearsable scenario, and a programme that has never walked through one does not, in practice, have a breach response — it has a legal exposure and an intention.

Checklist for a compliant M&E data operation

• Every dataset has a named controller, a documented lawful basis and a privacy notice that respondents actually received.
• Registration status with the ODPC has been assessed and actioned.
• Sensitive-tier data is inventoried against the Kenyan definition, not just the GDPR one.
• High-risk processing was preceded by a documented impact assessment.
• Access is role-based, identifier keys are separated, and small-cell rules govern publication.
• Cross-border flows are mapped, each with its safeguard and signed agreement.
• A retention schedule exists and is executed; a breach playbook exists and has been rehearsed.