Mzali Privacy Policy

1) Who we are

Mzali is operated by Mzali Development (Pty) Ltd ("Mzali", "we", "us", "our"). Mzali is based in South Africa.

Contact

• Email: [email protected]
• Telephone: 010 542 0776
• Address: Unit A15 Block A, Greenoaks Office Park, Bekker Road, Midrand, 1685

(These contact details and baseline policy structure are aligned to your current PDF policy.)

2) Scope & acceptance

This Privacy Policy applies to all users of the Platform, including parents/guardians, learners/students, teachers, school staff, school administrators, and platform administrators.

By accessing or using the Platform, you acknowledge that you have read and understood this Privacy Policy. If you do not agree, do not use the Platform.

3) Roles: School vs Mzali (controller/processor)

Mzali is a school platform, so roles can differ depending on the information:

• Student Data and school-managed records: The school typically decides why/how Student Data is processed for school administration and is the Responsible Party (controller). Mzali typically acts as an Operator (processor) processing Student Data on the school's instructions.
• Mzali account, security and operational data: For information needed to operate and secure the Platform (e.g., parent/staff accounts, login logs, device tokens, audits, support communications), Mzali may be a Responsible Party (controller) to the extent we decide the purposes/means.

Where necessary to protect the Platform, users, and data, Mzali may apply security controls that limit access, prevent abuse, and maintain auditability.

4) Information we collect

We collect information you give us and information collected automatically when you use the Platform.

4.1 Account and authentication

• Web: name, email, password (hashed), session data, "remember me" (if enabled), plus security metadata such as IP address and user agent.
• Mobile/API (Parent accounts): title, name, surname, email, phone, password (hashed), occupation, relationship, language, province; optional device identifiers (device_id/device_name); last login timestamp.
• Staff/School users: name, email, phone, school association, role, designation, status, app preferences, login and verification timestamps.

4.2 Refresh tokens (API)

Where the Platform issues refresh tokens, we store refresh tokens in hashed form and may store related metadata (e.g., device_id, device_name, IP address, timestamps) for session security, fraud prevention, and token revocation.

4.3 Student Data (entered/maintained by schools)

Student Data may include rich personal information such as accession/official ID, names, date of birth, gender, grade/class, contact/address data, guardian details, emergency contacts, and school records (e.g., academics, attendance, merits).

In some cases, Student Data may include special personal information (e.g., allergies, medical/special needs, medications) if the school captures it for learner welfare and operational purposes.

4.4 Parent–student linking

When a parent/guardian links to a learner, we may store relationship type, primary guardian markers, collection permission indicators, emergency contact flags, academic update preferences, and related consent/authorisation flags configured by the school.

4.5 Push notification device tokens

To deliver notifications, we store device tokens for Firebase Cloud Messaging (FCM) and/or Huawei Push Kit, plus platform, optional device metadata, app version, and last-used timestamp.

4.6 Notifications and attachments

We store notification content, delivery/read state, and attachments (where used) so the Platform can display notifications, allow users to mark them as read, and support school communications.

4.7 Auditing

We maintain audit logs of key data changes (what changed, when, and by whom) to support accountability, security, and compliance.

4.9 Textbook loan records

When a school uses the textbook management feature, we store records of textbook loans, returns, and related events. This may include: textbook title, barcode/copy identifier, learner identifier, date issued and returned, condition at issue and return, due date, overdue status, lost/damaged status, replacement fee, payment status, amount paid, and notes entered by school staff.

Textbook loan records are entered and managed by authorised school staff. The school is the Responsible Party for these records. Mzali processes them as Operator on the school's instructions.

4.10 Consent records and digital acceptance

The Platform supports a consent workflow that allows schools to send consent or liability forms to parents/guardians and to record their responses. We may store:

• Consent requests: type, status, associated learner, academic year, creation and update timestamps, reference number, and any custom fields defined by the school's consent template.
• Consent evidence and documents: generated PDF documents (stored in object storage), file path/name, version, and metadata snapshots at the time of document generation (e.g., list of textbooks and replacement cost totals for liability forms).
• Consent audit log: a timestamped record of status changes and actions (e.g., issued, submitted, approved, cancelled) and the user who performed each action.
• Digital acceptance metadata: when a parent/guardian accepts a consent form digitally via the Platform, we record the timestamp, IP address, browser/device user agent, and the identity of the authenticated user who accepted. This constitutes the Platform's record of the acceptance event.
• Verification records: where a school admin records a paper return or approval, we store who recorded it and when.

Consent records are initiated by schools and relate to their learners and linked parents/guardians. The school is the Responsible Party for consent records relating to their learners. Mzali acts as Operator and maintains the platform infrastructure and audit trail.

4.11 Automatic collection (logs, device data, cookies)

We may collect log information, device information (browser/OS/device type), IP address, and approximate location information (e.g., inferred from IP) depending on how you access the Platform.

If we enable Redis caching in future, it may temporarily store limited and short-lived cached data to improve performance and reliability (for example, rate limiting counters, session acceleration, queued jobs, or similar operational data). Cached data is typically ephemeral and is not intended to be a system of record.

4.12 Identity verification selfie (biometric information)

Where a school enables parent identity verification, you may be asked to take a live selfie so the school can confirm you are the child’s parent or guardian. A facial photograph is biometric information and is treated as personal information under POPIA (and as a special category of data under the GDPR). We collect it only with your consent, captured before the camera opens.

• Purpose & limitation: the selfie is used solely for manual identity review by authorized staff of your child’s linked school. We do not perform automated facial recognition, face-matching, or other automated biometric processing on it.
• Who can access it: only authorized administrators of the linked school (and Mzali platform administrators acting as operator). Each view of the image is access-controlled and audit-logged.
• Storage & security: stored on a private (non-public) store, never exposed by a public URL, and stripped of camera metadata (EXIF) before storage.
• Retention: kept while you remain linked to a school that uses verification, and deleted when you unlink from all such schools, delete your account, or ask us to remove it.
• Your rights: you may withdraw consent and request deletion at any time; the school may then be unable to grant verification-dependent access.

5) How we use information

We use information to operate the Platform, communicate with you, provide support, and improve the Platform.

• Account creation, authentication, access control, and session management
• Parent–learner linking and permission management
• Delivering in-app and push notifications
• Security: fraud prevention, abuse detection, rate limiting, and incident investigation
• Auditing of key actions for compliance and accountability
• Textbook loan management: tracking issued, returned, overdue, lost and damaged books; managing replacement fees and payment records
• Consent workflow management: generating consent and liability documents, routing them to parents, recording acceptance or rejection, and maintaining an immutable audit trail
• Support, troubleshooting, and service improvement
• Where permitted, marketing communications (with opt-out)

6) Lawful basis (POPIA)

We process personal information only where lawful and necessary, including for:

• Providing the Platform and performing contracts with users/schools
• Legitimate interests (e.g., Platform security, integrity, fraud prevention) balanced against data subject rights
• Compliance with legal obligations
• Consent where required (e.g., certain marketing and optional processing)
• School authority/mandate for education administration (for Student Data)

7) How we share information

We do not sell personal information to third parties for their marketing purposes. We may share information with limited staff, service providers, business partners (typically aggregated/non-identifiable), legal authorities where required, or third parties with explicit opt-in consent.

7.1 Service providers (operators/sub-processors)

We use vendors for hosting, storage, messaging, support tooling and similar services. They may only use information as needed to provide services to us (or to you through us), and must follow appropriate confidentiality and security obligations.

7.2 Push providers

Push notifications are delivered via Google (FCM) and/or Huawei (Push Kit). Device tokens and message payloads may be processed by those providers according to their own terms and policies.

7.3 Schools and authorised school staff

Where you are linked to a school, relevant information may be accessible to authorised school users based on role and tenant scoping.

7.4 Legal disclosure

We may disclose information to comply with legal process or to protect our legal rights, the Platform, and users.

8) Public APIs (student lookup / school search)

To support parent onboarding, the Platform may provide rate-limited endpoints designed for minimal disclosure:

• Student lookup: school identifier + accession number returns limited fields (e.g., student id, accession number, name, school name, grade) to enable linking.
• School search: rate-limited school search by name.

We apply technical controls (e.g., rate limiting, monitoring) and prohibit scraping, harvesting, reverse engineering, or abusive access attempts.

9) International transfers

We operate from South Africa. However, our infrastructure providers may process or store data in regions outside South Africa. Laravel Cloud routes application traffic to the AWS region assigned to the application, and Laravel Cloud states its hosting runs on dedicated AWS EC2 servers. Cloudflare R2 object storage location is determined by Cloudflare's data location controls and your configuration.

Where personal information is transferred across borders, we take reasonable steps to ensure appropriate safeguards are in place, including contractual protections with service providers and, where applicable, reliance on processor/sub-processor contractual terms.

10) Security

We use commercially reasonable safeguards, but no method of transmission or storage is 100% secure.

• Password hashing and secure authentication controls
• Hashed refresh token storage and revocation mechanisms
• HTTPS in production (where applicable) and secure cookie/session controls
• Role-based access control and tenant scoping (school data separation)
• Rate limiting on auth and public endpoints
• Audit logs for sensitive actions
• Operational monitoring and administrative access restriction

11) Retention

We retain personal information only for as long as necessary for the purposes in this policy, legal compliance, dispute resolution, and enforcement of agreements.

Recommended (set your actual numbers and implement them): audit logs and security logs should have defined retention periods; backups should be time-limited; Student Data retention should align to school instructions and applicable recordkeeping duties.

12) Your rights & choices

12.1 Marketing opt-out

You can opt out of marketing communications at any time. We will still send service-related communications.

12.2 Cookies

The Platform may use cookies; you can configure your browser to reject cookies, but some features may not function properly.

12.3 Access, correction, deletion

You may request confirmation that we hold personal information about you, access to your personal information, categories of third parties to whom we disclosed it, and correction/deletion of inaccurate or excessive data.

Requests can be made to [email protected]. Where the school is the Responsible Party for Student Data, we may refer the request to the school and/or require the school's instruction before changing Student Data.

12.4 Device tokens & notification controls

• Users can unregister device tokens (stops push notifications to that device).
• Users can manage notification preferences and mark notifications as read where supported.
• Users can log out and revoke refresh tokens (API) where supported.

12.5 Verification & limitations

We may require identity verification before fulfilling requests. We may refuse or limit requests where permitted by law, for example to protect others' rights or maintain Platform security.

13) Children / minors

The Platform processes information about minors primarily as Student Data managed by schools. Schools are responsible for ensuring they have a lawful basis and any required permissions/authorisations for uploading and maintaining Student Data (including special personal information).

14) Links to other applications

The Platform may contain links to third-party applications or services. We are not responsible for their privacy practices and recommend reading their policies.

15) Changes to this policy

We may update this policy from time to time. Changes will be posted and will take effect from the date of posting.

16) Complaints

If you have concerns, contact us at [email protected] first. We will investigate and respond as reasonably possible.

Annex A: Operator & Sub-processor terms Add-on

This annex summarises operator-grade obligations we apply when processing Student Data on behalf of schools. For a signed school contract, see Annex B (DPA template).

A1. Processing instructions

• Mzali processes Student Data only on documented school instructions (including configuration, roles, permissions, and feature use).
• Mzali may refuse instructions that are unlawful, insecure, or technically impossible, and will notify the school where applicable.

A2. Confidentiality

• Mzali personnel with access to Student Data are bound by confidentiality obligations and access controls.

A3. Security measures

• Mzali maintains technical and organisational measures appropriate to the risk, including access control, tenant scoping, audit logging, and secure credential handling.
• Mzali applies rate limiting and monitoring to reduce abuse of authentication and public endpoints.

A4. Sub-processors

Mzali may use sub-processors for hosting, storage, messaging and notifications. Sub-processors are required to protect data and use it only to provide services. We may update our sub-processor list from time to time; material changes will be posted in this policy and/or communicated to schools via contractual notice mechanisms.

Notes: Laravel Cloud indicates its hosting runs on dedicated AWS EC2 servers and traffic is routed to an AWS region assigned to the application. Cloudflare R2 storage location depends on your configuration and Cloudflare's data location controls. Where Redis is enabled, we configure it to store only short-lived cached data where feasible.

A5. Assistance with rights requests

• Mzali will reasonably assist schools to respond to data subject requests relating to Student Data, subject to verification and legal limits.
• For direct user account data (parents/staff/platform admins), Mzali responds as Responsible Party where applicable.

A6. Security incidents

• If Mzali becomes aware of a compromise affecting Student Data, Mzali will notify the school without undue delay and provide available information to support investigation and any required notifications.
• Mzali may delay specific details if necessary to avoid compromising security investigations, but will act reasonably and in good faith.

A7. Return/deletion

• Upon termination of a school's use of the Platform, Mzali will support export of Student Data and handle deletion/return in accordance with the school contract and applicable law.
• Backups are deleted on a rolling basis per retention schedules.

Annex B: School Data Processing Addendum (DPA) template (summary) Add-on

This is a contract template summary you can convert into a signed DPA with each school. Keep the full signed DPA separate, but you can reference it publicly from this policy.

B1. Parties and roles

• School: Responsible Party (controller) for Student Data.
• Mzali: Operator (processor) for Student Data; Responsible Party for Platform security/operational data where applicable.

B2. Purpose limitation

• Mzali processes Student Data solely to provide the Platform services, maintain security, support users, and comply with law.

B3. Processing details (Schedule)

• Categories of data: Student Data, guardian data, staff data, academic/attendance/merit records, notifications, audit logs, textbook loan and inventory records (including payment and condition history), consent records (requests, evidence, PDF documents, audit logs, digital acceptance metadata).
• Data subjects: learners, parents/guardians, staff.
• Special personal information: health/allergies/special needs where captured by the school.

B4. Confidentiality & access control

• Mzali restricts access by role/tenant scope; platform admins may have cross-school access for administration, support, compliance and security.
• Access is logged for audit where appropriate.

B5. Sub-processors

• Mzali maintains a list of sub-processors and ensures they have appropriate contractual protections.
• School is notified of material changes to sub-processors via contract notice mechanisms.

B6. Incident notification & cooperation

• Mzali notifies the school without undue delay after becoming aware of a security compromise affecting Student Data.
• Mzali supports investigation, containment, remediation, and required communications as agreed.

B7. Retention, return and deletion

• Retention schedules are agreed in the DPA; Student Data return/export format is defined (e.g., CSV/JSON exports).
• Deletion obligations are subject to legal recordkeeping requirements.

B8. Liability & limits

• DPA includes liability caps, exclusions for indirect loss, and a responsibility split aligned to who controls the processing decisions (school vs Mzali).

Annex C: Cookie notice Add-on

The web experience may use cookies and similar technologies to operate sessions, protect against attacks, and remember preferences. You can reject cookies in your browser, but parts of the Platform may not work correctly.

C1. Categories

• Strictly necessary: session management, authentication, security protections.
• Preferences: language or "remember me" style convenience features (where enabled).
• Security: CSRF protection and abuse prevention.
• Analytics (optional): if you add analytics later, list it here with opt-out controls.

C2. Typical examples (names may vary)

C3. Managing cookies

• You can delete cookies in your browser settings.
• You can block cookies, but some Platform features may break (login/session features).