Skip to main content

Morphee Data Breach Response Plan

DRAFT — Requires legal review before adoption.

This document was generated as part of GDPR compliance work (Art. 33, Art. 34). It must be reviewed by qualified legal counsel and adopted as an organizational policy.

Last updated: 2026-02-13

1. Purpose​

This plan establishes the process for detecting, containing, assessing, notifying, and remediating personal data breaches affecting Morphee users, in compliance with GDPR Articles 33 and 34.

2. Definitions​

  • Personal data breach (Art. 4(12)): A breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data.
  • Supervisory authority: The relevant data protection authority (e.g., CNIL for France, ICO for UK).
  • Data subjects: Morphee users whose personal data is affected.

3. Breach Response Team​

RoleResponsibilityContact
Incident Lead[To be assigned]Coordinates the response, makes notification decisions
Technical Lead[To be assigned]Investigates root cause, implements containment
Legal/DPOSébastien Mathieu (privacy@morphee.app)Assesses legal obligations, drafts notifications
Communications[To be assigned]Handles user and public communications

4. Detection​

4.1 Current Detection Capabilities​

  • Application logs (structured JSON via get_logger)
  • Database audit trail (PostgreSQL logs)
  • Authentication events (Supabase Auth logs)

4.2 Planned Detection Improvements​

  • Security event monitoring (Sentry or equivalent)
  • Failed authentication rate alerting
  • Anomalous data access pattern detection
  • Database query auditing for bulk data access
  • File integrity monitoring for Git memory repos

4.3 Reporting Channels​

Any team member who suspects a breach must immediately report to the Incident Lead via:

5. Response Procedure​

Phase 1: Containment (0-4 hours)​

  1. Confirm the breach — verify that personal data was actually compromised
  2. Contain the breach — take immediate action to stop ongoing data loss:
    • Revoke compromised credentials/tokens
    • Isolate affected systems
    • Block malicious IP addresses
    • Disable affected user accounts if necessary
  3. Preserve evidence — save relevant logs, database states, and system snapshots
  4. Assess scope — determine which data, users, and systems are affected

Phase 2: Assessment (4-24 hours)​

Evaluate the breach against the following criteria:

FactorAssessment
Nature of dataWhat types of personal data? (names, emails, conversations, AI memories, credentials)
VolumeHow many data subjects affected?
SensitivityDoes it include children's data, health info, or financial data?
ConsequencesRisk of identity theft, discrimination, financial loss, reputational damage?
ReversibilityCan the breach effects be reversed?
EncryptionWas the data encrypted? (reduces risk assessment)

Phase 3: Notification (24-72 hours)​

Supervisory Authority (Art. 33) — within 72 hours​

Must notify unless the breach is unlikely to result in a risk to rights and freedoms.

Notification must include:

  1. Nature of the breach (categories and approximate number of data subjects/records)
  2. Name and contact details of DPO or other contact point
  3. Likely consequences of the breach
  4. Measures taken or proposed to address the breach

How to notify:

Data Subjects (Art. 34) — without undue delay​

Must notify if the breach is likely to result in a high risk to rights and freedoms.

Notification must include:

  1. Description of the breach in clear and plain language
  2. Name and contact details of DPO or other contact point
  3. Likely consequences
  4. Measures taken or proposed, including mitigation steps users should take

How to notify:

  • Email to affected users
  • In-app notification banner
  • Privacy page update on the website

Exceptions to user notification (Art. 34(3)):​

  • Data was encrypted (unintelligible to unauthorized persons)
  • Subsequent measures ensure high risk is no longer likely
  • Individual notification would involve disproportionate effort (use public communication instead)

Phase 4: Remediation (1-4 weeks)​

  1. Root cause analysis — determine how the breach occurred
  2. Fix the vulnerability — implement technical/organizational fixes
  3. Review security measures — update security controls
  4. Update this plan — incorporate lessons learned
  5. Re-test — verify the fix prevents recurrence

6. Breach Register (Art. 33(5))​

All breaches must be logged, regardless of notification obligation.

Template​

FieldValue
Breach IDBREACH-YYYY-NNN
Date detected
Date occurred
Date contained
Description
Data categories
Data subjects affected
Approximate count
Risk assessmentLow / Medium / High
SA notifiedYes / No (with justification if No)
SA notification date
Users notifiedYes / No (with justification if No)
User notification date
Root cause
Remediation actions
Lessons learned

7. Morphee-Specific Risk Scenarios​

ScenarioRisk LevelData at RiskResponse Priority
Database compromiseCriticalAll user data (emails, names, conversations, memories)Immediate containment, rotate all credentials
Anthropic API key leakHighFuture conversations exposedRotate API key, audit recent API calls
Supabase Auth compromiseCriticalUser credentials, JWTsForce password resets, revoke all sessions
Git memory repo accessMediumAI-extracted memories per groupRevoke access, assess affected groups
Google OAuth token theftHighCalendar/email data for connected usersRevoke tokens, notify affected users
XSS/localStorage theftHighJWTs for active sessionsForce session invalidation
Push token interceptionLowDevice identifiersRotate affected tokens

8. Review Schedule​

This plan must be reviewed:

  • After every breach incident
  • At least annually
  • When significant system changes are made
  • When new data processing activities are added

This breach response plan was drafted on 2026-02-13 and requires legal review before adoption.