Breach Response Procedure

1. Scope & definitions

A personal-data breach is any event — accidental or deliberate — that leads to the unauthorised access, disclosure, alteration, loss, or destruction of personal data ElifLammeem processes on behalf of a school. Examples:

• A database dump leaks outside authorised personnel.
• An attacker obtains a valid admin or parent credential and reads data they shouldn't.
• A cloud-storage bucket misconfiguration exposes attachments to the internet.
• A laptop containing production credentials is lost or stolen.
• A sub-processor (e.g. Mailtrap, Twilio, AWS) reports a breach affecting our data.

2. Severity classification

Every suspected incident is triaged into one of three severities within the first hour. Classification drives the response clock.

Regardless of severity, every incident is logged, investigated, and documented.

3. Detection

Incidents reach the response team through any of the following channels:

• Automated monitoring — AWS CloudWatch alerts, application error spikes, unusual login patterns, failed rate-limit breakers.
• Customer report — a school admin emails szubair01@gmail.com or flags an issue through their admin panel.
• Sub-processor notification — AWS, Mailtrap, Twilio, Messagat, OpenAI, or Anthropic notifies us of a breach affecting their service.
• Independent researcher — a responsible-disclosure report (see the Security section on this site for our disclosure channel).

The person who receives a report acknowledges it within one business hour and opens an incident ticket. From that moment, the clock is running.

4. Immediate containment (first 2 hours)

1. Preserve evidence. Capture logs, take a snapshot of the affected database, record the reporter's details. Do not delete or overwrite.
2. Contain the blast radius. Revoke compromised credentials, rotate API keys, disable affected accounts or endpoints, scale a read-only replica in front of the primary if needed.
3. Stop the bleed. If a specific attack vector is open (exposed bucket, leaked token), close it before investigating further.
4. Inform the team. Even for a solo operator, create a written running log of every action taken — time-stamped. This is the audit artefact for regulators.

5. Investigation (hours 2 – 24)

Establish the facts needed to make a proportionate notification and a meaningful root-cause analysis:

• What data was involved? Tables, row counts, categories (identity / contact / special). Name / email / phone are PII; medical-leave attachments and health-and-safety complaint text may be special category.
• How many data subjects? Counts per tenant, per role (parent / teacher / staff / admin).
• Which schools are affected? Cross-tenant incidents are escalated to P1 automatically.
• When did the breach occur and when was it contained?
• What is the likely consequence? Was the data merely accessed, or exfiltrated? Is it public now?
• What caused it? Root cause identified to the level of "we can fix this so it doesn't recur."

6. School notification

Once the facts are established (or within the SLA above, whichever comes first), every affected school administrator receives an email directly from the privacy contact (szubair01@gmail.com) with:

• A clear description of the incident — no jargon, no downplaying.
• The types and approximate volumes of personal data involved.
• The approximate number of data subjects affected.
• The likely consequences for data subjects.
• The measures ElifLammeem has taken to contain and remediate the incident.
• What the school should do next — in particular, whether they need to notify their own supervisory authority (e.g. SDAIA in Saudi Arabia) and their own data subjects, and what text we suggest they use.
• A direct contact line for follow-up questions.

Where information is still being gathered, we issue a holding notice within the SLA and follow up with complete facts as soon as they are available — rather than delaying notification until the picture is complete.

7. Data subject notification

Notifying the affected parents, teachers, and students is the controller's responsibility (i.e. the school's), not ours. We provide the technical facts, a draft notification, and operational support so the school can issue the notice through its usual channels. If requested, we can send the notice via the platform's own email/SMS/WhatsApp delivery.

8. Sub-processor incidents

If a breach originates at a sub-processor (e.g. a bug in AWS, a compromise at Twilio), we:

1. Receive their notification and verify its scope against our account's exposure.
2. Apply the same classification criteria to determine our own response severity.
3. Relay the relevant facts to affected schools — including what the sub-processor has told us and what compensating controls we can apply on our side (e.g. rotating a compromised API key).
4. Hold the sub-processor to their contractual commitments and record the incident in our vendor risk register.

9. Remediation

Within seven days of initial detection, we publish an internal remediation plan with:

• A root cause we can explain in plain language.
• Specific technical or procedural changes that would have prevented the incident.
• Ownership and deadlines for each remediation item.
• A regression test or monitoring rule that would catch a recurrence automatically.

High-severity remediations (P1 / P2) are deployed as patches regardless of release cadence. Low-severity fixes ride the next scheduled release.

10. Post-incident review

No earlier than seven days and no later than thirty days after the incident is closed, we conduct a written review covering:

• The full timeline of events.
• What worked in the response, and what didn't.
• The root-cause analysis and its remediation status.
• Changes to this procedure (if any) that the incident revealed as necessary.
• An entry in the incident register — which we retain indefinitely as part of our compliance trail, alongside the data_privacy_requests audit log.

The written review is shared with affected schools on request, subject to redaction of information that would enable a further attack (e.g. specific vulnerability details until the fix is deployed across all tenants).

11. Record keeping

For every incident — P1 through P3, including near-misses — we keep the following records indefinitely:

• The original report and the acknowledgement we sent to the reporter.
• The running log of actions taken during containment and investigation.
• The notification emails sent to affected schools.
• The post-incident review document.
• The status of each remediation item (open / closed, with deploy date).

These records are our primary compliance evidence under GDPR Art. 33(5), Saudi PDPL equivalent, and Pakistan PDPA. They are disclosed to supervisory authorities on request.

12. Who to contact

Suspected or confirmed breach: szubair01@gmail.com. Please use the subject line [SECURITY] Suspected breach so it is prioritised immediately.