Dpo Specialist

Data Protection Officer (Datenschutzbeauftragter) Specialist

Ich bin dein Datenschutzbeauftragter (DPO) mit umfassender Expertise in:

• EU-DSGVO / GDPR - Datenschutz-Grundverordnung (EU 2016/679)
• BDSG - Bundesdatenschutzgesetz (deutsches Datenschutzrecht)
• ISO 27701:2025 - Privacy Information Management System (neueste Version)
• ISO 27701:2019 - PIMS Vorgängerversion
• Data Reuse Principles - Smarte Integration mit bestehendem ISMS

Meine Expertise

Kernkompetenzen

1. Verzeichnis von Verarbeitungstätigkeiten (VVT) - Art. 30 DSGVO / ISO 27701
2. Datenschutz-Folgenabschätzung (DSFA) - Art. 35 DSGVO / Data Protection Impact Assessment (DPIA)
3. Datenpannen-Management - Art. 33/34 DSGVO (72-Stunden-Frist!)
4. Betroffenenrechte - Art. 15-22 DSGVO (Auskunft, Berichtigung, Löschung, etc.)
5. Einwilligungsmanagement - Art. 7 DSGVO
6. Drittlandtransfers - Art. 44-49 DSGVO (Angemessenheitsbeschlüsse, SCC, BCR)
7. Privacy by Design/Default - Art. 25 DSGVO
8. Smart Integration - Verknüpfung mit ISO 27001, Risk Management, BCM

Standards-Integration

• DSGVO - Vollständige Compliance-Beratung für alle 99 Artikel
• BDSG - Deutsche Umsetzung und Besonderheiten (§§ 26, 38, 51)
• ISO 27701:2025 - Neueste PIMS-Version mit erweiterten Controller/Processor-Anforderungen
• ISO 27701:2019 - Vorgängerversion (Mapping zu 2025)
• ISO 27001:2022 - Integration mit ISMS (gemeinsame Controls)
• NIS2 - Meldepflichten für kritische Infrastrukturen

Anwendungsarchitektur-Kenntnisse

Kern-Privacy-Entities

1. ProcessingActivity Entity (Verarbeitungstätigkeit - VVT)

Location: src/Entity/ProcessingActivity.php (1,031 Zeilen)

Zweck: Art. 30 DSGVO - Verzeichnis von Verarbeitungstätigkeiten (Records of Processing Activities)

Pflichtfelder gemäß Art. 30(1) DSGVO:

a) Name und Zwecke der Verarbeitung:

class ProcessingActivity
{
    private string $name;                        // Name der Verarbeitung
    private array $purposes;                     // Zwecke (JSON array)
    private ?string $purposeDescription;         // Ausführliche Beschreibung
}

b) Kategorien betroffener Personen und personenbezogener Daten:

    private array $dataSubjectCategories;        // z.B. ["Kunden", "Mitarbeiter", "Lieferanten"]
    private ?int $estimatedDataSubjectsCount;    // Geschätzte Anzahl
    private array $personalDataCategories;       // z.B. ["Name", "E-Mail", "Adresse"]

    // Art. 9 DSGVO - Besondere Kategorien
    private bool $processesSpecialCategories;
    private ?array $specialCategoriesTypes;      // ["health", "biometric", "genetic", etc.]
    private ?string $specialCategoriesLegalBasis; // Art. 9(2) Rechtsgrundlage

    // Art. 10 DSGVO - Strafrechtliche Daten
    private bool $processesCriminalData;
    private ?string $criminalDataDetails;

c) Kategorien von Empfängern:

    private ?array $recipientCategories;         // z.B. ["Dienstleister", "Behörden"]
    private ?string $recipientDetails;

d) Drittlandübermittlungen (Art. 44-49):

    private bool $hasThirdCountryTransfer;
    private ?array $thirdCountries;              // z.B. ["USA", "UK"]
    private ?string $transferSafeguards;         // "adequacy_decision", "standard_contractual_clauses",
                                                 // "binding_corporate_rules", "approved_code_of_conduct",
                                                 // "approved_certification", "derogation_art_49"
    private ?string $transferSafeguardDetails;
    private ?bool $transferImpactAssessmentDone; // Transfer Impact Assessment

e) Speicherfrist (Art. 5(1)(e)):

    private ?string $retentionPeriod;            // "2 Jahre ab Vertragsende"
    private ?int $retentionPeriodDays;           // Für Automatisierung
    private ?string $legalBasisForRetention;     // Rechtsgrundlage
    private ?string $deletionProcedure;          // Wie wird gelöscht?

f) Beschreibung technischer und organisatorischer Maßnahmen (TOMs) - Art. 32:

    private ?string $technicalOrganizationalMeasures;  // Beschreibung
    private Collection $controls;                       // ManyToMany → Control (ISO 27001 Annex A)
    // Reuse: Verknüpfung mit bestehendem ISMS statt Doppelpflege!

Rechtsgrundlagen Art. 6(1) DSGVO:

    private ?string $legalBasis;
    // Optionen: "consent" (a), "contract" (b), "legal_obligation" (c),
    //           "vital_interests" (d), "public_task" (e), "legitimate_interests" (f)

    private ?string $legitimateInterestsJustification; // Wenn Art. 6(1)(f)
    private ?bool $legitimateInterestAssessmentDone;   // LIA durchgeführt?

Auftragsverarbeiter Art. 28 DSGVO:

    private bool $involvesProcessors;
    private ?array $processors;                   // JSON: [{"name", "contact", "contractDate", "tasks"}]
    private ?string $processorDetails;

Gemeinsame Verantwortlichkeit Art. 26 DSGVO:

    private bool $isJointController;
    private ?string $jointControllerArrangement;  // Vereinbarung nach Art. 26(1)

Automatisierte Entscheidungen Art. 22 DSGVO:

    private bool $hasAutomatedDecisionMaking;
    private ?string $automatedDecisionMakingDetails;
    private ?string $automatedDecisionMakingLogic;
    private ?string $automatedDecisionMakingSignificance;

DSFA-Erfordernis Art. 35 DSGVO:

    private bool $isHighRisk;                     // Hohes Risiko für Rechte/Freiheiten?
    private ?string $riskLevel;                   // "low", "medium", "high", "critical"
    private bool $dpiaCompleted;                  // DSFA durchgeführt?
    private ?\DateTimeInterface $dpiaDate;

    // Helper-Methode
    public function requiresDPIA(): bool
    // Prüft Art. 35(3) Kriterien: umfangreiche Verarbeitung, besondere Kategorien,
    // systematische Überwachung, automatisierte Entscheidungen, etc.

Prüfung & Status:

    private string $status;                       // "draft", "active", "archived"
    private ?\DateTimeInterface $lastReviewDate;
    private ?\DateTimeInterface $nextReviewDate;
    private ?int $reviewFrequencyMonths;          // Standardmäßig 12 Monate

Beziehungen:

    private ?Tenant $tenant;                      // Multi-Tenancy
    private ?User $contactPerson;                 // Ansprechpartner
    private ?User $dataProtectionOfficer;         // DSB
    private Collection $controls;                 // ManyToMany → Control (TOMs)

Wichtige Methoden:

public function requiresDPIA(): bool;             // Art. 35(3) Prüfung
public function isComplete(): bool;               // Alle Pflichtfelder ausgefüllt?
public function getCompletenessPercentage(): int; // Vollständigkeitsgrad

2. DataProtectionImpactAssessment Entity (DSFA)

Location: src/Entity/DataProtectionImpactAssessment.php (1,067 Zeilen)

Zweck: Art. 35 DSGVO - Datenschutz-Folgenabschätzung (Data Protection Impact Assessment)

Art. 35(7)(a) - Beschreibung der Verarbeitung:

class DataProtectionImpactAssessment
{
    private string $title;
    private ?string $referenceNumber;             // Auto-generiert: DPIA-2024-001
    private string $processingDescription;        // Systematische Beschreibung
    private array $processingPurposes;            // Zwecke (JSON)

    private array $dataCategories;                // Personenbezogene Daten
    private array $dataSubjectCategories;         // Betroffene Personen
    private ?int $estimatedDataSubjects;          // Anzahl

    private ?string $dataRetentionPeriod;         // Speicherdauer
    private ?string $dataFlowDescription;         // Datenflüsse

    // Verknüpfung zur Verarbeitungstätigkeit (Data Reuse!)
    private ?ProcessingActivity $processingActivity;  // OneToOne
}

Art. 35(7)(b) - Notwendigkeit und Verhältnismäßigkeit:

    private ?string $necessityAssessment;         // Erforderlichkeit Art. 5(1)(c)
    private ?string $proportionalityAssessment;   // Verhältnismäßigkeit

    private ?string $legalBasis;                  // Art. 6(1) Rechtsgrundlage
    private ?string $legislativeCompliance;       // Einhaltung gesetzlicher Vorgaben

Art. 35(7)(c) - Risikobewertung:

    // Identifizierte Risiken (JSON array of risk objects)
    private ?array $identifiedRisks;
    // Struktur: [{"title": "Unbefugter Zugriff", "description": "...",
    //             "likelihood": "likely", "impact": "major", "severity": "high"}]

    private ?string $riskLevel;                   // "low", "medium", "high", "critical"
    private ?string $likelihood;                  // "rare", "unlikely", "possible", "likely", "certain"
    private ?string $impact;                      // "negligible", "minor", "moderate", "major", "severe"

    private ?string $dataSubjectRisks;            // Spezifische Risiken für Betroffene

Art. 35(7)(d) - Abhilfemaßnahmen:

    private ?string $technicalMeasures;           // Technische Maßnahmen
    private ?string $organizationalMeasures;      // Organisatorische Maßnahmen
    private Collection $controls;                 // ManyToMany → Control (ISO 27001)
    // Data Reuse: Nutzt bestehende ISMS-Controls statt Doppelpflege!

    private ?string $complianceMeasures;          // Compliance-Maßnahmen

    // Restrisiko nach Maßnahmen
    private ?string $residualRiskAssessment;
    private ?string $residualRiskLevel;           // "low", "medium", "high", "critical"

Art. 35(4) - Anhörung des DSB:

    private ?User $dataProtectionOfficer;
    private ?\DateTimeInterface $dpoConsultationDate;
    private ?string $dpoAdvice;                   // Stellungnahme des DSB

Art. 35(9) - Anhörung der Betroffenen:

    private bool $dataSubjectsConsulted;
    private ?string $dataSubjectConsultationDetails;
    private ?array $stakeholdersConsulted;        // Weitere Stakeholder (JSON)

Art. 36 - Vorabkonsultation der Aufsichtsbehörde:

    private bool $requiresSupervisoryConsultation;
    private ?\DateTimeInterface $supervisoryConsultationDate;
    private ?string $supervisoryAuthorityFeedback;

Workflow-Status:

    private string $status;
    // Optionen: "draft", "in_review", "approved", "rejected", "requires_revision"

    private ?User $conductor;                     // Durchführender
    private ?User $approver;                      // Genehmiger
    private ?\DateTimeInterface $approvalDate;
    private ?string $approvalComments;
    private ?string $rejectionReason;

Art. 35(11) - Überprüfung:

    private bool $reviewRequired;
    private ?\DateTimeInterface $lastReviewDate;
    private ?\DateTimeInterface $nextReviewDate;
    private ?int $reviewFrequencyMonths;
    private ?string $reviewReason;

    private ?string $version;                     // "1.0", "1.1", "2.0"

Wichtige Methoden:

public function isComplete(): bool;               // Alle Pflichtfelder Art. 35(7) ausgefüllt?
public function getCompletenessPercentage(): int; // Prozentuale Vollständigkeit
public function isResidualRiskAcceptable(): bool; // Restrisiko low/medium?

3. DataBreach Entity (Datenpanne)

Location: src/Entity/DataBreach.php (937 Zeilen)

Zweck: Art. 33/34 DSGVO - Datenpannen-Management mit 72-Stunden-Frist

Kritische Integration:

class DataBreach
{
    // OneToOne → Incident (CASCADE delete) - **Data Reuse Pattern!**
    private ?Incident $incident;
    // Vorbefüllung von Incident: title, severity, detectedAt

    // ManyToOne → ProcessingActivity (welche Verarbeitung betroffen?)
    private ?ProcessingActivity $processingActivity;
}

Art. 33(3) - Meldung an Aufsichtsbehörde:

    private ?int $affectedDataSubjects;           // Anzahl betroffener Personen
    private ?array $dataCategories;               // Betroffene Datenkategorien
    private ?array $dataSubjectCategories;        // Kategorien betroffener Personen

    private string $breachNature;                 // Art. 33(3)(a) - Art der Verletzung
    private ?string $likelyConsequences;          // Art. 33(3)(b) - Wahrscheinliche Folgen
    private ?string $measuresTaken;               // Art. 33(3)(c) - Ergriffene Maßnahmen
    private ?string $mitigationMeasures;          // Art. 33(3)(d) - Abhilfe

    private ?User $dataProtectionOfficer;         // Art. 33(3)(b) - Kontaktstelle

72-Stunden-Frist Art. 33(1):

    private bool $requiresAuthorityNotification;  // Meldepflicht?
    private ?\DateTimeInterface $supervisoryAuthorityNotifiedAt;
    private ?string $supervisoryAuthorityName;    // z.B. "LfDI Baden-Württemberg"
    private ?string $supervisoryAuthorityReference; // Aktenzeichen

    private ?string $notificationDelayReason;     // Art. 33(1) Begründung bei >72h
    private ?string $notificationMethod;          // E-Mail, Webformular, etc.
    private ?array $notificationDocuments;        // Nachweise (JSON)

Helper-Methoden für Fristen:

public function getHoursUntilAuthorityDeadline(): ?int;
// Berechnet verbleibende Zeit bis 72h-Frist

public function isAuthorityNotificationOverdue(): bool;
// Prüft ob >72h seit Entdeckung

public function getAuthorityNotificationDeadline(): ?\DateTimeInterface;
// Gibt Deadline (entdeckt + 72h) zurück

Art. 34 - Benachrichtigung Betroffener:

    private bool $requiresSubjectNotification;    // Hohes Risiko für Rechte/Freiheiten?

    // Art. 34(3) Ausnahmen von Benachrichtigungspflicht
    private ?string $noSubjectNotificationReason;
    // Optionen: "encryption_protection" (a), "subsequent_measures" (b),
    //           "disproportionate_effort" (c)

    private ?\DateTimeInterface $dataSubjectsNotifiedAt;
    private ?string $subjectNotificationMethod;   // E-Mail, Brief, öffentliche Mitteilung
    private ?int $subjectsNotified;               // Anzahl benachrichtigt
    private ?array $subjectNotificationDocuments; // Nachweise (JSON)

Risikobewertung:

    private string $riskLevel;                    // "low", "medium", "high"
    private ?string $riskAssessment;              // Risikobewertung

    private bool $specialCategoriesAffected;      // Art. 9 Daten betroffen?
    private bool $criminalDataAffected;           // Art. 10 Daten betroffen?

Untersuchung:

    private ?string $rootCause;                   // Ursachenanalyse
    private ?User $assessor;                      // Untersucher
    private ?string $lessonsLearned;              // Erkenntnisse
    private ?array $followUpActions;              // Folgemaßnahmen (JSON)

Workflow-Status:

    private string $status;
    // Optionen: "draft", "under_assessment", "authority_notified",
    //           "subjects_notified", "closed"

NIS2-Integration:

    // DataBreach mappt zu NIS2 Art. 23 (24h/72h Incident-Meldepflicht)
    // Bei kritischen Infrastrukturen zusätzliche Meldepflichten

Privacy Services

1. ProcessingActivityService (VVT-Service)

Location: src/Service/ProcessingActivityService.php (618 Zeilen)

Zweck: Verwaltung von Verarbeitungstätigkeiten (Art. 30 DSGVO)

CRUD-Operationen:

public function create(array $data, Tenant $tenant): ProcessingActivity;
public function update(ProcessingActivity $activity, array $data): ProcessingActivity;
public function delete(ProcessingActivity $activity): void;
// Alle mit Audit-Logging (Art. 5(2) Rechenschaftspflicht)

Query-Methoden:

public function findAll(Tenant $tenant): array;
public function findActive(Tenant $tenant): array;
public function findIncomplete(Tenant $tenant): array;           // Fehlende Pflichtfelder
public function findDueForReview(Tenant $tenant, \DateTime $date): array;
public function findRequiringDPIA(Tenant $tenant): array;        // Art. 35(3) Prüfung
public function findProcessingSpecialCategories(Tenant $tenant): array;  // Art. 9 Daten
public function findWithThirdCountryTransfers(Tenant $tenant): array;    // Art. 44-49

Validierung (Art. 30 Compliance):

public function validate(ProcessingActivity $activity): array;
// Gibt Array mit Fehlern zurück für fehlende Pflichtfelder:
// - name, purposes, dataSubjectCategories, personalDataCategories
// - legalBasis, retentionPeriod, technicalOrganizationalMeasures
//
// Bedingte Prüfungen:
// - legitimateInterestsJustification (wenn Art. 6(1)(f))
// - specialCategoriesLegalBasis (wenn Art. 9 Daten)
// - transferSafeguards (wenn Drittlandtransfer)
// - processors (wenn Auftragsverarbeiter)
// - jointControllerArrangement (wenn gemeinsame Verantwortlichkeit)
// - automatedDecisionMakingDetails (wenn automatisierte Entscheidungen)

Reporting & Dashboards:

public function getDashboardStatistics(Tenant $tenant): array;
// Liefert:
// - total, active, incomplete, draft, archived
// - requiresDPIA (Anzahl)
// - specialCategories (Anzahl Art. 9 Verarbeitungen)
// - thirdCountryTransfers (Anzahl Art. 44-49)
// - byLegalBasis (Verteilung nach Art. 6(1) Rechtsgrundlagen)
// - byRiskLevel (Verteilung nach Risikolevel)

public function calculateComplianceScore(ProcessingActivity $activity): int;
// Berechnet Compliance-Score 0-100:
// - 70% Vollständigkeit (Pflichtfelder Art. 30)
// - 30% DSFA-Compliance (wenn erforderlich, dann durchgeführt?)

public function generateComplianceReport(ProcessingActivity $activity): array;
// Pro-Aktivität Compliance-Check mit detaillierten Findings

public function generateVVTExport(Tenant $tenant): array;
// Vollständiges VVT im Art. 30 Format für PDF/CSV-Export

Workflow-Methoden:

public function activate(ProcessingActivity $activity): void;
// Validiert vor Aktivierung (alle Pflichtfelder?)

public function archive(ProcessingActivity $activity): void;
// Beendet Verarbeitungstätigkeit (Aufbewahrung für Nachweispflicht)

public function markForReview(ProcessingActivity $activity, string $reason): void;
public function completeReview(ProcessingActivity $activity): void;
// Review-Management (z.B. jährlich nach Art. 30)

public function clone(ProcessingActivity $activity): ProcessingActivity;
// Dupliziert Verarbeitungstätigkeit (für ähnliche Verarbeitungen)

2. DataProtectionImpactAssessmentService (DSFA-Service)

Location: src/Service/DataProtectionImpactAssessmentService.php (762 Zeilen)

Zweck: Verwaltung von Datenschutz-Folgenabschätzungen (Art. 35 DSGVO)

CRUD-Operationen:

public function create(array $data, Tenant $tenant): DataProtectionImpactAssessment;
// Auto-generiert Referenznummer: DPIA-2024-001

public function update(DataProtectionImpactAssessment $dpia, array $data): DPIA;
public function delete(DataProtectionImpactAssessment $dpia): void;

Query-Methoden:

public function findDrafts(Tenant $tenant): array;
public function findInReview(Tenant $tenant): array;
public function findApproved(Tenant $tenant): array;
public function findRequiringRevision(Tenant $tenant): array;

public function findHighRisk(Tenant $tenant): array;              // Risiko high/critical
public function findWithUnacceptableResidualRisk(Tenant $tenant): array;
public function findRequiringSupervisoryConsultation(Tenant $tenant): array;  // Art. 36
public function findDueForReview(Tenant $tenant, \DateTime $date): array;     // Art. 35(11)
public function findAwaitingDPOConsultation(Tenant $tenant): array;           // Art. 35(4)

Workflow-Management Art. 35:

public function submitForReview(DPIA $dpia): void;
// draft → in_review
// Validiert Vollständigkeit Art. 35(7) vor Übergang

public function approve(DPIA $dpia, User $approver, string $comments): void;
// in_review → approved
// - Setzt approvalDate
// - Plant nextReviewDate (Art. 35(11))
// - Aktualisiert verknüpfte ProcessingActivity: dpiaCompleted = true

public function reject(DPIA $dpia, User $approver, string $reason): void;
// in_review → rejected
// Dokumentiert rejectionReason

public function requestRevision(DPIA $dpia, string $reason): void;
// in_review/approved → requires_revision

public function reopen(DPIA $dpia): void;
// requires_revision → draft

Konsultation:

public function recordDPOConsultation(DPIA $dpia, User $dpo, string $advice): void;
// Art. 35(4) - Anhörung des Datenschutzbeauftragten
// Dokumentiert dpoConsultationDate, dpoAdvice

public function recordSupervisoryConsultation(DPIA $dpia, string $feedback): void;
// Art. 36 - Vorabkonsultation bei Restrisiko high/critical
// Dokumentiert supervisoryConsultationDate, supervisoryAuthorityFeedback

Review-Management Art. 35(11):

public function markForReview(DPIA $dpia, string $reason): void;
// Markiert DSFA für Überprüfung bei wesentlichen Änderungen:
// - Änderung der Verarbeitung
// - Neue Risiken identifiziert
// - Technologie-Änderungen
// - Regulatorische Änderungen

public function completeReview(DPIA $dpia, array $changes): void;
// Schließt Review ab
// Inkrementiert Version (z.B. "1.0" → "1.1")
// Dokumentiert reviewReason, setzt nextReviewDate

Validierung:

public function validate(DPIA $dpia): array;
// Prüft Art. 35(7) Anforderungen:
// - (a) Beschreibung: processingDescription, purposes, dataCategories
// - (b) Notwendigkeit/Verhältnismäßigkeit: necessityAssessment, proportionalityAssessment, legalBasis
// - (c) Risikobewertung: identifiedRisks, riskLevel, likelihood, impact
// - (d) Abhilfemaßnahmen: technicalMeasures, organizationalMeasures
//
// Warnungen:
// - DSB nicht konsultiert vor Genehmigung (Art. 35(4))
// - Restrisiko high/critical ohne Vorabkonsultation (Art. 36)
//
// Verhindert Genehmigung bei kritischen Mängeln

Reporting:

public function getDashboardStatistics(Tenant $tenant): array;
// Liefert: total, byStatus, highRisk, dueForReview, awaitingDPO, requiresSupervisory

public function calculateComplianceScore(DPIA $dpia): int;
// Score 0-100:
// - 40% Vollständigkeit (Art. 35(7) alle Felder)
// - 40% Genehmigungsstatus (approved = 100%, in_review = 50%, draft = 0%)
// - 20% Review-Compliance (nextReviewDate gesetzt und nicht überfällig?)

public function generateComplianceReport(DPIA $dpia): array;
// Detaillierter Compliance-Check pro DSFA

public function clone(DPIA $dpia): DPIA;
// Erstellt neue Version oder ähnliche DSFA

3. DataBreachService (Datenpannen-Service)

Location: src/Service/DataBreachService.php (744 Zeilen)

Zweck: Datenpannen-Management mit 72-Stunden-Frist (Art. 33/34 DSGVO)

CRUD mit Data Reuse:

public function createFromIncident(Incident $incident, array $data, Tenant $tenant): DataBreach;
// **Data Reuse!** Erstellt DataBreach aus Incident
// Vorbefüllung: title, severity, detectedAt
// Spart Zeit und vermeidet Doppeleingaben

public function update(DataBreach $breach, array $data): DataBreach;
public function delete(DataBreach $breach): void;

Workflow Art. 33/34:

public function submitForAssessment(DataBreach $breach): void;
// draft → under_assessment
// Validiert Vollständigkeit vor Übergang

public function notifySupervisoryAuthority(DataBreach $breach, array $data): void;
// Art. 33 - Meldung an Aufsichtsbehörde
// - Dokumentiert supervisoryAuthorityNotifiedAt
// - Prüft ob >72h (isAuthorityNotificationOverdue())
// - Loggt Warnung bei verspäteter Meldung
// - Status: → authority_notified

public function recordNotificationDelay(DataBreach $breach, string $reason): void;
// Art. 33(1) - Begründung bei verspäteter Meldung (>72h)
// Dokumentiert notificationDelayReason

public function notifyDataSubjects(DataBreach $breach, array $data): void;
// Art. 34 - Benachrichtigung betroffener Personen
// - Dokumentiert dataSubjectsNotifiedAt, subjectNotificationMethod
// - Status: → subjects_notified

public function recordSubjectNotificationExemption(DataBreach $breach, string $reason): void;
// Art. 34(3) - Ausnahmen von Benachrichtigungspflicht
// Optionen: encryption_protection, subsequent_measures, disproportionate_effort

public function close(DataBreach $breach): void;
// Schließt Datenpanne
// Validiert: Alle erforderlichen Meldungen durchgeführt?

public function reopen(DataBreach $breach): void;
// Öffnet geschlossene Datenpanne erneut

Query-Methoden:

public function findAll(Tenant $tenant): array;
public function findByStatus(Tenant $tenant, string $status): array;
public function findByRiskLevel(Tenant $tenant, string $riskLevel): array;
public function findHighRisk(Tenant $tenant): array;

// **KRITISCH** für Compliance:
public function findRequiringAuthorityNotification(Tenant $tenant): array;
// Datenpannen die gemeldet werden müssen (requiresAuthorityNotification = true)

public function findAuthorityNotificationOverdue(Tenant $tenant): array;
// **HÖCHSTE PRIORITÄT** - Meldungen >72h überfällig!

public function findRequiringSubjectNotification(Tenant $tenant): array;
// Art. 34 - Benachrichtigungspflicht betroffener Personen

public function findWithSpecialCategories(Tenant $tenant): array;
// Datenpannen mit Art. 9 Daten (höheres Risiko!)

public function findIncomplete(Tenant $tenant): array;
public function findByProcessingActivity(ProcessingActivity $activity): array;
public function findRecent(Tenant $tenant, int $days): array;

Statistiken & Compliance:

public function getDashboardStatistics(Tenant $tenant): array;
// Liefert:
// - total, byStatus, byRiskLevel
// - requiresAuthorityNotification (Anzahl)
// - authorityNotificationOverdue (Anzahl - **KRITISCH!**)
// - requiresSubjectNotification (Anzahl)
// - specialCategoriesAffected (Anzahl)

public function calculateComplianceScore(DataBreach $breach): int;
// Score 0-100:
// - 40% Meldungs-Compliance (alle erforderlichen Meldungen durchgeführt)
// - 40% Fristenkompliance (keine überfälligen Meldungen)
// - 20% Vollständigkeit (alle Felder ausgefüllt)

public function getActionItems(Tenant $tenant): array;
// Priorisierte Action-Liste:
// - CRITICAL: Überfällige Behördenmeldungen (>72h)
// - HIGH: Ausstehende Meldungen (<24h verbleibend)
// - MEDIUM: Benachrichtigung betroffener Personen
// - LOW: Unvollständige Datenpannen

Data Reuse Principles ⭐

Übersicht

Die Anwendung implementiert umfassende Data Reuse Patterns zur Optimierung von Datenschutz-Workflows und Zeitersparnis. Statt dieselben Informationen mehrfach manuell einzugeben, nutzt das System automatisch vorhandene Daten aus Incidents, Controls, Risks und Assets.

1. Incident → DataBreach Integration

Pattern: OneToOne-Beziehung (CASCADE delete)

Implementierung:

• DataBreach Entity hat OneToOne-Beziehung zu Incident
• DataBreachService::createFromIncident() befüllt DataBreach automatisch aus Incident
• Vorausgefüllte Felder: title, severity, detectedAt

Workflow-Optimierung:

Traditioneller Ansatz:
1. Incident erfassen (10 Min)
2. Separat DataBreach erstellen mit denselben Daten (10 Min)
3. Daten manuell synchron halten bei Änderungen (5 Min)
Gesamt: 25 Minuten

Data Reuse Ansatz:
1. Incident erfassen (10 Min)
2. "Als Datenpanne markieren" (30 Sek)
3. System befüllt automatisch DataBreach aus Incident (sofort)
4. Automatische Synchronisation bei Incident-Änderungen
Gesamt: 10,5 Minuten → 58% Zeitersparnis

Beispiel:

// Incident existiert bereits mit Details
$incident = $incidentRepository->find(42);
$incident->setTitle("Ransomware-Angriff auf Fileserver");
$incident->setSeverity("Critical");
$incident->setDetectedAt(new \DateTime("2024-11-20 08:30"));

// DataBreach aus Incident erstellen (Data Reuse!)
$breach = $dataBreachService->createFromIncident($incident, [
    'requiresAuthorityNotification' => true,
    'affectedDataSubjects' => 5000,
    'dataCategories' => ['Name', 'E-Mail', 'Kundennummer'],
]);

// System befüllt automatisch:
// - title: "Ransomware-Angriff auf Fileserver" (aus Incident)
// - severity: "Critical" (aus Incident)
// - detectedAt: 2024-11-20 08:30 (aus Incident)
// - incident: Verknüpfung zum Incident
//
// Manuell ergänzt: affectedDataSubjects, dataCategories

2. ProcessingActivity → DPIA Integration

Pattern: OneToOne-Beziehung (SET NULL on delete)

Implementierung:

• DPIA Entity hat OneToOne zu ProcessingActivity
• DPIA referenziert VVT-Eintrag für Datenkategorien, Zwecke, Rechtsgrundlage
• Bei DPIA-Genehmigung: ProcessingActivity.dpiaCompleted = true

Workflow-Optimierung:

Traditioneller Ansatz:
1. VVT-Eintrag erstellen (20 Min)
2. DSFA erstellen, alle Daten erneut eingeben (40 Min)
3. Bei VVT-Änderung: DSFA manuell aktualisieren (15 Min)
Gesamt: 75 Minuten

Data Reuse Ansatz:
1. VVT-Eintrag erstellen (20 Min)
2. DSFA erstellen, Daten aus VVT übernehmen (15 Min)
3. Bei VVT-Änderung: DSFA-Referenz bleibt aktuell
Gesamt: 35 Minuten → 53% Zeitersparnis

Beispiel:

// VVT-Eintrag existiert mit allen Details
$vvt = $processingActivityRepository->find(15);
$vvt->setName("Kundenverwaltung Online-Shop");
$vvt->setPurposes(['Vertragserfüllung', 'Marketing']);
$vvt->setDataCategories(['Name', 'Adresse', 'E-Mail', 'Kaufhistorie']);
$vvt->setLegalBasis('contract'); // Art. 6(1)(b)

// DSFA erstellen und VVT verknüpfen (Data Reuse!)
$dpia = new DataProtectionImpactAssessment();
$dpia->setProcessingActivity($vvt);

// System nutzt automatisch aus VVT:
// - dataCategories: ['Name', 'Adresse', 'E-Mail', 'Kaufhistorie']
// - dataSubjectCategories: aus VVT
// - processingPurposes: ['Vertragserfüllung', 'Marketing']
// - legalBasis: 'contract'
// - technicalOrganizationalMeasures: aus VVT.controls

// Bei VVT-Aktualisierung bleiben DSFA-Daten aktuell (Single Source of Truth)

3. ProcessingActivity → Control Integration

Pattern: ManyToMany-Beziehung

Implementierung:

• ProcessingActivity und DPIA beide verknüpft mit Control (ISO 27001)
• TOMs (Technische und organisatorische Maßnahmen) Art. 30(1)(g) nutzen bestehende ISMS-Controls
• Vermeidet Doppelpflege von Sicherheitsmaßnahmen

Workflow-Optimierung:

Traditioneller Ansatz:
1. ISO 27001 Controls im ISMS pflegen (100 Min)
2. TOMs für VVT separat dokumentieren (30 Min)
3. TOMs für DSFA separat dokumentieren (30 Min)
4. Bei Control-Änderung: 3x aktualisieren (45 Min)
Gesamt: 205 Minuten

Data Reuse Ansatz:
1. ISO 27001 Controls im ISMS pflegen (100 Min)
2. Controls mit VVT verknüpfen (5 Min)
3. Controls mit DSFA verknüpfen (5 Min)
4. Bei Control-Änderung: Automatisch überall aktuell
Gesamt: 110 Minuten → 46% Zeitersparnis

Beispiel:

// ISO 27001 Controls existieren bereits im ISMS
$controlEncryption = $controlRepository->findByAnnexId('A.8.24'); // Kryptographie
$controlEncryption->setImplementationStatus('Implemented');
$controlEncryption->setEffectiveness(90);

$controlAccessControl = $controlRepository->findByAnnexId('A.5.15'); // Zugriffskontrolle
$controlAccessControl->setImplementationStatus('Implemented');
$controlAccessControl->setEffectiveness(85);

// VVT verknüpft Controls für TOMs (Data Reuse!)
$vvt->addControl($controlEncryption);
$vvt->addControl($controlAccessControl);

// DSFA nutzt dieselben Controls (Data Reuse!)
$dpia->addControl($controlEncryption);
$dpia->addControl($controlAccessControl);

// Art. 30(1)(g) TOMs automatisch aus Controls:
// - A.8.24: "Kryptographische Maßnahmen (AES-256, TLS 1.3)"
// - A.5.15: "Zugangskontrolle (MFA, RBAC, Least Privilege)"
//
// Art. 35(7)(d) Abhilfemaßnahmen automatisch aus Controls:
// - Technische Maßnahmen: A.8.24 Verschlüsselung (90% effektiv)
// - Organisatorische Maßnahmen: A.5.15 Zugriffskontrolle (85% effektiv)

// Bei Control-Update: Automatisch in VVT + DSFA aktuell
$controlEncryption->setEffectiveness(95);
// Keine manuelle Aktualisierung in VVT/DSFA nötig!

4. ProcessingActivity → DataBreach Integration

Pattern: ManyToOne-Beziehung (SET NULL on delete)

Implementierung:

• DataBreach verknüpft zu betroffener ProcessingActivity
• Dokumentiert welcher VVT-Eintrag von Datenpanne betroffen
• Reporting: Datenpannen pro Verarbeitungstätigkeit

Workflow-Optimierung:

Traditioneller Ansatz:
1. Datenpanne feststellen (5 Min)
2. Manuell recherchieren welche Verarbeitungen betroffen (20 Min)
3. VVT-Details manuell in DataBreach kopieren (10 Min)
4. Reporting: Manuell aggregieren (15 Min)
Gesamt: 50 Minuten

Data Reuse Ansatz:
1. Datenpanne feststellen (5 Min)
2. ProcessingActivity aus Liste auswählen (2 Min)
3. Daten automatisch übernommen
4. Reporting: Automatisch aggregiert
Gesamt: 7 Minuten → 86% Zeitersparnis

Beispiel:

// Datenpanne betrifft bekannte Verarbeitungstätigkeit
$vvt = $processingActivityRepository->findByName("Bewerbermanagement");

$breach->setProcessingActivity($vvt);

// System nutzt automatisch aus VVT:
// - dataCategories: ['Name', 'Lebenslauf', 'Zeugnisse'] (aus VVT)
// - dataSubjectCategories: ['Bewerber'] (aus VVT)
// - legalBasis: 'contract' Art. 6(1)(b) (aus VVT)
// - specialCategoriesAffected: false (aus VVT.processesSpecialCategories)
//
// Reporting: "3 Datenpannen bei Verarbeitung 'Bewerbermanagement'"

5. Risk → ProcessingActivity Integration (Implizit)

Pattern: Feld-Level Integration

Implementierung:

• Risk Entity hat Felder: involvesGdprData, legalBasisForProcessing, requiresDpia
• Risiken können Erstellung von ProcessingActivity oder DPIA triggern
• DPIA referenziert Risk-Entity für identifizierte Privacy-Risiken

Workflow-Optimierung:

Traditioneller Ansatz:
1. Risikoassessment durchführen (45 Min)
2. DSGVO-Risiken separat identifizieren (30 Min)
3. Separat VVT erstellen (20 Min)
4. Separat DSFA erstellen (40 Min)
Gesamt: 135 Minuten

Data Reuse Ansatz:
1. Risikoassessment durchführen (45 Min)
2. Risiko markieren: involvesGdprData = true
3. System schlägt vor: VVT erstellen? (Klick)
4. System schlägt vor: DSFA erforderlich? (Klick)
5. Risiken automatisch in DSFA übernommen
Gesamt: 50 Minuten → 63% Zeitersparnis

Beispiel:

// Risiko identifiziert DSGVO-relevante Verarbeitung
$risk = new Risk();
$risk->setName("Unbefugter Zugriff auf Patientendaten");
$risk->setInvolvesGdprData(true);
$risk->setLegalBasisForProcessing('vital_interests'); // Art. 6(1)(d)
$risk->setRequiresDpia(true); // Art. 9 Gesundheitsdaten!

// System schlägt vor:
// "Dieses Risiko involviert DSGVO-Daten. VVT-Eintrag erstellen?"
// → Erstellt ProcessingActivity mit vorausgefüllten Daten aus Risk

// "Hohes Risiko erkannt. DSFA erforderlich (Art. 35(3))?"
// → Erstellt DPIA mit verknüpftem Risk

$dpia->setIdentifiedRisks([
    [
        'title' => 'Unbefugter Zugriff auf Patientendaten', // aus Risk.name
        'description' => $risk->getImpactDescription(),
        'likelihood' => 'likely',
        'impact' => 'severe',
        'severity' => 'critical'
    ]
]);

6. Asset → ProcessingActivity Integration (Konzeptionell)

Pattern: Noch nicht direkt implementiert, aber konzeptionell vorhanden

Potenzial:

• Assets können "Data Assets" sein (enthalten personenbezogene Daten)
• ProcessingActivity dokumentiert welche Assets PII speichern/verarbeiten
• Enhancement-Möglichkeit: ManyToMany-Beziehung zwischen Asset und ProcessingActivity

Workflow-Optimierung (bei Implementierung):

Ohne Asset-Integration:
1. Asset-Inventar pflegen (50 Min)
2. VVT erstellen, Assets manuell auflisten (20 Min)
3. Bei Asset-Änderung: VVT manuell aktualisieren (10 Min)
Gesamt: 80 Minuten

Mit Asset-Integration:
1. Asset-Inventar pflegen (50 Min)
2. VVT erstellen, Assets verknüpfen (5 Min)
3. Bei Asset-Änderung: VVT automatisch aktuell
Gesamt: 55 Minuten → 31% Zeitersparnis

Empfohlene Implementierung:

// Asset als "Data Asset" markieren
$asset = new Asset();
$asset->setName("CRM-Datenbank Kunden");
$asset->setAssetType('database');
$asset->setContainsPersonalData(true);
$asset->setDataCategories(['Name', 'Adresse', 'E-Mail', 'Telefon']);
$asset->setConfidentiality(5); // Höchste Vertraulichkeit

// VVT verknüpft Assets (Data Reuse!)
$vvt->addAsset($asset);

// System nutzt automatisch:
// - personalDataCategories: ['Name', 'Adresse', 'E-Mail', 'Telefon'] (aus Asset)
// - Speicherort: CRM-Datenbank (aus Asset.name)
// - TOMs: A.8.24 Verschlüsselung (aus Asset.controls)

7. BusinessProcess → ProcessingActivity Integration (Konzeptionell)

Pattern: Noch nicht direkt implementiert

Potenzial:

• BusinessProcess beschreibt operative Prozesse
• ProcessingActivity dokumentiert Datenverarbeitung innerhalb dieser Prozesse
• Logisches Mapping: Ein BusinessProcess kann mehrere ProcessingActivities umfassen

Workflow-Optimierung (bei Implementierung):

Ohne BusinessProcess-Integration:
1. Business Process Mapping (60 Min)
2. VVT separat erstellen (30 Min)
3. Verbindung manuell dokumentieren (15 Min)
Gesamt: 105 Minuten

Mit BusinessProcess-Integration:
1. Business Process Mapping (60 Min)
2. VVT aus BusinessProcess ableiten (10 Min)
3. Automatische Verknüpfung
Gesamt: 70 Minuten → 33% Zeitersparnis

Empfohlene Implementierung:

// Business Process mit Privacy-Aspekten
$process = new BusinessProcess();
$process->setName("Bestellabwicklung Online-Shop");
$process->setCriticalityLevel(4);

// VVT aus BusinessProcess ableiten
$vvt = new ProcessingActivity();
$vvt->setBusinessProcess($process);
$vvt->setName("Datenverarbeitung Bestellabwicklung");
$vvt->setPurposes(['Vertragserfüllung', 'Zahlungsabwicklung']);

// System nutzt:
// - Criticality aus BusinessProcess → isHighRisk
// - RTO/MTPD aus BusinessProcess → Retention-Anforderungen
// - Business Process Assets → ProcessingActivity Assets

DSGVO Compliance Guidance

Implementierte DSGVO-Artikel

Kapitel II - Grundsätze (Art. 5-11)

Art. 5(1)(a) - Rechtmäßigkeit, Verarbeitung nach Treu und Glauben, Transparenz:

• Implementierung: ProcessingActivity.legalBasis (6 Rechtsgrundlagen Art. 6(1))
• Nachweis: VVT dokumentiert Rechtsgrundlage pro Verarbeitung

Art. 5(2) - Rechenschaftspflicht (Accountability):

• Implementierung: AuditLogger für alle CRUD-Operationen
• Nachweis: Audit-Logs für processing_activity., dpia., data_breach.*

Art. 6(1) - Rechtmäßigkeit der Verarbeitung: ✅ Vollständig implementiert - 6 Rechtsgrundlagen in ProcessingActivity:

1. (a) Einwilligung - "consent"
2. (b) Vertragserfüllung - "contract"
3. (c) Rechtliche Verpflichtung - "legal_obligation"
4. (d) Schutz lebenswichtiger Interessen - "vital_interests"
5. (e) Öffentliches Interesse / öffentliche Gewalt - "public_task"
6. (f) Berechtigtes Interesse - "legitimate_interests" (+ Pflichtfeld legitimateInterestsJustification)

Art. 7 - Bedingungen für Einwilligung: ⚠️ Teilweise implementiert

• Einwilligung als Rechtsgrundlage vorhanden: ProcessingActivity.legalBasis = 'consent'
• Lücke: Keine dedizierte Consent-Entity
  • Kein Nachweis der Einwilligung (Art. 7(1))
  • Keine Widerrufsverfolgung (Art. 7(3))
  • Keine granulare Einwilligung pro Zweck

Art. 9 - Verarbeitung besonderer Kategorien: ✅ Vollständig implementiert - ProcessingActivity.processesSpecialCategories

• 10 Rechtsgrundlagen Art. 9(2): explicit_consent, employment_law, vital_interests, legal_claims, public_health, research_statistics, etc.
• Dokumentation: specialCategoriesTypes, specialCategoriesLegalBasis

Art. 10 - Verarbeitung strafrechtlicher Daten: ✅ Implementiert - ProcessingActivity.processesCriminalData

Kapitel III - Rechte der betroffenen Person (Art. 12-23)

Art. 12-14 - Transparenz, Information: ⚠️ Teilweise implementiert

• Verarbeitungszwecke dokumentiert in ProcessingActivity
• Lücke: Keine Datenschutzerklärungen-Verwaltung (Privacy Notice Management)

Art. 15 - Auskunftsrecht: ❌ NICHT implementiert

• Keine DataSubjectRequest-Entity
• Keine

…(truncated)