SARATech AI Solutions Private Limited
Privacy Policy
QuizAttempt Teacher — Android application and school platform
Effective 12 August 2026 · Version 1.0
Download this document as a PDF1Who we are
This policy explains how SARATech AI Solutions Private Limited ("SARATech", "we", "us") handles personal data in the QuizAttempt Teacher Android application and the QuizAttempt platform it connects to.
CIN U62013JH2026PTC028520. Registered office: C/O Uttam Kumar, Uliyan, Govind Nagar, Kadma, East Singhbhum, Jamshedpur, Jharkhand 831005, India. Contact: hello@quizattempt.com.
It applies to two groups of people, and the distinction runs through everything below: teachers and school staff, who hold accounts with us directly, and students, whose data we hold only because a school placed it with us.
It is governed by the Digital Personal Data Protection Act, 2023 and the Information Technology Act, 2000 with its rules.
2Our role: the school decides, we execute
For all student data, the school is the data fiduciary and SARATech is the data processor. The school decides which students are enrolled, which teachers may see them, what is recorded and when it is removed. We act on the school's instructions and do not use student data for our own purposes.
The app is built around that division rather than merely asserting it. A teacher cannot correct a roster entry or a date of birth directly: those are submitted as requests an organisation administrator approves. The same holds for proposed curriculum edits. Authority over the record stays with the school, and each change carries an approver and a timestamp.
One consequence deserves stating plainly rather than burying: we do not obtain consent from parents ourselves. The school obtains it within the enrolment relationship it already holds with the family, and confirms to us that it has done so. Where a child's data is involved the DPDP Act requires verifiable parental consent, and our agreement with each school places that obligation on the school.
For a teacher's own account data — name, contact details, subjects taught, and the assessments they author — SARATech is the data fiduciary, because a teacher's relationship with the platform continues even when they change schools.
3What the app handles
| Category | What it is | Where it comes from |
|---|---|---|
| Teacher account | Name, email, mobile number, the organisations they belong to, classes and subjects assigned, role and permissions | Entered by the teacher, or by the school when it issues an invitation |
| Student records | Name, class and section, school identifier, date of birth, attendance, marks, quiz answers and scores | Supplied by the school; corrections verified by an administrator |
| Teaching content | Quizzes, question banks, question papers, worksheets and lesson plans, and the curriculum they map to | Authored by teachers, alone or with AI assistance |
| Authentication | Session tokens carrying the active organisation, one-time passcodes for verification and password reset, and a password held only as a salted one-way hash | Generated at sign-in and organisation switch |
| Workflow and usage | Approval requests and their outcomes, notifications, AI generation job records, plan and credit consumption | Created as the app is used |
| On-device cache | Attendance marked while offline, held until it can sync; PDFs the teacher downloads | Written to the device by the app |
| Technical logs | App and Android version, device model, crash diagnostics, and the IP address a request arrives from. Held in our own infrastructure — the app contains no third-party crash-reporting or analytics library | Collected automatically for security and fault diagnosis |
What the app does not collect. No location data. No contacts, call logs or SMS. No photographs or files beyond what a teacher deliberately attaches to teaching content. No biometric data, no health data, and no financial data — the teacher app takes no payments.
No advertising and no tracking. The app contains no advertising SDK, no analytics SDK, no attribution or fingerprinting library, and no third-party tracker of any kind. We do not build advertising profiles, and we do not permit behavioural advertising or tracking directed at children anywhere on the platform. This is a design constraint we do not intend to relax.
4Why we handle it
Each purpose is limited to what the school engaged us to do. We do not repurpose data for anything outside this list.
- To let a teacher create, run, grade and report on quizzes, question papers, worksheets and lesson plans for their assigned classes.
- To record attendance and marks, and to show a teacher, HOD or principal how a class or a student is progressing.
- To route roster corrections, marks entry and curriculum proposals to whoever in the school is authorised to approve them.
- To carry a class forward at the end of an academic year when the school promotes it.
- To share a student's own results with that student's parent, where the school has enabled it.
- To authenticate users, verify a number by one-time passcode, keep accounts secure and investigate misuse.
- To meter plan and credit usage, diagnose crashes, and keep the service available.
5How we use AI
The app uses third-party AI models to help teachers draft teaching material. It does not use them to read or assess student work. Schools scrutinise this section hardest, so generation and scoring are described separately rather than together as "AI features".
5.1Generating teaching content
What is sent. Only curriculum and instructional text: board, class, subject, chapter or topic, the difficulty and question pattern requested, marks distribution, and the teacher's own prompt or reference material.
What is never sent. No student name, roll number or date of birth. No attendance. No marks or quiz responses. Generation requests carry no student data in identified or pseudonymised form.
Generation runs as a background job, so a teacher can navigate away while it completes. We retain the job record and the generated content; the request itself is not retained beyond what is needed to produce and store the result.
5.2Scoring student answers
Quizzes are objective, and scoring them sends nothing anywhere. Quizzes use objective question types such as multiple choice. The correct answer is fixed when the question is created — by the AI at generation time, or by the teacher from the question bank — and scoring compares the student's selected option against that stored key. It is a comparison inside our own systems, not an act of interpretation, and no student answer is transmitted to any AI provider in order to score it. The teacher can override any score in the answer-by-answer editor.
Subjective answers are never marked by AI. Question papers and worksheets are generated for the teacher’s own use and are evaluated by the teacher. We do not offer AI marking of written or long-form answers, and we do not upload student written work for AI assessment. This is a deliberate limit, not a feature we have yet to build.
Providers and training. We use more than one established commercial AI provider and may change providers as models improve. All are engaged on paid enterprise API tiers under terms that prohibit the use of submitted content to train their models, and we do not opt in to any training or model-improvement programme. We will name the providers in use, in writing, to any school or parent who asks — write to contact@quizattempt.com. We name them on request rather than in this policy so that the list stays accurate as models change, and we will notify schools in writing before any change that affects what leaves our systems.
No automated decisions about a child. Generated papers are drafts a teacher reviews before a student sees them, and a score is a figure the teacher can confirm or replace. Marks of record, promotion and stream guidance remain human judgements. No outcome affecting a student is finalised by a model.
6Who else touches the data
We engage a small number of sub-processors. Each is bound by contract to confidentiality, to process only on our instructions, and to security standards no lower than our own. We do not sell personal data, and we do not share it for advertising.
| Purpose | Who | What they see |
|---|---|---|
| Application hosting and database | Amazon Web Services, Mumbai region (ap-south-1) | All platform data, encrypted at rest |
| Web front-end delivery | Vercel Inc., global edge network | Static application files, and page-view counts and page-load timings for the website: the route pattern of the page, the campaign parameters of any marketing link that led to it, plus referrer, country, device type and connection speed. Identifiers in a URL are removed in the browser before either is sent, and the signed-in parts of the platform send no campaign parameters at all, so no student data reaches it. Requests carrying personal data go to our Mumbai servers, not to the edge |
| AI content generation | Commercial AI providers, named on request | Curriculum and instructional text only (section 5.1). No student data |
| Email and one-time passcodes | An email delivery provider and an SMS gateway, named on request | A teacher's email address or mobile number and the message sent. No student data |
We disclose personal data outside this list only where the law compels it — a valid order from a court or authorised agency — or to the school that placed the data with us. We will tell the affected school of any compelled disclosure unless we are barred from doing so.
7Where the data lives
Student and teacher records are stored in India, in AWS's Mumbai region (ap-south-1). Our databases, backups and application servers are all in that region.
Two things cross a border, and both are stated so a school can assess them:
- Static web files are served from Vercel's global edge network, which places copies of application code close to the user. These files contain no personal data. The same provider counts page views on the website and measures how fast pages load — the route pattern, the campaign parameters of any marketing link, referrer, country, device type and connection speed, with identifiers removed in the browser before sending, and no cookies set.
- AI generation requests may be processed by a provider outside India, carrying only the curriculum text described in section 5.1. No student data is transferred.
Any transfer is made under contractual safeguards with the recipient. The DPDP Act permits transfer except to countries the Central Government restricts by notification; we will cease transferring to any such country if notified.
8How long we keep it
| Data | Retention |
|---|---|
| Student records, while a school is a customer | Kept for as long as the school instructs, so that a multi-year learning record is available to it |
| Student records, after the contract ends | 90 days in which the school may export its data, then permanent deletion from live systems and from backups within a further 30 days |
| An individual student who leaves a school | Deleted on the school's instruction, within 30 days of a written request (section 9) |
| Teacher account | Kept while the account is active; deleted within 30 days of a deletion request. Content the teacher authored for a school remains with that school |
| Attendance cached on the device | Cleared once synced, and on sign-out |
| Technical and security logs | 180 days, unless a longer period is required to investigate an incident or to comply with law |
Where we must keep something longer to comply with law, we retain only what the law requires and nothing else.
9Deletion, and how to ask for it
Because the school is the fiduciary, the school instructs and we execute. That keeps a stranger from being able to erase a child's academic record by email.
- A school writes to help@quizattempt.com from a registered administrator address. We acknowledge within 3 working days and complete deletion within 30 days, confirming in writing when it is done.
- A parent or guardian should raise the request with the school, which holds the enrolment relationship and the consent record. If a parent writes to us directly we will not ignore them: we acknowledge, explain this route, and inform the school so the request is not lost.
- A teacher may ask us directly to access, correct or delete their own account data, at the same address.
Under the DPDP Act a data principal may seek access to their data, its correction or completion, its erasure, and redress of a grievance, and may nominate another person to exercise these rights. For students those rights are exercised through the school; for teachers, with us.
10How we protect it
- In transit: TLS on every connection. The app makes no plaintext request, and non-TLS traffic is refused rather than downgraded.
- On the device: credentials and session tokens are held in hardware-backed secure storage, not in shared preferences or plaintext files.
- At rest: databases and backups are encrypted. Passwords are stored only as salted one-way hashes and cannot be recovered by us.
- Access control: a teacher sees only their assigned classes. Attendance marking is gated on an explicit permission, so a subject teacher cannot mark a class they do not hold. Roster and curriculum changes require an administrator's approval. Switching organisation re-scopes the session rather than widening it.
- Internal access: restricted to the smallest number of engineers needed to operate the service, on a need-to-know basis, under confidentiality obligations.
No system is immune. In the event of a personal data breach we will notify the Data Protection Board of India and each affected school without undue delay, in the manner the DPDP Act prescribes, and support the school in notifying families.
11Children
The teacher app is for adults. Students do not hold accounts in it. Student data appears in it only because a school placed that data with us for the purpose of teaching those students.
Where children's data is processed we do not carry out tracking or behavioural monitoring of children, and we do not direct advertising at them. We do not profile a child for any purpose other than the educational reporting the school has asked for. Verifiable parental consent is obtained by the school, as described in section 2.
12Teacher accounts across schools
A teacher may belong to more than one school or campus and switch between them without signing out. The active organisation is carried in the session token, and a teacher sees only the students of the organisation currently active. Data is not pooled across organisations, and one school cannot see another school's students through a shared teacher account.
13Grievance officer
As required by the Digital Personal Data Protection Act, 2023 and the Information Technology Rules, our grievance officer is:
Ravi Kumar Pandey, Chief Executive Officer
SARATech AI Solutions Private Limited C/O Uttam Kumar, Uliyan, Govind Nagar, Kadma, East Singhbhum, Jamshedpur, Jharkhand 831005 ravi@quizattempt.com · +91 6207 225 395
We acknowledge a grievance within 3 working days and resolve it within 30 days. If a data principal remains unsatisfied they may approach the Data Protection Board of India.
14Changes to this policy
We will post any change on this page with a new effective date and version. Where a change materially affects how student data is handled we will notify each school in writing before it takes effect, so the school can consider it against its own consent position. Continued use after the effective date constitutes acceptance for teacher account data.
15Contact
SARATech AI Solutions Private Limited C/O Uttam Kumar, Uliyan, Govind Nagar, Kadma, East Singhbhum, Jamshedpur, Jharkhand 831005, India contact@quizattempt.com · +91 6207 225 395 · quizattempt.com