Privacy policy

Last updated: 12 August 2026

1. Who we are

Makatib.App is operated by Project Paced Ltd, a company registered in England & Wales (Company Number 16969966). Registered office: International House, 64 Nile Street, London, N1 7SR, United Kingdom. Project Paced Ltd is registered with the Information Commissioner’s Office under reference ZC169939, with Makatib.App recorded as a trading name.

This policy explains how personal data is handled on the Makatib.App website and in the Makatib.App service, in line with the UK General Data Protection Regulation (UK GDPR) and the Data Protection Act 2018. For privacy questions or to exercise your rights, contact privacy@makatib.app.

2. The two roles we play

Makatib.App is used by madrassas to manage their own classes, which means we handle data in two capacities:

• As a processor. Student and family records (names, dates of birth, attendance, Quran progress, guardian contact details) are entered and managed by your madrassa. This includes applications a family submits to a madrassa through its own application link or QR code: the madrassa decides whether to run an application form, what it asks for and who may see the answers, and is the controller for those submissions from the moment they arrive. The madrassa decides what is recorded and who may see it, and is the data controller for those records. Project Paced Ltd processes them only to provide the service, on the madrassa's instructions.
• As a controller. For account data (staff, adult learner and guardian logins), beta interest submissions, customer-contract and billing contacts, website enquiries, consent choices, service-security records and technical logs, Project Paced Ltd is the data controller. Stripe is an independent controller for payment data it needs to provide regulated payment services, prevent fraud and meet its legal obligations.

3. Information we collect

Provided by you or your madrassa

• Account details: name, email address and access capacity (management, teacher, adult learner, parent or guardian) for people who sign in. Legal basis: performance of a contract.
• Student and family records, entered by madrassa staff: student names, dates of birth, class membership, attendance, tasks, Quran progress logs, the child's home address, and guardian contact details. Processed on the madrassa's instructions (see section 2). A home address is recorded so a madrassa knows where a child lives; it is visible to that madrassa's management, is not shown to parents or teachers in the service, and is not used to rank, sort or measure distance for admissions.
• Messages: content of messages and announcements between staff, adult learners and authorised guardians through the service.
• Application forms, where a madrassa invites families to apply for a place: the child's name, date of birth, gender, home address, previous Qur'an learning, and an emergency contact. An adult applicant supplies their own email and phone; an application for a minor instead includes the name, relationship and contact details of each parent or guardian listed. A madrassa may additionally choose to ask for health information about the child, including allergies, medical conditions, medication and any additional needs. Those health questions are off by default and appear only if the madrassa turns them on. Applying does not create an account, and an application is not a place at the madrassa. Processed on the madrassa's instructions; the madrassa is the controller and decides what it asks for, how long it keeps unsuccessful applications and what it tells families.
• Fee and payment records, where your madrassa collects fees through the service: what was invoiced, when it was due, what has been paid and by which method, plus any note or reference the madrassa records. Processed on the madrassa’s instructions. Where a madrassa marks a family as exempt or on a reduced rate, any reason it records is visible only to that madrassa’s management. The madrassa determines the lawful basis for these records; we process them under its instructions and our Data Processing Agreement.
• Card and bank details are never sent to us. When you pay through the portal, your card number or bank details go directly to Stripe, who process the payment for your madrassa. We receive only the outcome: an amount, a date, a payment method type, and the last few digits where Stripe provides them.
• Beta interest form: madrassa name, contact name, email, optional phone number, location, approximate student count, role and any message you include. Legal basis: our legitimate interest in responding to your enquiry, and steps taken at your request prior to entering a contract. If you separately choose to receive product updates, we also record that choice and the version of the consent wording. Legal basis for those updates: consent, which you can withdraw through the unsubscribe link in every update.

Collected automatically

• Cookies and analytics: essential storage keeps you signed in and remembers your cookie choice. If you consent, Google Analytics collects usage information such as pages visited, approximate location, device and browser information, and referral source. Legal basis: consent. We do not send student records or message content to Google Analytics, and we do not use advertising cookies. See the cookie policy.
• Technical logs: IP address, browser type and request logs generated by our hosting providers, retained briefly for security and reliability. Legal basis: legitimate interest in keeping the service secure.
• Abuse protection on forms: forms that can be reached without an account, including signing in, signing up, password reset, the beta enquiry form and a madrassa's application form, count submissions per IP address for a short rolling window so a form cannot be flooded. Most of those forms, and the change-password form inside the app, also carry Cloudflare Turnstile, which checks that a submission is not automated: Cloudflare receives a challenge token and the visitor's IP address, and no form content. Legal basis: legitimate interest in protecting the service and our customers from automated abuse.

Where the information comes from

Account and enquiry data comes from the person concerned or their organisation. Customer Data comes from the madrassa, its authorised staff, adult learners and guardians using the portal and service-generated activity such as attendance, message, invoice and payment events. Payment outcomes come from Stripe. Security and device information comes from the browser and our infrastructure providers.

Our controller purposes and lawful bases

4. Children's data

Students at madrassas are usually children, so we treat their records with particular care:

• Learners under 18 do not create accounts or sign in. Their records are created and managed by madrassa staff and viewed by their guardians. Adult learners may use their own account. A guardian linked before the eighteenth birthday keeps full access by default, while a guardian linked later starts with no access. The adult learner can restrict, remove or restore each guardian's access at any time.
• Where a madrassa runs an application form, a minor's details are submitted by their parent or guardian, while an adult applies in their own capacity. An application is visible only to that madrassa's management, never to its teachers or other families, until the madrassa accepts it and the child becomes a student.
• Every record is scoped to a single madrassa and protected by row-level security in the database. Guardians can only ever see children linked to their own account.
• The madrassa, as controller, is responsible for selecting and documenting the applicable Article 6 lawful basis and, where relevant, an Article 9 condition; giving appropriate notices; keeping records accurate; and meeting the enhanced transparency and fairness duties owed to children and adult learners.
• We never sell personal data, and we do not use student data for advertising or AI training.

Religious-belief and other special-category data

Attendance at a madrassa, Quran progress and message content may reveal or strongly imply religious beliefs. Religious belief is special-category data. The relevant controller must identify both an Article 6 lawful basis and a separate Article 9 condition before processing it, record that decision and complete any required appropriate policy document. Project Paced does not choose the madrassa's bases; as processor, we handle this data only under the madrassa's documented instructions. If Project Paced ever determines a separate controller purpose involving special-category data, we will document and publish our own Article 6 and Article 9 grounds before starting it.

Health data

A madrassa may choose to ask about a child's health on its application form, and to record the same on a student's file. The purpose is narrow and worth stating exactly: so that the adults caring for a child know about a condition or allergy that could affect them, and are prepared for it while the child is in their care. It is not a medical record, it is not used to decide whether a child is offered a place, and it is not used for any other purpose. A madrassa should ask only for what meets that need, and families should leave anything blank that does not apply.

Health data is nonetheless special-category data under Article 9, and it is a separate category from religious belief: a condition that covers one does not automatically cover the other.

These questions are switched off by default. A madrassa that turns them on is instructing us to process health data and is responsible for identifying its own Article 6 basis and Article 9 condition, giving families a clear notice, and deciding how long it keeps the information. The consent tick-box we provide on the application form, and the record we keep of when it was ticked and against which version of the wording, are tools to help a madrassa evidence its own decision; they are not our determination of its lawful basis, and ticking a box is not by itself a valid Article 9 condition in every case.

Within a madrassa, health information a family provides is visible to its management and, once a child is enrolled, to the teachers who teach that child. This is the reason for collecting it, since the person who needs to know about an allergy is the one in the room. It is kept collapsed rather than displayed by default, is never shown to other families, and is never included in any report or spreadsheet export.

5. Sharing and sub-processors

We do not share personal data with third parties except the infrastructure providers needed to run and understand the service (hosting, database, email delivery, payment processing and consented analytics). These are listed, with the purpose of each and the applicable transfer mechanism, on the sub-processors page. We may also disclose information where required by law.

Payments are a special case worth stating plainly. Where a madrassa collects fees through the service, that madrassa holds its own account with our payment provider and is the merchant. Project Paced Ltd never receives, holds or moves the money, and takes no share of it. The payment provider is an independent controller of the payment data it handles, and its own privacy notice applies to that. See the payment terms.

6. International transfers

Current processing locations and transfer mechanisms are listed on the sub-processors page and checked against the applicable vendor contract. A restricted transfer is made only where UK adequacy regulations apply or an appropriate safeguard is in place, such as the UK International Data Transfer Agreement or UK Addendum to EU Standard Contractual Clauses. Where those contractual safeguards are used, we complete and keep the required transfer risk assessment and supplementary-measures decision. A generic reference to contractual clauses is not treated as sufficient on its own.

7. Retention and deletion

• Madrassa data is retained while its account is active and according to the controller's documented instructions. On leaving, the madrassa can request an export and choose return or deletion under the Data Processing Agreement and offboarding procedure. Production copies are scheduled for deletion within 30 days after that window; encrypted backups expire on their documented rotation unless a valid legal hold applies.
• Inactive unpaid accounts. Where an authorised madrassa manager has accepted the current Terms and Data Processing Agreement, an unpaid onboarding, beta or trial account may be suspended after 90 days without a sign-in or product activity. We warn management 30 days and one day before suspension. Suspension begins a further 30-day recovery and export window, with a final one-day warning before deletion. Paid, active, paused, internal and legally held accounts are not deleted under this inactivity rule.
• Fee and payment records require a controller decision. A madrassa may have tax, accounting, safeguarding, dispute or charity-law retention duties, but those are not automatically Project Paced's own controller obligations. Before offboarding, the madrassa must instruct us which fee records to return, delete or retain, the legal reason and end date. Any retained processor copy is isolated from ordinary service use and deleted when the instruction or valid legal hold ends. Records we hold for our own legal obligations are separately documented and limited to that controller purpose.
• Applications are kept by the madrassa while they are under consideration. Once accepted, the child's details move onto their student record and are retained as part of it. Once accepted, rejected or withdrawn, the duplicate application record is normally marked for deletion 90 days after the decision. An undecided application is normally marked for deletion 180 days after the family's latest submission, with a 30-day warning to management. These defaults apply only after the madrassa records its controller instruction; it may set a different period or document a legal hold.
• Beta interest submissions are kept while the beta programme runs and deleted, at the latest, 12 months after the programme closes if no account is created.
• Product-update contact and consent records are kept until you unsubscribe or ask us to delete them. Resend retains suppression records where needed to ensure we do not email an address that has opted out or produced a permanent delivery failure.
• Technical logs are retained for short, rolling periods by our hosting providers.
• Google Analytics retention is governed by our Analytics settings and Google's applicable retention controls. Your local analytics cookies last for up to 2 years unless you withdraw consent or delete them sooner.

8. Security

Data is encrypted in transit (TLS) and at rest by our database provider. Access is restricted by role-based permissions and database-level row security, so staff see only their own madrassa, adult learners see their own record, and guardians see only records for which they currently have age-appropriate or consented access.

Our Data Processing Agreement describes the processor obligations, assistance, breach notification, sub-processors, deletion and audit framework that applies to Customer Data.

9. Your rights

Under UK GDPR you have the right to:

• access the personal data we hold about you;
• have inaccurate data corrected, or data deleted where there is no reason to keep it;
• restrict or object to processing, and receive a portable copy of data you provided;
• withdraw consent at any time, where processing is based on consent.

Contact privacy@makatib.app and we will respond within one month. If your request concerns student records controlled by a madrassa, we will coordinate with the madrassa, which may need to action it as controller. You can also complain to the Information Commissioner's Office at ico.org.uk.

10. Changes to this policy

We will update this policy as the product develops, including before full launch, when the final version will be published. Material changes will be notified to madrassa administrators by email or in the app. Questions: info@makatib.app.