Incident & Breach Process
Security incidents and GDPR notification chain
1. Normative baseline
The incident and breach process is aligned to Art. 32 GDPR (security of processing), Art. 33 GDPR (notification of breaches to the supervisory authority), and Art. 34 GDPR (communication to data subjects).
This page is technical compliance transparency documentation and does not supersede binding contract documents (in particular Terms (AGB)).
It applies to all security events that affect or could affect the confidentiality, integrity, or availability of personal data within the prokodo Marketplace platform.
This section constitutes a technical compliance draft. Open validation item (Legal): Align with organization-wide incident response policy and sector-specific requirements where applicable.
As of February 16, 2026. Subject to change.
2. Scope and definitions
The following terms are used in this process:
- Security incident: Any event that potentially compromises the security of information systems or personal data — including unauthorized access, data loss, availability disruptions, and configuration errors
- Personal data breach: A security incident leading to a breach of protection of personal data (Art. 4(12) GDPR) — accidental or unlawful destruction, loss, alteration, unauthorized disclosure, or access
- CIA impact: Assessment of affected protection goals — Confidentiality, Integrity, Availability
- Severity: Classification based on impact to affected individuals and systems. Open validation item (Security): Define formal severity classification (e.g., P1/P2/P3/P4) and document criteria.
3. Mandatory procedural phases
Each security incident must be processed through the following mandatory phases. Skipping a phase requires documented justification and 2nd-line approval.
- Phase 1 — Detection & triage: Initial capture, classification (incident vs. breach), scope determination, affected data categories and systems, initial risk assessment. Infrastructure-level monitoring alerts are available (Typesense: uptime, CPU, memory, disk; Verification: stuck detection, queue backlog, failure ratio, worker silent; Cloud Monitoring dashboard)
- Phase 2 — Containment: Immediate technical controls to limit impact (e.g., access revocation, service isolation, credential rotation). Document measures taken and their effectiveness
- Phase 3 — Forensics: Preservation and integrity-maintaining analysis of relevant evidence (logs, configuration states, audit events). No deletion or modification of potentially evidentiary data. VPC flow logs and Cloud Logging serve as forensic sources
- Phase 4 — Legal assessment: Legal evaluation of notification obligation to supervisory authority (Art. 33) and data subjects (Art. 34). The decision is documented, including decisions not to notify. No external communication without legal clearance
- Phase 5 — Recovery & closure: Restoration of normal operations. Corrective actions (root-cause elimination) and preventive actions (recurrence prevention). Final report with action plan, owners, and deadlines. Effectiveness validation of implemented measures
4. Timelines, notification path, and escalation
Regulatory timelines are mandatory. Internal deadlines must be set to ensure regulatory deadlines can be met.
- Initial internal capture: immediately upon becoming aware of the incident
- Internal escalation: immediately to the responsible security and privacy role. Open validation item (Ops): Confirm escalation channels and on-call coverage (e.g., on-call rotation, escalation distribution list).
- Initial legal assessment: without undue delay after triage completion
- Art. 33 GDPR — authority notification: within 72 hours of becoming aware of the breach, where a risk to the rights and freedoms of natural persons exists. Supplementary notification is permitted where details become available subsequently
- Art. 34 GDPR — data subject communication: without undue delay where a high risk to the rights and freedoms of natural persons exists
- Decision log: Every notification/no-notification decision must be documented with rationale, responsible person, and timestamp
- Final report: within 14 days of incident closure (target). Open validation item (Legal): Confirm final deadline for closure report.
5. Evidence and documentation obligations
Every incident must be fully documented. Documentation serves as compliance evidence and as a basis for continuous improvement.
- Unique incident ID and complete timeline (detection, triage, containment, forensics, assessment, recovery, closure)
- Affected systems and data domains (e.g., user profiles, payment data, audit logs)
- Affected data categories and estimated number of affected individuals (to the extent determinable)
- Decision log: notification, no-notification, or supplementary notification — each with rationale
- Action list with effectiveness validation and responsible owner
- References to preserved audit evidence (audit events, Cloud Logging, VPC flow logs)
- Retention period for incident documentation. Open validation item (Legal): Define minimum retention period for incident records.
6. Link to legal hold, erasure, and retention
Where an incident impacts erasure execution (e.g., legal hold during an investigation), the following rules apply:
- Legal-hold block reasons in the erasure workflow: LEGAL_HOLD, OPEN_DISPUTE, FRAUD_REVIEW. Each block reason must be auditably recorded with: reason, responsible person, timestamp, justification codes
- In a blocked state, only legally required minimum data may be retained; no discretionary profile enrichment
- Retention-based systems (backups, log streams, monitoring telemetry): Deletion via documented expiry/rotation rules, not per-record hard delete
- Firestore backups: 14 weeks retention (configured). Cloud Logging and error telemetry: per provider/sink setting
- Incident-related retention extensions must be separately documented and lifted upon investigation closure
7. Communication rules
The following rules apply to internal and external communications during security incidents; related transfer/vendor context is documented in DPA / SCC / TIA and Subprocessors.
- No user or customer communication before legal clearance (Phase 4 — Legal assessment)
- Internal communication on a need-to-know basis; no dissemination through unsecured channels
- Templates for supervisory authority notification and data subject communication should be prepared in advance. Open validation item (Legal): Create and maintain notification templates.
- Press inquiries or public communication only through authorized representatives
- Where a subprocessor is involved: coordinated communication with the affected processor in accordance with DPA incident clauses
