# Zimbabwe Cyber & Data Protection Act — Compliance Brief

**NFR7** — Data Sovereignty for the Next Gen Learning school management system.

| | |
|---|---|
| **Document version** | 1.0 — 2026-07-28 |
| **Status** | Draft — pending client (Lesticom) sign-off |
| **Owner** | Lesticom Development Team (fchin — review/merge owner) |
| **Statute** | [Cyber and Data Protection Act, 2021 (Zimbabwe)](https://www.veritaszim.net/node/2547) (Chapter 12:07) |
| **Regulator** | Postal and Telecommunications Regulatory Authority of Zimbabwe (POTRAZ), Data Protection Authority (DPA) once constituted |
| **Source artefacts** | `Next Gen Learning SRS.pdf` §3.2 NFR7; `evidence/audit-2026-07-28.md` §4.2 NFR7 row |
| **Related docs** | `docs/spec-deviations.md` (NFR1, NFR5); `docs/SYNC.md` (offline-first data flow) |

---

## 1. Executive summary

The Next Gen Learning system processes personal data of minors (students), their parents/guardians, and school staff. As a Zimbabwe-deployed service handling this data, it is subject to the **Cyber and Data Protection Act, 2021** (CDPA), which:

- Establishes a lawful basis requirement for processing personal data (§4);
- Mandates specific consent for processing data of minors (§4(3));
- Imposes data minimisation, accuracy, storage limitation, and integrity/confidentiality duties (§5–§9);
- Requires breach notification to the Authority and affected data subjects (§26);
- Imposes cross-border transfer restrictions for personal data leaving Zimbabwe (§24);
- Provides data subjects with rights of access, correction, and erasure (§12–§17).

This brief documents how the system's design **satisfies** each of these obligations, and explicitly calls out the **deviations and remaining gaps** that need either client acceptance or future remediation.

> **Posture:** the system is designed for an **on-premise / in-country** deployment by default. The cloud sync target (Supabase / `api.next_gen.techarvest.co.zw`) is hosted in Zimbabwe. No data is intended to leave the country. Where this differs from the SRS, the deviation is documented in §6.

---

## 2. Data inventory

A complete inventory of personal-data fields processed by the system. All PII is in the `users` table plus a handful of supporting tables.

### 2.1 Data subjects

| Category | Approx. count per school | Source |
|---|---|---|
| Students | 500–2,000 | Seeded by `init.js` + admin onboarding |
| Parents/guardians | 500–2,000 | Linked via `parent_students` |
| Teachers | 30–100 | Seeded by `init.js` |
| School admins / support staff | 5–20 | Seeded by `init.js` |
| Applicants / alumni (data subject erasure) | variable | `offboarding` table |

### 2.2 Personal data fields

| Field | Table | Sensitive? | Lawful basis |
|---|---|---|---|
| `first_name`, `last_name` | `users` | PII | Contract (enrolment / employment) |
| `email` | `users` | PII | Contract; explicit consent (optional) |
| `phone` | `users` | PII | Explicit consent (optional) |
| `id_number` (national ID) | `users` | **Sensitive PII** | Contract + explicit consent |
| `date_of_birth` | `users` | Sensitive PII (minor status) | Contract + explicit consent |
| `address` (line 1/2/city) | `users` | PII | Contract |
| `gender` | `users` | Sensitive (SADC region) | Optional; explicit consent |
| `blood_type`, `allergies`, `medical_conditions` | `medical_documents` | **Special category** (health) | Explicit consent required |
| `emergency_contact` | `users` | PII (third party) | Explicit consent (the third party must be informed) |
| `academic_year`, `grades`, `attendance` | `grades`, `attendance` | Behavioural | Contract |
| `disciplinary_records` | `disciplinary_records` | Sensitive | Contract + safeguarding obligation |
| `payment_method`, `paynow_reference` | `payments` | Financial | Contract |
| `salary`, `bank_account` | `payroll` | Financial | Contract |

> **Special category data** (health, biometrics) is processed only with **explicit consent** under CDPA §4(3) and only for the duration required to provide the service. The system does not collect biometric data today.

### 2.3 Children's data (CDPA §4(3))

The system processes the personal data of minors (students). The system implements:

- **Parental consent capture** at registration (`parent_students` linkage + consent workflow in `transfers.controller.js` — `POST /api/xfer/consent`).
- **No direct marketing to minors** — the system has no marketing surface.
- **Limited third-party disclosure** — third parties (e.g. receiving schools during a transfer) only receive a record package with explicit, signed consent (`signature_hash` on `transfer_consents`).

---

## 3. Lawful basis

CDPA §4(1) requires a lawful basis for every processing activity. The mapping:

| Processing activity | Lawful basis | Notes |
|---|---|---|
| Operating the school's academic record (grades, attendance, behaviour) | **Contract** with the parent / adult student | Implied by enrolment; no separate consent needed. |
| Maintaining contact details for emergency & school communications | **Contract** + **legitimate interest** (school safety) | Phone & email are required for school operations. |
| Medical information (allergies, blood type) | **Explicit consent** | Required at registration; can be withdrawn but doing so means the school cannot safely admit the child. |
| Transfer of records to another institution (Form 1 placement, university) | **Explicit consent** | `POST /api/xfer/consent` workflow with SHA-256 signature hash; immutable audit trail. |
| Financial transactions (Paynow integration) | **Contract** | Necessary to perform the fee payment service. |
| Backup & disaster recovery | **Legitimate interest** (continuity of service) | Backups are encrypted and stored in the same legal jurisdiction. |
| Aggregate, anonymised reporting to the Ministry | **Legal obligation** | Required by the Education Act; data is anonymised before transmission. |
| Marketing, third-party advertising | **N/A — system does no marketing** | — |

---

## 4. Data subject rights

CDPA §12–§17 grants data subjects the right to access, correct, and erase their personal data. The system's current support:

| Right | Status | Endpoint / workflow |
|---|---|---|
| Right of access (§12) | ✅ | `GET /api/users/me` returns the data subject's own profile. Admins can pull a record for a parent/teacher on request. |
| Right to correction (§13) | ✅ | `PATCH /api/users/:id` (admin) or self-service profile edit in the client. |
| Right to erasure / "right to be forgotten" (§14) | ⚠️ | Partial — see §6.2. The `offboarding` service anonymises a user (`is_deleted = 1` + cleared PII), but linked records (grades, attendance, payments) are preserved in aggregated form. |
| Right to data portability (§15) | ✅ | `POST /api/xfer/graduation` exports a self-contained JSON package (academic + attendance + disciplinary + financial clearance) for the receiving institution. |
| Right to object (§16) | ⚠️ | Documented but not yet a self-service UI flow. Admin-mediated. |
| Right not to be subject to automated decision-making (§17) | ✅ | The system performs no automated decision-making that produces legal or similarly significant effects on the data subject. |

### 4.1 Erasure workflow (current state)

The system implements a **soft-delete + anonymise** pattern rather than a hard delete, to preserve the integrity of historical academic and financial records (which the school is legally required to retain — see §5). When a data subject invokes the right to erasure:

1. Admin or HR marks the user for offboarding in the **Offboarding** workflow (`/api/offboarding`).
2. The `OffboardingService` (see `server/src/services/OffboardingService.js`) runs:
   - Sets `users.is_deleted = 1` and clears PII fields (`first_name`, `last_name`, `email`, `phone`, `address`).
   - Replaces PII with `[REDACTED-<uid>]` so historical references stay consistent.
   - Preserves `users.uid` so the audit trail remains intact.
   - Logs the erasure in `audit_logs` with the requesting user + timestamp.
3. The data subject receives a confirmation record via the on-file email (if it was retained) or via the school admin.

---

## 5. Retention schedule

CDPA §5(2)(c) requires that personal data be kept "no longer than is necessary for the purposes for which it is being processed." The system enforces the following retention schedule:

| Data category | Retention | Justification |
|---|---|---|
| Academic records (grades, reports) | **7 years after the student leaves the school** | Education Act + ZIMSEC audit window |
| Attendance records | **7 years** | Education Act |
| Disciplinary records | **5 years after the student turns 18** | Safeguarding + Education Act |
| Financial / payment records | **7 years** | Zimbabwe Revenue Authority (ZIMRA) tax retention obligation |
| Payroll records (staff) | **7 years after the staff member leaves** | ZIMRA + Labour Act |
| Medical records | **2 years after the student leaves** (or until consent is withdrawn) | Practical minimum; not legally mandated for longer |
| User authentication data (passwords) | Until account is closed | Operational requirement |
| Audit logs | **Permanent** (immutable) | Required for compliance demonstration and dispute resolution |
| Sync queue / failure logs | 90 days | Operational; not personal data |
| Backups | **1 year rolling** | Disaster recovery |

> **Note:** "deleted" users are retained as anonymised records to preserve referential integrity in audit logs. True hard-deletion is **not** performed because it would break the chain of evidence for academic and financial audits.

---

## 6. Cross-border data transfer (CDPA §24)

CDPA §24 restricts the transfer of personal data to a country outside Zimbabwe unless that country has adequate data-protection laws or the data subject has given explicit consent.

### 6.1 Current state

- **Sync target:** `https://api.next_gen.techarvest.co.zw` — hosted in Zimbabwe. ✅ Adequate; no cross-border issue.
- **Payments:** Paynow (Zimbabwean payment processor) — hosted in Zimbabwe. ✅
- **Email / SMS providers:** SMS and email are routed via providers selected by the deploying school. **Deviation:** the system does not currently enforce that the provider be Zimbabwe-hosted. This is a deployment-time decision, not a code-time one. The deployment manifest in `docker-compose.yml` should be configured to use a ZW-hosted SMTP and SMS provider. **See §6.3 (action item).**
- **Cloud backups:** the system supports both local (same-host) and remote (S3-compatible) backup targets. Remote backups are an **explicit opt-in** by the deploying school; the default is local. When remote backups are enabled, the school must configure a ZW-hosted S3-compatible store (or accept the §24 risk via the school's own DPA filing).

### 6.2 No third-party sharing

The system does not sell or share personal data with third parties for marketing or any other commercial purpose. The only third-party data flows are:

- **Receiving institutions** during a record transfer (with explicit consent — see `transfers.controller.js`).
- **Payment processors** (Paynow) for fee collection.
- **Ministry reporting** (anonymised aggregates, not personal data).

### 6.3 Action items

| # | Item | Owner | Status |
|---|---|---|---|
| 6.3.1 | Document the recommended ZW-hosted SMTP/SMS providers in `docs/DEPLOY.md` | Lesticom | ⏳ open |
| 6.3.2 | Add a startup-time check that the configured SMTP/SMS endpoints are in-country (or at minimum: log a warning if the resolved IP geolocates outside ZW) | Lesticom | ⏳ open |
| 6.3.3 | Add a deployment-time "data sovereignty" flag that disables remote backups unless explicitly enabled | Lesticom | ⏳ open |

---

## 7. Security controls

The system implements the following technical and organisational measures (CDPA §9 — security safeguards):

| Control | Implementation | Evidence |
|---|---|---|
| Password hashing | bcrypt, 10 rounds (configurable) | `server/src/utils/password.js` |
| Authentication | JWT (HS256), 7-day expiry | `server/src/config/index.js` — `jwtSecret` |
| Authorisation (RBAC) | Per-route role gates; full RBAC matrix sweep on every change | `server/src/middleware/requireRole.js` + `client/e2e/rbac-sweep.spec.ts` (Phase 3, 152/152 passing) |
| Transport security | TLS terminated at the reverse proxy (Nginx / Caddy) | Out of scope of the app; deployment-time concern |
| Audit logging | `audit_logs` table is append-only; every state change is recorded | `server/src/services/AuditService.js` |
| Database encryption at rest | Not enabled by default. **Deviation** — see §6.4 | — |
| Backup encryption | Backups are plaintext SQLite. **Deviation** — see §6.4 | — |
| Rate limiting | Express rate limit on `/api/auth/login` and `/api/auth/register` | `server/src/middleware/rateLimit.js` |
| CSRF | CORS is wide-open in dev (see AGENTS.md); production deployments must set `ALLOWED_ORIGINS` to the school domain | `server/src/config/index.js` — `allowedOrigins` |
| Input validation | JSON body limit 50 MB (configurable); multer file uploads capped at 5 MB | `server/src/index.js` |
| Dependency hygiene | No automated SCA today; manual review at PR time | Open follow-up |

### 7.1 Action items

| # | Item | Owner | Status |
|---|---|---|---|
| 7.1.1 | Add **automated dependency scanning** (npm audit + Dependabot or Renovate) | Lesticom | ⏳ open |
| 7.1.2 | Add **database encryption at rest** via SQLCipher or filesystem-level encryption (LUKS / eCryptfs) | Lesticom | ⏳ open |
| 7.1.3 | Add **backup encryption** (gpg / age) to the backup script | Lesticom | ⏳ open |

---

## 8. Breach notification (CDPA §26)

CDPA §26 requires notification to the Authority **and** to affected data subjects "as soon as reasonably possible" after discovery of a breach that is likely to result in significant harm.

### 8.1 Current incident response

1. Detection: an anomaly in the audit log or a user report.
2. Containment: the admin disables the affected account via `PATCH /api/users/:id` with `is_active = 0`.
3. Investigation: the `audit_logs` table is reviewed (append-only).
4. Notification: the school admin (acting as the data controller) is responsible for notifying the Authority and the data subjects. The system does not yet automate the external notification step.
5. Post-mortem: documented in the project's `evidence/` folder.

### 8.2 Action items

| # | Item | Owner | Status |
|---|---|---|---|
| 8.2.1 | Add a **breach notification workflow** to the admin dashboard that pre-fills the Authority's notification template with the affected user IDs, dates, and types of data | Lesticom | ⏳ open |
| 8.2.2 | Document the **incident response runbook** in `docs/RUNBOOK.md` (who to call, what to capture, what to preserve) | Lesticom | ⏳ open |

---

## 9. Lawful basis register (record of processing)

CDPA §6 requires a record of processing activities. The full register is maintained by the school (data controller); the system supports it via the `audit_logs` table.

| # | Processing activity | Categories of data | Data subjects | Recipients | Retention | Cross-border? |
|---|---|---|---|---|---|---|
| 1 | Enrolment & academic record | Identity, academic, behavioural | Students | School staff, parents (self-access) | 7 years post-departure | No |
| 2 | Attendance tracking | Identity, attendance | Students, teachers | School staff, parents (self-access) | 7 years | No |
| 3 | Behavioural & disciplinary | Identity, behavioural | Students | School staff, parents (on request) | 5 years post-18th birthday | No |
| 4 | Fee collection (Paynow) | Identity, financial | Parents | Paynow (payment processor) | 7 years | No (ZW) |
| 5 | Payroll | Identity, financial | Staff | School admin, ZIMRA (on audit) | 7 years post-employment | No |
| 6 | Medical & safeguarding | Health, identity | Students | School nurse, parents (on request) | 2 years post-departure | No |
| 7 | Record transfer to next institution | Academic, attendance, disciplinary, financial | Students | Receiving institution (with consent) | One-time | No (within ZW) |
| 8 | Ministry reporting | Anonymised aggregates | N/A (anonymised) | Ministry of Education | Permanent (immutable) | No |
| 9 | Backup & disaster recovery | All above | All | Same-host (default) or school-configured S3 | 1 year rolling | Depends on backup target |
| 10 | Authentication & session management | Authentication tokens | All | None (local) | Until account closure | No |

---

## 10. Data Protection Impact Assessment (DPIA)

CDPA §8 requires a DPIA for processing that is likely to result in significant harm. The following activities warrant a DPIA:

| Activity | DPIA required? | Status |
|---|---|---|
| Routine academic record | No (low risk; standard school operations) | — |
| **Cross-school record transfer** | **Yes** (data leaves the school, even with consent) | DPIA template drafted, sign-off pending |
| Ministry aggregate reporting | No (anonymised) | — |
| **Disciplinary records** (special category) | **Yes** (could affect child's future) | DPIA template drafted, sign-off pending |
| Offboarding / right to erasure | No (low risk; data subject's own request) | — |
| Medical records (special category) | **Yes** | DPIA template drafted, sign-off pending |
| Remote backup to S3-compatible store | **Conditional** (depends on whether S3 endpoint is in ZW) | Open |

---

## 11. Deviations from the strict reading of the CDPA

The following items are technically deviations from the strict reading of the CDPA. Each is documented so the client can either accept the deviation or fund remediation.

| # | Deviation | Reason | Acceptance by |
|---|---|---|---|
| 6.3.x | SMTP / SMS providers are not enforced to be ZW-hosted at the application layer | Provider choice is a deployment-time decision by the school | School / Lesticom |
| 7.1.2 | Database encryption at rest is not enabled by default | SQLite + SQLCipher integration is a follow-on engineering task | School / Lesticom |
| 7.1.3 | Backups are not encrypted at rest | Same reason as 7.1.2 | School / Lesticom |
| 7.1.1 | No automated dependency scanning | Engineering bandwidth; the team reviews deps manually at PR time | Lesticom |
| 8.2.x | Breach notification is admin-mediated, not automated | Requires integration with the Authority's notification API when published | Lesticom |
| §10 | DPIAs for cross-school transfer, disciplinary, and medical processing are drafted but not signed | Requires Lesticom legal review + sign-off | Lesticom + school |

---

## 12. Acceptance & sign-off

This brief is intended to be reviewed and signed by:

- **Lesticom Development Lead** (technical owner) — `_________________________`  Date: `__________`
- **Lesticom Delivery Manager** (commercial owner) — `_________________________`  Date: `__________`
- **School Principal** (data controller's representative) — `_________________________`  Date: `__________`
- **School IT Lead** (operational owner) — `_________________________`  Date: `__________`

Sign-off indicates the school has reviewed the data flows, accepted the documented deviations, and agreed to the retention schedule. Material changes to the data flows (e.g. switching to a non-ZW sync target, adding a new third-party processor) require a re-issue of this brief.

---

## 13. Change log

| Date | Version | Author | Change |
|---|---|---|---|
| 2026-07-28 | 1.0 | Mavis (on behalf of fchin) | Initial draft. Closes NFR7 from the SRS audit (`evidence/audit-2026-07-28.md`). |