Privacy Policy

1. Who we are, and who is responsible

Two different sets of records are involved, and they are governed differently. Your madrasa decides what to record about its students, teachers and guardians and how long to keep it. Those decisions are yours, so your madrasa is the controller of that data and we process it only on your instructions — we do not decide what goes in it, we do not use it for any purpose of our own, and we do not disclose it to anyone else without your instruction or a legal obligation.

The second set is small and belongs to us: the account we opened for your madrasa, what we invoiced and whether it was paid, anything you send us by email or WhatsApp, and the traffic measurement on our public website. Nobody instructs us about those records, so we are answerable for them ourselves and this policy is where we account for them.

In practice this means a parent asking about their child’s records should ask the madrasa, and the madrasa should ask us. You can reach us at contact@sijil.pk or +92 371 2633733. Questions about privacy and requests about information go to the same address; a named person reads them, and we have not appointed a formal data protection officer because at our size that would be a title rather than a safeguard.

2. What is in Sijil

These are the fields themselves, not categories. A madrasa decides which of the optional ones it fills in; several can be left empty and the product still works.

About a student

Name, father’s name, date of birth, gender, photograph, home address, a phone number for the student and one for the guardian, guardian’s name, roll number, admission date, class, the current para and sabaq, the monthly fee and any discount on it, and whether the student is active, inactive, graduated or expelled.

About a teacher

Name, father’s name, phone number, CNIC number, photograph, the class PIN used to mark attendance, a six-digit login PIN where one is set, and whether the teacher is active.

About a guardian

The phone number the madrasa entered against the student, the PIN the guardian chooses, the device the guardian signs in from, and a count of failed PIN attempts so that the account can be locked after too many.

About an administrator

The name and email address on the Google account used to sign in, the identifier Google gives that account, the role held in the madrasa, and a master PIN for actions that need a second confirmation.

Made by using the product

Every attendance mark, with the date and the class timing it belongs to. Every fee charged, paid, waived or left outstanding. Every progress entry a teacher records. And a sign-in record for each time someone signs in, holding the date and time, the IP address, the browser and device description sent by the browser, and a signature of that device used to detect a session being replayed somewhere else.

On an application to join

This is filled in before the madrasa exists in Sijil, and it is the one record on this list that is ours rather than a madrasa’s. It carries the madrasa’s name, the applicant’s own name, the full address and the city in Urdu, and the same four again in English where they were typed in; the year the madrasa was founded; the web address asked for; a phone number, confirmed by a code sent to it; the email address on the Google account the form was started with, the identifier Google gives that account, and the moment Google confirmed that address; and a notes box for anything else the applicant wants to tell us. The six-digit master PIN chosen on the form is stored only as a hash, so nobody at Sijil can read it back. Everything else on the form is optional and may be skipped in full: who is filling it in, the province, roughly how many students and how many teachers, whether the students are boys, girls or both, what is taught, which shifts run, how records are kept today, how the madrasa heard of Sijil, the best time and the language to telephone on, the board the madrasa says it is affiliated with, and a WhatsApp number.

Recorded with that application

Two boxes have to be ticked before an application can be sent — these documents, and a confirmation that the person is permitted to register the madrasa — and against each we record the moment it was ticked, which version of the documents was on the screen, and which language they were being read in. Recorded with the submission itself: the IP address it arrived from and the description the browser sent of itself, so that two applications from one address can be told apart from one application sent twice; how many times this Google account has applied; and, where an application follows a refused one, a link back to it. If an application is refused, the reason written by the person who read it is kept on the row and is shown to the applicant, while the working notes that person writes for themselves are not put on the applicant’s screen.

Sent to us from the public side

An enquiry left on a madrasa’s public page carries a name, a phone number and a message, and is stored for that madrasa to read. A message sent to us through the contact form on sijil.pk is emailed to us and is not written to any database.

3. Where the information comes from

• Typed in by your own staff — almost all of it. A student record exists because an administrator created it.
• Produced by using the product: an attendance mark, a fee entry, a progress entry.
• Chosen by the person themselves: the PIN a teacher or a guardian sets.
• From Google, when an administrator signs in — the name and email address on that Google account, and the identifier Google uses for it.
• From whoever applies to register a madrasa, before there is an account at all — the whole application form, and the Google account it was started with.
• From the browser, automatically, on every request: the IP address it is coming from and the description it sends of itself. Our host records this on every request whether we ask for it or not — that is how the web works — and we keep a copy of it deliberately in two places only: a sign-in record, and a registration application.
• From a family, when someone fills in the enquiry form on your public page.

4. Why we hold it

• To run the register you asked for: class lists, attendance, fees and progress.
• To let the right people in and keep everyone else out — which is what the PINs, the sign-in records and the device records are for.
• To show a guardian their own child’s record, and no other child’s.
• To invoice you and to keep the accounts a tax authority can ask to see.
• To answer you when you write to us, and to look at a specific problem when you ask us to.
• To keep the service standing up, which means our host records requests and errors.
• To understand which pages of the public website people read — and only if you have agreed to it.
• To do something the law requires of us.

Pakistan has no comprehensive data protection statute in force, so there is no list of statutory lawful bases to tick here and it would be misleading to publish one as though there were. What we can tell you is the honest position: nearly everything we do with your madrasa’s records, we do because your madrasa instructed us to when it started using Sijil, and we stop when you tell us to stop. The exceptions are the ones above that are ours rather than yours — keeping the service running, keeping our accounts, answering you — and analytics, which happens only with consent and can be withdrawn without losing access to anything.

5. Children’s information

Most of what Sijil holds describes a child. Two facts about how the product is built matter more here than any promise we could make.

The first is that a student never has an account. There is no student sign-in, no student app and no way to send a student a message through Sijil. A child cannot log in, and nothing about a child is published anywhere: the public page a madrasa can switch on describes the madrasa — its classes, its timings, its contact details — and does not list students. Only the madrasa’s own staff, and a guardian looking at their own child, can see a student record at all.

The second is that we do nothing with a child’s record beyond keeping the register working. It is not used to target advertising, because there is no advertising in Sijil. It is not used to build a profile of anyone, not sold or shared with data brokers, and not used to train machine-learning models. If we ever wanted to do any of those things we would have to come and ask you, and this section would have to change first.

If a guardian wants a child’s record corrected, or the child taken off the register, the person to ask is the madrasa: an administrator can do both inside the product immediately, without us. If a guardian writes to us instead, we pass the request to the madrasa and tell the guardian we have done so. We will not alter or delete a madrasa’s records because someone outside that madrasa asked us to.

6. Photographs

A student photograph is optional. Sijil works without a single one, and a madrasa that would rather not hold faces should simply not upload any.

When one is uploaded it does not go into our database. It goes to Cloudinary, an image hosting company, which resizes it to a square 800-pixel portrait cropped to the face and serves it back to the product. Teachers’ photographs are handled the same way.

7. Who else can see it

No other madrasa can see your records, and we do not give them to anyone who asks. Sijil does, however, run on other companies’ machines, and each of them necessarily holds the part it handles. This is the complete list. If a company is not on it, we are not sending your information there.

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.

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.

Beyond that list there are three situations in which information leaves us. If you ask us to send it somewhere, we will. If a court order, a warrant or a law we are subject to requires us to hand something over, we will comply — and we will tell you unless we are forbidden from telling you. And if Sijil is ever transferred to the company described at the top of this page, or to anyone else, the records move with it and you will be told in writing before that happens, in time to take your data and leave instead.

8. What we do not do

Some of these are promises. Most are simply descriptions of a product that has no such feature, which is a stronger guarantee than a promise, and we would rather you knew which is which.

• There is no card payment in the product. No card number, expiry or CVV is ever typed into Sijil, because there is nowhere to type one.
• There is no self-service export or delete button. When you ask for a copy of your data or its deletion, a person does it by hand.
• We do not sell data, share it with advertisers or data brokers, or use it to target advertising. There is no advertising anywhere in Sijil.
• We do not use your madrasa’s records to train machine-learning models.
• We do not read your madrasa’s records except when you ask us to help with a specific problem, or where we must to keep the service running or to meet a legal obligation.

9. Cookies and measurement

Sijil sets a small number of cookies it cannot work without — the one that keeps you signed in, the one that remembers whether you are reading in English or Urdu, the one that recognises your device. Nothing about those is optional, and we do not ask permission for them, because switching them off means switching off signing in.

Measurement is different, and it is the one thing on this page you are asked to agree to. Until you agree, no measurement script loads at all. If you agree, we can see which pages are read and which parts of the product are used; inside the portal that measurement is tied to the staff account using it, including the person’s name and their madrasa’s name. You can say no, or change your mind later, and nothing stops working either way. The cookie policy lists every cookie by name, what it is for and how long it lasts.

Two things about that measurement are worth stating plainly, because a mohtamim may be asked either one. The first is that our measurement provider sells a screen recorder — a tool that replays what a member of staff had on the screen, register and all — and it is switched off in our own code rather than only in that provider’s settings, so nothing here replays a register. The second is that what does get sent includes the address of each page, and portal addresses contain the identifiers of records, so a trail of which member of staff opened which class or which child’s page reaches the provider even though the record itself never does. That is why our own advice to staff is to refuse measurement on the devices the register is opened on. Refusing keeps every part of it off on that browser, and section 4 of the cookie policy sets the whole of it out.

10. How long we keep it

A register is only useful if it goes back years, so the honest answer for most of what is in Sijil is “for as long as your account is open”. Where something is deleted on a fixed schedule by a job that actually runs, the period is in the table. Where nothing enforces a period, the table says so instead of inventing one.

One kind of record is missing from that table because it belongs to no account: an application to join. Nothing deletes one, whether it was approved or refused — an approved application is the record of how a madrasa came to be here, and a refused one is what that applicant’s next attempt is read against. If you applied and would rather we did not keep it, write to us from the Google address you applied with and we will remove it.

11. How it is protected

What follows is a list of measures that exist in the software, not a list of intentions. One of them reads as a weakness and is included for that reason: an administrator can read a teacher’s or a guardian’s PIN back to them, which means that one secret in the system is recoverable. That is a deliberate trade — a guardian who has forgotten a four-digit PIN needs it read out at the office rather than a password-reset email they cannot receive — and you are entitled to know it before you decide to trust us.

• 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.

None of this makes a system unbreakable, and a page that said otherwise would be worth less than this one. What it does mean is that the ordinary failures — a shared password, a stolen phone, a guessed PIN, one madrasa’s account reaching another’s records — are the ones we have actually built against.

12. If something goes wrong

If we find that records have been exposed, altered or lost when they should not have been, we will tell the affected madrasa within 72 hours of becoming aware of it. We will say what happened, which kinds of records were involved, what we have done about it and what we advise the madrasa to do — including, where it matters, telling the families concerned. We would rather send an early notice that turns out to be smaller than feared than a late one that is complete.

The notice goes to the madrasa because the madrasa decides what its families are told and how; we are not the right voice to appear in a parent’s inbox about their child’s record. Where the law obliges someone to notify an authority, that obligation is the madrasa’s, and we will give it whatever we hold that it needs in order to do so. If you believe you have found a security problem in Sijil, write to security@sijil.pk; we would much rather hear it from you than from someone else.

13. What you can ask us for

We give you the following, in writing, as a promise rather than as a summary of a statute — see the next section for why that distinction matters. Whichever of these you ask for, you ask a person, and a person answers.

• Ask what we hold about you, and why.
• Ask for a copy of it.
• Have it corrected if it is wrong.
• Have it deleted, unless we have to keep it — an unpaid invoice or a tax record, for example.
• Ask us to stop a particular use of it, or to object to that use.
• Withdraw your consent to analytics at any time, without losing access to anything.
• Complain to us, and expect an answer rather than a form.

Two practical notes. There is no button for any of this: a copy of your data or its deletion is done by hand by us, which is slower than a self-service export but means nothing is deleted by accident. And we will ask enough to be satisfied that you are who you say you are before we act — for a madrasa administrator that is normally the account they sign in with; for anyone else it is the madrasa vouching for them. We ask for the least that will do, and we do not keep the proof afterwards.

14. Which law applies

Sijil is operated from Karachi and is used by madaris in Pakistan, so this policy is governed by the laws of Pakistan and the courts of Karachi have exclusive jurisdiction over any dispute about it.

The honest position on Pakistani data protection law is that there is not much of it yet. The Prevention of Electronic Crimes Act 2016, as amended in January 2025, makes unauthorised access to and interference with an information system a criminal offence, which is the law that protects your records from an intruder. A comprehensive data protection statute — the Personal Data Protection Bill — has been in draft since 2023 and has not been enacted. There is therefore no data protection authority in Pakistan to register with, complain to, or notify of a breach.

That gap is why the previous section is written as a promise. We have taken the rights and the deadlines that European data protection law would impose on us — access, correction, deletion, objection, a month to answer, seventy-two hours to report a breach — and given them to you here because they are the right standard, not because a Pakistani statute compels them. We do not claim to be certified or found compliant with any foreign regime, and you should treat any Pakistani software company that does claim it with suspicion. If your madrasa is subject to a foreign data protection law through its own funders, partners or families abroad, tell us and we will put the additional terms you need into your data processing agreement.

15. Changes to this policy

This policy will change, because the product will. When it changes in a way that affects you — a new company holding some part of your information, a new kind of record collected, a shorter or longer retention period, a narrower promise — we will email every madrasa administrator before the change takes effect and say plainly what is different. Corrections that do not change what we do, such as fixing a wrong word or adding an explanation, we simply make.

The two dates at the top of this page are there so you can check that for yourself: the first is the version your madrasa agreed to, the second is whether anything has moved since. If they differ and nobody told you, that is a failure on our part and worth writing to us about.

16. How to reach us

Who operates Sijil

Hassan, an individual trading as Sijil, in Karachi, Sindh, Pakistan.

Privacy, and requests about information

contact@sijil.pk — the same address for a question, a complaint, or a request to see, correct or delete something.

Security problems

security@sijil.pk — if you have found a weakness, this address reaches us fastest.

By phone

+92 371 2633733. Urdu or English, whichever you prefer.

If you have asked us something about your madrasa’s records and we have told you to ask the madrasa instead, and the madrasa has not answered you, write to us again and say so. We cannot overrule a madrasa about its own register, but we can tell it that a family is waiting.