Data Processing Agreement

1. Who decides, and who acts

Your madrasa decides what is recorded about its students, teachers and guardians, why, and for how long. Those are your decisions and they stay yours. In the language this field uses, your madrasa is the controller of those records and we are the processor: we hold them and act on them for you, and for no purpose of our own.

A small second set of records is ours rather than yours: the account we opened for your madrasa, what we invoiced and whether it was paid, what you send us by email, and website measurement. We answer for those ourselves, and the privacy policy is where we account for them. This agreement is about your records, not those.

We use the words controller and processor because they carry a settled meaning, not because a Pakistani statute imposes them. Pakistan has no enacted general data protection law, so the obligations below are ones we have taken on by contract with you. That makes them enforceable against us in the courts of Karachi under the terms and conditions — which, for a madrasa, is a good deal more useful than a citation to a regulation nobody here administers.

2. Exactly what is covered

A processing agreement is worth little if it does not say what it is about. This is the scope, and if your madrasa puts something into Sijil that is not described here, tell us — it means either the description needs widening or the record should not be there.

Subject matter

Running your madrasa’s register: enrolment, attendance, fees, lesson progress, the timetable, and the parent and teacher access that goes with them.

How long

From the day your account opens until your madrasa asks for its records to be removed. Closing the account does not by itself delete them, and nothing expires on a timer; the end of this document describes exactly how the removal happens.

What we do with it

Store it, show it back to the people your madrasa has authorised, calculate from it — attendance totals, fee balances, progress — back it up nightly, and delete it when you say so.

Whose data

Your students, most of whom are children. Their guardians. Your teachers and administrators. Anyone who sends an enquiry through your madrasa’s public page.

What kinds of information

Names in both scripts, dates of birth, guardian names and phone numbers, addresses where entered, enrolment and class, attendance, fee amounts and payments, lesson progress, photographs where uploaded, teachers’ contact details and identity-card numbers, and the sign-in and device records that come with letting people in.

3. Your instructions, and our limits

Everything we do with your records has to trace back to an instruction from your madrasa, and almost every one of those instructions is given by using the product. When your administrator enrols a student, when a teacher marks a register, when a guardian opens a fee balance — those are instructions, and acting on them is all we do.

Anything outside that — a bulk export, a correction the screens cannot make, a request to hand records to somebody else — has to reach contact@sijil.pk in writing from an administrator of your madrasa. Once we act on such a request it becomes part of your instructions, and we keep the message as our record of why we did it.

The other half of an instruction clause is the list of things we will not do even if it would be easy, and even if nobody in Pakistan would notice:

• We do not use your records for any purpose of our own — not to build features, not to train anything, not to advertise, not to compile figures about madaris that we then quote at other madaris.
• We do not sell them, rent them, or pass them to a data broker. There is no arrangement of that kind and no plan to make one.
• We do not send them to any artificial-intelligence service. No such service is part of Sijil and none is installed in it, so this is not a promise of restraint — there is nothing there to restrain.
• We do not move a record from one madrasa to another, even when the same child later enrols somewhere else that also uses Sijil. A transfer means your madrasa exporting and the other madrasa entering.
• We do not read a child’s record, a fee ledger or an attendance sheet out of curiosity. We open them when a named person at your madrasa asks us to look at something specific, and for as long as that takes.

If an instruction looks unlawful to us, we will say so and give our reason, and we may decline it rather than quietly comply. Pakistan has no data protection authority we could ask for a view, so that judgement is ours alone and it may be wrong — but you will know we made it, which is better than finding out later that we did something because we were told to.

4. That most of them are children

Most of the people described in your records are children. That is not an extra paragraph at the end of a data agreement; it is the reason the rest of it is written the way it is. A child cannot give a meaningful permission to a piece of software, will never read this document, and did not choose to be entered into it. Every limit above exists mainly for them.

No student holds an account. There is no student sign-in, no student password and no student device — a child’s record is seen by the staff your madrasa authorises, by the guardian your madrasa invites, and by us only in the narrow circumstances described in this document. A guardian’s screen is deliberately small: their own children, and nothing about anybody else’s.

We do not profile children, score them, rank them against children at other madaris, or use anything about them to aim a message at anybody. Attendance is counted and progress is recorded because your madrasa asked for those counts and reads them itself. Dates of birth sit in the record because your madrasa entered them; we do not check a child’s age and have no reason to.

Pakistan has no children’s data statute to point at here, so there is nothing to cite and nothing to hide behind. The two items in your records that would do the most harm if they escaped are a child’s photograph and a guardian’s phone number. The photograph is the subject of the next section, and it is the one part of this document not to skim.

5. Photographs

A student photograph is optional — nothing in Sijil requires one, and a madrasa that never uploads a picture loses no feature. If your madrasa does upload them, they are not kept in the same place as the rest of the register. They are stored with Cloudinary, a service outside Pakistan, and delivered from there to whichever screen shows the child.

Because of that, your madrasa promises us two things before any picture of a child is uploaded: that the guardian has agreed to it, and that your madrasa can show how that agreement was obtained if it is ever questioned. If a guardian later says they never agreed, answering that is your madrasa’s responsibility, and your madrasa will cover our costs if we are drawn into it. We ask for this not to move blame but because we cannot check it: we have no way of knowing what a father in Karachi was asked.

Deletion of a photograph is the one deletion in Sijil that is not left to a person. When a photograph is replaced, the old file is removed from Cloudinary straight away. When a student is removed from the register, the photograph goes too: the record stops pointing at the file and the file is destroyed at Cloudinary in the same breath. It is the only thing that removal takes away — the child’s attendance, fees and progress stay, because a register that forgets its own history is no use to the madrasa that has to answer for it. If what your madrasa wants is a wider clearance — every picture of one family, or every picture it ever uploaded — tell us at contact@sijil.pk and we will do it within 30 days, because that part is still done by hand.

6. Who else touches the data

Sijil has no staff and owns no machines. Everything the product does that we do not do with our own hands is done by a company we pay, and those companies hold your records in order to do it. A processor that hides this list is worth less than one that prints it, so here it is in full — seven providers, and no others.

WhatsApp is not on that list, and the distinction matters. Where the product offers to message a guardian on WhatsApp, it opens WhatsApp on your own phone or computer with the text already written; you send it yourself from your own number. We do not connect to WhatsApp, we do not send anything through it, and no data reaches Meta from us. What happens to that message afterwards is between you, the guardian and WhatsApp.

Your madrasa’s acceptance of this document is your authorisation for those seven. If we add a provider or replace one, we will tell your madrasa’s administrators by email before any of your records reach it, at least 30 days ahead where the timing is ours to choose. Where a provider fails, is withdrawn, or has to be replaced in a hurry, we will tell you as soon as we can and say plainly why the notice was short. If your madrasa objects to a new provider, write to contact@sijil.pk: if we cannot settle it, your madrasa may end the agreement and take its records out, and we will not charge for the part of the term you no longer use.

Each of those companies is bound by its own agreement with us, which permits it to use the data only to provide its service. From your madrasa’s side, though, none of them is your problem: we chose them, and if one of them mishandles your records that is our failure to answer for, on the same terms and subject to the same limit as anything else we get wrong under the terms and conditions.

7. Where the data physically is

All of those providers operate outside Pakistan, so your madrasa records are stored and processed abroad. Pakistani law does not currently restrict this or require a particular transfer mechanism, and we are not going to quote European clauses at you that do not govern your data. What protects it is the contract we have with each provider, the fact that each one processes the data only to provide its service to us, and the security measures set out below.

8. What actually protects it

The security clause is the part of a data agreement most likely to have been written by somebody who never read the code. Every item below is either something your madrasa can confirm by using the product or something we can show you the working of if you ask.

• Everything travels over an encrypted connection (HTTPS/TLS). There is no unencrypted route into the product.
• Staff passwords and the PINs used by teachers and guardians are stored as bcrypt hashes, which cannot be turned back into the original.
• One exception, by design: a teacher’s or guardian’s PIN is additionally stored in a reversible encrypted form so that an administrator can read it back to someone who has forgotten it. Only that madrasa’s own administrator can trigger it.
• The database enforces separation between madaris at the row level, so one madrasa’s account cannot read another’s records even if the software asked it to.
• Each signed-in session is tied to the device that created it. A stolen session cookie replayed from a different device is refused.
• Administrator accounts sign in with Google only. We never hold an administrator’s password.
• Public forms are rate-limited and checked with Google reCAPTCHA, which is why a form can occasionally refuse a legitimate submission.
• A repeated wrong PIN locks the account for a period rather than allowing unlimited attempts.

So that you can assess this properly rather than take a reassurance on trust: the nightly backup is compressed and encrypted with AES-256-GCM before it leaves our servers, and the file sitting in private object storage cannot be read without a key that is kept separately from the storage credentials. Two limits are worth stating plainly. The key is held as a single server-side secret rather than in dedicated key-management hardware, so our own infrastructure can decrypt a backup. And backups written before 28 August 2026 were plain text; they are removed by the seven-day rotation rather than re-encrypted, so none survive a week after that date. If your madrasa needs a stronger arrangement — a key only you hold, or no backups at all — tell us and we will agree how to handle it.

What is missing should count for as much as what is present. There is no security team, no SOC 2 report, no ISO certificate and no external penetration test — Sijil is one person’s work, reviewed by one person. Any product at this stage claiming otherwise to a madrasa is selling something. What we offer instead is a small system with few moving parts, seven providers rather than thirty, and a written account of the weakest link rather than a page of reassurance.

Half of the security of these records is not ours to hold. A class PIN written on the staff-room wall, an administrator’s Google account without two-step verification, a phone handed to a student with the register still open — we cannot defend against any of those from here. The terms and conditions place that duty on your madrasa. We repeat it in this document because it is, honestly, the likeliest way a child’s record in Sijil will ever be seen by the wrong person.

9. Which people can see it

On our side the answer is one person: Hassan. There is no support department, no contractor with a login and no offshore team. That is a weakness in some ways and a protection in others — the list of humans who can reach a madrasa’s register is one name long, and it is printed at the top of this document.

That access is used to keep the product working and to answer what your madrasa asks. We look at a particular record when your madrasa reports a problem with it or asks us to check something, and we look at as little as the question needs. We do not copy records onto other devices, keep private copies, or take an export away for our own reference. Anything we are told in the course of that work is confidential and stays so after the agreement ends.

Two consequences of being one person, said plainly. If that ever changes — an assistant, a contractor, a second developer — whoever gets access will be bound in writing to these same limits before they are given it, and this section will be updated to say so. And because there is only one of us, support answers stop when that one person is ill or unreachable, even though the product keeps running without anybody touching it. A madrasa whose whole register lives here should ask us for an export from time to time and keep it. We would give the same advice about any one-person supplier, including this one.

10. If something goes wrong

A breach, for the purposes of this agreement, is any incident in which your madrasa’s records were seen, altered, lost or taken by somebody who should not have had them — or may have been. It covers a mistake of ours as squarely as an attack from outside, and it covers a failure at one of the seven providers.

We will tell your madrasa’s administrators within 72 hours of becoming aware of one, by email and by phone if the email goes unanswered. We will not wait until we understand it fully — the first message will say what we know, what we do not yet know, which records appear to be involved, what we have already done, and when the next update will come. Pakistan has no authority to file such a report with, so this notice goes to you and to nobody else. If your madrasa chooses to report the matter onward — to its board, to a parents’ committee, to the police — we will put what we know in writing for you to use.

We will not write to your guardians ourselves. They are your madrasa’s families, they gave their details to your madrasa and not to us, and a message from an unfamiliar software company would alarm them more than it informed them. Deciding whether and how to tell them is your madrasa’s call as the controller. If you want us to draft that message, or to sit in the room while you explain what happened, we will.

It runs the other way too. If anybody at your madrasa suspects something — a screen showing another madrasa’s student, a PIN that stopped working, a parent seeing a child who is not theirs — write to security@sijil.pk and we will treat it as real until we can show it was not. We would far rather look into ten false alarms than hear about the real one from a guardian.

11. If somebody official asks us for your records

Pakistan’s operative law in this area is the Prevention of Electronic Crimes Act 2016, as amended in January 2025. It is criminal-procedure legislation, not data protection legislation: it gives investigators routes to demand data from a service like ours, and it gives your madrasa no regulator to complain to. That imbalance is a reason to write down how we will behave, since nothing else does.

So: we will not hand over a single record on a telephone call, a WhatsApp message or a visit, whatever office is named. We require the demand in writing, we check that it is addressed to us and appears lawful on its face, we give the narrowest set of records that answers it rather than a copy of your database, and we keep a record of what was asked and what was given.

We will tell your madrasa before anything leaves, so that you can take your own advice, unless we are lawfully forbidden from telling you — and in that case we will tell you as soon as the prohibition lifts. What we cannot honestly promise is to fight it for you: we are one person in Karachi, not a legal department, and an order that stands will be obeyed. What we can promise is that nothing goes out quietly.

12. When a parent or teacher asks about their data

Those requests are yours to answer, because your madrasa is the controller and the relationship is with you. Most of them need nothing from us: a guardian’s phone number, a child’s spelling, a wrong attendance mark and a mistaken fee entry can all be corrected by your own administrator in the product, and a person who wants to know what is held can be shown the record on screen.

Where the screens cannot do it — a full copy of everything held about one child, a deletion that has to reach the photograph and the backups, a correction the interface refuses — write to contact@sijil.pk and we will do it within 30 days, usually within a few. We give a number of days instead of promising it instantly because there is no export button and no delete button in Sijil: one person does this by hand, and we would rather name the real timetable than advertise a feature that does not exist.

If a guardian or a teacher comes to us directly, we will not answer them out of your records. We will tell them the request belongs with their madrasa, and we will tell your administrators the same day that somebody asked, so that a request does not disappear because it arrived at the wrong door.

If your madrasa has to satisfy a board, a donor or an affiliation body about how these records are handled, we will answer their questions in writing and you may quote this document in full. What we will not do is fill in a security questionnaire with certifications we do not hold, or hand you a formal impact assessment with our name on it as though it had been done by somebody independent.

13. Checking that any of this is true

An audit clause that offers more than a processor can deliver is worthless, so here is the version that is real. Your madrasa may ask in writing how any part of this document works in practice, and we will answer in writing within 30 days. We will take an administrator, or an adviser your madrasa appoints, through the relevant screens on a call, and where the answer is in the code we will show the code.

What we cannot offer, and will not pretend to: there is no third-party audit report to send you, no SOC 2, no ISO certificate, and no office with an audit team to receive. If your madrasa’s own rules require a supplier who has those, Sijil does not meet them today. It is better for you to learn that before a register is moved here than afterwards.

If your madrasa appoints somebody to inspect on its behalf, we will cooperate at reasonable times and at your cost, provided they are not a competitor of ours and they keep confidential what they see about other madaris — which, in a shared system, they may inadvertently see. Nothing in this section entitles anybody to look at another madrasa’s records, and if an inspection cannot be arranged without that, it will not be arranged.

14. How long it is kept, and the end of the agreement

How long a former student’s record should stay in the register is your madrasa’s decision, not ours, and we do not delete anything of yours on a schedule of our own invention. What follows is what the system does by default, and the two things we are obliged to keep for our own reasons.

When the agreement ends — because your madrasa leaves, or because we stop offering the service — your records are yours to take first. Ask us and we will produce a copy of everything held about your madrasa in a form another system can read. This is done by hand, so ask before you need it rather than on the last day, and expect it within the 30-day window rather than in an afternoon.

Two things that are easy to confuse. An unpaid account is locked, not emptied: the register becomes read-only and every record stays exactly where it is, and the billing document sets out that sequence step by step. And after your records are gone, we still hold our own invoices to your madrasa, because Pakistani tax law requires us to keep our accounts — those show your madrasa’s name and what it paid, and not one line about any child.

15. The agreement itself

This document runs from the day your madrasa’s account opens until the last copy of your records has gone, and it needs no separate signature: using Sijil accepts it, in the same way the terms and conditions are accepted. If your madrasa needs a signed copy for its own file — for a board, a trust deed, an affiliation body — ask us and we will sign and return one, word for word as published.

Where this document and the terms and conditions disagree about personal data, this one governs. Everything else comes from the terms — what is owed, how the service may be used, and the limit on what we can be required to pay if we cause loss — and that limit applies to this document too, including to the acts of the seven providers. Both are governed by the laws of Pakistan, and the courts of Karachi have exclusive jurisdiction.

We will change this document when the system changes, because a data agreement that no longer describes the code is worse than none. If a change narrows a protection your madrasa has here, we will email your administrators at least 30 days before it takes effect, and if you do not accept it you may end the agreement and take your records out. A correction that widens a protection, names a provider more accurately or fixes a mistake takes effect when it is published, and the date at the top of the page moves.

Everything here comes to one address: contact@sijil.pk, or +92 371 2633733 if a matter is urgent, with security@sijil.pk for anything that looks like a security problem. And a standing request: if any sentence in this document turns out not to match what the software actually does, tell us. One of the two is wrong, and it is usually the sentence — but until somebody says so, neither gets fixed.