Data Processing Agreement

Parties

This Data Processing Agreement ("DPA") is entered into between:

• "The School" (Controller): the educational institution that has signed up for a ElifLammeem tenant, identified by its primary administrator account and billing details.
• "ElifLammeem" (Processor): Sharjeel Zubair, operating the ElifLammeem platform as sole proprietor, pending incorporation of a company in Pakistan and the Kingdom of Saudi Arabia. Upon incorporation, this agreement transfers automatically to the incorporated entity. Contact: szubair01@gmail.com.

Background

1. The School operates an educational institution and, in that capacity, is a Controller of personal data relating to parents, teachers, students, and staff.
2. ElifLammeem provides a hosted, multi-tenant Software-as-a-Service platform that the School uses to collect, manage, and respond to parent/teacher submissions, run leave, circulars, meetings, and consent-form workflows, and maintain related records.
3. In providing the platform, ElifLammeem Processes personal data on behalf of the School as a Processor.
4. This DPA sets out the terms on which ElifLammeem may Process the School's personal data and the measures it takes to safeguard that data.

1. Definitions

Terms in capitals in this DPA have the meanings given below. Where this DPA refers to "Applicable Data Protection Law", it means any law governing the Processing of personal data that applies to the School — in particular the Saudi Personal Data Protection Law (PDPL) and its implementing regulations, Pakistan's Personal Data Protection legislation, and — where the School has data subjects in the European Economic Area or United Kingdom — the EU GDPR and UK GDPR.

• Personal Data — any information relating to an identified or identifiable natural person Processed under this DPA.
• Special Category Data — Personal Data revealing health, religious belief, political opinion, or similar, as defined by Applicable Data Protection Law.
• Data Subject — the individual whose Personal Data is Processed (e.g. a parent, teacher, student, or staff member).
• Processing — any operation performed on Personal Data, including collection, storage, use, transmission, and deletion.
• Sub-processor — a third party engaged by ElifLammeem to Process the School's Personal Data on ElifLammeem' behalf.
• Personal Data Breach — a breach of security leading to the accidental or unlawful destruction, loss, alteration, or unauthorised disclosure of, or access to, Personal Data.

2. Role of the parties

The School is the Controller of Personal Data Processed under this DPA. ElifLammeem is the Processor. The School instructs ElifLammeem to Process Personal Data only as necessary to provide the platform and only in accordance with this DPA, the main subscription terms, and any lawful documented instructions given by the School.

3. Subject matter, nature, and duration of Processing

The subject matter, duration, nature, and purpose of the Processing, the categories of Data Subject, and the types of Personal Data Processed are described in Annex I. This DPA remains in force for as long as ElifLammeem Processes Personal Data on behalf of the School and terminates automatically when the School's subscription ends, subject to the return-or-deletion obligations in Section 11.

4. Obligations of ElifLammeem (Processor)

ElifLammeem shall:

1. Process Personal Data only on documented instructions from the School, including with regard to transfers to a third country, unless required to do otherwise by applicable law (in which case ElifLammeem will notify the School in advance where legally permitted).
2. Ensure that personnel authorised to Process Personal Data are bound by appropriate confidentiality obligations.
3. Implement and maintain the technical and organisational security measures set out in Annex II.
4. Not engage any Sub-processor without the authorisations set out in Section 6.
5. Assist the School, taking into account the nature of the Processing, in responding to requests from Data Subjects exercising their rights under Applicable Data Protection Law, as described in Section 7.
6. Assist the School in ensuring compliance with its obligations regarding security, breach notification, data protection impact assessments, and consultation with supervisory authorities, as far as the information required is available to ElifLammeem.
7. At the School's choice, delete or return all Personal Data to the School upon termination of the services, as described in Section 11.
8. Make available to the School all information necessary to demonstrate compliance with the obligations in this DPA and allow for audits as described in Section 10.
9. Immediately inform the School if, in its opinion, an instruction from the School infringes Applicable Data Protection Law.

5. Security

ElifLammeem has implemented and shall maintain the technical and organisational security measures listed in Annex II, which include (non-exhaustively): encryption in transit and at rest, role-based access controls within each tenant, two-factor authentication for administrator accounts, isolation of each tenant's data, short-lived signed URLs for attachments, rate-limited access code authentication, and a detailed activity log.

ElifLammeem reviews these measures periodically and updates them to reflect technology developments and the evolving risk landscape. Any material changes that reduce the overall security posture will be notified to the School.

6. Sub-processors

The School gives ElifLammeem general authorisation to engage the Sub-processors listed in Annex III. ElifLammeem shall:

1. Only engage Sub-processors that provide sufficient guarantees to implement appropriate technical and organisational measures.
2. Enter into a written contract with each Sub-processor that imposes data-protection obligations substantively equivalent to this DPA.
3. Remain fully liable to the School for the performance of each Sub-processor's obligations.
4. Notify the School at least 14 days in advance of the addition or replacement of a Sub-processor. The School may object in writing on reasonable data-protection grounds. If the objection cannot be resolved, the School may terminate the relevant portion of the services without penalty.

7. Data subject rights

ElifLammeem shall, taking into account the nature of the Processing, provide reasonable assistance to the School to respond to Data Subject requests to exercise their rights under Applicable Data Protection Law (access, rectification, erasure, restriction, portability, objection). Where ElifLammeem receives a request directly from a Data Subject, it will promptly forward the request to the School and will not respond substantively unless explicitly instructed to do so.

8. Personal Data Breach

ElifLammeem shall notify the School without undue delay, and in any event within 72 hours, after becoming aware of a Personal Data Breach affecting the School's Personal Data. The notification will include, to the extent known at the time:

• The nature of the Breach, the categories and approximate number of Data Subjects concerned, and the categories and approximate number of records concerned;
• The likely consequences of the Breach;
• The measures taken or proposed to address the Breach and mitigate its adverse effects;
• The name and contact details of the ElifLammeem privacy contact from whom further information can be obtained.

ElifLammeem shall cooperate with the School to investigate the Breach and support any notifications to supervisory authorities or affected Data Subjects that the School may be required to make.

9. International transfers

ElifLammeem primarily hosts the service in the United States (AWS). Where Personal Data is transferred to a country that has not been recognised as providing an adequate level of protection under Applicable Data Protection Law, ElifLammeem and its Sub-processors rely on contractual safeguards — including Standard Contractual Clauses where applicable — to ensure appropriate protection.

ElifLammeem will, on written request, make available to the School copies of the safeguards in place with each Sub-processor. ElifLammeem is planning a migration of KSA-tenant data to the AWS Middle East (Bahrain) region; details will be shared before migration.

10. Audits

The School may, at its own cost and no more than once per 12-month period, audit ElifLammeem' compliance with this DPA. An audit will be:

• Scheduled at a mutually agreeable time with at least 30 days' written notice;
• Conducted in a manner that does not interfere with ElifLammeem' normal business operations;
• Limited to the School's own Personal Data and the security measures that apply to it;
• Subject to appropriate confidentiality obligations.

ElifLammeem may satisfy audit requests by providing up-to-date security certifications or third-party audit reports (for example, its AWS sub-processor's SOC 2 report) where these cover the relevant scope.

11. Return or deletion of data

11.1 On termination of the services

On termination of the services for any reason, the School may, within 30 days, request that ElifLammeem either:

• Return all Personal Data to the School in a portable machine-readable format (CSV + JSON + attachments); or
• Securely delete all Personal Data from ElifLammeem's production systems.

After the 30-day window expires, ElifLammeem will securely delete the School's Personal Data from production systems within a further 30 days, unless a longer period is required by law. Backups will age out in line with ElifLammeem's standard backup rotation (90 days). ElifLammeem will provide written confirmation once deletion is complete.

11.2 On an individual Data Subject erasure request

When a Data Subject (parent or teacher) submits an erasure request via the portal's /my-data endpoint, the request is captured as a pending record in the data_privacy_requests register and notifies the School's administrator(s). No personal data is removed until the School approves the request. On approval, ElifLammeem executes the following within a single database transaction:

Deleted outright

• The Data Subject's access codes (hard-deleted from access_codes).
• Direct PII fields on the contact record: email, phone, external/SIS identifier, push-notification token, device platform, arbitrary metadata.

Anonymised (records retained for school record-keeping, identifiers stripped)

• The contact's name field is replaced with "Deleted Contact"; the record is marked deactivated_at = now() with revoke_reason = erasure_request.
• Messages authored by the contact have their author_id and author_type nulled; the denormalised meta.actor_name is replaced with "Deleted Contact". Message content is preserved so the conversation history remains intelligible.
• Activity-log entries that carried the contact's name in their JSON payload have that field replaced with "Deleted Contact".

Detached but retained (the School owns these records)

• Issues (issues.roster_contact_id → null) — retained for the School's audit trail; required by several regulatory frameworks that apply to schools.
• Leave requests, consent responses, meeting bookings (each table's roster_contact_id → null) — retained as the School's own record of its decisions.
• Students (students.roster_contact_id → null) — the School owns the student record; it can be relinked to a new or returning guardian later.
• CSAT responses — already linked via issue only, never carried direct PII.

Automatic housekeeping on erasure approval

• All open issues for the contact are closed (status = closed, close_reason = contact_erased, assigned_user_id = null). Each closure is individually logged in the activity log, attributed to the approving administrator.
• All future meeting bookings held by the contact are cancelled (status = cancelled), freeing the slot. Each cancellation is individually logged.
• One summary activity-log entry of type privacy_erasure is written against the School record, including the contact's original name and email (for audit), the approving administrator, and counts of issues auto-closed and meetings cancelled.
• The data_privacy_requests row is transitioned from pending to completed, stamped with the responder's identity and timestamp.

Rollback, durability, and backups

• The entire erasure sequence runs inside a single transaction — any failure rolls back all changes, and the request is flagged failed for administrator retry.
• Database backups taken before the erasure will continue to contain the Data Subject's Personal Data until the backups age out (90-day rolling retention). On written request, ElifLammeem will confirm the oldest extant backup and the expected date at which the Data Subject's PII is fully expunged from backups.
• No reversal of an approved erasure is possible through normal operations. Restoration from a backup would require a joint decision by ElifLammeem and the School, and is reserved for disaster-recovery scenarios — not for undoing a legitimate erasure.

Records kept indefinitely (compliance trail)

• The data_privacy_requests row for the erasure itself — with the contact's name and email captured at the moment of the request, the reason, the approver, and the timestamp. This is the School's compliance evidence; it does not allow re-identification of anonymised downstream records.
• The privacy_erasure activity-log entry.

12. Liability

Each party's liability arising out of or related to this DPA is subject to the limitations of liability set out in the main subscription terms between the parties.

13. Governing law and disputes

This DPA is governed by the law specified in the main subscription terms. In the absence of a specified governing law, it is governed by the laws of the Islamic Republic of Pakistan. Disputes shall be resolved through good-faith negotiation, failing which the courts of Islamabad, Pakistan, have exclusive jurisdiction — without prejudice to the right of either party to seek urgent injunctive relief in any competent court.

14. Amendments

ElifLammeem may update this DPA from time to time to reflect changes in Sub-processors, security measures, or applicable law. Material updates will be notified to the School administrator by email at least 30 days before they take effect. Continued use of the service after the effective date constitutes acceptance.

Annex I — Details of Processing

Subject matter

Provision of the ElifLammeem multi-tenant SaaS platform to the School, including parent/teacher issue submissions, conversation threads, attachments, activity log, leave requests, circulars, parent-teacher meeting bookings, consent forms, CSAT surveys, and related AI-assisted triage.

Duration of Processing

For as long as the School's subscription is active, plus the return-or-deletion period in Section 11.

Nature and purpose of Processing

Storage, transmission, retrieval, display, analysis, and automated triage of Personal Data submitted to the platform, for the purpose of helping the School manage parent and teacher communications, record-keeping, and internal workflows.

Categories of Data Subjects

• Parents and legal guardians of students
• Teachers and staff of the School
• Students (indirectly, via parent records)
• School administrators and authorised staff using the admin panel

Categories of Personal Data

• Identity & contact data: name, email, phone, role, preferred language, school/student reference ID
• Child records: student name, grade, section, optional external ID
• Issue content: title, description, category, attachments, message threads, AI-generated summaries
• Leave-request content: student, leave type, dates, reason, optional attachments (may include medical certificates)
• Meeting bookings: slot selection, student, optional notes
• Consent responses: Approve/decline decisions per child, optional notes
• CSAT survey responses: 1–5 rating, timestamps
• Activity log: user/actor name, action, timestamp, subject reference
• Authentication data: hashed passwords, 2FA tokens (for admin accounts), random access codes (for parents/teachers)
• Technical data: IP addresses (for rate-limiting and security), server logs (90-day retention)

Special Category Data

Some Personal Data may constitute Special Category Data — most commonly:

• Health information, where a parent submits a sick-leave request with a medical certificate, or a health-and-safety issue containing medical context.
• Religious belief, where a parent submits a religious-leave request.

ElifLammeem applies additional safeguards to Special Category Data: attachments are stored privately and served through short-lived signed URLs; access is limited to authorised School staff; AI analysis of issue text strips personally identifying fields before transmission to AI Sub-processors.

Annex II — Security Measures

Encryption

• All network traffic to and from the platform is encrypted using TLS 1.2 or higher.
• Databases and file storage are encrypted at rest using AES-256 via AWS managed keys.
• Administrator passwords are hashed using bcrypt with a per-password salt. Plaintext passwords are never stored or logged.

Access control

• Role-based access control (Admin, Branch Manager, Staff) within each tenant, scoped at the query level.
• Branch-level scoping for branch managers and staff — cross-branch visibility is enforced server-side.
• Each tenant is isolated from every other tenant at the database row level via a tenancy middleware, with global scopes preventing accidental cross-tenant reads.
• Two-factor authentication available for admin accounts (plan-gated).
• Session-only storage of parent access codes — codes are not persisted in cookies and are cleared when the browser tab closes.
• Attachments served through short-lived signed URLs — never publicly indexable.

Platform hardening

• Access codes are 8-character random tokens; endpoints that accept codes are rate-limited (5–10 requests per IP per minute) to prevent brute-force enumeration.
• CSRF protection on all state-changing requests.
• Input validation on every public endpoint; file-upload MIME and size restrictions.
• Cross-site scripting (XSS) protection via Blade auto-escaping.
• SQL injection protection via parameterised queries (Eloquent ORM).
• Dependency security updates applied monthly or on critical advisories.

Personnel

• All personnel with access to production data are bound by confidentiality obligations.
• Production access is limited to documented incident-response and support scenarios.
• Each production access is logged.

Incident response

• Breach notifications issued to affected School administrators within 72 hours of discovery.
• Security alerts monitored continuously; elevated alerts escalated immediately.
• Post-incident review conducted for every confirmed incident.

Backups

• Daily automated backups of the production database.
• Backups encrypted at rest and retained for 90 days on a rolling basis.
• Restore procedures tested periodically.

Business continuity

• Infrastructure hosted on AWS with automated failover for critical services.
• Recovery Time Objective (RTO): 24 hours for a full region failure.
• Recovery Point Objective (RPO): 24 hours maximum data loss (aligned with backup cadence).

Annex III — Authorised Sub-processors

The following Sub-processors are authorised as of the date at the top of this DPA. ElifLammeem will notify the School at least 14 days in advance of any change to this list.

Each Sub-processor has been reviewed and is bound by a written contract that incorporates data-protection obligations substantively equivalent to those in this DPA, including applicable Standard Contractual Clauses for cross-border transfers.