Compliance

Data Breach Response Policy

Incident handling and GDPR/DSGVO notification workflow

Brand: Nidai
Owner / Inhaber: Mohamed Essam Mohamed Shafey
Address / Anschrift: Frankfurter Allee 281, 10317 Berlin, Germany
Website: https://nidai.eu
Email / E-Mail: hallo@nidai.eu
Phone / Telefon: +49 157 51456670
Legal form / Rechtsform: Einzelunternehmen (sole proprietorship, not registered in the commercial register)
VAT / USt.: VAT is not charged pursuant to § 19 UStG (Kleinunternehmerregelung).
Tax / Steuer: Steuernummer pending; USt-IdNr. pending.

Purpose

This policy defines how Nidai detects, triages, contains, documents and communicates personal data breaches. When Nidai acts as processor, Nidai must notify the affected customer/controller without undue delay. The controller is generally responsible for authority/data-subject notification unless the contract says otherwise.

Incident Classification

Severity	Examples	Initial response target
Low	Suspicious login attempt, blocked attack, no confirmed personal data exposure	Document and monitor
Medium	Potential unauthorized access to limited customer records or misdirected email with non-sensitive data	Triage immediately, contain, notify internal owner
High	Confirmed unauthorized access, lost admin credential, exposure of documents/invoices/transcripts, sensitive data	Immediate containment and customer notification
Critical	Large-scale breach, special-category data, ransomware, public exposure, cross-customer data leak	Emergency response; external legal/forensic support

Response Steps

Detect and record time of awareness.
Preserve evidence: logs, screenshots, impacted systems, relevant commits/secrets.
Contain: revoke tokens, rotate secrets, disable affected accounts, isolate systems.
Assess scope: affected customers, data categories, data subjects, special categories, time window.
Determine Nidai role: controller or processor for each affected dataset.
Notify affected customer/controllers without undue delay when Nidai is processor.
Support controller with facts needed for potential Art. 33/34 notification.
Remediate root cause and verify fix.
Document facts, effects and remedial action in breach register.
Post-incident review and update TOMs/processes.

Breach Register Template

Field	Entry
Incident ID	[Complete]
Date/time detected	[Complete]
Date/time confirmed	[Complete]
Reporter	[Complete]
Systems affected	[Complete]
Customers affected	[Complete]
Data subjects affected	[Complete]
Data categories	[Complete]
Special categories?	[Complete]
Likely consequences	[Complete]
Containment actions	[Complete]
Customer notified?	[Complete]
Authority notified by controller?	[Complete]
Data subjects notified?	[Complete]
Root cause	[Complete]
Remediation	[Complete]
Lessons learned	[Complete]

Communication Rules

Do not guess publicly before facts are established.
Do not hide uncertainty; communicate what is known, unknown and being done.
Customer notification should include facts, data categories, approximate numbers, measures taken and recommended customer actions.
Keep all incident communications in one internal incident folder.