Personal Data Breach Notification Playbook

Operational procedure for handling a personal data breach under GDPR Art. 33 + Art. 34 + Romanian Law 190/2018. Aligns to the DPA §7 48-hour Controller-notice obligation and the Art. 33 72-hour regulator-notice obligation. v1 drafted 2026-05-15.

Counsel-review status

Developer-drafted v1. Counsel reviews ANSPDCP-specific notification routing and template wording, confirms which breach types require Data Subject notification under Art. 34, and validates the decision-tree. Living document; iterated after each tabletop exercise.

Definitions

• Personal Data Breach (Art. 4(12)): a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed.
• Incident (broader): any operational event that may or may not amount to a personal data breach — assessed by triage.
• Aware (Art. 33): the moment the platform has reasonable degree of certainty that a security incident has occurred and led to personal data being compromised. The 72-hour clock starts here, not at the first ambiguous alert.

Roles

Role	Holder	Responsibilities
Incident Commander (IC)	Designated on-call engineer; rotates per the on-call schedule	Owns the response. Calls roles. Final decision on containment actions
DPO	{{DPO_NAME}} — dpo@restartix.pro	Assesses notification requirements; drafts ANSPDCP notice (on Controller's behalf when applicable to RestartiX-the-clinic; advisory when applicable to a tenant clinic); signs Art. 33 submission
Communications lead	{{COMMS_LEAD}} (typically the Sole Administrator or designated communications person)	External communications; Data Subject notification copy; press inquiries if relevant
Engineering forensics	Senior engineer not on the IC's immediate team where possible	Preserves evidence, identifies the root cause, scopes the affected dataset
Legal	F11.0.5 counsel ({{COUNSEL_FIRM}})	Consulted on regulator notice content, Data Subject notice content, mitigation framing

The IC role is always staffed — the on-call engineer is the default IC. Other roles can be paged in by the IC.

Notification timelines

Audience	Deadline	Basis
Incident Commander → DPO	Immediately, no later than 4 hours from awareness	Internal SLO
Platform (Processor) → Controller	Within 48 hours of awareness	DPA §7
Controller → ANSPDCP	Within 72 hours of awareness, unless unlikely to result in risk	Art. 33
Controller → Data Subjects	Without undue delay, if high risk	Art. 34

The 48-hour Processor → Controller window is intentionally inside the 72-hour Art. 33 window, leaving the Controller ~24 hours to draft and submit the ANSPDCP notice.

End-to-end flow

Alert / Report / Discovery
   │
   ▼
[1] DETECT      → Incident Commander paged
   │
   ▼
[2] TRIAGE      → Is this a personal-data breach? (~1 hr)
   │             ├─ No  → log as security incident, close
   │             └─ Yes → proceed
   ▼
[3] CONTAIN     → Stop the bleeding (immediate — parallel with triage)
   │
   ▼
[4] ASSESS      → Scope: who, what, how much, how long, severity (~hours)
   │
   ▼
[5] NOTIFY      → DPO → Controllers → (Controllers notify) ANSPDCP & Data Subjects
   │
   ▼
[6] REMEDIATE   → Root cause fix; deploy mitigation
   │
   ▼
[7] DOCUMENT    → Internal incident report; ANSPDCP records; audit trail
   │
   ▼
[8] LEARN       → Post-incident review; update playbook; share with DPO

[1] Detect

Sources of detection:

• Automated: CloudWatch alarms (failed-auth spike, RLS error rate, audit-log gap, unusual cross-tenant query attempt), Sentry (uncaught error storm), Cloudflare WAF events, AWS GuardDuty (when enabled).
• Reports: customer support email, in-platform abuse report, security researcher disclosure to security@restartix.pro (mailbox to be provisioned), bug bounty (post-launch).
• Personnel: an engineer notices anomalous behaviour during normal work.

Every detection channel routes to the on-call rotation. The on-call engineer becomes IC on receipt.

[2] Triage

The IC asks five questions:

1. What happened? One-sentence factual summary.
2. Was personal data accessed, modified, lost, or disclosed? If unclear, assume yes for triage purposes.
3. Whose data? Specific Data Subjects (named patients?), categories (all patients of one clinic?), broad classes (all platform users?).
4. Confidentiality, integrity, availability — which? A confidentiality breach (data disclosed) is different from an availability breach (data inaccessible) and an integrity breach (data altered).
5. Is it still happening? Active vs. contained.

If any answer points to personal-data exposure, declare a breach and proceed. If unclear, escalate to the DPO within the 4-hour internal SLO; the DPO calls.

[3] Contain

Run in parallel with assessment. Common containment actions:

• Revoke credentials (Clerk session invalidation, API key rotation, KMS key rotation if signing key compromised)
• Block traffic (Cloudflare firewall rule, WAF block)
• Take the affected surface offline (feature flag, ECS service to zero tasks)
• Quarantine compromised data (read-only mode on the affected org_id, freeze writes)
• Preserve evidence (snapshot RDS, capture CloudTrail logs, capture Sentry events, preserve relevant audit-log partitions)

The IC has authority to take containment actions immediately and notify after the fact.

[4] Assess

The Engineering Forensics role + IC determine:

Question	Output
Affected Data Subjects	List of principal_id values; group by organization_id (each affected Controller). Estimate count if exact unknown
Data categories affected	Identity, health (Art. 9), CNP, authentication, etc. — map to ROPA categories
Volume	Records, sessions, time window
Duration	When the breach started; when it stopped (or whether it's ongoing)
Mechanism	Root-cause-pending hypothesis: bug, misconfiguration, sub-processor compromise, insider, external attack
Special considerations	Was special-category data exposed? Were under-16 records exposed? Was a sub-processor implicated?

This information feeds the Art. 33 notice. The DPO advises on what's required at the 48/72-hour mark vs. what can come later as "additional information as it becomes available."

[5] Notify

5.1 Internal → DPO (within 4 hours)

Channel: phone call + email to dpo@restartix.pro. Provide:

• One-paragraph factual summary
• Triage outcome (breach yes/no)
• Containment status
• Affected Controllers (org list)
• Tentative scope (numbers, categories)
• Pre-mitigation actions in flight

5.2 Processor (Platform) → Controllers (within 48 hours)

Channel: in-platform notification (always-on for break-glass-style banners) + email to registered admin contact.

Template — Controller notice

Subject: [URGENT] Personal Data Breach Notification — RestartiX

Dear [Controller name],

Pursuant to Article 33(2) GDPR and §7 of our Data Processing Agreement, we are notifying you of a Personal Data Breach affecting your organisation's data on the RestartiX platform.

Nature of the breach
[One-paragraph factual description. What happened, when it was discovered.]

Approximate categories and number of Data Subjects affected
[Categories — e.g. "patient profile + email; no clinical instruments accessed". Number — exact if known, estimate otherwise.]

Approximate categories and number of records affected
[Same shape as Data Subjects but for record count.]

Likely consequences
[Realistic risk to Data Subjects. Confidentiality / integrity / availability impacts.]

Measures taken or proposed
[Containment actions completed; remediation in progress; supplementary measures.]

Contact for further information
RestartiX DPO — dpo@restartix.pro
Incident reference: {{INCIDENT_REF}}

As Controller, you are responsible for notifying ANSPDCP within 72 hours of becoming aware of the breach (Art. 33) and, where the breach is likely to result in a high risk to the rights and freedoms of natural persons, notifying the affected Data Subjects without undue delay (Art. 34). RestartiX is available to assist with the technical content of these notifications.

Sincerely,
RestartiX DPO

5.3 Controller → ANSPDCP (within 72 hours)

This is the Controller's obligation, not the Processor's. For breaches affecting RestartiX-the-clinic's own patients (RestartiX SRL acting as Controller under the inner DPA), the DPO drafts and submits the Art. 33 notice on behalf of the SRL.

ANSPDCP notification channel: per ANSPDCP's published form, currently online via the ANSPDCP portal. The DPO maintains the credentials and the pre-filled organisational details template.

The Art. 33 notice content (minimum):

• Nature of the breach including categories and approximate numbers
• Name and contact details of the DPO
• Likely consequences
• Measures taken or proposed
• Where information is not available at the time, the deadline by which it will be provided

The DPO submits the initial notice on time, then files supplementary notices as the picture clarifies.

5.4 Controller → Data Subjects (Art. 34 — when high risk)

Triggered when the breach is likely to result in a high risk to the rights and freedoms of natural persons. Decision criteria (counsel-validated):

Factor	Indicator of high risk
Data sensitivity	Special-category data (Art. 9) exposed → high risk
Identifiability	Direct identifiers + sensitive attributes → high risk
Likelihood of harm	Public disclosure, financial exposure, reputational impact → high risk
Reversibility	Data widely distributed, recovery infeasible → high risk
Mitigating measures	Strong encryption that preserved confidentiality → may avoid high risk classification
Volume	Large number of affected subjects → tendency toward high risk

If high risk is uncertain, default to notifying — under-notification carries regulator-attention risk that over-notification does not.

Channel: in-app banner + email to the affected patient's registered address. Where the email is the affected attribute, additional contact (phone if available) is attempted.

Template — Data Subject notice

Subject: Important — Notification of a Personal Data Incident

Dear [Patient name],

We are writing to inform you about a Personal Data incident affecting your information at [Clinic name on the RestartiX platform].

What happened
[One-paragraph factual description in plain language.]

What information was affected
[Specific categories — "your email address and name" or "session adherence records from [date] to [date]".]

What we are doing
[Containment + remediation in plain language.]

What you can do
[Specific recommended actions, e.g. password change, vigilance against phishing. Be honest about what helps and what doesn't.]

If you have questions
[Clinic name] — [Clinic support contact]
ANSPDCP — anspdcp.ro

Sincerely,
[Clinic name]

For breaches affecting RestartiX-the-clinic's patients, the SRL signs as Controller. For breaches affecting tenant clinics' patients, the tenant clinic signs (the platform provides the technical channel and the draft).

[6] Remediate

The root-cause fix lands on a branch + PR + CI + production deploy via the standard change-control flow. No "emergency direct production write" outside the platform's change-control system. A genuine emergency containment in step 3 may have used a runtime feature flag or a Cloudflare WAF rule — those are the in-band emergency controls.

Remediation includes:

• The fix itself (code, config, IaC).
• Verification (test that the same root cause cannot recur; add regression test).
• Sub-processor changes if applicable (e.g. revoke a compromised credential, rotate keys).
• Telemetry update if the assessment surfaced a monitoring gap (new CloudWatch alarm, new structured-log capture).

[7] Document

The incident report is structured and lives in version-controlled internal documentation ({{INCIDENT_LOG_LOCATION}}):

• Title — short, specific (e.g. "2026-06-15 cross-tenant cache leak via P42 mis-scoped tag")
• Incident ref — INC-{{YYYY-MM-DD}}-{{seq}}
• Timeline — UTC timestamps from first signal to resolution
• Affected Controllers — list
• Data exposed — categories + counts
• Root cause — technical narrative
• Detection — how we found it
• Containment — actions taken, when, by whom
• Notifications — who was notified, when, by what channel
• Remediation — PR / commit / deploy references
• Action items — assigned, due-dated
• Lessons learnt — what does the playbook need to change?

The DPO retains a copy. ANSPDCP-submitted notices are retained for 6+ years.

[8] Learn

A post-incident review is held within 7 working days of resolution. Format: factual, blameless, focused on systemic changes. Attendees: IC, DPO, Engineering Forensics, Comms Lead, the team(s) owning the affected surface.

Outputs:

• Updated this playbook if any procedural gap was exposed
• New telemetry / alerts
• Engineering action items prioritised in the platform backlog
• DPO update to the quarterly compliance review

Decision tree — quick reference

Breach detected
│
├─ Special-category data exposed?
│  ├─ YES → assume HIGH RISK → notify Data Subjects (Art. 34) unless rebuttable
│  └─ NO  → continue
│
├─ Confidentiality of personal data compromised AND not encrypted-at-rest-with-controlled-keys?
│  ├─ YES → notify ANSPDCP within 72h (Art. 33)
│  └─ NO  → still document; notify ANSPDCP if Art. 33 is otherwise triggered
│
├─ Availability loss > the platform's RTO with material patient impact?
│  └─ YES → assess Art. 33 trigger
│
├─ Integrity loss (data altered without authorisation)?
│  └─ YES → assess case-by-case; usually notify
│
└─ No clear trigger?
   └─ Document, escalate to DPO for advisory, store internally; review at quarterly DPO meeting

Tabletop exercises

The DPO organises one tabletop exercise per quarter. Scenarios rotate:

• Q1: cross-tenant cache leak via misconfigured P42 cache tag
• Q2: lost AWS KMS key access (availability)
• Q3: sub-processor breach (Clerk credential leak — supply chain)
• Q4: insider scenario (operator extracts a cross-tenant patient list via Console without break-glass)

The drill exercises the on-call rotation, the notification template, the ANSPDCP-form-fill process, and the inter-Controller communication shape (for the inner-DPA case).

Pre-prepared artefacts

• ANSPDCP notification template — {{ANSPDCP_TEMPLATE_PATH}} — pre-filled with {{LEGAL_ENTITY}}'s details, DPO contact, registered office
• Controller-notification template — embedded above (§5.2)
• Data-subject-notification template — embedded above (§5.4)
• Incident-report template — {{INCIDENT_REPORT_TEMPLATE_PATH}}
• On-call rotation roster — {{ON_CALL_ROSTER}} (provisioned pre-launch)
• security@restartix.pro mailbox — provisioned pre-launch; published in public-facing security disclosure

Change log

Date	Change
2026-05-15	Initial v1 — end-to-end flow, templates, decision tree, tabletop schedule