Data Protection Policy

Data Protection Policy

Effective Date: December 17, 2025
Last Updated: December 17, 2025

1. Introduction

Gestlat ThinkLab Limited builds and operates business systems that hold information our customers depend on, and within that information personal data belonging to their employees, patients, students, tenants, guests, customers and suppliers.

This policy sets out how we protect that information. It is written so that a customer, a prospective customer, an auditor or a regulator can read it and see exactly what we do.

Our commitments are simple: the customer owns its data, we hold it only to deliver the service the customer has asked for, we protect it with measures appropriate to the risk, and we can show what we did.

The detailed internal procedures that carry this policy out, covering access provisioning, support access, data subject requests, breach response, restore testing, patching, supplier assessment, deletion, offboarding, incident escalation, personnel changes, training and audit, are provided to customers and prospective customers on request. Write to [email protected].

2. Scope

This policy applies to:

• every system and service we operate or host for customers, across our full product range, including our enterprise resource planning, school management, healthcare, pharmacy, retail, hospitality, food and beverage, manufacturing, property management, field operations, human resources and tournament management platforms;
• all personal data and customer data we process, in any format, whether held in our systems, on our devices or with an approved supplier;
• all employees, directors, contractors, interns and any other person acting for Gestlat ThinkLab; and
• all locations and devices from which our work is done, including remote and home working.

Compliance is a condition of employment and of every contract for services with us.

3. Applicable law

We operate under the data protection law of the country in which we are established, and, for each engagement, under the data protection law of the host country: the country in which the client operates and in which the project is delivered.

How this works in practice:

• Identified at onboarding. Before processing begins, the applicable legal framework for that engagement is identified jointly by our compliance function and the client's own compliance, legal or data protection function. The client knows its own jurisdiction best, and we rely on that knowledge alongside our own assessment.
• Recorded in the agreement. What has been identified is written into the Data Processing Agreement for that engagement, so both parties are working from the same understanding rather than an assumption.
• Steps taken before processing. Where the host country's framework requires registration, notification to an authority, a particular contractual instrument, a specified location for storage, or any other step before personal data may be processed, those steps are agreed and completed before processing begins.
• The stricter standard applies. Where this policy and the host country's requirements differ, we apply whichever is stricter. Nothing in this policy reduces a protection the applicable law gives a data subject.
• Sector rules included. Where the client is regulated, for example in health, education or financial services, the requirements of its own regulator are identified in the same way and accommodated where they are consistent with this policy.
• Reviewed when things change. Where the law of the host country changes materially during an engagement, we review what we do with the client and adjust it.
• Recorded in a document the client can keep. On request, what has been identified and agreed for an engagement is set out in a Data Protection and Security Assurance Statement issued and signed for that client, described in section 22. That statement, not this page, carries the specifics of a particular project.

We are registered with the data protection authority that supervises us, and with any further authority whose registration our processing requires. Registration details are provided to customers and to regulators on request.

4. Data protection principles

In everything we do with personal data we apply these principles, which are common to the data protection frameworks we work under:

• Accountability. We can demonstrate what we do and why.
• Fairness and lawfulness. We process personal data only on a lawful basis and in a way the data subject would expect.
• Purpose limitation. We process personal data only for the purpose for which it was collected, and for any further purpose the law allows.
• Minimality. We hold only the personal data we need.
• Accuracy. We keep personal data accurate, complete and up to date, and correct it when told it is wrong.
• Storage limitation. We keep personal data only as long as it is needed, then destroy or de-identify it.
• Security. We protect personal data against loss, unauthorised access, destruction and unlawful processing.

5. Legal basis for processing

When acting as a processor for a customer, we rely on the customer's lawful basis. Our contracts require the customer to confirm that it has one.

When acting as a controller, we identify the lawful basis before collecting personal data, and we tell people what we collect, why, who receives it and how long we keep it, through our Privacy Policy. The bases we rely on are consent, performance of a contract, compliance with a legal obligation, and our legitimate interests in running and securing our business.

We do not use customer data for our own purposes. We do not sell personal data.

6. Data processing roles

When an organisation uses one of our systems, that organisation decides what personal data is held in it and why. That organisation is the data controller. We hold and process the data only on its instructions, as data processor.

This applies to every system we operate. A school using Shule360 is the controller for its student, guardian and staff records. A health facility using HealthCenterOps360, or a pharmacy using DrugStoreOps360, is the controller for its patient records. An employer using Pevron360 is the controller for its staff and payroll records.

We are the controller only for data we hold for our own purposes: our own staff and applicants, our prospects and enquirers, our customers' contact people, and visitors to our website.

Where we act as processor, the terms are set out in a Data Processing Agreement. Our standard Data Processing Agreement is available on request and forms part of our Master Subscription and Services Agreement.

7. What personal data each system holds

This section lets a customer see what its own system holds. The detail for an individual customer is recorded in that customer's Data Processing Agreement.

8. Rights of data subjects

Individuals may ask to see the personal data we hold about them, ask for it to be corrected or erased, object to its processing, ask that processing is restricted or stopped, including for direct marketing, ask for their data in a portable format, withdraw a consent they have given, and complain to us or to the data protection authority in their country. Erasure is subject to any record we are required by law to keep. Where the applicable law gives a data subject a further right, that right applies.

Where the request concerns data held in a customer's system, the customer is the controller and answers the request. We pass the request to the customer within two business days and assist them within five business days of being asked.

Where the request concerns data we control, we acknowledge within five business days and respond within 30 days, or sooner where the applicable law requires it. We do not charge for a first request, and we verify identity before disclosing anything.

9. Sensitive data, health records and children

Some of our systems are built for sectors that handle sensitive information: patient records and clinical data in our healthcare and pharmacy platforms, student records in our school platform, payroll data in our human resources platform, and staff location history in our field operations platform.

Data in a sensitive category, such as health and medical records, financial information, and the data of children, is processed only where the applicable law permits it and the customer has confirmed the basis in writing.

Where a system holds sensitive data or the data of children, the following apply in addition to the rest of this policy:

• access is restricted to the smallest possible group of named users, set by the customer;
• access by our own staff is permitted only to resolve a specific, recorded support request, and each access is logged and retained;
• records are not copied out of the production environment, and are never used as test data;
• the customer configures role-based restrictions so that a user sees only the records their role requires.

Personal data relating to children is processed only where the applicable law permits it, which in most frameworks requires the consent of a parent or guardian. In school systems the school is the controller and is responsible for that consent and for the notices given to parents.

Where a customer is a health facility, a pharmacy or a school, we will sign any additional undertaking its regulator requires, where it is consistent with this policy.

10. Data security measures

We maintain technical and organisational measures appropriate to the risk, in line with generally accepted information security practice. These are our own standards and we hold to them wherever we operate.

We identify the reasonable risks to the data we hold, put precautions in place against them, verify regularly that the precautions work, and keep them up to date. Risks are reviewed at least annually and after any significant incident or change.

11. Access control and our access to your data

Access to systems and data is granted on the principle of least privilege. Every user has a uniquely identified account; shared or generic accounts are not used for production systems or customer data. Multi-factor authentication is required for administrative access.

Access is approved and recorded, reviewed every quarter, and removed within one business day of a person leaving or changing role.

Our staff access customer data only where it is needed to deliver or support the service, or where the customer asks us to. Such access is logged and recorded against the support request. Where a customer's contract requires prior consent, we obtain it in writing first.

12. Backup, recovery and continuity

Customer data is backed up at least daily. Backups are encrypted, stored separately from the system they protect, and kept for at least 30 days.

Our recovery objectives are no more than 24 hours of data lost in a recovery, and service restored within one business day of a major failure. A restore is tested at least once every quarter and the result recorded. A customer may witness a test on request.

Where a product offers it, a customer may also enable an automatic copy of its backups to a storage account the customer itself owns and controls.

We maintain arrangements to continue or restore service after a disruption, covering loss of a system, loss of premises, loss of a key person and failure of a supplier. These are reviewed annually.

13. Sub-processors

To run our systems we use a small number of service providers. Where any of them handles personal data on behalf of our customers, they act as our sub-processors. Each is assessed before use, is bound by written terms no less protective than our own obligations, and remains our responsibility to our customers.

Some features connect to services that the customer chooses and holds its own account with, for example AI providers, SMS and messaging gateways, payment providers and customer-owned backup storage. Those providers are engaged directly by the customer and are not our sub-processors.

We give customers at least 30 days' written notice before adding or replacing a sub-processor that handles their personal data. A customer may object on reasonable data protection grounds within that period, and we then have 10 business days to agree a solution. If none is agreed, the customer may end the affected services and receive a refund of prepaid fees for the unused period. To receive these notices by email, write to [email protected].

Provider names, the country in which each provider processes data, contract dates and the specific safeguards in place are held in our internal register, confirmed for each engagement in its Data Protection and Security Assurance Statement, and shared with customers and their advisers on request, under a non-disclosure agreement.

14. Where data is processed, and cross-border transfers

Personal data is processed or stored outside the host country only where the applicable law permits it, which in most frameworks requires either that the destination provides protection at least equivalent to that of the host country, or the consent of the data subject.

Where a transfer relies on contractual safeguards, we put standard contractual clauses in place with the recipient, require encryption in transmission, and reserve the right to audit the recipient.

Where a client's own framework requires data to be held within its country, or imposes any other location requirement, the client raises this with us at onboarding and we confirm in writing whether we can meet it before processing begins. We do not assume that a requirement does not exist because it has not been mentioned.

We keep records of the basis and the safeguards for any cross-border processing and make them available to the customer and to the relevant authority on request. We do not permit onward transfer to a further country except as the applicable law allows.

15. Artificial intelligence and your data

Several of our systems include features that use artificial intelligence. Our position is:

• We do not train models on your data. We do not use customer data, or output generated from it, to train, fine-tune or improve any artificial intelligence model, whether ours or anyone else's.
• We bind our suppliers to the same rule. Any AI provider whose service is used in delivering our systems is bound by the same restriction in writing.
• You own the output. Content generated for you by an AI feature belongs to you, on the same terms as the rest of your data.
• Your data is not shared between customers. One customer's data is never used to produce results for another.
• AI features are optional and the system works without them.
• You keep control of the provider. Where a system connects to an external AI provider, it runs on your own provider account unless your contract says otherwise.

AI features produce suggestions that a person reviews and accepts. No system of ours takes an automated decision with legal or similarly significant effect on an individual. AI output is generated automatically and can be wrong; it should be checked before it is relied on.

Our staff are prohibited from entering customer data or personal data into public or personal AI tools. Where we use AI tools internally, we use approved tools configured so that inputs are not retained and are not used for training.

Where the host country introduces specific requirements for artificial intelligence, those are identified at onboarding in the same way as the rest of the applicable framework.

16. Data retention

We keep personal data only as long as it is needed for the purpose, or as the applicable law requires. Where the law of the host country sets a longer minimum, that period applies instead.

Paper records are shredded. Storage media are securely erased or physically destroyed before disposal, and the disposal is recorded.

17. Your data, and getting it back

The customer owns its data. We claim no rights in it beyond what is needed to deliver the service.

A customer may export a complete copy of its data, in a commonly used machine-readable format, at any time during the subscription and for 30 days after it ends, at no additional charge. We do not withhold customer data, and an export is provided even where there is a commercial dispute, subject to the customer's contract.

After that 30-day period the data is deleted or de-identified so that it cannot be reconstructed, except where we are required to keep it. Backup copies expire in the normal backup cycle. Deletion is confirmed in writing on request.

18. Data breach management

If we reasonably believe that personal data has been accessed or acquired by an unauthorised person:

• We notify the supervisory authority without delay. Where the applicable law sets a deadline, we meet it. Where it sets no deadline, or sets one longer than our own standard, we notify immediately on forming that belief rather than waiting.
• We notify the affected customer within 48 hours at the latest, and sooner wherever we can.
• We tell the customer what happened, the categories and approximate number of data subjects and records affected, the likely consequences, the measures taken, and a contact point, and we update them at least every two business days until the incident is closed.
• Data subjects are notified where the authority directs or the applicable law requires, and we support the customer, as controller, in making that notification.
• Every incident is recorded, its root cause established within 10 business days, and corrective actions assigned and tracked.

19. Privacy by design and by default

New systems and significant changes are assessed for their effect on personal data before they are built, not after. Defaults are set to the most protective setting that still delivers the feature. We collect the minimum data needed and make it straightforward for a customer to restrict access further.

20. Data protection impact assessments

Where a new system or a significant change is likely to result in a high risk to individuals, in particular where it involves sensitive data, children's data or systematic monitoring such as location tracking, we carry out an impact assessment before proceeding, record the outcome, and consult the relevant authority where the applicable law requires it.

21. Roles, responsibilities and training

The Data Protection Officer oversees compliance with this policy, handles data subject and customer enquiries, maintains the records this policy requires, and is our contact point for data protection authorities.

The Technical Lead owns the security controls, approves access to production systems, and leads the response to security incidents.

The directors approve this policy, provide the resources to operate it, and receive reports on incidents and on the annual review.

Before being given access, every employee and contractor signs a confidentiality undertaking that survives the end of the engagement. Everyone completes data protection and security awareness training at induction and at least annually, and attendance is recorded. Breach of this policy is a disciplinary matter.

Anyone who suspects a problem must report it immediately. Reporting a suspected problem in good faith never attracts blame.

22. Monitoring, audits and customer assurance

The Data Protection Officer monitors compliance and reports to the directors at least annually.

We maintain the records this policy requires, including the access register, access reviews, training records, restore tests, supplier assessments, incident records and deletion records.

A customer may request a written description of our security measures once in any 12-month period, and after any security incident affecting its data. We respond within 20 business days. Where a customer's contract provides for it, an independent auditor bound by confidentiality may review our compliance, at the customer's cost, during business hours, without access to other customers' data.

We co-operate with any lawful request or investigation by a data protection authority or other regulator with jurisdiction over the processing.

The Data Protection and Security Assurance Statement

This page states the standards that apply to every customer. It does not state the particulars of any one project, because those differ from client to client and some of them are confidential.

Where a customer needs the particulars, whether for its own board, its regulator, its auditor or its procurement process, we issue a Data Protection and Security Assurance Statement for that engagement. It is signed by Gestlat ThinkLab and addressed to that customer, and it sets out, for that project:

• the products and modules in use, and the categories of personal data each one holds;
• which party is controller and which is processor, for each category;
• the data protection law identified as applying to the engagement, and the sector rules accommodated alongside it;
• the countries in which data is processed and backed up, the providers involved, and the basis and safeguards for any cross-border transfer;
• the named individuals on both sides who hold data protection responsibility, and their contact details;
• the security measures, access arrangements, retention periods and deletion commitments agreed for that project;
• breach notification contacts and timings;
• any additional undertakings agreed with that customer.

To request one, write to [email protected]. We issue it within 10 business days. Where it contains information we treat as confidential, including provider names and processing locations, it is issued under a non-disclosure agreement.

A signed Assurance Statement does not replace the Data Processing Agreement, which is the contractual instrument. It is the document that shows what has been agreed and put in place.

23. Policy review and updates

This policy is reviewed at least annually, whenever our operations change materially, and whenever the law of a country in which we deliver an engagement changes materially. Where a change materially affects our customers, we tell them.

24. Contact

Data Protection Officer, Gestlat ThinkLab Limited
[email protected] · +256 706 107 619
P.O. Box 120356, Wakiso, Uganda
Business Registration Number 80034932485765

To report a suspected security vulnerability, see the reporting section of our Acceptable Use Policy.

A data subject may also complain to the data protection authority in their own country.

25. Related policies and documents

Privacy Policy · Terms of Service · Acceptable Use Policy · Service Level Agreement · End User Licence Agreement · Cookie Policy · Refund Policy · Anti-Spam Policy.

Available on request: a signed Data Protection and Security Assurance Statement for your engagement, our Data Processing Agreement, our internal procedures supporting this policy, our registration details, and our sub-processor register with provider names, under a non-disclosure agreement.

Last Updated: December 17, 2025
Effective Date: December 17, 2025
Version: 1.0