Privacy Policy

This policy explains what personal data this platform handles, why it handles it, who it reaches, how long it is kept and what a person can ask about it. It covers School Tech, the school management platform published by School Tech, together with the website it is served from and every part of it a school, a member of staff, a parent or a learner uses.

Two different responsibilities sit behind that sentence, and the difference matters under Ugandan data protection law:

The school

A school using the platform decides which records are kept about its learners, their families and its staff, and for what purpose. Under the Data Protection and Privacy Act, 2019 the school is the data collector - the body that determines the purpose and the means of processing. Any privacy notice the school has given families governs those records, and the head teacher or the person the school has nominated for data protection is the first person a data subject should write to.

School Tech

We build and run the platform and hold the infrastructure the records sit on. We process personal data on the documented instructions of the school, as a data processor. We are a data collector in our own right only for the small set of things we decide for ourselves: the requests sent through the public website, the accounts of people who correspond with us, and the technical records that keep the service standing.

Where this policy says a school decides, the school is answerable for that decision. Where it says we do something, we are answerable for it. A school remains responsible for its own choice of what it records, whose consent it obtains and how long it keeps a record, and this policy does not shift that responsibility onto us.

The Constitution of the Republic of Uganda provides at Article 27 that a person has a right to privacy, which includes protection of their person, home, correspondence and other property. The framework this platform is built to give effect to that right in practice is:

• The Data Protection and Privacy Act, 2019 (Cap. 97) and the Data Protection and Privacy Regulations, 2021, which came into force on 12 March 2021. These are the principal law on personal data in Uganda.
• The Registration of Persons Act, Cap. 332, which lies behind the national identification numbers held on staff and guardian records.
• The Access to Information Act, Cap. 95, which sets out what may be disclosed and what must be protected.
• The Regulation of Interception of Communications Act, Cap. 101.
• The Computer Misuse Act, Cap. 96, as amended, which makes unlawful access to and interference with computer data a criminal offence.
• The Electronic Transactions Act, 2011, which gives legal effect to records created and kept in electronic form.

The Act is administered by the Personal Data Protection Office, established under section 4 and constituted by the Regulations, which operates within the National Information Technology Authority - Uganda. The Office keeps the public Register of Data Collectors, Controllers and Processors referred to in the Regulations, issues guidance, and receives complaints from data subjects. Our own entry in that Register is shown at the head of this page.

Ugandan law treats the data of children with particular care. Section 6 of the Act is dealt with in full in the section headed learners and children below.

Personal data

Any information relating to an identified or identifiable person - the words of the Act. A name, a phone number, an identification number, a photograph, a class register entry that points at one child, a location reading taken from a person's phone.

Sensitive personal data

Data whose misuse is more likely to cause harm, and which the Act and the Regulations treat with more care: health, biometric verification material, identity document numbers, financial detail, and the data of a child.

Data subject

The person the data is about: a learner, a parent or guardian, a staff member, an applicant, or a visitor who has used the website.

Processing

Anything done with data - collecting it, recording it, holding it, organising it, retrieving it, using it, sharing it, restricting it, combining it or destroying it.

Record

A thing the platform holds about a person: a learner file, a staff file, a family link, an attendance event, a fee account, a payroll entry, a clinic visit, a borrowed book.

Account

A signed-in identity on the platform, carrying a role, a set of permissions and the schools it is allowed to stand in.

The platform is modular. A school turns the parts it needs on and leaves the rest off, so no installation holds everything described in this policy. Personal data reaches it in the following ways and in no others:

• Entered by school staff. Admissions and enrolment, class registers, marks and assessments, fee and payment records, payroll, library loans, clinic visits, transport and boarding arrangements, discipline notes.
• Created when an account is opened. A staff, parent or learner account is created by the school or by an invitation, and carries the identity and contact details needed to run it.
• Used by a parent or guardian directly. The family door lets a registered parent look up a learner, follow attendance, see fees and reply to a school notice.
• Marked as attendance. A register, a gate pass, a self-attendance check-in: the time, the place, and where a school has enabled it a location reading or a face check.
• Sent from the public website. The five answers a visitor gives to ask for a demonstration, described in their own section below.
• Generated by the platform itself. Session records, sign-in records and the audit trail of every change.

We do not obtain personal data from any other source. We do not purchase lists, we do not receive feeds of people from third parties, and nobody is added to anything on the strength of somebody else's data.

The list below is the whole of what the platform is capable of holding. It is written so that a family can read it and know what a school could have recorded about them.

Identity

Name, gender, date and place of birth, nationality, national identification or NINS number and other identity document numbers, photograph or portrait, religion where a school records it, and the internal references the platform uses to link a person's records together.

Family and contacts

The relationship between a learner and each parent or guardian, postal and physical address, phone numbers, email addresses, occupations and employers, siblings, and the people authorised to collect a child or to be told about it.

Academic

Class, stream and house, subjects and subject choices, admission and withdrawal dates, terms and years attended, timetables, assignments and marks, examination numbers, report cards, and any behavioural or disciplinary note a school records.

Attendance and movement

Daily registers and their reasons, gate passes with the reason and the time, and self-attendance events carrying the time, the place, the accuracy of the location reading, the device address of the check-in and the result of any verification run.

Health

Blood group, allergies, chronic and current conditions, immunisations where recorded, clinic visits and their notes, medicine a school is asked to administer, and the contacts to be called in an emergency. This is sensitive personal data.

Location

The coordinates of the school, of a pickup point and of a drop-off point, used to decide whether a check-in happened where it should have and to tell a family when a learner has been picked up or let in.

Money

Fee structures and their items, invoices, discounts, bursaries, payments, refunds and their methods, mobile money numbers used for a payment, deposits and the balances a family holds, and for staff the salary, grade, deductions, loan and advance records. This is sensitive personal data.

Access

A username, email or phone number, a hashed password, a role and its permissions, the schools an account may enter, and the state of anything the account has been asked to do, such as changing a password.

Technical and audit

Session records, the internet address a request arrived from, the browser and device it was made with, a reference that ties the entries of one visit together, and a copy of the field before and the field after every change.

None of this is compulsory in any installation. A school that does not use the clinic module holds no health data. A school that has not switched on transport holds no pickup coordinates. A school that marks its register on paper and imports nothing holds only what it chose to import.

There is also no field in this list that a school is obliged to complete. A school records what its purpose requires and what it has told families it records, and a data subject may ask the school why any particular field is there.

Three categories on the platform call for more than the general rules above:

• Health, held because a school must be able to act in an emergency and to keep an infirmary record.
• Face and liveness verification, held because a school has decided that an attendance claim must be proved.
• Identity document numbers and financial detail, held because a school has a duty to keep them in order to pay, to bill, to account and to report.

For each of them the same three things hold. The field does not exist in an installation until the module that carries it is switched on. Only the roles that need it can read it - a clinic note is visible to the roles a school has given clinic access, and to nobody else. And it is used for the purpose it was recorded for and for nothing else: an allergy is not used to sort a class, a salary is not used to decide a fee, a number on an identity document is not used to find a person somewhere else.

A school may ask a member of staff or a learner to prove presence by taking a photograph of themselves, or to prove that a check-in was made by a live person rather than by holding up another photograph to the camera. This is the part of the platform most likely to be asked about, so it is described in full.

• The check runs inside the application itself, in the same code that serves every other screen. The image is not sent to any other company, is not processed by any third-party service, and is not transmitted anywhere except to the platform it belongs to.
• What is kept is the result of the check, not the picture. The record holds a liveness score, a match score against the reference photograph, whether each cleared the threshold the school has set, whether the attempt was flagged for a human to review, and a one-way fingerprint of the image which proves that a particular image was involved without the image itself being retained.
• Attempts are counted and limited - three by default - after which the check stops and may be tried again only after a waiting period of fifteen minutes.
• The reference photograph a school enrols is an ordinary portrait, the photograph the school already holds for a passbook, a register or an identity card. It is compared against and nothing more.
• A location check that accompanies a verification carries a reading and its accuracy in metres, and the reading is discarded if it is too imprecise to be relied on rather than being used loosely.

Where a school enables this, the school has decided to use it and the school must be able to explain it to the people whose attendance it marks. We provide the mechanism and the settings; the decision, the explanation and the policy around it belong to the school.

A person who does not want to be checked this way should say so to the school. There is usually an ordinary register entry, a card, or a supervisor's signature that serves the same purpose, and the school can switch the requirement off for that person or for the whole installation.

Section 7 of the Act is the rule that governs all of this: personal data may not be collected, processed, used or kept unless the data subject has first consented to it, and consent obtained by fraud, misrepresentation or undue influence is not consent. The purposes the platform serves are these:

• Running the school: admissions, classes, timetables, assessments and reports.
• Communicating with families about fees, events, attendance, and a child's welfare.
• Keeping a child safe: knowing who may collect one, who is expected and did not arrive, whom to call, and what medicine they are liable to.
• Billing, receiving payment and accounting for it.
• Paying staff and accounting for payroll.
• Producing the returns, statistics and records a school is required by law to keep or to submit.
• Keeping an accurate account of who changed what, which is how a disputed mark, a disputed payment or a missing item is resolved.
• Securing the service and keeping it standing.

The Act permits collection and processing without consent in the situations it sets out - among them where it is necessary for a contract to which the data subject is party, to comply with a legal obligation, in the proper conduct of proceedings, or to protect a vital interest such as treating a child who has been taken ill. Where the platform relies on one of those instead of on consent, the school is told which, and the reason is recorded with the record.

Consent may be withdrawn. Where it is, the school is informed, and the processing that rested on it stops - unless one of the situations above keeps it lawful, in which case the school is told that it does and why.

Section 6 of the Act provides that no person shall collect, process, use or publish the personal data of a child unless it is done with the prior consent of the child's parent or guardian, or of another person who by law has authority over the child, and that any such collection must take account of the child's best interests. On this platform that means the following.

• Consent for a learner's data is taken by the school, at enrolment or before it, from a parent, guardian or the person with legal authority. It is not taken by software, and we do not put a tick-box on a school's behalf and treat it as the consent the Act requires.
• Nothing on the platform markets to a child, builds a profile of a child, or shows a child any advertising.
• A learner's own access is limited to what the school has switched on, and a learner sees their own record and what the school permits them to see - never the record of another learner.
• A health note, an allergy or a disciplinary note reaches the roles the school has decided need it, and no others.
• Where a learner's family is separated, the contacts the school holds define who may see what, and the school is responsible for keeping that list right.

The family door needs stating plainly, because it is the one place a person reaches for a child's record without being handed an account. A parent identifies themselves with a phone number. That number is matched against the contacts the school holds for the learner, and the match is what makes a person a parent for the platform. It is why the school keeping those numbers current is a protection rather than a formality.

A phone number on an account cannot simply be replaced. The change is confirmed with a code sent to the number, a number cannot be changed again on one account more often than every thirty days, and the codes themselves expire within minutes.

Within an installation, a person sees only the records their role and permissions reach, and only the school they are standing in. Nothing in the platform lets a reader widen that by editing an address in the browser: the data and the school the account belongs to decide what is available.

Outside it, personal data leaves the platform only through one of the following routes, and only where the installation has switched the route on:

• An email provider, where the installation sends mail through an outside service rather than its own server. Invitations, receipts, notices and password resets go through it, with the address they are going to.
• Africa's Talking, where text messaging is switched on, so that a message may reach a phone: the number, the body of the message and the approved sender name.
• Relworx, where mobile money is switched on, so that a payment may be taken or made: the amount, the phone number paying or being paid and a reference. Money always moves on the school's own account, never ours.
• Have I Been Pwned, and only where a platform administrator has switched on the check that rejects a password which has appeared in a known breach. The first few characters of a hash of the password are sent to it - never the password, and nothing that identifies the person choosing it.
• The hosting provider, and any object storage the installation writes uploaded files to, in each case under the arrangement that puts the platform there.
• An auditor, adviser or lawyer, in a form that discloses no more about individuals than the work requires.
• A court, a regulator, the police or the Personal Data Protection Office, where Ugandan law requires it to be given. Where we are able to, we tell the school before we do.

We do not sell personal data. We do not rent, trade or aggregate lists. No third party places advertising on this platform and none is shown on it.

There is one thing a visitor's browser fetches from somebody other than this installation: the typefaces this page loads from Google Fonts. That request reveals the visitor's internet address to Google, as any web request does. It carries nothing a person has typed and nothing about the records on the platform. A school that does not want it may have the platform served without the external typefaces.

Records sit on the infrastructure the installation has been deployed to. The platform does not assume a country: an installation may be hosted in Uganda or elsewhere, and the school is told where its records are.

Section 19 of the Act and the Regulations that support it restrict a transfer of personal data outside Uganda. In short, the recipient country must afford a level of protection that is adequate and equivalent to that guaranteed by the Act, or the data subject must have consented, or one of the situations the Act allows must apply; and a person who has received data on that footing may not pass it further on without the same footing. As at the date of this version the Office has not published a list of countries it regards as adequate. Until it does, we treat a transfer outside Uganda as needing either the school's documented instruction or the consent of the people concerned, and we tell the school which applies.

• Where the platform is hosted in Uganda, no transfer arises and none is made.
• Where an installation is served from infrastructure outside Uganda, the school is told, and the same duties of confidentiality, access control and incident response travel with the data under the arrangement that placed it there.
• Where one of the services named above operates from outside Uganda, the transfer is only the one that service must make in order to do the job it was switched on for, and only for that job.
• Backups are held on the same terms, and in the location the installation is configured to write them to.

A school's own retention schedule decides how long a record is kept, and the platform is configured to match it. What follows is what the platform does with each kind of data.

Operational records

A learner's file is kept while they are known to the school and afterwards for as long as the school's policy and its statutory duties require. We do not delete a school's records on a timetable of our own, and we do not keep them past the point at which the school tells us to destroy them.

Deleted records

A record that has been deleted is hidden from every screen at once. It is destroyed outright only after the number of days set in the platform's retention settings, and the default for that setting is no automatic destruction at all - because a purge on a period nobody chose is not a retention schedule.

Audit trail

Kept for the period set in the retention settings. The default is about seven years, which is the period a school is most likely to need in order to show who changed a mark, a fee or a medical note and when it was changed. It may be set to keep indefinitely.

Sessions

A signed-in session ends after the period of inactivity configured for the installation. Cookies stay on a browser for as long as the browser keeps them.

Requests from the website

Kept until an administrator deletes them. Nothing is sent out of the installation from that form.

Codes and verification

A phone-change code expires within minutes of being issued. A verification event is kept with the attendance event it proves, because it is the evidence that the marking was genuine.

Backups

Compressed dumps of the database are kept until the retention count configured for the installation prunes them. A backup is not a way of keeping a record beyond its date: restoring one puts back only what the school still has a right to hold.

An aggregate, anonymised count of records - how many learners were enrolled in a year, what the attendance rate was - is not personal data and may be kept after the individual records behind it have gone. Statistics of that kind are only ever produced where the individuals cannot be re-identified from them.

No system that holds records of this kind can promise that nothing will ever go wrong. Rather than make such a promise, the measures below say what the platform actually does.

• Access is by role. Every screen and every record sits behind a permission, and a role that has not been granted it cannot read it.
• Schools are kept apart. Each record carries the school it belongs to and every query is scoped to the school the account is standing in.
• Passwords are stored as a hash and never as readable text. The password policy sets a minimum length of at least eight characters, ten by default, and can require mixed case together with a number and a symbol.
• Cookies are marked so that scripts on the page cannot read the session, and so that another site cannot cause the session to be sent with a request from that site. Where the installation is configured to be served only over an encrypted connection, they are marked so that they are never carried over an unencrypted one.
• Sign-in is limited. Repeated failures lock the account for a configured period. The doors a person who is not signed in may knock on - a password reset, the family lookup, the issuing of a code, an upload, a request from the website - are each rate limited.
• Secrets are stored encrypted rather than in the clear: an SMS API key, a payment key, a webhook signing key, a mail password.
• Every change is written to the audit trail with who made it, which record it touched, the address it came from, and the value before and the value after.
• Uploads are checked for type and size and an image used for the brand is re-encoded. Files are held on storage that is not publicly listed.
• Database backups are written outside the directory the website is served from, so that a mistake in the web root does not reach them.
• The form on the public site carries a field that no visitor can see; anything filled into it is refused and not written down.
• An account may be marked as required to change its password before it is used, which is how an invitation cannot leave a known password live.

What the platform does not do matters as much as what it does. There are no analytics scripts, no advertising identifiers, no tracking pixels and no third-party code watching what a school types. Every page of this platform is produced by this application; the only thing a visitor's browser is asked to fetch from anybody else is the typefaces named above.

Section 23 of the Act requires a person who has custody of personal data, and the Regulations that support it require a registrant, to notify the Personal Data Protection Office immediately where there is a reasonable belief that the data may have been accessed or used in an unauthorised way. It is for the Office to determine whether the people whose data is involved must themselves be informed, and a registrant also files an annual summary of the incidents recorded.

Our own procedure is this:

1. Establish what has happened and what records it touches.
2. Stop it, and secure the affected accounts, sessions and records.
3. Notify the Personal Data Protection Office immediately once there is reason to believe personal data may have been reached in an unauthorised way.
4. Tell the affected school without delay. It is the collector, the families are its families, and it must be able to act.
5. Keep a written record of the incident, the assessment and the remedy, which is what the annual summary is drawn from.
6. Inform the people affected where the Office so determines, or where the school asks us to.

If you believe something has happened to your own record, tell your school and tell us. Neither of those waits for the other, and neither is a condition of the other.

The Act and the Regulations give a data subject rights over the personal data held about them. These are those rights in the form they take here.

To be told what is held

A right to be informed, in a form a person can read, of what personal data is held about them and why. We provide this for the data we collect in our own right and we assist the school for the records it holds as collector. A request must be complied with promptly and in any event within thirty days. Where part of a request concerns somebody else, the reason it cannot be met is explained rather than the request being ignored.

To have it corrected

A name spelled wrongly, a number out of date, a class recorded against the wrong child: a school corrects its own records directly, and we correct what we hold on the school's instruction.

To have it deleted or destroyed

Data that has no right to be held, or that is being held beyond the purpose it was collected for, may be asked to be deleted or destroyed. A school's own duty to keep an academic record, an accounting record or a medical record is a limit on this, and is the reason such a request is sometimes refused - the refusal is explained, never left bare.

To object

Where processing would cause unwarranted damage or distress, a data subject may object to it. The platform then stops using the data for that purpose unless the Act permits it to continue, and says on what footing it continues.

To complain

To the school, to us, or directly to the Personal Data Protection Office. Taking a complaint to the Office affects nothing else a person may be entitled to ask for.

Making a request:

1. For a learner's or a family's records, write to the school. It is the collector, it holds the registers, and it is the body that can answer about them.
2. For anything we hold in our own right - a request sent from the website, the account of somebody at a school that has contracted us, our own correspondence - write to the data protection contact shown at the head of this page, or use the contact page if no address has been published.
3. Say which school the request is about and how you are connected to it, so that the right record is looked at. We may ask for proof of identity before anything is disclosed: handing a child's record to the wrong person is precisely the harm the whole of this is meant to avoid.

A request may be made in ordinary language, in a letter, an email or a message, and does not have to be on any particular form.

The platform sets a very small number of cookies, and each of them has a reason:

• One session cookie, which keeps a person signed in to the portal they are using. Without it a signed-in page cannot know who is looking at it.
• One token cookie, which lets a submitted form be proved to have come from the page it was shown on, and which is how the platform refuses a request that came from somewhere else.

No cookie is set for advertising. No cookie is set to follow a person from this site to another site, and no cookie is set to identify a device across sites. Signed-in pages are not indexed by search engines; the robots file on this installation says which parts of the site are closed to crawlers.

The public pages hold one form that takes anything at all from a visitor: the request to see the platform, which asks a name, the school you speak for, a number that can be rung, the part you play and a day that suits you.

• Those five answers are everything that is written down. No address, no browsing record, no note about who you are is stored when you use the form.
• Nothing is sent out of the installation by the form. The answers stay in the installation's own database and are read only by the people its administrator has given access to that screen.
• They are used to answer the request and for nothing else. They do not become a marketing list and they are not added to one.
• A day is asked for because the request is for a conversation at a time that suits you.

Once the request has been answered, an administrator may delete it, and will do so on request. To have one removed, write to the contact at the head of this page and say roughly when it was sent.

The platform generates report cards, receipts, statements, passes, visitor lists and returns from the records it holds, and those leave as documents on the device that asked for them. Once a school has printed, exported or emailed a copy, its handling is the school's decision and this policy does not reach the paper in a family's hand.

A school should think about where exported files go and keep them in the same places as the records themselves. We do not retain a copy of anything a school exports, and we do not send a document to anybody other than the person the school asked for it to go to.

The version and the effective date are printed at the head of this page. A new version takes effect when it is published here, and a school may be told about a change that matters to the records it holds.

A school may publish its own privacy notice covering the records it collects. Where the two differ about a school's own records, the school's notice governs them; where they differ about what we do with the platform itself, this one does.

About this policy, or about personal data held on the platform, write to the data protection contact shown at the head of this page. Where no address has been published, the contact page on this website is the way in.

About the records a school holds about you, write to the school. It is the data collector and it is the body that can correct, explain or delete them.

About the way personal data is handled in Uganda generally, or to make a complaint, the Personal Data Protection Office may be approached directly. It operates within the National Information Technology Authority - Uganda in Kampala and is reachable through its website at pdpo.go.ug, where the arrangements for registering as a data collector, controller or processor and for filing a complaint are set out.

Nothing in this policy, and nothing in the terms of service, limits anything the Data Protection and Privacy Act, 2019 gives a data subject, or anything the Personal Data Protection Office may require of a data collector or a processor.