Data Breach Response Plan

[PLATFORM PROVIDER] — Event PlatformGDPR Articles 33 & 34Last Updated: [DATE]

---

1. Purpose and Scope

This Data Breach Response Plan defines procedures for detecting, containing, investigating, and responding to personal data breaches affecting the [PLATFORM PROVIDER] event platform.

Definitions (GDPR Art 4(12)):

• Personal Data Breach: A breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored, or otherwise processed.

Examples:

• Unauthorized access to customer databases (PostgreSQL, Firestore)
• Ransomware encrypting production data
• Accidental exposure of PII (misconfigured Firestore, Realtime Database or Cloud Storage security rules)
• Lost/stolen laptop containing unencrypted database backups
• Insider threat (malicious employee exfiltrating data)
• Third-party breach (sub-processor such as Railway Corp. or Google LLC compromised)
• Platform misconfiguration that disables authentication, so that requests are trusted on the strength of caller-supplied headers or unverified tokens (see Section 5.2, Scenario 5)
• Compromise of, or interception at, the reverse proxy that terminates TLS for attendee traffic (Cloudflare, Inc.), through which every attendee registration submission passes in plaintext

Scope: Applies to all personal data processed by [PLATFORM PROVIDER] as Data Processor on behalf of customer organizations (Data Controllers).

Objectives:

1. Detect breaches quickly (minimize exposure window)
2. Contain breach (prevent further unauthorized access)
3. Assess impact (how many Data Subjects affected, what data)
4. Notify affected parties (customers within 24h, supervisory authority within 72h if required)
5. Remediate root cause (prevent recurrence)

---

2. Roles and Responsibilities

Incident Response Team (IRT)

Role	Responsibilities	Contact
Incident Commander	Overall incident coordination, decision-making, escalation	CTO ([Email], [Phone])
Technical Lead	Technical investigation, containment, remediation	Senior Backend Engineer ([Email], [Phone])
Legal Counsel	Legal obligations, notification drafting, supervisory authority liaison	External Lawyer ([Firm Name], [Email], [Phone])
Data Protection Officer (DPO)	GDPR compliance oversight, risk assessment, supervisory authority contact	[Name, Email, Phone] (if appointed)
Communications Lead	Customer notifications, public statements (if needed), media relations	CEO ([Email], [Phone])
Customer Success	Customer support, fielding inbound inquiries, reassurance	Customer Success Manager ([Email])

Escalation and Availability

• Primary: Technical Lead, contacted directly using the details in Section 7. No paging platform is provisioned and no rotation schedule is maintained in any system of record, so escalation is manual and out-of-hours contact depends on reaching a named individual directly.
• Escalation: Incident Commander (CTO), contacted by telephone.
• The roles in the table above are functions, not a guarantee of distinct individuals. Where one person holds more than one role, that fact and any compensating review must be recorded in the incident record.
• The divergence between this position and the arrangements described in earlier versions of this plan is recorded in the note at Section 3.1.

---

3. Detection and Reporting

3.1 Detection Mechanisms

Monitoring and alerting. The platform emits structured application logs to standard output, which the hosting provider retains and makes searchable, and exposes an administrator-only system-health endpoint reporting request counters and database read counters. Those counters are held in process memory and reset on every restart or deployment. There is no error-tracking service, no on-call paging integration and no automated alerting: incident detection depends on a person observing logs, the health endpoint or a customer report.

Detection in practice. Detection is manual and reactive. It occurs through:

• Security researcher disclosure (responsible disclosure via [email protected])
• Customer report (unusual activity in their org's data)
• Staff observation (suspicious behaviour, unexpected data access, review of application logs)
• Third-party notification (sub-processor breach, or a notice appearing in a hosting provider's own console)

Detection latency. Because no channel is monitored automatically, an incident that produces no customer-visible symptom may go undetected until a person reads the application logs or the security mailbox. The 72-hour period in GDPR Art 33(1) runs from the moment [PLATFORM PROVIDER] becomes aware of a breach, so the exposure window preceding awareness may be materially longer than the notification window that follows it. That must be stated plainly in any notification to a controller or to the supervisory authority, and the impact assessment must proceed on a worst-case basis for the whole period during which the condition existed, not only for the period after it was noticed.

GAP-PROC-02 · PROCESS — KNOWN GAP, REMEDIATION PENDING

Earlier versions of this plan described a detection and alerting tier consisting of automated hosting-provider and Firebase security alerts, a centralised log-analysis capability, an incident chat channel that alerted the response team automatically, a paging rotation and a security mailbox monitored around the clock. None of that infrastructure exists: the platform has no error-tracking service, no paging integration, no incident chat channel and no automated alerting of any kind, and the two-hour and four-hour acknowledgement targets stated in earlier versions were supported by no monitored channel and by no measurement. Detection today is manual and reactive, as described above, and the tooling entries in Section 6.1 have been corrected accordingly. This divergence is recorded on the compliance remediation register and is under review.

3.2 Reporting Channels

Internal Reporting (Staff):

• Email: [email protected]
• Telephone: the Technical Lead or the Incident Commander, using the details in Section 7. This is the only channel that reaches a person while the mailbox is not being read.

External Reporting (Researchers, Customers):

• Email: [email protected]
• Web Form: (future) https://restartix.ro/security-disclosure
• Acknowledgement: a report is acknowledged when the mailbox is next read. Nothing routes an inbound report to a person automatically, so a report arriving outside working hours may not be seen until the next working day. No acknowledgement service level is currently supported by a monitored channel; see the note at Section 3.1.

Mandatory Reporting (Staff Obligation):

• All staff MUST report suspected breaches immediately (no waiting, no self-investigation)
• "If you see something, say something" — better false alarm than delayed response
• No retaliation for good-faith reports

---

4. Incident Response Phases

Phase 1: Detection and Initial Assessment (0-2 hours)

Actions:

1. Report Received: a report reaches [email protected], a member of staff or a customer raises the matter directly, or a sub-processor gives notice. There is no automated alert (Section 3.1).
2. Assemble Team: Incident Commander contacts the IRT by telephone and email within 30 minutes.
3. Confirm Breach: Is this a real security incident or false positive?
   • Review logs, within their limits. The HTTP access log records the request method, the full request path including its query string, the response status, the latency, a client IP address and a request identifier. It does not record the organisation identifier, the acting user or the user agent, so it cannot on its own establish who accessed what. Request-level attribution exists only for staff actions written to the audit log; public, attendee, service-to-service and webhook traffic leaves no per-request record of the actor.
   • Check system status (hosting provider and Firebase consoles)
   • Interview reporter (if staff/customer report)
4. Initial Classification:
   • Severity: Low / Medium / High / Critical
     • Critical: Plaintext PII exposed publicly, large-scale exfiltration (>10,000 Data Subjects)
     • High: Unauthorized access to production database, ransomware
     • Medium: Unauthorized access to single customer's data (<1,000 Data Subjects)
     • Low: Attempted breach (blocked by security measures), no data exfiltration
   • Scope: How many customers affected? How many Data Subjects?
   • Data Categories: What types of personal data? Enumerate them against the storage-layer checklist in Phase 3, item 2, rather than from memory.
5. Activate Plan: Incident Commander declares incident level, assigns roles

Decision Point: If not a personal data breach (e.g., DDoS attack, service outage, no PII involved) → escalate to standard IT incident response (not this plan). If yes → proceed to Phase 2.

---

Phase 2: Containment (2-6 hours)

Goal: Stop the bleeding — prevent further unauthorized access or data loss.

Immediate Actions:

1. Isolate Affected Systems:

   • If database compromised: Revoke compromised credentials, rotate database passwords
   • If API vulnerable: Deploy firewall rules to block attacker IP ranges
   • If ransomware: Shut down affected servers (Railway: stop deployment, isolate database)
   • If misconfigured security rules: Fix Firestore/RTDB rules, deploy immediately (firebase deploy --only firestore:rules,database)

2. Preserve Evidence:

   • Do NOT delete logs (needed for forensics)
   • Export the application logs from the hosting provider's log store to a location outside the platform's own infrastructure, and do so as a first action. Retention of those logs is governed by the hosting provider's own retention window and not by [PLATFORM PROVIDER], so evidence is lost by expiry if the export is deferred.
   • Do not use the platform's own Cloud Storage bucket as the evidence store. Its security rules end in a catch-all granting read and write access to any authenticated user, and the organisation-scoped paths above that catch-all are unconditionally readable without authentication (Section 5.2).
   • Handle exported logs as sensitive material in their own right. The access log records the full request path including the query string, so any credential transmitted as a query parameter — the funnel webhook secret, for example — is present in the exported file.
   • Take a database snapshot before making any change.
   • Screenshot affected systems, attacker tools, error messages
   • Caveat on attribution. The IP address recorded on audit-log entries is taken from client-supplied forwarding headers, which are accepted without trusted-proxy validation and can therefore be set by the caller. It must not be presented to a customer or to ANSPDCP as reliable evidence of the origin of a request.

3. Revoke Access:

   • Compromised credentials: Reset passwords for all affected accounts (Firebase Authentication, hosting provider, source-code hosting)
   • Attendee authentication: where the attendee application is in scope, remove the app-store review demo configuration as a first containment step. That configuration allows one specified email address to sign in to the attendee application with a fixed code, bypassing the emailed one-time code entirely and minting a full authentication token. It does not expire, is intended to be set in production, and leaves no audit-log entry — only a warning line in the application log.
   • Platform secrets — rotate as a named inventory: the connection strings for both the privileged and the restricted database roles, the service-to-service shared secret, the Firebase service-account credential, the Firebase Web API key, the model-provider API key, and the app-store review demo credentials. All are held as environment variables on the hosting platform, so rotation is a configuration change followed by a redeployment.
   • Per-organisation integration secrets: rotate the credentials held in Google Secret Manager for each affected organisation, covering the messaging, email, content-delivery and advertising integrations. Where the SMS messaging provider is in scope, its credentials must additionally be assumed to be present in that provider's own request logs, because the account username and password are transmitted as URL query-string parameters on every send.
   • Firebase service accounts and third-party console logins: rotate and review access.
   • Suspicious staff accounts: Suspend access pending investigation (if insider threat suspected)

4. Close Attack Vector:

   • Patch vulnerable code (deploy hotfix to production)
   • Update dependencies (if CVE in npm package, Go module)
   • Disable vulnerable feature (if fix takes >24h, temporarily disable feature to stop exploit)

Timeline: Containment complete within 6 hours of initial alert (critical incidents: 2 hours).

Communication During Containment:

• Incident Commander provides updates to the IRT every 30 minutes, by telephone or email; no incident chat channel is provisioned (Section 6.1)
• NO external communication yet (customers not notified until assessment complete)

---

Phase 3: Assessment and Notification (6-24 hours)

Goal: Determine impact and notify affected parties.

3.1 Impact Assessment

Questions to Answer:

1. How many Data Subjects affected?

   • PostgreSQL holds no per-row read record. The contact table has no last-access column, so the scope of an incident cannot be derived from the contact records themselves. Staff-side access is reconstructed from the audit log, which records, for each audited staff action, the organisation, the acting user and role, the action, the target, the metadata, an IP address and a timestamp — including contact views, segment-member views and contact and segment exports. Select the audited actions falling inside the exposure window and derive the affected organisations from them.
   • Everything else is unattributable. For any path that does not go through the staff dashboard — public, attendee, service-to-service and webhook traffic — no per-row read record exists. Scope must then be inferred from the privileges of the compromised credential or from the reach of the misconfigured rule, and assessed on a worst-case basis.
   • Realtime Database: there is no per-read audit log for the Realtime Database and none can be produced retrospectively. Any exposure of live-session data must be assessed on the assumption that everything readable under the affected rule was read.
   • Firestore and Cloud Storage: per-document read logging requires Cloud Audit Data Access logs, which are disabled by default and are not provisioned in the platform's current configuration. Unless that has changed by the time of the incident, no record of individual document reads exists and the same worst-case basis applies.

   The worst-case scope of a live-session exposure is wide, because that data is never pruned:

   Live-session data in the Realtime Database is retained indefinitely. There is no scheduled cleanup function: the Cloud Functions codebase exports ten functions, of which nine are database triggers and one is a minutely presence reconciler, and none deletes session data. Moving a session to replay or archived status does not prune it either — the lifecycle job writes a statistics snapshot to Firestore and performs no deletion in the Realtime Database. The only operations that remove a live-session node are the manual deletion of a session and the manual deletion of the parent webinar. Chat message text, attendee display names, presence and attendance records, poll votes, reactions, offer clicks and feedback responses therefore persist for the lifetime of the webinar record.

GAP-PROC-07 · PROCESS — KNOWN GAP, REMEDIATION PENDING

Earlier versions of this plan directed the responder to scope an incident from a database column recording each contact's last access, from Realtime Database access logs, and from Firestore audit logs showing who read which documents. None of those sources exists: the contact table has no such column, the Realtime Database has no per-read audit log, and Cloud Audit Data Access logging is not provisioned on the production project. Scope must instead be reconstructed from the audit log for staff actions and assessed on a worst-case basis for every other access path. This divergence is recorded on the compliance remediation register and is under review.

2. What data was accessed/exfiltrated?

   • Confirmed exfiltration: Attacker downloaded data (network egress spike, provider-side evidence)
   • Potential access: Attacker had credentials but uncertain if data copied (assume worst case)
   • Categories: do not work from a fixed list in this plan. The authoritative inventory of the personal data the platform processes is the Record of Processing Activities (ROPA), read together with the Data Retention Policy. Enumerate the affected categories from those documents, so that the figures given under Art 33(3)(b) and (c) do not drift as the product changes.
   • Storage layers to enumerate, one at a time:
     • PostgreSQL — contact and registration records, consent records, behavioural events, funnel entries (campaign attribution, device and approximate-location data, webhook payloads and purchase data received from a customer's store), funnel page views (a persistent pseudonymous visitor identifier derived from the visitor's IP address and user agent), SMS delivery records, segment-broadcast recipient records, automation enrolments and step-execution records, AI generation jobs, the audit log and the data-subject request register.
     • Firestore — contact PII (plaintext email address, name and telephone number), registration documents and their PII subcollection, consent records, verification codes and magic links.
     • Realtime Database — the live-session nodes: the chat stream, the moderated-removed stream (which retains the original message text and its author), the actor directory holding attendee display names, presence, attendance, poll votes, reactions, offer clicks, feedback responses, per-actor message counts, and the identity cache mapping an anonymous actor identifier to the hash of an email address.
     • Cloud Storage — organisation media, branding, landing-page assets, page templates and staff uploads.
     • Application logs held by the hosting provider — including plaintext email addresses written by the bulk import, staff-invitation and attendee-authentication paths, and full request paths including query strings.
     • The API's in-process cache of contact PII — see item 4 below.

3. Which customers (orgs) affected?

   • List all org_id values in affected data
   • Prioritize notification (largest customers first, most sensitive data)

4. Was data encrypted or pseudonymised?

   • At rest: Yes (PostgreSQL, Firestore encrypted) BUT attacker with database access sees plaintext (encryption protects against disk theft, not authorized-but-malicious access)
   • In transit: If attacker intercepted network traffic, was TLS enabled? (assume yes, all connections TLS 1.2+)
   • Pseudonymisation — the general position: No PostgreSQL table holds a plaintext email address, telephone number or personal name. Contacts are keyed by an SHA-256 hash of the lowercased, trimmed email address, and plaintext contact details are held only in Firestore at orgs/{orgId}/contacts/{emailHash}/pii/private.
   • The exception: Two exceptions apply. First, the automations engine records the outcome of each executed step as a JSON document in PostgreSQL, and for email and SMS steps that document includes the recipient's plaintext email address or telephone number; those records are removed when the contact is deleted, by cascade, but they are not otherwise pseudonymised. Second, the ai_jobs table stores the full prompt text of each AI generation, which may contain an approved attendee testimonial together with the name and company recorded on it; those rows carry no contact link and are not removed on erasure.
   • In-process cache: The API holds an in-process cache of plaintext contact details (email address, name and telephone number), keyed by organisation and email hash, to avoid repeated Firestore reads. The cache has no expiry, and entries are invalidated only within the process that performs the write. Where more than one API instance is running, a correction or a deletion applied on one instance does not evict the copy held by another.
   • Application logs: plaintext email addresses are written to the hosting provider's log store by the bulk import, staff-invitation and attendee-authentication paths.
   • Strength of the pseudonym: the email hash is an unsalted SHA-256 of the lowercased, trimmed email address, so it can be recomputed by anyone who knows the address, and the Firestore rules permit any authenticated principal to fetch the contact PII document held at that path. The hash must therefore be treated as a lookup key, not as a measure that renders the data unintelligible.
   • Consequence for the assessment: a compromise confined to PostgreSQL must still be assessed as a plaintext-PII compromise unless the automation step-execution records, the in-process cache and the application logs are all demonstrably out of scope. Establish which stores were in scope case by case; do not carry a standing conclusion into the assessment.

5. Likelihood of harm to Data Subjects?

   • High risk: Plaintext email + name + chat messages exposed publicly (risk of phishing, harassment, reputational damage)
   • Medium risk: Email + name only (risk of spam, phishing)
   • Low risk: Email hashes alone, and only where it has been established that no plaintext store was in scope — Firestore contact PII, automation step-execution records, the in-process PII cache and the application logs — and that the attacker holds no list of candidate addresses from which the hashes could be recomputed. This is a conclusion to be reached on the facts of the incident; it must never be assumed from the fact that the affected store was PostgreSQL.

GAP-SEC-03 · CODE — KNOWN GAP, REMEDIATION PENDING

Earlier versions of this plan reasoned that a PostgreSQL compromise exposed only email hashes, treated that as a low-risk outcome, and relied on hashing as an Art 34(3)(a) safeguard capable of removing the obligation to notify data subjects. PostgreSQL is not hash-only — automation step-execution records hold the recipient's plaintext email address and telephone number — the API holds an unexpiring in-process cache of plaintext contact details, plaintext email addresses reach the hosting provider's log store, and the hash itself is an unsalted SHA-256 of the address that anyone knowing the address can recompute. Both the risk conclusion and the availability of the Art 34(3)(a) exemption must therefore be established on the facts of each incident. This divergence is recorded on the compliance remediation register and is under review.

3.2 Notification Decision Matrix

Scenario	Notify Customers (Controllers)?	Notify Supervisory Authority (ANSPDCP)?	Notify Data Subjects?
Unauthorized access, <250 Data Subjects, email+name only, no exfiltration confirmed	✅ Yes (within 24h)	❌ No (low risk, not likely to result in risk to rights and freedoms)	❌ No (customer decides)
Unauthorized access, >1,000 Data Subjects, email+name+chat messages, exfiltration likely	✅ Yes (within 24h)	✅ Yes (within 72h of becoming aware)	⚠️ Customer decides (but Art 34 likely requires it due to high risk)
Ransomware encrypts backups, production data intact, no access to plaintext	✅ Yes (within 24h, transparency)	✅ Yes (within 72h, loss/destruction of data)	❌ Probably no (data not disclosed to unauthorized party)
Firebase security rules misconfigured for 2 hours, fixed immediately; no read log exists that could either confirm or exclude access	✅ Yes (within 24h, even if no access is detected)	⚠️ Assess on the worst case: absence of a read log is not evidence that no access occurred, so if access was possible → Yes	⚠️ Customer decides, on the worst-case scope rather than on confirmed access
A sub-processor (for example Railway Corp.) notifies us of a breach affecting our data	✅ Yes (immediately upon the sub-processor's notice)	✅ Yes (within 72h of becoming aware via the sub-processor)	⚠️ Customer decides (depends on the scope of the sub-processor's breach)

GDPR Art 33 (Notify Supervisory Authority):

• Trigger: Breach is likely to result in a risk to Data Subjects' rights and freedoms
• Timeline: 72 hours from becoming aware (not from occurrence, from discovery)
• Exemption: If breach is unlikely to result in risk (e.g., encrypted data, no keys compromised)

GDPR Art 34 (Notify Data Subjects):

• Trigger: Breach is likely to result in a HIGH risk to Data Subjects' rights and freedoms
• Timeline: Without undue delay
• Exemptions:
  • Appropriate safeguards applied (e.g., encryption at rest, where the keys were not themselves compromised). Hashing of email addresses does not qualify as implemented: the hash is an unsalted SHA-256 of the lowercased address and can be recomputed from any known address, so it does not render the data unintelligible within the meaning of Art 34(3)(a). See item 4 of the impact assessment above.
  • Measures taken to reduce risk (e.g., forced password reset, free credit monitoring)
  • Disproportionate effort (>10,000 Data Subjects → public communication instead of individual emails)

[PLATFORM PROVIDER] Responsibility vs Customer Responsibility:

• [PLATFORM PROVIDER] (Processor): Notifies customers (Controllers) within 24h, provides all details
• Customer (Controller): Decides whether to notify supervisory authority and Data Subjects ([PLATFORM PROVIDER] assists with info)
• Exception: If breach originates from [PLATFORM PROVIDER] systems AND affects multiple customers, [PLATFORM PROVIDER] may directly notify ANSPDCP (with customer coordination)

3.3 Customer Notification (Within 24 Hours)

Notification Method:

• Email: There is no registered security-contact field on the organisation record and no setting through which a customer can nominate one. Notification is therefore addressed to the email addresses of the organisation's administrator users, taken from the staff user records for that organisation. Where a customer has given a different contact in correspondence, that address is used in addition, not instead.
• Telephone: For critical incidents (>10,000 Data Subjects), the Incident Commander calls the largest affected customers, using contact details held outside the platform.

There is no in-product incident banner and no customer-facing breach screen. Every artefact described below — the notification email, the forensic report and the list of affected data subjects — is produced and delivered manually.

GAP-PROC-08 · PROCESS — KNOWN GAP, REMEDIATION PENDING

Earlier versions of this plan directed the responder to a registered security-contact address held on the organisation record, to a red incident banner in the dashboard, and to a "Settings → GDPR → Breach Report" screen from which a customer could export the list of affected data subjects. None of the three exists: the organisation record has no security-contact field, no incident banner is implemented, and the dashboard has no breach-reporting screen. Notification and the affected-subject list are produced manually, as set out in this section. This divergence is recorded on the compliance remediation register and is under review.

Email Template:

Subject: URGENT — Personal Data Breach Notification

Dear [Customer Organization Name],

We are writing to inform you of a personal data breach affecting your organization's data on the [PLATFORM PROVIDER] event platform.

INCIDENT SUMMARY:
- Date/Time Detected: [YYYY-MM-DD HH:MM UTC]
- Nature of Breach: [Unauthorized access / Ransomware / Misconfiguration / etc.]
- Affected Data Categories: [enumerate from the Record of Processing Activities; e.g. email, name, phone, chat messages, poll votes]
- Estimated Data Subjects Affected: [Number]
- Exfiltration Confirmed: [Yes / No / Uncertain]

DETAILS:
[2-3 paragraph description of what happened, how attacker gained access, what data was exposed]

CONTAINMENT ACTIONS TAKEN:
- [Action 1: e.g., Revoked compromised credentials]
- [Action 2: e.g., Patched vulnerability in API]
- [Action 3: e.g., Deployed firewall rules]
- Containment completed: [YYYY-MM-DD HH:MM UTC]

YOUR OBLIGATIONS (Data Controller):
Under GDPR Article 33, you must assess whether this breach requires notification to your supervisory authority (within 72 hours of receiving this notice).

Under GDPR Article 34, you must assess whether Data Subjects must be notified (if high risk to their rights and freedoms).

[PLATFORM PROVIDER] recommends: [Our assessment: Notify / Do Not Notify — with reasoning]

ASSISTANCE FROM [PLATFORM PROVIDER]:
- Detailed forensic report: Attached (PDF)
- List of affected Data Subjects: Attached (CSV), prepared for your organisation
- Legal support: Our external counsel is available to consult (contact [email protected])

ROOT CAUSE AND PREVENTION:
[Brief description of why it happened and what we're doing to prevent recurrence]

CONTACT:
Incident Commander: [Name, Email, Phone] (available 24/7 during incident)
Support: [email protected]

We sincerely apologize for this incident and are committed to preventing future occurrences.

Sincerely,
[Incident Commander Name]
CTO, [PLATFORM PROVIDER]

Attachments:

• Forensic report (PDF): Timeline, affected data, containment actions, root cause
• CSV export: List of affected Data Subjects, for the customer's own notification. There is no self-service export. The file is produced by an operator, by selecting the affected records in PostgreSQL — which yields the email hash and the registration identifier — and resolving each contact's plaintext email address and name from Firestore, which holds the only copy of them. The delivered file contains, for each subject, the email address, the name where one was given, the email hash and the registration identifier.

3.4 Supervisory Authority Notification (Within 72 Hours)

If required (per decision matrix above):

Authority: ANSPDCP (National Authority for the Supervision of Personal Data Processing, Romania) Contact: [email protected], https://www.dataprotection.ro/en/notification-form

Notification Method:

• Online form: ANSPDCP website (preferred)
• Email: [email protected] (if form unavailable)
• Phone: [ANSPDCP emergency hotline] (critical incidents)

Information to Provide (GDPR Art 33(3)):

1. Nature of the breach:

   • Description: [Unauthorized access / Ransomware / Misconfiguration]
   • Date/time of occurrence (if known): [YYYY-MM-DD HH:MM]
   • Date/time [PLATFORM PROVIDER] became aware: [YYYY-MM-DD HH:MM]

2. Categories and approximate number of Data Subjects:

   • Categories: Event attendees, customer staff users
   • Number: [e.g., 15,000 attendees across 50 organizations]

3. Categories and approximate number of personal data records:

   • Categories: enumerate from the Record of Processing Activities and from the storage-layer checklist in the impact assessment above, not from a fixed list in this plan. Depending on scope this may include registration and contact data (email address, name, telephone number), consent records, live-session content (chat messages including moderated-removed messages, poll votes, reactions, feedback, display names, presence and attendance), behavioural events, funnel attribution together with device and approximate-location data, a persistent pseudonymous visitor identifier for landing-page visitors, purchase data received from a customer's e-commerce store, SMS delivery records, segment-broadcast recipient records, automation step-execution records containing plaintext email addresses and telephone numbers, AI generation prompts and outputs containing approved attendee testimonials, and audit-log entries recording IP addresses and user agents.
   • Records: [e.g., 15,000 contact records, 50,000 behavioral event records]

4. Name and contact details of DPO (if applicable):

   • [DPO Name, [email protected], Phone]

5. Likely consequences:

   • Risk of phishing attacks (email addresses exposed)
   • Risk of reputational damage (chat messages exposed)
   • Risk of identity theft (if combined with other datasets)

6. Measures taken or proposed:

   • Immediate: Revoked credentials, patched vulnerability, forced password reset
   • Short-term: Security audit, penetration testing
   • Long-term: Enhanced monitoring, additional encryption layer, staff training

7. If notification >72h, explain delay:

   • [Reason: Ongoing investigation to determine scope, consulted legal counsel, etc.]

Follow-up: If initial notification incomplete (e.g., still assessing scope), submit phased notifications:

• Phase 1 (within 72h): Preliminary notification with known facts
• Phase 2 (within 7 days): Updated notification with full impact assessment

3.5 Data Subject Notification (If Required)

[PLATFORM PROVIDER] Role: Provide customer with tools to notify Data Subjects (customer makes final decision)

How the list of affected Data Subjects is produced: manually, as described under Customer Notification above. There is no dashboard breach-reporting screen and no self-service export: an operator selects the affected records in PostgreSQL, resolves the plaintext email address and name from Firestore, and delivers the file to the customer together with the notification.

Customer's Notification Template ([PLATFORM PROVIDER] provides):

Subject: Important Security Notice — Your Event Registration Data

Dear [First Name],

We are writing to inform you of a security incident that may have affected your personal data.

WHAT HAPPENED:
On [date], our event platform provider ([PLATFORM PROVIDER]) experienced a data breach. Unauthorized individuals may have accessed your registration information.

WHAT DATA WAS AFFECTED:
- Your email address: [email]
- Your name: [name]
- [If applicable: Chat messages you sent during events, poll votes, etc.]

WHAT WE ARE DOING:
- The breach has been contained and the vulnerability patched.
- We are conducting a full security review.
- We have reported this to the appropriate supervisory authority.

WHAT YOU CAN DO:
- Be vigilant for phishing emails (we will never ask for your password or payment info via email)
- Monitor your accounts for suspicious activity
- If you reused your event name/email elsewhere, consider changing passwords on those accounts

QUESTIONS:
Contact us at [[email protected]] with any concerns.

We sincerely apologize for this incident and are committed to protecting your data.

Sincerely,
[Your Organization Name]

---

Phase 4: Remediation and Recovery (24 hours - 2 weeks)

Goal: Fix root cause, restore normal operations, prevent recurrence.

4.1 Root Cause Analysis (RCA)

Framework: 5 Whys Example:

1. Why did attacker gain access? → Weak password on Railway database
2. Why was password weak? → Generated manually by engineer (not auto-generated strong password)
3. Why manual generation? → No password policy enforced in Railway
4. Why no policy? → Onboarding checklist didn't include "enforce MFA + strong passwords"
5. Why no checklist? → Informal onboarding process, no written security standards

Root Cause: Lack of formal security onboarding checklist

Corrective Action: Create mandatory security checklist (MFA, password manager, least privilege), enforced before production access is granted

4.2 Remediation Actions

Vulnerability management. Dependency and vulnerability scanning is performed manually. There is no continuous integration pipeline in the repository, no automated dependency-update service and no automated security scanning of commits, dependencies or container images. Vulnerabilities are identified through manual review of dependency advisories and through the security notices published by the hosting providers and the framework maintainers, and are remediated by a developer raising and deploying the change directly. Any remediation step below that depends on a vulnerability being detected must therefore be planned as a manual review, not as the output of a pipeline.

Immediate (within 48 hours):

• [ ] Patch vulnerability (deploy code fix to production)
• [ ] Rotate all credentials from the named inventory in Phase 2 (database connection strings, service-to-service shared secret, service-account credential, API keys, app-store review demo credentials, per-organisation integration secrets)
• [ ] Force password reset for all staff users (if auth system compromised)
• [ ] Add logging on the affected path and define, in writing, what a person must look for and how often; note that no automated alerting exists (Section 3.1), so additional logging changes what can be found after the fact, not what is detected in the moment

Short-term (within 2 weeks):

• [ ] Conduct security audit (internal or external consultant)
• [ ] Penetration testing (re-test patched vulnerability + broader scan)
• [ ] Review and update security policies (password policy, access control, MFA enforcement)
• [ ] Staff re-training (security awareness, incident reporting)

Long-term (within 3 months):

• [ ] Implement enhanced security measures (e.g., database encryption with customer-managed keys, centralised log analysis, intrusion detection)
• [ ] Achieve security certification (ISO 27001, SOC 2 Type II)
• [ ] Bug bounty program (incentivize responsible disclosure)

The three long-term items above are objectives, not controls in place. No security certification has been obtained, no bug bounty programme is operated, and no centralised log-analysis or intrusion-detection capability exists. None of them may be represented to a customer, to a data subject or to a supervisory authority as an existing measure.

4.3 System Recovery

Data Restoration (if needed):

• Restore from the last clean backup taken before the incident, using the backup facilities of the hosting provider and of Firebase
• Verify backup integrity (scan for malware, verify data completeness)
• Incremental recovery (restore production database from backup, replay transaction logs)

Timeline: RTO (Recovery Time Objective) = 4 hours, RPO (Recovery Point Objective) = 24 hours (maximum data loss). These are objectives, not validated figures. No restore runbook is maintained, no restore has been performed and timed against production data, and no scheduled job exercises one, so recovery must be treated as best-effort until a timed restore has been carried out and its result recorded.

GAP-PROC-04 · PROCESS — KNOWN GAP, REMEDIATION PENDING

Earlier versions of this plan presented the four-hour recovery time objective and the twenty-four-hour recovery point objective as commitments, and the evaluation criteria in Section 5.2 assumed a restore could be exercised against them. No documented restore procedure exists, no restore has been performed and timed against production data, and no scheduled job exercises one, so neither objective is evidenced. Ransomware is the first scenario this plan contemplates, which makes an unvalidated restore path the widest gap between this document and an actual incident. This divergence is recorded on the compliance remediation register and is under review.

Service Resumption:

• Phased rollout (restore staging → test → production)
• Customer communication: "Services restored, breach contained, security enhanced"

---

Phase 5: Post-Incident Review (customer report within 14 days; internal review 2-4 weeks)

Goal: Learn from incident, improve defenses, demonstrate accountability.

5.1 Post-Incident Report

Deadline: the customer-facing incident report is due within 14 days of becoming aware, as committed in Section 9.1 of the Data Processing Agreement. The internal lessons-learned process may continue after that date, but must not delay the report to customers.

Sections:

1. Executive Summary (1 page)
   • What happened, impact, resolution, lessons learned
2. Timeline (detailed)
   • [YYYY-MM-DD HH:MM] - Breach occurred (estimated)
   • [YYYY-MM-DD HH:MM] - Breach detected
   • [YYYY-MM-DD HH:MM] - IRT convened
   • [YYYY-MM-DD HH:MM] - Containment complete
   • [YYYY-MM-DD HH:MM] - Customers notified
   • [YYYY-MM-DD HH:MM] - Supervisory authority notified
   • [YYYY-MM-DD HH:MM] - Remediation complete
3. Root Cause Analysis (5 Whys)
4. Impact Assessment (Data Subjects affected, data categories, exfiltration confirmed)
5. Response Effectiveness (what worked, what didn't)
6. Corrective Actions (completed + planned)
7. Recommendations (process improvements, security enhancements)

Distribution:

• Internal: All staff (anonymized if sensitive)
• Customers: Provided to every affected customer within 14 days of becoming aware, per Section 9.1 of the Data Processing Agreement, redacted only so far as the confidentiality of other customers requires; provided to other customers on request
• Supervisory Authority: If requested during investigation

5.2 Lessons Learned Session

Participants: IRT + all engineering team Format: Blameless post-mortem (no finger-pointing, focus on systems and processes)

Discussion:

• What went well? (e.g., fast detection, clear roles, effective containment)
• What went poorly? (e.g., delayed notification, missing logs, unclear escalation)
• What surprised us? (e.g., vulnerability we didn't expect, attacker technique)
• How can we improve? (e.g., better monitoring, faster patching, clearer runbooks)

Output: Action items, each with a named owner and a date, recorded in the incident record and tracked to completion

5.3 Update This Plan

Revisions Based on Incident:

• Add new detection mechanisms (if incident revealed blind spot)
• Update notification templates (if initial template missing key info)
• Clarify roles (if confusion during incident)
• Add FAQs (common questions from customers)

Version Control: Increment version number, document changes in changelog

---

5. Training and Testing

5.1 Staff Training

Frequency: Annually (mandatory for all staff with access to personal data) Topics:

• What is a personal data breach (examples, non-examples)
• How to report ([email protected], no delay, no self-investigation)
• Phishing awareness (don't click suspicious links, verify sender)
• Password hygiene (use password manager, MFA, no reuse)
• Social engineering (verify identity before granting data access)

Quiz: Pass 80% to complete training. ⚠️ No system of record for training completion has been identified, so completion of this training cannot presently be evidenced.

5.2 Tabletop Exercises

Frequency: Quarterly (4 times per year). ⚠️ No tabletop exercise has been recorded since this plan was adopted, so the cadence stated here is a commitment rather than an established practice. Format: 1-hour simulated breach scenario (no actual systems affected)

Example Scenarios:

• Scenario 1: Ransomware encrypts PostgreSQL database (test backup restoration process)
• Scenario 2: Security rules misconfigured so that data belonging to organisations other than the caller's is readable for 2 hours (test notification to 100+ customers). This scenario must be run against the standing conditions set out below, not against a hypothetical
• Scenario 3: Insider threat — engineer exfiltrates customer data (test offboarding procedures, audit log review)
• Scenario 4: A sub-processor notifies us of a breach (test sub-processor escalation, customer notification)
• Scenario 5: A configuration change disables authentication — the API is started without the identity-platform project identifier, without the service-to-service shared secret, or against an authentication emulator — so that requests are trusted on the strength of caller-supplied headers or of tokens whose signature, expiry and issuer are not verified. Containment is a configuration change and a redeployment; the scope is every request served during the window, which the access log cannot enumerate because it records neither the organisation nor the acting user

Evaluation:

• Can we notify all customers within 24 hours? (test email sending, contact list accuracy)
• Can we draft supervisory authority notification in <2 hours? (test template, info gathering)
• Can we restore from backup within 4 hours? (test RTO — no restore has yet been performed and timed; see Phase 4, Section 4.3)

Output: Lessons learned → update plan, fix gaps (e.g., outdated contact list, missing credentials)

Standing conditions these scenarios must be run against. The following are descriptions of the current configuration, not of a simulated one.

The Firestore security rules restrict organisation configuration, staff user records, page records, private webinars, contact-level consent records and the registration PII subcollection to authenticated members of the owning organisation, and they deny all client access to the top-level collections that hold verification codes and magic links. They do not restrict two categories of personal data:

• Contact PII. The document at orgs/{orgId}/contacts/{emailHash}/pii/private, which holds the contact's plaintext email address, name and telephone number, may be fetched by any authenticated Firebase user — including any anonymous web attendee and any email-verified mobile user, from any organisation — provided they know the organisation identifier and the email hash. The email hash is an unsalted SHA-256 of the lowercased, trimmed email address, so the document path can be computed directly by anyone who knows the target's address. Listing the collection still requires staff of the owning organisation.
• Registration documents. Documents at orgs/{orgId}/webinars/{webinarId}/sessions/{sessionId}/registrations/{registrationId} are readable without authentication, exposing the registration status, the email hash, the registration timestamp and the registration metadata. The rule grants read, which covers both individual fetches and collection listings, notwithstanding an inline comment in the rules file stating that listing requires staff. Registration documents may also be created without authentication, which is how the public registration form works.

Session documents, non-private webinar documents, polls, offers and testimonials are likewise publicly readable, and testimonials and abuse reports are publicly creatable, by design.

Access to live-session data in the Realtime Database is authorised by the role claim in the caller's authentication token alone. The security rules contain no organisation identifier and make no comparison between the caller's organisation and the organisation that owns the session, so an authenticated dashboard user holding any of the admin, moderator, marketer or staff roles — in any organisation on the platform — can read any live session's data given only its session identifier. This includes the chat stream, the moderated-message stream, presence, attendance, presence timelines, per-actor message counts, offer clicks, feedback responses and the identity cache that maps an attendee's anonymous actor identifier to the hash of their email address. Separately, the chat stream, the actor directory (which holds attendee display names), the banned and muted actor lists, the feedback definition and the tracked-link table are readable by any authenticated user, which includes every anonymous attendee of every session. All organisations share a single Firebase project per environment, so a single rule set governs the whole platform.

The Cloud Storage security rules grant unconditional public read access to all seven organisation-scoped paths — webinars/, pages/, offers/, media/, page_templates/, branding/ and staff/ — so any object stored under an organisation's prefix is readable by anyone who knows or can guess its path, without authentication. Write access on those same paths requires only that the caller be authenticated; the organisation identifier in the path is never compared against the caller's token, so an authenticated user of one organisation can overwrite another organisation's branding, media, page templates and landing-page files. A final catch-all rule grants read and write access to every remaining object in the bucket to any authenticated user, which includes every anonymous attendee.

Three further configuration-dependent conditions bear on Scenario 5. Where the identity-platform project identifier is not configured, the API falls back to header-based authentication and accepts the organisation, user and role asserted by the caller. Where the service-to-service shared secret is not configured, the service authentication middleware accepts any bearer token, grants administrative privilege and takes the organisation identifier from a caller-supplied header. Where an authentication emulator host is configured, both the staff and the attendee authentication paths parse tokens without verifying the signature, the expiry or the issuer. None of the three is asserted against at start-up in the way the restricted database connection is, and none would be detected, because there is no alerting.

GAP-ISO-02 · CONFIG — KNOWN GAP, REMEDIATION PENDING

This plan previously presented cross-tenant exposure through misconfigured security rules purely as a training scenario. The conditions set out immediately above are the platform's current configuration rather than a simulation: contact PII documents are readable by any authenticated principal and registration documents without authentication at all, the Realtime Database rules contain no organisation check, and the Cloud Storage rules grant unconditional public read access to organisation-scoped paths and end in an authenticated catch-all. No assessment under Art 33(1) has been carried out or recorded in respect of these conditions. This divergence is recorded on the compliance remediation register and is under review.

---

6. Tools and Resources

6.1 Communication Tools

Tool	Purpose	Access
Email ([email protected])	Inbound reports, IRT coordination, customer notifications	IRT + support team
Telephone (Section 7 directory)	Convening the IRT and out-of-hours escalation; the only channel that reaches a person while the mailbox is not being read	IRT members
Hosting provider and Firebase consoles	Vendor-side status and incident notices	Admin users

No incident chat channel, paging platform, dedicated video room or customer-facing incident banner is provisioned. Earlier versions of this plan listed all four; see the note at Section 3.1.

6.2 Technical Tools

Tool	Purpose	Access
Hosting provider CLI and console	Database access, backup restoration, application log export	Technical Lead, Incident Commander
Firebase Console	Security rules, usage metrics, Realtime Database profiler. Neither Firestore nor the Realtime Database provides a per-read audit log	Admin users
Google Cloud Console	Cloud Functions logs, Secret Manager	Admin users
Wireshark / tcpdump	Network traffic analysis on locally controlled machines only; the platform runs on managed hosting where packet capture is not available	Technical Lead
PostgreSQL CLI (psql)	Forensic queries against the audit log and the affected tables	Technical Lead

6.3 Documentation Templates

Document	Location	Purpose
Customer Notification Email	Section 4, Phase 3, §3.3 of this plan	Copy-paste template, fill in brackets
Supervisory Authority Notification	ANSPDCP website (https://www.dataprotection.ro)	Online form, auto-generates
Data Subject Notification	Section 4, Phase 3, §3.5 of this plan	Template for customers to use
Post-Incident Report	Section 4, Phase 5, §5.1 of this plan	Section structure given in full at that point; ⚠️ no separate template file is maintained

---

7. Contact Information

Internal Contacts

Role	Name	Email	Phone	Availability
Incident Commander	[CTO Name]	[[email protected]]	[+40 XXX XXX XXX]	24/7
Technical Lead	[Engineer Name]	[[email protected]]	[+40 XXX XXX XXX]	24/7 by direct telephone contact; no paging rotation (Section 2)
Legal Counsel	[Lawyer Name]	[[email protected]]	[+40 XXX XXX XXX]	Business hours + emergency line
DPO (if appointed)	[DPO Name]	[email protected]	[+40 XXX XXX XXX]	Business hours

External Contacts

[PLATFORM PROVIDER] engages eleven sub-processors, listed in Annex III. Every sub-processor that actually processes personal data must appear in the table below, because a breach at any of them may be a breach of personal data processed on a customer's behalf. Google LLC appears once here although it occupies two rows in Annex III (Firebase and Google Cloud; Google Analytics and Google Ads), and LinkedIn Corporation is omitted because that integration is not implemented.

Entity	Contact	Purpose
ANSPDCP (Romanian DPA)	[email protected] https://www.dataprotection.ro	Supervisory authority notification (Art 33)
Romanian Cyber Security Authority (CERT-RO)	[email protected] https://cert.ro	Critical infrastructure incidents (if applicable)
Railway Corp.	https://railway.app/support	PostgreSQL, Go API and Next.js hosting; application log retention
Google LLC	https://cloud.google.com/support	Firebase (Authentication, Firestore, Realtime Database, Cloud Storage, Cloud Functions) and Secret Manager; also YouTube embeds loaded directly by visitors' browsers, Google Fonts (fetched server-side by the public application, and by staff browsers in the page-editor preview), and the Google Ads and Analytics entity listed separately in Annex III
NewsmanApp SRL	[[email protected]]	Transactional and marketing email delivery; holds plaintext email addresses, names, segment membership and open and click behavioural data
Cloudflare, Inc.	⚠️ Not established	Reverse proxy, CDN and Turnstile. Terminates TLS for attendee traffic in production, so every attendee registration submission passes through it in plaintext, and every client IP address the platform records or forwards is derived from a Cloudflare-supplied header
Meta Platforms, Inc.	⚠️ Not established	Meta Pixel and Meta Conversions API; receives hashed contact identifiers together with the raw IP address and user agent
TikTok Pte. Ltd.	TikTok Privacy Policy	TikTok Pixel and TikTok Events API; receives hashed contact identifiers together with the raw IP address and user agent
Microsoft Corporation, contracted for EU customers via Microsoft Ireland Operations Limited (MIOL)	⚠️ Not established	Microsoft Clarity session analytics
Anthropic PBC	https://privacy.anthropic.com	AI generation of landing-page and marketing content and of poll questions; prompts may contain approved attendee testimonials
SendSMS.ro	https://www.sendsms.ro	Transactional SMS delivery; receives the recipient's telephone number in plaintext and the full message body

⚠️ No dedicated security contact and no vendor breach-notification service level is established for any of the vendors above; the entries given are general support routes. Confirming a security contact and the contractual notification period for each vendor is an outstanding action and must be completed as part of executing the data processing agreements identified as outstanding in Annex III.

---

8. Breach Register (GDPR Art 33(5))

Location: ⚠️ No breach register is currently maintained. Earlier versions of this plan named an internal file path and a ticketing project; neither exists, and no entry has ever been recorded in either. The register must be established as a maintained internal record, available to the supervisory authority on request, before this plan can be relied on as evidence of compliance with Art 33(5). The column structure below is the structure it must take.

Retention: Three years, matching the commitment given in Section 9.4 of the Data Processing Agreement. Register entries may contain the email hash of a data subject who has since exercised the right to erasure; that is a deliberate consequence of the Art 33(5) documentation obligation and of the accountability principle in Art 5(2), and is not a failure of the erasure process.

Columns:

Breach ID	Date Detected	Date Occurred (est.)	Nature	Data Subjects Affected	Data Categories	Exfiltration?	Notified Authority?	Notified Data Subjects?	Resolution Date	Root Cause
BR-2026-001	[YYYY-MM-DD]	[YYYY-MM-DD]	[Unauthorized access]	[15,000]	[Email, name, chat]	[Yes/No]	[Yes/No]	[Yes/No]	[YYYY-MM-DD]	[Weak password]

Even if NOT notifiable (low risk), log every incident for internal tracking and trend analysis.

Backfill. When the register is established it must be backfilled, not started from the date of its creation. Internal review has identified historical configuration states and one email-suppression defect that require a retrospective assessment under Art 33(1) and a recorded decision — including, where that is the conclusion, a reasoned decision not to notify. Those are: the period during which the live-session presence and statistics nodes in the Realtime Database were readable without authentication while the statistics node also held per-actor ledgers that were joinable to attendee display names; the standing security-rule conditions described in Section 5.2; and the period between 16 May 2026 and 3 July 2026 during which the email-provider synchronisation re-subscribed contacts who had previously unsubscribed.

GAP-PROC-01 · PROCESS — KNOWN GAP, REMEDIATION PENDING

This plan previously stated that a breach register was maintained at a named internal location and that every incident was logged there whether or not it was notifiable. No such register exists in any location, and no incident has been assessed or recorded in one, so [PLATFORM PROVIDER] cannot presently evidence compliance with Art 33(5); the historical conditions listed immediately above have not been assessed. This divergence is recorded on the compliance remediation register and is under review.

---

9. Updates and Maintenance

Review Cycle: Annually (or after every breach) Owner: Incident Commander (CTO) + DPO (if appointed) Approval: CEO, Legal Counsel

Triggers for Update:

• GDPR guidance changes (EDPB opinions, court rulings)
• A change to Annex III (Sub-Processors). Adding, removing or re-scoping a sub-processor there must, in the same change, update the External Contacts table in Section 7 of this plan. The two lists are to be reconciled whenever either is edited
• A material change to the platform's security rules, authentication configuration, logging or storage layers, each of which changes what this plan can establish during an incident
• Organizational changes (new IRT members, new tools)
• Lessons learned from tabletop exercise or real incident

⚠️ Between its adoption and this review, this plan was not revised, while the sub-processor trigger above was met on several occasions — among them the activation of the TikTok Events API, the addition of a server-side Meta Conversions API page-view, the introduction of Cloudflare as a mandatory in-path reverse proxy for attendee traffic, and the engagement of Anthropic PBC and of SendSMS.ro. Section 7 fell correspondingly out of date and has been reconciled with Annex III in this revision.

Version Control:

Version	Date	Changes	Approved By
1.0	[DATE]	Initial draft	[Legal Team]

---

10. Appendices

Appendix A: Breach Severity Matrix

Severity	Data Subjects	Data Categories	Exfiltration	Response Time (Containment)	Example
Critical	>10,000	Plaintext PII + sensitive content (chat, health)	Confirmed exfiltration, publicly posted	2 hours	Database backup leaked to a public code repository; or a configuration change that disables authentication, so that the organisation boundary is lost across every tenant for the duration of the window
High	1,000 - 10,000	Email, name, phone, chat messages	Likely exfiltration (attacker had access >24h)	6 hours	Ransomware encrypts production DB, attacker copied data first
Medium	100 - 1,000	Email, name	Potential access (misconfigured rules; no read log exists that could confirm or exclude access)	12 hours	Firebase security rules misconfigured for 4 hours, access neither confirmed nor excluded
Low	<100	Email hash only, and only where every plaintext store has been shown to be out of scope (see Phase 3, item 4)	No exfiltration (attempted breach, blocked)	24 hours	Failed brute-force attack on API, no successful login

A severity assigned at Low or Medium on the basis that only hashed identifiers were exposed must record which stores were checked and found out of scope. Where an incident cannot be scoped — which is the case for every access path other than audited staff actions — severity is assigned on the worst case consistent with the evidence, not on the absence of evidence of access.

Appendix B: Customer Notification Checklist

• [ ] Identify affected customers (from audited staff actions in the audit log; otherwise from the reach of the compromised credential or misconfigured rule)
• [ ] Retrieve the email addresses of each affected organisation's administrator users; there is no registered security-contact field
• [ ] Draft notification email (use template in Section 4, Phase 3, §3.3)
• [ ] Generate forensic report (PDF attachment)
• [ ] Produce the affected Data Subjects list for each customer manually (PostgreSQL selection plus Firestore resolution of plaintext details); there is no self-service export
• [ ] Send emails within 24 hours of detection
• [ ] Follow up with phone calls (critical incidents, largest affected customers)
• [ ] Track customer responses in the incident record, closing each when the customer acknowledges

Appendix C: Legal Checklist (72-Hour Timeline)

Hour 0-24 (Detection to Containment):

• [ ] Detect breach
• [ ] Assemble IRT
• [ ] Contain breach
• [ ] Assess impact (Data Subjects, data categories)
• [ ] Notify customers (Data Controllers)

Hour 24-48 (Assessment to Notification Decision):

• [ ] Complete forensic investigation
• [ ] Determine if supervisory authority notification required (Art 33 risk threshold)
• [ ] Draft supervisory authority notification (if required)
• [ ] Consult legal counsel (risk assessment, notification wording)

Hour 48-72 (Final Notification Deadline):

• [ ] Submit notification to ANSPDCP (if required)
• [ ] Provide customers with Data Subject notification template (if Art 34 applies)
• [ ] Document notification in breach register

Post-72h:

• [ ] Monitor supervisory authority response (they may request more info)
• [ ] Cooperate with any investigation
• [ ] Implement corrective measures
• [ ] Update customers on remediation progress every 48 hours until resolved, per Section 9.1 of the Data Processing Agreement
• [ ] Deliver the final incident report to affected customers within 14 days of becoming aware, per Section 9.1 of the Data Processing Agreement
• [ ] Record the incident, the assessment and the notification decision in the breach register (Section 8)

---

Document Version: 1.0 (DRAFT) Prepared by: [Security Team] Review Status: ⚠️ REQUIRES LEGAL REVIEW — This is a draft for lawyer consultation

CRITICAL: Test this plan via tabletop exercise BEFORE a real breach occurs.

---

End of Data Breach Response Plan