- School decides why and how data is used; ScholaGH acts only on instructions.
- We list our Sub-processors and tell you before they change.
- We notify you of any personal-data breach without undue delay.
- On leaving, you can export your data, then we delete it.
Contents
This Data Processing Agreement ("DPA") governs how ScholaGH processes Personal Data on behalf of a School. It is the core document that defines and limits responsibility: the School is the Controller and SCHOLAGH TECHNOLOGIES is the Processor under the Data Protection Act, 2012 (Act 843). It forms part of, and is subject to, our Terms of Service and should be read with our Privacy Policy. The Schedules at the end list the categories of data, the purposes of processing, and the Sub-processors.
1. Definitions
Capitalised terms not defined here have the meaning given in the Terms of Service. "Controller", "Processor", "Personal Data", "Sub-processor", and "Student Data" are used as defined there and in Act 843.
2. Roles of the parties
2.1 The School is the Controller of the Personal Data it places in the Service. It decides the purposes and means of processing and is responsible for the lawful basis and for the notices and consents required under Act 843, including for Student Data about minors.
2.2 SCHOLAGH TECHNOLOGIES is the Processor. It processes Personal Data only on behalf of the School and only on the School's documented instructions.
3. Scope and instructions
3.1 The subject matter, duration, nature, purpose, types of Personal Data, and categories of data subjects are set out in Schedule 1.
3.2 The School's instructions are given through this DPA, the Terms, and the settings and actions the School's Authorised Users take in the Service. We will not process Personal Data for any other purpose unless the law requires it, in which case we will tell the School first unless the law forbids it.
3.3 We do not sell Personal Data, do not use Student Data for advertising, and do not use Student Data to train machine-learning or artificial-intelligence models.
4. Our obligations as Processor
We will:
- process Personal Data only on the School's documented instructions;
- ensure people authorised to process Personal Data are bound by confidentiality;
- apply the security measures described in clause 6 and Schedule 3;
- respect the conditions in clause 7 for engaging Sub-processors;
- assist the School as described in clauses 9 and 10; and
- delete or return Personal Data as described in clause 12.
5. Confidentiality
We keep Personal Data confidential and ensure that our employees, contractors, and Sub-processors who process it are under a duty of confidentiality.
6. Security measures
Taking into account the state of the art and the risks of processing children's data, we apply appropriate technical and organisational measures, including those in Schedule 3. We may update these measures over time, provided the level of protection is not reduced.
7. Sub-processors
7.1 The School gives general authorisation for us to engage the Sub-processors listed in Schedule 2 to help provide the Service.
7.2 We impose data-protection obligations on each Sub-processor that are, in substance, no less protective than those in this DPA, and we remain responsible for their performance.
7.3 If we intend to add or replace a Sub-processor, we will update Schedule 2 and, where practicable, give the School advance notice so it can raise a reasonable objection.
8. Location of processing
Personal Data may be hosted and processed at the locations of our Sub-processors. Our hosting and object-storage Sub-processors (Railway and Cloudflare R2) process data in the United States, while our SMS and payment Sub-processor (Hubtel) processes data in Ghana. Where Personal Data is transferred outside Ghana, we will take steps consistent with Act 843 to protect it and to ensure each Sub-processor is bound by comparable data-protection obligations.
9. Assisting the Controller
9.1 Taking into account the nature of the processing, we will assist the School, by appropriate technical and organisational measures and so far as is possible, to respond to requests from data subjects exercising their rights under Act 843.
9.2 Where a data subject contacts us directly, we will refer them to the relevant School and will not respond ourselves except to acknowledge and redirect, unless the School instructs otherwise.
9.3 We will also provide reasonable assistance to the School with data-protection impact assessments and consultations with the Data Protection Commission, so far as they relate to our processing.
10. Personal-data breaches
10.1 If we become aware of a breach affecting the School's Personal Data, we will notify the School without undue delay after becoming aware of it.
10.2 Our notification will describe, so far as we can, the nature of the breach, its likely consequences, and the measures taken or proposed. We will support the School's own response and any notification the School must make to the Data Protection Commission or to affected individuals.
11. Audits and information
11.1 We will make available to the School information reasonably necessary to show compliance with this DPA.
11.2 The School may audit our compliance no more than once a year (and after a breach affecting its data), on reasonable prior notice, in a way that does not compromise the security or confidentiality of other customers' data. The parties will agree the scope and timing in advance. For parts of the Service operated by our Sub-processors, we may satisfy an audit by providing their relevant compliance information or independent third-party reports.
12. Return and deletion of data
12.1 On termination, the School may export its Personal Data during the Export Window stated in the Terms (thirty (30) days after termination).
12.2 After the Export Window, we will delete or irreversibly anonymise the School's Personal Data within a reasonable period, except for any copy the law requires us to keep or that remains in routine backups until those backups expire in the ordinary course, during which it stays protected by this DPA.
13. Liability
Liability under this DPA is subject to the limitations and exclusions in the Terms of Service.
Schedule 1: Details of processing
Subject matter and duration: provision of the ScholaGH school-management Service for the duration of the School's subscription and any Export Window.
Nature and purpose of processing: hosting, storing, organising, displaying, and transmitting Personal Data so the School can run attendance, assessments, report cards, fees, communication, and reporting.
| Categories of data subjects | Categories of Personal Data | Purpose of processing |
|---|---|---|
| Students (usually minors) | Names, ages/date of birth, photographs, class, admission number, attendance, assessment scores, report cards | Managing enrolment, attendance, assessment, reporting |
| Parents / guardians | Names, phone numbers, email addresses, relationship to student | Communication, billing, parent-portal access |
| Staff | Names, roles, contact details, attendance, GPS clock-in location, payroll-adjacent records the School keeps | Staff management and attendance |
| Payers | Invoice and payment records, amounts, status | Fee management and receipts |
| Message recipients | Phone numbers and message content/logs | Sending SMS/WhatsApp the School enables |
| Authorised Users | Usernames, hashed passwords, encrypted 2FA secrets, activity logs | Authentication, security, audit trail |
Schedule 2: Sub-processors
| Sub-processor | Service provided | Location |
|---|---|---|
| Hubtel | SMS gateway and payment support | Ghana |
| Railway | Application and database hosting | United States |
| Cloudflare R2 | Storage of uploaded logos and photographs | United States |
Each Sub-processor listed above is engaged under its own data-processing terms, which are published on that provider's website (Hubtel, Railway, and Cloudflare).
Schedule 3: Security measures
- Encryption of data in transit (HTTPS/TLS).
- Two-factor authentication for administrator, finance, and teaching accounts.
- Encrypted storage of two-factor secrets; passwords stored only as secure hashes.
- Role-based access control limiting each user to what their role permits.
- Audit trail of sensitive actions (payments, corrections, publishing).
- Regular database backups to support recovery.
- Content Security Policy and other defensive HTTP headers; self-hosted assets to avoid third-party tracking.
This document forms part of your agreement with SCHOLAGH TECHNOLOGIES and is provided for information. It is not legal advice.