Internal SOP for responding to PDPL data-subject-rights (DSR) requests from UAE pupils, parents, or staff.
Version: 1.1 Last updated: 1 June 2026 Owner: OMNIA Inclusion Ltd — Data Protection lead Statutory deadline: 30 days from receipt (PDPL Article 13)
This runbook is operational. It is not legal advice. For novel or contested requests, escalate to OMNIA's DP lead and the School's DPO.
Scope — rights covered
Under the UAE PDPL, data subjects have rights to:
| Right | PDPL article | Typical request |
|---|---|---|
| Access | Art. 13 | "Send me everything you hold about my child" |
| Correction | Art. 14 | "My address / DOB / diagnosis is wrong" |
| Erasure | Art. 15 | "Delete my child's record" |
| Restriction | Art. 16 | "Stop processing while I dispute X" |
| Object | Art. 17 | "Stop using my data for Y" |
| Portability | Art. 18 | "Send my data to another provider in a machine-readable format" |
| Withdraw consent | Art. 6 | "I no longer consent" |
Day 0 — Intake (within 1 working day)
- Acknowledge receipt by email to the data subject within 24 hours. Template: "We've received your request and will respond by [date + 30 days]. If we need to verify your identity, we'll contact you within 5 working days."
- Log the request in the internal DSR tracker with:
- Requestor name + relationship to data subject (self / parent / guardian)
- School (tenant ID)
- Right requested
- Date received
- Statutory deadline = received + 30 days
- Notify the School's DPO. OMNIA is the processor for school data — the School is the controller and leads the response. OMNIA assists (UAE Addendum §2.3(f)).
Day 1–5 — Identity verification
- For pupil/parent requests: verify via the School's existing parent contact channel. Do not verify identity solely via email.
- For staff requests: verify via School HR.
- For requests received directly by OMNIA (not via the School): redirect to the School DPO. Confirm to the requestor that this has been done.
Day 5–25 — Fulfilment
Access request
- Use the in-product DSAR export (Admin → Pupil → Export). Restricted to admin / SENCo / inclusion_lead roles.
- Export bundles: profile, plans, assessments, voice records, timeline, audit trail of who accessed the record.
- Review for third-party data (e.g. comments mentioning other pupils) — redact before release.
- Deliver via secure channel (encrypted ZIP + password by separate channel, or School's existing secure portal).
Correction request
- School admin makes the correction in-product.
- Audit log captures the change automatically.
- Confirm to data subject within deadline.
Erasure request
- Confirm with School DPO that erasure does not conflict with retention obligations (e.g. statutory pupil record retention).
- Use Erase pupil (Admin → Pupil → Erase). Restricted to admin / SENCo / inclusion_lead roles. Action is logged and irreversible.
- If retention obligation applies, restrict processing instead and inform the requestor.
Restriction / objection / consent withdrawal
- Disable the relevant processing surface (e.g. parent voice, AI suggestions).
- Tag the pupil record so future processing prompts the operator.
- Confirm to requestor.
Portability
- Run DSAR export in machine-readable format (JSON + CSV bundles).
- Deliver as access request above.
Day 25–30 — Close out
- Final response to data subject (via School DPO).
- Mark DSR ticket as closed in tracker with outcome + date.
- Retain DSR records for 3 years (audit trail).
BYOK (Bring Your Own Key) schools — note
Where the School has activated BYOK (available to every school), AI prompts and
responses are processed on the School's own Anthropic or Azure OpenAI
tenancy. OMNIA holds no copy. Any DSR scope covering AI-derived material
must be put to the School's own AI provider directly by the School
(controller). OMNIA assists by providing the date / scope / endpoint
records held in audit_logs.
Escalation triggers
Escalate to OMNIA DP lead and School DPO immediately if:
- The request involves a child welfare or safeguarding concern.
- Identity cannot be verified within 5 working days.
- Fulfilment will breach a retention obligation or court order.
- The request is from a UAE Data Office investigation or law-enforcement order.
- The request volume from a single requestor is abusive or systematic.
Refusal grounds
Requests may be refused under PDPL where:
- The request is manifestly unfounded or excessive (Art. 13(3)).
- Fulfilment would prejudice another data subject's rights.
- A statutory retention or legal-hold obligation applies.
Refusals must:
- Be in writing within the 30-day deadline.
- State the legal basis for refusal.
- Inform the requestor of their right to complain to the UAE Data Office (dataoffice.gov.ae).
Metrics (review quarterly)
- Number of DSR requests by type.
- Median time to acknowledge / fulfil.
- Number of escalations.
- Number of refusals + grounds.