Data processing agreement

1. Who this is between

1.1. This agreement is between the Customer (the madressah, school or organisation using Madrasaty) and Madrasaty Limited (registered in England and Wales, company number 17504107), of Suite A, 82 James Carter Road, Mildenhall, IP28 7DE ("Madrasaty", "we").

1.2. It forms part of our terms and lasts as long as we process Customer Personal Data. Words defined in the terms have the same meaning here. "Data Protection Law" means the UK GDPR, the Data Protection Act 2018 and the Privacy and Electronic Communications Regulations 2003, as amended. "Controller", "processor", "personal data", "personal data breach" and "data subject" have the meanings given in the UK GDPR. "Customer Personal Data" means personal data in Customer Data.

2. Roles

2.1. The Customer is the controller of Customer Personal Data, and Madrasaty is its processor. Annex 1 describes the processing.

2.2. The Customer is responsible for having a lawful basis for the processing, including a condition under Article 9 of the UK GDPR for any special category data (such as information revealing religious belief, or about health), and for giving data subjects the information Data Protection Law requires.

3. Instructions

3.1. We process Customer Personal Data only on the Customer's documented instructions, including about transfers outside the UK. The terms, this agreement, and the Customer's use and configuration of Madrasaty are its instructions. The Customer may give further reasonable instructions in writing.

3.2. If the law requires us to process Customer Personal Data otherwise, we'll tell the Customer before doing so, unless the law prohibits that.

3.3. We'll tell the Customer straight away if we believe an instruction breaks Data Protection Law.

3.4. We don't process Customer Personal Data for our own purposes. We don't sell it, use it for advertising, or use it to train artificial intelligence models.

4. Our people

4.1. Only people who need access to provide, secure or support Madrasaty can access Customer Personal Data, and each of them is bound by a duty of confidentiality.

4.2. We access a Customer's records to give support only when the Customer asks us to, or where it is necessary to keep Madrasaty secure and working.

5. Security

5.1. We take appropriate technical and organisational measures to protect Customer Personal Data, as required by Article 32 of the UK GDPR, taking into account that it concerns children and may include special category data. Annex 2 describes them. We may change them, but never so as to lower the overall level of protection.

6. Sub-processors

6.1. The Customer authorises us to use the sub-processors listed on our sub-processors page.

6.2. We'll tell the Customer at least 30 days before adding or replacing a sub-processor. If the Customer objects on reasonable data protection grounds, we'll discuss it in good faith. If we can't resolve it, the Customer may end the terms and leave without charge before the change takes effect.

6.3. We impose data protection obligations on each sub-processor that are at least as protective as this agreement, and we remain responsible to the Customer for their performance.

7. Transfers outside the UK

7.1. Customer Personal Data is stored in the UK. We'll transfer it outside the UK only where Data Protection Law allows: to a country the UK has found adequate, or under the International Data Transfer Agreement or the UK Addendum to the EU Standard Contractual Clauses, or under another safeguard Data Protection Law recognises.

8. Helping you

8.1. Taking into account the nature of the processing, we'll help the Customer respond to requests from data subjects exercising their rights. Most requests can be answered directly in Madrasaty: administrators can view, correct, export and anonymise records. If we receive a request directly, we'll pass it to the Customer without undue delay and won't respond to it ourselves except on the Customer's instructions.

8.2. We'll give the Customer reasonable help with its security obligations, data protection impact assessments and any consultation with the Information Commissioner's Office, using the information available to us. A summary of our own data protection impact assessment is available on request.

9. Breaches

9.1. We'll notify the Customer without undue delay, and in any case within 48 hours, after becoming aware of a personal data breach affecting Customer Personal Data. We'll send the notice to the Customer's administrators by email.

9.2. The notice will describe, as far as we know at the time, what happened, the categories and approximate number of data subjects and records concerned, the likely consequences, and what we have done or propose to do. We'll follow up with more information as we learn it.

9.3. We'll take reasonable steps to contain the breach and reduce its effects, and help the Customer meet its own obligations to notify the ICO and data subjects. Notifying a breach isn't an admission of fault.

10. Deletion and return

10.1. When the terms end, the Customer may ask for a copy of Customer Personal Data in a common, machine-readable format, at any time during the following 30 days.

10.2. We'll delete Customer Personal Data within 60 days after the terms end, unless the law requires us to keep it. Copies in backups expire within a further 7 days. We'll confirm deletion in writing if asked.

11. Information and audits

11.1. We'll make available the information reasonably needed to show that we meet this agreement and Article 28 of the UK GDPR, including answers to reasonable security questionnaires.

11.2. If that information isn't enough, the Customer, or an auditor it appoints who is bound by confidentiality, may audit our compliance once a year, on at least 30 days' notice, during normal business hours and in a way that doesn't compromise other Customers' records or our security. More frequent audits are allowed after a personal data breach, or where a regulator requires one.

12. General

12.1. If this agreement and the terms conflict, this agreement prevails for anything about personal data. Liability under this agreement is subject to the limits in the terms, except where Data Protection Law doesn't allow it to be limited.

12.2. We may update this agreement to reflect changes in law or in Madrasaty, under the same notice as changes to the terms. No update will reduce the protection given to Customer Personal Data.

12.3. This agreement is governed by the law of England and Wales.

Annex 1

The processing

Subject matter	Providing Madrasaty, a management system for madressahs, to the Customer.
Duration	For as long as the terms are in force, and then until deletion under section 10.
Nature and purpose	Hosting, storing, organising, displaying and transmitting records so that the Customer can manage pupils, guardians, staff and classes; take registers; record progress; receive absence reports; send notices; and record staff hours. Also backing up, securing, monitoring and supporting the service.
Data subjects	Pupils; their parents and guardians; the Customer's staff and volunteers; staff members' next of kin.
Personal data	Pupils: name, date of birth, classes, attendance, progress, absence reports, and the guardians linked to them. Guardians: title, name, contact details, postal address, preferred language and contact method, relationship to each child, collection and emergency-contact permissions, and notices received. Staff: title, name, date of birth, contact details, postal address, next of kin, position, employment terms, employee number, hourly rate, hours worked, and classes taught. Account holders: email address, hashed password, roles, sign-in sessions and service logs.
Special category data	Information revealing religious belief, inferred from enrolment at a madressah. Health information, where a guardian gives it as the reason for an absence. Access to guardians' absence notes is limited to the child's class teacher and the Customer's administrators.
Location	Microsoft Azure, UK South region (London), including backups.

Annex 2

Security measures

Hosting and encryption

• Hosted on Microsoft Azure in the UK South region, which is certified to ISO 27001 among other standards.
• All connections are HTTPS only, with TLS 1.2 or later.
• The database is encrypted at rest. Its backups stay in the same region and are kept for 7 days for point-in-time recovery.
• Notice attachments are kept in private storage in the same region, encrypted at rest. They have no public address: a file is served only to someone the notice itself may be shown to.

Separation between madressahs

• Each madressah's records are separated in the database by a filter applied to every query. The madressah is fixed in each user's signed sign-in token, so a request can't choose another.
• Automated tests check that one madressah's records can't be reached from another's accounts.

Access within a madressah

• Access depends on role. Administrators see the whole madressah. Teachers see their own classes and pupils. Parents and guardians see only their own children, through a separate service that refuses staff accounts.
• Staff members' home addresses, dates of birth and pay are shown only to administrators.

Sign-in

• Passwords are stored only as salted, slow hashes. Nobody, including us, can read them.
• A new account opens nothing until its user replaces the temporary password they were given.
• Sign-in tokens are short-lived. Session tokens rotate on every use, and reusing an old one ends that session. Changing a password signs out every other session.
• Sign-in attempts are rate-limited per address, accounts lock after repeated failures, and every request is rate-limited per user.
• An administrator can revoke a login at once. Deactivating a staff member also ends their access.

Records and their history

• Changes to pupils, staff, the links between pupils and guardians, and registers and progress are kept as an audit history.
• Anonymising a pupil, guardian or staff member clears their personal details. For a pupil that includes the notes on their register marks and progress records, and every earlier version of those records kept in the audit history.

Operations

• Production access is limited to named people, using accounts protected by multi-factor authentication.
• The database accepts only Microsoft Entra ID sign-in, so there are no database passwords to leak. Deployments use short-lived federated credentials, and secrets are kept in platform configuration, never in source code.
• Every change passes automated tests before it is deployed. Database changes are applied as reviewed migrations.
• Service logs are kept for 90 days with IP addresses masked, and failures raise alerts.
• A written breach procedure sets out how incidents are contained, assessed and reported.