Data Breach Response Plan

Data Breach Response Plan

Organization: ALAI Holding ASBilko — DropBalkan PaymentAccounting AppSaaS Document Number: IRP-DROP-BREACH-BILKO-001 Version: 1.0 Date: 2026-02-23 Author: ALAICompliance Security TeamArchitect Status: Draft — Approved for use (requires named contacts when team is hired) Reviewers: CISO, DPO, Legal CounselCounsel, Engineering Lead, CEO Next Review: 2027-02-2026-08-23 (annual) or after any P1/P2 incident Classification: Confidential — Restricted Distribution

Document History

Sources: legal/hendelseshaandtering.md (IRP-DROP-001), legal/ikt-sikkerhetspolicy.md §9, legal/personvernerklaering.md

IMPORTANT — Keep This Document Accessible

This plan must be accessible even when systems are down. Maintain:

Maintain

offline
• Offlinecopies copyand ensure key contacts are saved in printed form at office location
• Encrypted copy in a non-Drop system (personal emailphones. /Key offline storage)contacts: Offline[email protected] copy| last[email protected] updated:| 2026-02-23

[email protected]

1. Incident Classification

Drop processes sensitive financial data (fødselsnummer, bank accounts, transaction data) regulated by GDPR, DORA, and Hvitvaskingsloven. Classification determines urgency and regulatory notification obligations.

GDPR72-hour notification trigger: P1 and P2 incidents MUST be assessed for 72-hour Datatilsynetregulatory notification obligation.obligation DORAacross notificationall trigger:active P1 and major P2 incidents MUST be assessed for Finanstilsynet reportingjurisdictions (initial:HR: 4h,AZOP; intermediate:RS: 72h,Poverenik; final:BA: 1 month)AZLP).

Source:Financial data sensitivity note: legal/hendelseshaandtering.mdBilko §3handles 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

24/7 security contact: Alem Bašić (CISO) — +47 40 47 42 51[email protected] | [email protected] Security email: [email protected] (planned — forward to [email protected])[email protected]

3. Response Team Roles & Contacts

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

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: ________________
  □ Assign to on-call engineer (Alem Bašić until team hired)
  □ Create incident channel: #incident-{DATE}-{N}
  (Slack)□ Assign to security lead
  □ Start incident log (chronological — chronological,everything everythinggoes in the loglog)

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? (authentication,api.bilko.io, transactions,Railway KYC,DB, AMLCloudflare data)R2, SEF/HR-FISK connections)
  □ Is the attack/leak ongoing?
  □ What data categories potentially affected? -(tax FødselsnummerIDs, IBAN, invoice data, user credentials)
  □ Which jurisdictions are affected? (nationalRS, ID)?BA, →HR, CRITICALor — Datatilsynet notification likely
    - Bank account data? → CRITICAL
    - Transaction data? → HIGH
    - Email/phone only? → MEDIUMmultiple)

Step 1.3 — CLASSIFY INCIDENT
  (P1/P2/P3/P4)
  □ Assign severityseverity: usingP1 criteria/ inP2 §1/ P3 / P4
  □ Notify Incident Commander (CEO)
  □ If P1/P2: NotifyActivate allfull IRT roles immediately
  □ If P3/P4: Notify CISOSecurity Lead

Step 1.4 — EVIDENCE PRESERVATION (CRITICAL — before containment if safe)
  □ Export SentryRailway eventslogs for the incident time(30-day window around incident)
  □ Export database queryCloudflare logs
  □ TakeExport snapshotSentry oferror applicationtimeline
  logs□ Query LoggedAction: SELECT * FROM logged_actions WHERE action_timestamp > [incident_start]
  □ Screenshot systemanomalous state
  □ Export AWS CloudTrail logs (Phase 2 — when on AWS)metrics
  □ DO NOT wipe or restart affected systems until evidenceforensics collectedcomplete

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

Phase 2: Containment (1–4 hours)

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

Step 2.1 — IMMEDIATE CONTAINMENT
  □ Revoke compromisedall userJWT sessionsrefresh tokens (server-sideDELETE sessionFROM revocation)refresh_tokens □— Revokeforces compromisedre-login APIfor keysall / JWT_SECRET rotation if compromisedusers)
  □ Block malicious IP addresses at WAF/Cloudflare (Phase 2)WAF
  □ Disable vulnerablecompromised API endpoint if applicable
  □ Rotate JWT_SECRET and JWT_REFRESH_SECRET (featureall flagactive orsessions route removal)invalidated)
  □ IfRotate FIELD_ENCRYPTION_KEY if database field encryption compromised
  □ Isolate affected Railway services if active exfiltration: take service offline temporarilyexfiltration

Step 2.2 — DROP-SPECIFIC CONTAINMENT ACTIONS
  □ If auth compromise: Revoke ALL active sessions (UPDATE sessions SET revoked=1)
  □ If KYC data breach: Notify Sumsub (legal/dpa-sumsub.md contact)
  □ If banking data breach: Notify Neonomics/Swan (legal/dpa-swan.md contact)
  □ If BankID compromise: Contact BankID Norge AS immediately
  □ If AML data involved: Preserve for EFE — do NOT delete

Step 2.3 — SCOPE ASSESSMENT
  □ Which data was accessed/exfiltrated? (query LoggedAction + Railway logs)
  □ Which data subjects areaffected? (query: SELECT COUNT(*) and list affected organizationIds)
  □ What jurisdictions affected? (queryRS usersdata tablesubjects? forBA? affected records)HR?)
  □ What time period does the breach cover?period? (fromfrom: ___ toto: ___)
  □ WasWere datatax transferredIDs outside(PIB/JMBG/OIB/JIB) Norway/EEA?or IBAN exposed?
  □ Were authentication credentials (password hashes) exposed?
  □ Draft scope statement for DPO/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.defined, 72h countdown tracked.

Phase 3: Eradication (4–24 hours)

Goal: Remove the root causecause. entirely.Ensure attacker completely out.

Step 3.1 — ROOT CAUSE ANALYSIS
  □ How did the attacker gain access? (entry vector)
  □ What vulnerability was exploited?
    - Auth bypass?
    - SQL injection? (allJWT queries are parameterized — check for gaps)
    -bypass? Compromised credential?credentials? -Cloudflare Dependencymisconfiguration?)
  vulnerability?□ -Was Insiderthere threat?a vulnerability in Prisma query construction?
  □ Was org-scoping WHERE clause bypassed?
  □ How long didwas theaccess attacker have access?maintained?
  □ Were other systemsorganizations' reachabledata from compromised system?accessible?

Step 3.2 — REMEDIATE ROOT CAUSE
  □ Apply security patch
  or□ configurationFix fixvulnerability (e.g., missing org-scope, Zod bypass, rate limit bypass)
  □ Remove any unauthorized accountsdatabase entries or session tokensbackdoors
  □ Rotate: JWT_SECRET, database passwords,Rotate all secrets and API keys
  □ Update vulnerable dependency (per remediation SLAs: Critical → 24h, High → 7 days)

Step 3.3 — VERIFICATION
  □ SecurityRun teamPlaywright confirmssecurity test suite
  □ Verify org-scoping isolation tests pass
  □ Verify RBAC tests pass
  □ Confirm no persistence mechanisms
remain
  □ Re-run security audit on affected components
  □ Review similar endpoints for same vulnerability pattern

Exit criteria: Root cause identified and eliminated. No attacker persistence.

Phase 4: Recovery (24–72 hours)

Goal: Restore systems to full operation safely.

Step 4.1 — SAFE RESTORATION
  □ RestoreDeploy frompatched known-good state or deploy fresh buildversion
  □ Rotate ALL credentials (JWT_SECRET,on DBaffected passwords,systems
  third-party□ APIEnable keys)enhanced monitoring for 30 days post-recovery
  □ Verify data integrity (compare LoggedAction against backupsexpected state)
  □ Re-enable services incrementallyin (not all at once)
  □ Deploy with enhanced logging verbositystages

Step 4.2 — ENHANCED MONITORING (30 days post-incident)
  □ Increase Sentry alert sensitivity
  □ Add specific rate limit rules for repeat attack patterns
  □ Daily security check for 7 days post-recovery
  □ AML review of all transactions during breach window

Step 4.3 — STAKEHOLDER UPDATES
  □ Update incident channel with recovery progress
  □ Brief management (Alem Bašić)CEO
  □ Prepare userregulatory notifications (see §5)
  □ Prepare customer communication if applicable
(see §6.2)
  □ Prepare Finanstilsynet notification if DORA-reportable (see §5.1)

Exit criteria: Systems operational. Enhanced monitoring in place. Notifications sent.

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

Goal: Learn, prevent recurrence, meet legal obligations.

Step 5.1 — POST-MORTEM (within 5 business days for P1/P2)days)
  □ Blameless post-mortem meeting
  □ Complete timeline of events
  (minute-by-minute)
  □ Root cause analysis (5 Whys)
  □ What went well?well □/ Whatwhat failed? (detection gaps, response gaps, communication gaps)failed
  □ Action items with owners and deadlines

□ Publish post-mortem report

Step 5.2 — REGULATORY COMPLIANCE
  □ All regulatory notifications filed (see §5)
  □ Datatilsynet notification (GDPR — 72h deadline)
  □ Finanstilsynet notification (DORA — if major ICT incident)
  □ Data subject notifications (sent if high risk — without undue delay)required
  □ AMLDPA notificationcustomer tonotifications
  EFE□ ifInsurance breachclaim involved AML-relevant datafiled

Step 5.3 — REMEDIATION TRACKING
  □ All action items in issue tracker
  □ Weekly review for 4 weeks
  □ Update threat modelDPIA with newlessons attack vectorlearned
  □ Update this response plan based on lessons learned

5. Notification Requirements

5.1 DatatilsynetCroatia — AZOP (GDPR SupervisoryArt. Authority33 (— 72 hours)

Legal basis: GDPR Art.Regulation (EU) 2016/679, Article 33 /Required Personopplysningsloven

Breach likely to result in a risk to rights and freedoms of natural persons Deadline: Within 72 hours of becoming aware of(not theconfirmed breach— 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: [email protected] DPO submits: [email protected]

Required onlyinformation:

• 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 is likely to result in risk to rights and freedoms of dataindividuals subjectsDeadline: Within 72 hours of becoming aware

What to report (GDPR Art. 33(3)):

• Nature of breach: categories and approximate number of data subjects and records
• Contact details of DPO
• Likely consequences of the breach
• Measures taken or proposed to address the breach

Supervisory Authority: DatatilsynetPoverenik za informacije od javnog značaja i zaštitu podataka o ličnosti Notification portal:Portal: https://www.datatilsynet.no/personvern-pa-ulike-omrader/virksomheter-og-sikkerhet/brudd-pa-personopplysningssikkerhet/poverenik.rs Submitted by:Email: DPO[email protected] (once appointed) — interim: Alem Bašić

Partial notification allowed:Address: SubmitBulevar what'skralja knownAleksandra within15, 72h,11000 supplementBelgrade, later.Serbia

5.23 FinanstilsynetBosnia & Herzegovina — DORAAZLP ICT(72 Incidenthours Reporting— best practice)

Legal basis: DORAZakon Art.o 19zaštiti (applicableličnih podataka BiH — breach notification not explicitly mandated in Norwaysame est.detail 2026as H2)GDPR, /but IKT-forskriftenbest practice is 72-hour notification following GDPR standard. Deadline: 72 hours (voluntary/best practice)

Reporting thresholds (when an incident is "major"):

• Affects critical payment services
• Affects significant number of users
• Causes or may cause significant economic loss
• Causes data loss or confidentiality compromise
• Has reputational consequences

Contact:Authority: [email protected]AZLP — Agencija za zaštitu ličnih podataka Bosne i Hercegovine Email: [email protected] Address: Hamdije Čemerlića 2/VI, 71000 Sarajevo, Bosnia & Herzegovina

5.3 GDPR —4 Data Subject Notification

Legal basis: (GDPR Art. 34

Required if: Breach is likely to result in HIGH risk to data subjects

Timeline: Without undue delay (immediate after confirming high risk)

Method: EmailDirect email to affected users +— in-appindividual, pushnot notificationpublic + SMS if availableannouncement

NotFinancial requireddata breach — assess HIGH risk if:

was
• Tax encryptedIDs and(PIB/JMBG/OIB/JIB) keyexposed not— compromisedidentity ORtheft post-breachrisk
measures
• IBAN ensureexposed high— 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 no longer likely

  5.4 AML — EFE Notification

  When: If breach involved AML-relevant data (transaction data, KYC records) and there is suspicion of money laundering or terrorist financing

  Contact: EFE (Enheten for finansiell etterretning) via Altinn

  Important: Do NOT inform the customereven if STRhashes (suspiciousexposed

transaction report) has been or will be filed — TIPPING OFF is prohibited (hvvl. §28)

5.5 ContractualMulti-Jurisdiction ObligationsNotification Checklist

□ 

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

UTC

Team,

WeSecurity haveincident identified a 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 Bašić(CEO)
Incident channel: #incident-{DATE}-{N}

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

Do NOT discuss this incident on public channels, with users,customers, or on social media.
All external communications go through the Incident Commander.Alem.

Next update: {TIME} UTC

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

regardingPoštovani your{IME} Drop account/ Dear {FIRST_NAME},

WeBilko are(bilko.io) writingvas toobavještava informo yousigurnosnom ofincidentu akoji securityje incidentmogao thatutjecati
mayna havevaš affectedračun.

yourŠto account.se dogodilo / What happened:
On approximatelyDana {DATE}DATUM}, wesaznali becamesmo awareza ofneovlašteni apristup securitynašim incidentsustavima involvingkoji unauthorizedje accessmogao
toizložiti systemsvaše containingosobne personalpodatke.

informationKoji associatedpodaci withsu yourzahvaćeni Drop/ account.Data Whatpotentially information was involved:
The following information may have been accessed:affected:
{DATA_CATEGORIES}KATEGORIJE_PODATAKA}

[e.g.,Što name,smo emailpoduzeli address, phone number, transaction history]/ What we have done:did:
- Contained the security incident and eliminated the threat{MJERA_1}
- Revoked{MJERA_2}

allŠto activetrebate sessionsučiniti (you will need to log in again)
- Notified the Norwegian Data Protection Authority (Datatilsynet)
- Enhanced monitoring and security measures/ What you should do:
- LogPromijenite backlozinku intona bilko.io / Change your Droppassword accountat and verify your account detailsbilko.io
- MonitorOmogućite yourdvofaktorsku bankautentikaciju accounts/ forEnable anytwo-factor unauthorized transactionsauthentication
- ContactPratite yoursumnjive bankaktivnosti if/ youMonitor notice anyfor suspicious activity

-Za Ifviše youinformacija have concerns: contact [email protected]/ For more information:
DataDPO: Protection[email protected]
Officer:Privacy: [email protected]bilko.io/privacy

PrivacyIspričavamo Policy:se https://getdrop.no/personvernza Datatilsynet:uzrokovanu www.datatilsynet.noneugodnost.
We take the security of your information very seriously and sincerely apologize for any concern this may cause.

Regards,Bilko Droptim —/ ALAIBilko HoldingTeam
ASDPO: Data Protection Officer: {DPO_NAME}[email protected]

To: Datatilsynet{AUTHORITY_NAME} — {AUTHORITY_EMAIL}
From: {DPO_NAME}, DPO — ALAI Holding ASBilko (Drop)bilko.io)
Date: {DATE} {TIME} UTC

NOTIFICATION OF PERSONAL DATA BREACH (GDPR Art. 33)
Organization: ALAI Holding AS, org.nr. 932 516 136
Product: Drop (getdrop.no)

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

2. Categories and approximate number of data subjects concerned:and approximate numbers:
   - Data subjects: {NUMBER} (estimated)
   - Categories: {DATA_CATEGORIESuser —account e.g.,data name,/ email,tax transactionIDs data,(PIB/JMBG/OIB/JIB) fødselsnummer}/ IBAN / invoice data}
   - EstimatedRecords: {NUMBER} (estimated)
   - Countries of affected data subjects: {NUMBER}RS -/ EstimatedBA affected/ records: {NUMBER}HR}

3. Categories and approximate number of personal data records:
   {RECORD_CATEGORIES_AND_COUNTS}

4. Contact details of DPO:
   Name: {DPO_NAME}
   Email: [email protected][email protected]
   Phone:Organization: {DPO_PHONE}Bilko 5.(bilko.io)

4. Likely consequences of the breach:consequences:
   {CONSEQUENCESASSESSMENT — e.g., "Tax ID exposure creates risk of identity thefttheft; risk,IBAN exposure creates risk of financial harm,fraud"}

reputational damage}

6.5. Measures taken or proposed:
   - Immediate: {MEASURES — e.g., sessions revoked, systems patched, credentials rotated}
   -CONTAINMENT_MEASURES}
   Ongoing: Enhanced monitoring for 30 days
   -{ONGOING_MEASURES}
   Planned: {PLANNED_MEASURES}REMEDIATION_MEASURES}

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

[DPO Signature]

To: [email protected]
From: CISO — ALAI Holding AS (Drop)
Date: {DATE} {TIME} UTC

INITIAL REPORT — IKT-HENDELSE (DORA Art. 19)
Organization: ALAI Holding AS, org.nr. 932 516 136
Product: Drop (betalingsformidling og pengeoverføringer)

1. Hendelsestype: {TYPE — sikkerhetshendelse/databrudd/DDoS/etc.}
2. Tidspunkt oppdaget: {DATE TIME}
3. Berørte tjenester: {betalingstjenester/AISP/PISP/KYC}
4. Innledende konsekvens: {beskrivelse}
5. Iverksatte tiltak: {containment-tiltak}
6. Status: {Pågående/Inneholdt}
7. Kontaktperson: Alem Bašić, CISO — [email protected] / +47 40 47 42 51

Intermediær rapport følger innen 72 timer.[email protected]

Evidence collection checklist:
□ ExportRailway Sentrylog errorexport: events:all Fullservices, time30-day window + 24h beforearound incident
□ ExportCloudflare applicationlog logs:export: Authentication,WAF transaction, APIevents, access logs
□ ExportSentry: rate_limitserror tableevents snapshotexport
□ ExportLoggedAction sessionsquery: table:all All active sessionsmutations during incident window
  □SELECT Export* affectedFROM users/transactions:logged_actions ScopedWHERE toaction_timestamp breachBETWEEN window'{start}' AND '{end}'
□ ExportPostgreSQL: AWSpg_stat_activity CloudTrailsnapshot, logsconnection (Phase 2 — when on AWS)history
□ NetworkAuthentication trafficlogs: capturefailed (tcpdump)login ifattempts, attacktoken is ongoing
□ Screenshot: System state, Sentry dashboard, affected endpointsusage

Chain of custody:
- All evidence files: SHA-256 hash computedall exported files immediately after collection
- HashRecord: log:filename, evidence/chain-of-custody.txthash, collector, timestamp
- Storage: Write-protected encrypted volume,archive, access loggedrestricted -to Custody transfers: Documented with timestampsIRT