# Data Breach Response Plan

# Data Breach Response Plan

> **Organization:** Bilko — Balkan Accounting SaaS
> **Document Number:** IRP-BILKO-001
> **Version:** 1.0
> **Date:** 2026-02-23
> **Author:** Compliance Architect
> **Status:** Draft
> **Reviewers:** DPO, Legal Counsel, Engineering Lead, CEO
> **Next Review:** 2026-08-23
> **Classification:** Confidential — Restricted Distribution

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1 | 2026-02-23 | Compliance Architect | Initial draft — three-jurisdiction notification requirements RS/BA/HR |

---

## IMPORTANT — Keep This Document Accessible

> This plan must be accessible even when systems are down. Maintain offline copies and ensure key contacts are saved in personal phones.
> Key offline contacts: compliance@bilko.io | security@bilko.io | dpo@bilko.io

---

## 1. Incident Classification

| Severity | Definition | Response Team | Max Time to Classify |
|---------|-----------|--------------|---------------------|
| **P1 — Critical** | Confirmed breach of Restricted/Confidential data (tax IDs, IBAN, financial records) affecting any number of data subjects; OR active system compromise | Full IRT + Management + Legal | 1 hour |
| **P2 — High** | Suspected breach with evidence; or confirmed breach of Internal data; or targeted attack detected | Core IRT + Security Lead | 2 hours |
| **P3 — Medium** | Security event with potential for breach; precautionary action required | Security team | 8 hours |
| **P4 — Low** | Security anomaly, no confirmed breach | Security team | Next business day |

**72-hour notification trigger:** P1 and P2 MUST be assessed for regulatory notification obligation across all active jurisdictions (HR: AZOP; RS: Poverenik; BA: AZLP).

**Financial data sensitivity note:** Bilko handles invoices with national tax IDs (PIB/JMBG/OIB/JIB) and IBAN numbers. Any breach exposing these fields is automatically P1 — tax identity theft has severe consequences for data subjects.

---

## 2. Detection Mechanisms

| Detection Method | Tool | Responsible | Alert Channel |
|----------------|------|------------|--------------|
| Error rate spike | Sentry | Platform team | Slack #alerts |
| Railway API/CPU anomalies | Railway metrics | Platform team | Slack #alerts |
| Failed authentication spike (>10 in 1h) | Auth service logs | Platform team | Slack #alerts |
| Cloudflare WAF block spike | Cloudflare dashboard | Platform team | Email |
| Audit log anomalies (unusual DELETE patterns) | LoggedAction monitoring | Security team | Slack #alerts |
| Third-party notification | Vendor contacts us | Security email | security@bilko.io |
| User-reported | Support ticket | Support team | Escalate to security |
| Penetration test finding | External pen tester | Security team | Direct report |

**24/7 security contact:** security@bilko.io | compliance@bilko.io

---

## 3. Response Team Roles & Contacts

| Role | Primary | Backup | Email |
|------|---------|--------|-------|
| Incident Commander | CEO (Alem) | Engineering Lead | alem@alai.no |
| Security Lead | Compliance Architect | Engineering Lead | security@bilko.io |
| Engineering Lead | Lead Developer | — | engineering@bilko.io |
| DPO (GDPR/ZZPL/ZZLP) | TBD | Compliance Architect | dpo@bilko.io |
| Legal Counsel | External (TBD) | — | legal@bilko.io |
| Communications | CEO | — | alem@alai.no |

**External regulatory contacts (72-hour notification recipients):**

| Jurisdiction | Authority | Contact | When |
|-------------|-----------|---------|------|
| **Croatia (HR)** | AZOP — Agencija za zaštitu osobnih podataka | azop@azop.hr / https://azop.hr/prijavapovrede | P1/P2 within 72h (GDPR Art. 33) |
| **Serbia (RS)** | Poverenik za informacije od javnog značaja i zaštitu podataka o ličnosti | office@poverenik.rs / https://www.poverenik.rs | P1/P2 within 72h (ZZPL Art. 56) |
| **Bosnia & Herzegovina (BA)** | AZLP — Agencija za zaštitu ličnih podataka BiH | info@azlp.ba / https://www.azlp.ba | P1/P2 within 72h (best practice) |

**Notify ALL jurisdictions where affected data subjects reside.** If a breach affects data from multiple countries, notify all relevant authorities simultaneously.

---

## 4. Response Procedures by Phase

### Phase 1: Detection & Identification (0–1 hour)

**Goal:** Confirm whether a breach occurred and scope it.

```
Step 1.1 — ALERT RECEIVED
  □ Log initial alert time: ________________
  □ Create incident channel: #incident-{DATE}-{N}
  □ Assign to security lead
  □ Start incident log (chronological — everything goes in the log)

Step 1.2 — INITIAL ASSESSMENT (within 30 minutes)
  □ What triggered the alert?
  □ Is this a false positive? (if YES → close P4, document)
  □ What systems are affected? (api.bilko.io, Railway DB, Cloudflare R2, SEF/HR-FISK connections)
  □ Is the attack/leak ongoing?
  □ What data categories potentially affected? (tax IDs, IBAN, invoice data, user credentials)
  □ Which jurisdictions are affected? (RS, BA, HR, or multiple)

Step 1.3 — CLASSIFY INCIDENT
  □ Assign severity: P1 / P2 / P3 / P4
  □ Notify Incident Commander (CEO)
  □ If P1/P2: Activate full IRT immediately
  □ If P3/P4: Notify Security Lead

Step 1.4 — EVIDENCE PRESERVATION (CRITICAL — before containment if safe)
  □ Export Railway logs (30-day window around incident)
  □ Export Cloudflare logs
  □ Export Sentry error timeline
  □ Query LoggedAction: SELECT * FROM logged_actions WHERE action_timestamp > [incident_start]
  □ Screenshot anomalous metrics
  □ DO NOT wipe or restart affected systems until forensics complete
```

**Exit criteria:** Incident classified, IRT assembled, evidence preserved, 72h clock started if P1/P2.

---

### Phase 2: Containment (1–4 hours)

**Goal:** Stop the breach. Prevent further data exposure.

```
Step 2.1 — IMMEDIATE CONTAINMENT
  □ Revoke all JWT refresh tokens (DELETE FROM refresh_tokens — forces re-login for all users)
  □ Block malicious IP at Cloudflare WAF
  □ Disable compromised API endpoint if applicable
  □ Rotate JWT_SECRET and JWT_REFRESH_SECRET (all active sessions invalidated)
  □ Rotate FIELD_ENCRYPTION_KEY if database field encryption compromised
  □ Isolate affected Railway services if active exfiltration

Step 2.2 — SCOPE ASSESSMENT
  □ Which data was accessed/exfiltrated? (query LoggedAction + Railway logs)
  □ Which data subjects affected? (query: SELECT COUNT(*) and list affected organizationIds)
  □ What jurisdictions affected? (RS data subjects? BA? HR?)
  □ What time period? (from: ___ to: ___)
  □ Were tax IDs (PIB/JMBG/OIB/JIB) or IBAN exposed?
  □ Were authentication credentials (password hashes) exposed?
  □ Draft scope statement for DPO and legal review

Step 2.3 — ASSESS CONTAINMENT IMPACT
  □ What services are disrupted by containment actions?
  □ Inform support team of expected user disruption
  □ Prepare user communication if service unavailability expected
```

**Exit criteria:** Active threat contained, no ongoing exfiltration, scope defined, 72h countdown tracked.

---

### Phase 3: Eradication (4–24 hours)

**Goal:** Remove root cause. Ensure attacker completely out.

```
Step 3.1 — ROOT CAUSE ANALYSIS
  □ How did the attacker gain access? (SQL injection? JWT bypass? Compromised credentials? Cloudflare misconfiguration?)
  □ Was there a vulnerability in Prisma query construction?
  □ Was org-scoping WHERE clause bypassed?
  □ How long was access maintained?
  □ Were other organizations' data accessible?

Step 3.2 — REMEDIATE ROOT CAUSE
  □ Apply security patch
  □ Fix vulnerability (e.g., missing org-scope, Zod bypass, rate limit bypass)
  □ Remove any unauthorized database entries or backdoors
  □ Rotate all secrets and API keys

Step 3.3 — VERIFICATION
  □ Run Playwright security test suite
  □ Verify org-scoping isolation tests pass
  □ Verify RBAC tests pass
  □ Confirm no persistence mechanisms
```

---

### Phase 4: Recovery (24–72 hours)

**Goal:** Restore systems safely.

```
Step 4.1 — SAFE RESTORATION
  □ Deploy patched version
  □ Rotate ALL credentials on affected systems
  □ Enable enhanced monitoring for 30 days post-recovery
  □ Verify data integrity (compare LoggedAction against expected state)
  □ Re-enable services in stages

Step 4.2 — STAKEHOLDER UPDATES
  □ Update incident channel with progress
  □ Brief CEO
  □ Prepare regulatory notifications (see §5)
  □ Prepare customer communication if applicable
```

---

### Phase 5: Post-Incident (72 hours – ongoing)

```
Step 5.1 — POST-MORTEM (within 5 business days)
  □ Blameless post-mortem meeting
  □ Complete timeline of events
  □ Root cause analysis (5 Whys)
  □ What went well / what failed
  □ Action items with owners and deadlines

Step 5.2 — REGULATORY COMPLIANCE
  □ All regulatory notifications filed (see §5)
  □ Data subject notifications sent if required
  □ DPA customer notifications
  □ Insurance claim filed

Step 5.3 — REMEDIATION TRACKING
  □ All action items in issue tracker
  □ Weekly review for 4 weeks
  □ Update DPIA with lessons learned
  □ Update this response plan
```

---

## 5. Notification Requirements

### 5.1 Croatia — AZOP (GDPR Art. 33 — 72 hours)

**Legal basis:** GDPR Regulation (EU) 2016/679, Article 33
**Required if:** Breach likely to result in a risk to rights and freedoms of natural persons
**Deadline:** Within **72 hours** of becoming aware (not confirmed — aware)
**Partial notification allowed:** Submit what's known within 72h, supplement later

**Authority:** AZOP — Agencija za zaštitu osobnih podataka
**Portal:** https://azop.hr/prijavapovrede
**Email:** azop@azop.hr
**DPO submits:** dpo@bilko.io

**Required information:**
- Nature of breach (categories, number of data subjects, number of records)
- DPO contact details
- Likely consequences
- Measures taken or proposed

### 5.2 Serbia — Poverenik (ZZPL Art. 56 — 72 hours)

**Legal basis:** Zakon o zaštiti podataka o ličnosti, Article 56
**Required if:** Breach likely to result in risk to rights and freedoms of individuals
**Deadline:** Within **72 hours** of becoming aware

**Authority:** Poverenik za informacije od javnog značaja i zaštitu podataka o ličnosti
**Portal:** https://www.poverenik.rs
**Email:** office@poverenik.rs
**Address:** Bulevar kralja Aleksandra 15, 11000 Belgrade, Serbia

### 5.3 Bosnia & Herzegovina — AZLP (72 hours — best practice)

**Legal basis:** Zakon o zaštiti ličnih podataka BiH — breach notification not explicitly mandated in same detail as GDPR, but best practice is 72-hour notification following GDPR standard.
**Deadline:** 72 hours (voluntary/best practice)

**Authority:** AZLP — Agencija za zaštitu ličnih podataka Bosne i Hercegovine
**Email:** info@azlp.ba
**Address:** Hamdije Čemerlića 2/VI, 71000 Sarajevo, Bosnia & Herzegovina

### 5.4 Data Subject Notification (GDPR Art. 34 / ZZPL Art. 57)

**Required if:** Breach likely to result in HIGH risk to data subjects
**Timeline:** Without undue delay
**Method:** Direct email to affected users — individual, not public announcement

**Financial data breach — assess HIGH risk if:**
- Tax IDs (PIB/JMBG/OIB/JIB) exposed — identity theft risk
- IBAN exposed — financial fraud risk
- Password hashes exposed (weak hashing) — credential stuffing risk
- Note: bcrypt-hashed passwords with cost=12 are computationally infeasible to crack — assess as LOW risk even if hashes exposed

### 5.5 Multi-Jurisdiction Notification Checklist

```
□ Identify all affected data subjects by country
□ If Croatian users affected → notify AZOP within 72h
□ If Serbian users affected → notify Poverenik within 72h
□ If BiH users affected → notify AZLP within 72h (best practice)
□ If HIGH risk to any users → notify affected users directly (no undue delay)
□ If DPA customers affected → notify per DPA contract terms
□ Document all notifications with timestamp and reference number
```

---

## 6. Communication Templates

### 6.1 Internal Incident Alert

```
Subject: [INCIDENT P{SEVERITY}] Security Incident — Bilko — {DATE} {TIME}

Team,

Security incident detected. Details:

Incident ID: INC-BILKO-{DATE}-{N}
Severity: P{SEVERITY}
Detected: {DATE} {TIME} UTC
Jurisdictions potentially affected: {RS / BA / HR}
Data potentially affected: {tax IDs / IBAN / credentials / invoice data}
Status: ACTIVE — Containment in progress

Incident Commander: Alem (CEO)
Incident channel: #incident-{DATE}-{N}

72h regulatory notification clock started: {DATE} {TIME} UTC
Notification deadlines:
  - AZOP (HR): {DATE+72h}
  - Poverenik (RS): {DATE+72h}
  - AZLP (BA): {DATE+72h}

Do NOT discuss on public channels, with customers, or social media.
All communications through Alem.

Next update: {TIME} UTC
```

### 6.2 Data Subject Notification (Croatian / English)

```
Subject: Važna sigurnosna obavijest o vašem računu / Important security notice

Poštovani {IME} / Dear {FIRST_NAME},

Bilko (bilko.io) vas obavještava o sigurnosnom incidentu koji je mogao utjecati
na vaš račun.

Što se dogodilo / What happened:
Dana {DATUM}, saznali smo za neovlašteni pristup našim sustavima koji je mogao
izložiti vaše osobne podatke.

Koji podaci su zahvaćeni / Data potentially affected:
{KATEGORIJE_PODATAKA}

Što smo poduzeli / What we did:
- {MJERA_1}
- {MJERA_2}

Što trebate učiniti / What you should do:
- Promijenite lozinku na bilko.io / Change your password at bilko.io
- Omogućite dvofaktorsku autentikaciju / Enable two-factor authentication
- Pratite sumnjive aktivnosti / Monitor for suspicious activity

Za više informacija / For more information:
DPO: dpo@bilko.io
Privacy: bilko.io/privacy

Ispričavamo se za uzrokovanu neugodnost.
We sincerely apologize for any concern this may cause.

Bilko tim / Bilko Team
DPO: dpo@bilko.io
```

### 6.3 Regulatory Notification Draft (GDPR Art. 33 — for AZOP, Poverenik, AZLP)

```
To: {AUTHORITY_NAME} — {AUTHORITY_EMAIL}
From: {DPO_NAME}, DPO — Bilko (bilko.io)
Date: {DATE} {TIME} UTC

NOTIFICATION OF PERSONAL DATA BREACH

1. Nature of the breach:
   On {DATE}, we became aware of {unauthorized access to / accidental disclosure of}
   personal data processed by Bilko. The breach {is/was} {ONGOING/CONTAINED}.

2. Categories of data subjects and approximate numbers:
   - Data subjects: {NUMBER} (estimated)
   - Categories: {user account data / tax IDs (PIB/JMBG/OIB/JIB) / IBAN / invoice data}
   - Records: {NUMBER} (estimated)
   - Countries of affected data subjects: {RS / BA / HR}

3. Contact details of DPO:
   Name: {DPO_NAME}
   Email: dpo@bilko.io
   Organization: Bilko (bilko.io)

4. Likely consequences:
   {ASSESSMENT — e.g., "Tax ID exposure creates risk of identity theft; IBAN exposure creates risk of financial fraud"}

5. Measures taken or proposed:
   Immediate: {CONTAINMENT_MEASURES}
   Ongoing: {ONGOING_MEASURES}
   Planned: {REMEDIATION_MEASURES}

6. Note: This is a {complete / preliminary — supplementary notification to follow} report.

[DPO Signature]
{DPO_NAME}
dpo@bilko.io
```

---

## 7. Evidence Preservation

```
Evidence checklist:
□ Railway log export: all services, 30-day window around incident
□ Cloudflare log export: WAF events, access logs
□ Sentry: error events export
□ LoggedAction query: all mutations during incident window
  SELECT * FROM logged_actions WHERE action_timestamp BETWEEN '{start}' AND '{end}'
□ PostgreSQL: pg_stat_activity snapshot, connection history
□ Authentication logs: failed login attempts, token usage

Chain of custody:
- SHA-256 hash all exported files immediately after collection
- Record: filename, hash, collector, timestamp
- Storage: encrypted archive, access restricted to IRT
```

---

## 8. Drill Schedule

| Drill Type | Frequency | Participants | Scenario |
|-----------|-----------|------------|---------|
| Tabletop exercise | Quarterly | Full IRT + CEO | Tax ID breach / IBAN exposure / credential stuffing |
| Notification drill | Semi-annual | DPO + Legal | 72-hour multi-jurisdiction notification dry run |
| Technical response | Annual | Engineering + Security | Simulated org-scope bypass in staging |

**Last drill:** Not yet conducted — schedule within 30 days of product launch
**Drill coordinator:** Compliance Architect (security@bilko.io)

---

## Approval
| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | Compliance Architect | 2026-02-23 | |
| DPO | | | |
| Legal Counsel | | | |
| CEO | | | |