Sign in →
Privacy & GDPR1 min read

Breach Response (Articles 33 & 34)

Personal data breach workflow with 72-hour Article 33 SLA, Article 34 subject notification, automated anomaly detection, and the operator response playbook.

Updated 2026-06-15Suggest edits
Docs Privacy & GDPR Breach Response

Article 33 requires controllers to notify the supervisory authority of a personal data breach within 72 hours of becoming aware of it. Article 34 requires notifying affected data subjects when the breach is likely to result in high risk. Aforo provides the workflow, SLA timers, and audit trail to operate that clock confidently — plus an automated detector framework that flags suspicious patterns before they escalate.

What counts as a personal data breach#

Article 4(12) defines a personal data breach as "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." Three categories matter:

TypeDescriptionExample
Confidentiality breachUnauthorised or accidental disclosurePII exposed to the wrong tenant due to an access-control failure
Integrity breachUnauthorised or accidental alterationBug overwrites correct billing address with another customer's data
Availability breachAccidental or unlawful loss of access or destructionRansomware encrypts the customer database; data subjects lose access to their accounts
INFO
Not every security incident is a personal data breach. A vulnerability with no evidence of exploitation is a finding, not a breach. The 72h clock starts when the controller becomes aware that a breach has occurred — Article 29 WP Guidelines clarify "awareness" means reasonable degree of certainty, not full forensic confirmation.

The 72-hour Article 33 clock#

From the moment you become aware of a breach, you have 72 hours to notify your supervisory authority. The notification must include the four Article 33(3) elements:

Nature of the breach
Categories + approximate number of data subjects affected, categories + approximate number of personal data records affected.
DPO contact
Name + contact details of the DPO or other contact point where more information can be obtained.
Likely consequences
A description of the likely consequences of the personal data breach.
Mitigation measures
Measures taken or proposed to address the breach and, where appropriate, to mitigate its possible adverse effects.
WARNING
Aforo cannot notify your supervisory authority on your behalf — that is the Controller\'s obligation. Aforo notifies you (the operator) within 12 hours of suspected breach detection; you then notify your authority within the remaining time before 72 hours elapse from initial awareness. If the breach originates within Aforo as Processor, we cooperate fully and provide all forensic evidence requested.

What happens when you miss 72 hours

  • You can still notify — Article 33(1) allows late notification with a justified reason ("where feasible").
  • The notification must explicitly include the reasons for the delay.
  • Late notification without justification is itself an Article 83 fineable offence (up to €10M or 2% of global turnover, whichever is higher).

When Article 34 subject notice is required#

Article 34 requires you to also notify the affected data subjects, but only when the breach is "likely to result in a high risk to the rights and freedoms of natural persons." Three exemptions in Article 34(3) let you skip subject notification:

ExemptionArticleExample
Encrypted data with intact keys34(3)(a)Stolen encrypted backup tape; keys never compromised
Subsequent measures eliminate the risk34(3)(b)Detected within minutes, all sessions invalidated, no actual exploitation
Disproportionate effort34(3)(c)Use a public communication (press release, in-app banner) instead of direct contact

Operator playbook — Privacy Operations → Breach Incidents#

Breach incidents are filed and managed at Aforo Product UI → Governance → Privacy Operations → Breach Incidents. Each incident carries an Article 33 SLA timer that flips green → amber → red as the deadline approaches. RBAC is OWNER, ADMIN, BILLING_ADMIN. The full Article 33 four-field notification draft can be composed inline and stamped with the actual authority-notification timestamp once sent.

Step-by-step (T+0 through T+72h)

  1. T+0 — Awareness. Page the Privacy Operations on-call. File the incident in Aforo with severity (LOW / MEDIUM / HIGH / CRITICAL) and source (MANUAL / AUTOMATED / EXTERNAL_REPORT / SUBPROCESSOR).
  2. T+30min — Contain. If the breach is ongoing (e.g. credential leak), revoke + rotate immediately. Update incident status to INVESTIGATING.
  3. T+2h — Assess scope. Determine affected tenant IDs (JSONB affected_tenant_ids), data categories (affected_data_categories), approximate subject count.
  4. T+6h — Notify customers (B2B). If a subset of tenant operators are affected, fire the customer notification — this satisfies your Processor obligation to inform the Controller.
  5. T+12h — Aforo notifies its DPO. Internal DPO review of the incident draft. Aforo as Controller of operator data acts at this stage if operator accounts are affected.
  6. T+24-48h — Draft Article 33 notification. Compose the 4-field notification (nature, DPO contact, consequences, mitigation) inline in the incident detail drawer. Save as draft.
  7. T+72h — Submit to authority. Click "Mark as Article 33 Notified". Aforo stamps the authority_notified_at field. State auto-transitions to CONTAINED.
  8. T+72h+ — Article 34 (if high risk). Compose subject notification. If using a public communication route, document the justification. Mark subjects_notified_at.
  9. Day 7-30 — Root cause + postmortem. Add evidence, mitigation measures, prevention plan. Transition to RESOLVED.

Automated detection#

Aforo ships a detector SPI (BreachDetector interface) and a scheduler that runs registered detectors on the prior hour\'s audit data. Detector hits auto-file PENDING_TRIAGE incidents with source=AUTOMATED. The framework is feature-flagged (aforo.breach-detector.enabled=false by default) — operators enable per-tenant once detector confidence is calibrated.

v2 detector roadmap

DetectorWhat it watchesTrigger threshold
PiiReadVelocityDetectorVolume of pii.* audit actions per operator per hour>10× operator's 30-day P95
CrossTenantAccessDetectorPII reads where operator's home tenant ≠ subject's tenantAny hit (zero tolerance)
FailedLoginBurstDetectorFailed authentication attempts against operator accounts>20/min sustained for 5 min
MassExportOutsideHoursDetectorBulk data exports filed outside the operator's typical hours>3 exports in a 24h window outside normal

Implementing a custom detector

MyCustomBreachDetector.java
@Component
public class MyCustomBreachDetector implements BreachDetector {

    @Override
    public String getDetectorId() {
        return "my-custom-detector-v1";
    }

    @Override
    public List<DetectionResult> detect(Instant windowStart, Instant windowEnd) {
        List<DetectionResult> hits = new ArrayList<>();

        // Your detection logic here — query audit log, usage events, etc.
        // for the [windowStart, windowEnd) window. Return one
        // DetectionResult per suspected breach.

        for (var suspect : findSuspiciousPatterns(windowStart, windowEnd)) {
            hits.add(DetectionResult.builder()
                .correlationKey(suspect.uniqueKey())           // idempotency — same key won't file twice
                .tenantId(suspect.tenantId())
                .severity(BreachSeverity.HIGH)
                .title("Suspected " + suspect.kind())
                .description(suspect.evidence())
                .affectedDataCategories(List.of("PII_EMAIL", "PII_PHONE"))
                .detectionMetadata(Map.of("tenantId", suspect.tenantId(), "rule", "high-velocity-pii"))
                .build());
        }

        return hits;
    }
}
INFO
Idempotency by correlationKey. The scheduler tracks which correlationKeys have already been filed. Re-running a detector against the same window does not create duplicate incidents — the scheduler skips keys it has seen. This lets you safely re-run detectors after a fix without alert spam.

State machine + severity#

Status lifecycle

StatusMeaningAllowed transitions
PENDING_TRIAGEJust filed (manual or automated) — needs operator triageINVESTIGATING, FALSE_POSITIVE
INVESTIGATINGOperator is gathering scope + evidenceCONTAINED, FALSE_POSITIVE
CONTAINEDArticle 33 notification sent + bleeding stoppedRESOLVED
RESOLVEDPostmortem complete, prevention plan documentedTerminal (cannot reopen)
FALSE_POSITIVEInitial signal was not a breach — kept for audit historyTerminal
WARNING
RESOLVED is irreversible. Operators get a confirmation dialog before transitioning. Once resolved, the incident is locked from further state changes. If new information emerges, file a follow-up incident referencing the original via the parent_incident_id field.

Severity assignment

SeverityTypical scenariosArticle 34 default
CRITICALMass PII disclosure, financial data exposed, encrypted DB compromised with keysSubject notification required
HIGHCross-tenant data leak (small scope), credential exfiltration, integrity breach on billingSubject notification likely required
MEDIUMSingle operator misconfiguration exposing one tenant's metadataDiscretionary — depends on data categories
LOWInternal-only audit anomaly, no subjects affectedNot required