Controller & processor identity
- Processor: Sharjeel Zubair, operating ElifLammeem as sole proprietor, pending incorporation in Pakistan and the Kingdom of Saudi Arabia.
- Processor contact (privacy): szubair01@gmail.com
- Controller(s): Each school customer is a separate controller. This register describes processing we perform on behalf of all of them collectively; specific data volumes are held per-tenant and are not disclosed here.
- Representative in the EU / UK: None appointed — ElifLammeem does not offer services directly to EU/UK data subjects. If that changes, a representative will be appointed under GDPR Art. 27.
Activity 1 — Issue submission and handling
Purpose. Accept, route, track, and resolve complaints and feedback from parents and teachers; enable staff conversation, internal notes, and audit.
Legal basis. Performance of the contract between the school and the parent / teacher (enrolment or employment); legitimate interests of the school and its community in safeguarding and record-keeping.
Data subjects. Parents, legal guardians, teachers, staff members, and (indirectly) students referenced in issue content.
Data categories. Identity & contact (name, email, phone, role, branch); submission content (title, description, messages, attachments which may include photos and documents); AI-generated analysis (category suggestion, urgency, theme).
Special-category data. Possible where the submission concerns health, injury, or religion.
Recipients. Authorised school staff (role-scoped); AWS (hosting); OpenAI / Anthropic (text-only AI analysis with identifiers stripped).
Third-country transfer. United States (AWS us-east-1, OpenAI, Anthropic). Safeguarded by Standard Contractual Clauses with each sub-processor.
Retention. Closed issues + messages + attachments: 3 years from closure. Attachments removed from storage at purge time.
Security measures. TLS in transit, AES-256 at rest, tenant isolation, role-based access, private-disk attachments with short-lived signed URLs, full activity log.
Activity 2 — Access code issuance and authentication
Purpose. Authenticate parents and teachers into the public portal via a school-issued random access code, without requiring them to create an account.
Legal basis. Performance of the contract; legitimate interests (security).
Data subjects. Parents, teachers.
Data categories. Random 8-character code; the contact it belongs to; timestamps of generation, delivery, use.
Recipients. Authorised school staff; Mailtrap (email delivery); Twilio / Messagat (SMS delivery); AWS (hosting).
Third-country transfer. Mailtrap (EU); Twilio / AWS (US); Messagat (Saudi Arabia). Safeguards as above.
Retention. Used access codes deleted 90 days after last use. Active codes kept as long as the contact relationship continues.
Security measures. Codes are opaque random strings; endpoints accepting codes are rate-limited to prevent enumeration; codes are session-scoped in the browser (cleared on tab close); no codes in server access logs (inputs travel via POST).
Activity 3 — Leave request processing
Purpose. Accept, review, approve / reject / request-info on leave requests for students; maintain a printable signature-ready record.
Legal basis. Performance of the contract; legitimate interests (record-keeping); legal obligation (some jurisdictions require attendance records).
Data subjects. Students, parents / guardians.
Data categories. Student name, leave type (sick / family / religious / travel / other), dates, reason, optional attachments (e.g. medical certificate).
Special-category data. Health (medical certificates), religious belief (leave reason).
Recipients. Authorised school staff; AWS (hosting, attachment storage).
Third-country transfer. United States (AWS). Safeguards via SCCs.
Retention. 2 years from submission, then automatic purge (row + attachment files).
Security measures. Attachments on private local disk, streamed via signed URL only; strict tenant + role scoping on the admin review queue.
Activity 4 — Circulars & homework broadcast
Purpose. Publish school circulars, homework notices, and events, targeted by branch, grade, or section; optionally notify parents via email, SMS, or WhatsApp with a link back to the portal.
Legal basis. Performance of the contract.
Data subjects. Parents (as recipients).
Data categories. Circular content (title, body, attachment); recipient contact details pulled from roster at send time; delivery status per recipient.
Recipients. Authorised school staff (compose + send); AWS (storage, delivery queue); Mailtrap / Twilio / Messagat (delivery); Meta Cloud API (WhatsApp, when enabled).
Third-country transfer. US (AWS, Twilio, Meta); EU (Mailtrap); KSA (Messagat). SCCs.
Retention. Circular rows are kept for the duration of the school's relationship (their own notice archive). Per-recipient delivery logs age out with the circular.
Security measures. Broadcast scope enforced server-side (school staff cannot send beyond their branch scope); attachment downloads via signed URLs.
Activity 5 — Parent-teacher meeting booking
Purpose. Publish PTM slots, let parents book per-child, send confirmation emails with cancel links.
Legal basis. Performance of the contract.
Data subjects. Parents, teachers, students.
Data categories. Slot definition (teacher, date, time, location); booking (parent contact, student, optional note).
Recipients. Authorised school staff; AWS; Mailtrap (confirmation emails).
Third-country transfer. US (AWS); EU (Mailtrap).
Retention. Bookings for slots more than 1 year in the past are automatically purged. Slots themselves are school-managed roster data.
Security measures. 30-day signed cancel-link tokens; capacity locks against concurrent double-booking.
Activity 6 — Consent-form publication and responses
Purpose. Collect structured Yes/No consent per student for trips, photo/video, medical activities, policy acknowledgements, etc.; lock past-deadline responses.
Legal basis. Consent (parent's explicit consent for the specific activity); performance of the contract (for the portal itself).
Data subjects. Parents, students.
Data categories. Form definition (title, body, event details, attachment); per-student response (approve / decline, optional note, timestamp); 40-char signed response tokens.
Special-category data. Possible for medical consents.
Recipients. Authorised school staff; AWS; Mailtrap (response-link emails).
Third-country transfer. US (AWS); EU (Mailtrap).
Retention. Responses purged 2 years after the event date (or after response date if no event date set). Form templates retained as school property.
Security measures. Response tokens are per-student, uniquely indexed per tenant, and never exposed to the portal JS. Server-side deadline enforcement.
Activity 7 — AI-assisted triage & chatbot
Purpose. Suggest urgency level, theme, and one-line summary for new issues; answer parent questions from a school-curated knowledge base (when enabled).
Legal basis. Legitimate interests (improving response quality).
Data subjects. Parents, teachers (as submitters / questioners).
Data categories. Issue text; chatbot question text. No names, contact details, or identifiers sent to the AI provider.
Recipients. OpenAI, Anthropic.
Third-country transfer. United States.
Retention. Providers' enterprise terms commit them not to train on API inputs. Suggestions are stored in our database alongside the issue and age out with it (3 years from closure).
Security measures. PII stripping before transmission; no automated decision — a named staff member always makes the final call on status, assignment, or approval.
Activity 8 — Satisfaction surveys (CSAT)
Purpose. Ask closed-issue parents to rate the school's handling from 1–5 stars via a one-tap email link, to feed aggregate satisfaction metrics.
Legal basis. Legitimate interests (quality improvement).
Data subjects. Parents.
Data categories. 1–5 rating, submission timestamp. Linked to the issue, not directly to a contact row.
Recipients. Authorised school staff; AWS; Mailtrap (survey invite).
Third-country transfer. US (AWS); EU (Mailtrap).
Retention. 2 years from submission, then automatic purge.
Security measures. Single-use 48-char signed token; second submission silently ignored.
Activity 9 — Activity log / audit trail
Purpose. Maintain a timestamped record of every significant action across the platform (issue status changes, assignments, circular publications, leave decisions, consent responses, privacy erasures) for dispute resolution and audit.
Legal basis. Legitimate interests (audit); legal obligation (where record-keeping is mandated).
Data subjects. Staff (as actors); parents / teachers (as actors via the portal); students (indirectly as subjects).
Data categories. Action type, actor identity, subject reference, timestamp, structured data payload (e.g. old vs new status).
Recipients. Authorised school staff; AWS.
Third-country transfer. US (AWS).
Retention. 3 years from creation, then automatic purge — except privacy-erasure entries, which are kept indefinitely as the compliance trail committed to in the DPA.
Security measures. Admin view filters out parent-originated entries; rows remain in the DB as audit artefacts.
Activity 10 — Data-subject rights handling
Purpose. Process data-subject requests for access, portability, and erasure, as required under GDPR, Saudi PDPL, Pakistan PDPA, and equivalent laws.
Legal basis. Legal obligation.
Data subjects. Parents, teachers.
Data categories. Request record (type, reason, status, approver); captured copy of the contact's name and email at request time (so the audit trail survives anonymisation).
Recipients. School administrators (to approve / reject); AWS (hosting).
Third-country transfer. US (AWS).
Retention. Indefinite — this is the compliance evidence that an erasure request was honoured.
Security measures. Request flow is access-code-authenticated; admin approval required before deletion executes; full anonymisation transaction is logged.
Activity 11 — Administrator accounts and authentication
Purpose. Provide authenticated staff access to the admin panel.
Legal basis. Performance of the contract; legitimate interests (security).
Data subjects. School staff (admin / branch manager / staff).
Data categories. Name, email, phone, role, branch assignments, category assignments, bcrypt-hashed password, 2FA secret and recovery codes (where enabled), login timestamps.
Recipients. AWS (hosting).
Third-country transfer. US (AWS).
Retention. For the life of the school's subscription, plus 2 years after cancellation for audit and possible re-activation.
Security measures. bcrypt with per-password salt; optional 2FA (plan-gated); session cookie with secure / HTTP-only flags; CSRF tokens on state-changing routes; soft-delete with anonymisation of message author names on hard-delete.
Activity 12 — Billing & subscription management
Purpose. Bill school customers for subscription plans; track payment status.
Legal basis. Performance of the contract; legal obligation (tax records).
Data subjects. School billing contacts.
Data categories. Name, email, school, plan, subscription status; last 4 digits of card and brand (full card data handled by the payment processor only).
Recipients. Payment processor; AWS.
Third-country transfer. Depends on chosen processor.
Retention. 7 years (tax-law requirement).
Security measures. Payment processor is PCI-DSS-compliant; no raw card data ever touches ElifLammeem servers.
Updates to this register
This register is reviewed at least annually and updated whenever a new processing activity is introduced, a sub-processor changes, or a retention rule shifts. The "Last updated" date at the top of this page reflects the current version. Previous versions are archived privately and available to auditors on request.