Data Breach Response Plan

Data Breach Response Plan

Organization: BilkoALAI Holding AS — BalkanDrop AccountingPayment SaaSApp Document Number: IRP-BILKO-DROP-BREACH-001 Version: 1.0 Date: 2026-02-23 Author: ComplianceALAI ArchitectSecurity Team Status: Draft — Approved for use (requires named contacts when team is hired) Reviewers: CISO, DPO, Legal Counsel, Engineering Lead, CEOCounsel Next Review: 2026-08-2027-02-23 (annual) or after any P1/P2 incident Classification: Confidential — Restricted Distribution

Document History

notificationrequirementsRS/BA/HR

Version	Date	Author	Changes
0.1	2026-02-2312	Compliance ArchitectAgent (ALAI)	Initial draftplan —(legal/hendelseshaandtering.md, three-jurisdictionlegal/beredskapsplan.md)
1.0	2026-02-23	Security Architect (ALAI)	English compliance template format

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. MaintainMaintain:

• Offline copy in printed form at office location
• Encrypted copy in a non-Drop system (personal email / offline copiesstorage) andOffline ensurecopy keylast contactsupdated: are2026-02-23
saved in personal phones. Key offline contacts: [email protected] | [email protected] | [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.

Severity	Definition	Response Team	Max Time to Classify
P1 — Critical	Confirmed breach of Restricted/Confidentialfinancial/PII datadata; (taxfull IDs,service IBAN,outage; financialactive records)cyberattack; encryption key compromise; incident affecting any number>10% of data subjects; OR active system compromiseusers	Full IRT + Management + Legal	1 hour
P2 — High	Suspected breach with evidence; or confirmed breachinternal ofdata Internalbreach; data;compromised oradmin targetedaccount; attackunauthorized detectedproduction access; critical vendor incident	Core IRT + Security LeadCISO	2 hours
P3 — Medium	Security event with potentialbreach for breach;potential; precautionary actioncontainment; requiredhigh CVSS vulnerability in production	Security team	8 hours
P4 — Low	Security anomaly,anomaly; no confirmed breachbreach; elevated monitoring	Security team	Next business day

72-hourGDPR notification trigger: P1 and P2 incidents MUST be assessed for regulatory72-hour Datatilsynet notification obligationobligation. acrossDORA allnotification activetrigger: jurisdictionsP1 and major P2 incidents MUST be assessed for Finanstilsynet reporting (HR:initial: AZOP;4h, RS:intermediate: Poverenik;72h, BA:final: AZLP)1 month).

Financial data sensitivity note:Source: Bilkolegal/hendelseshaandtering.md 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.§3

---

2. Detection Mechanisms

Compliance

Detection Method	Tool	Responsible	Alert Channel
Error rate spikemonitoring	Sentry	Platform team	SlackSentry #alertsalerts → email
RailwaySIEM API/CPU anomaliesalerts	RailwayTBD metrics(Phase 3)	Platform team	PagerDuty (planned)
Anomalous API traffic	Rate limiting logs, WAF (Phase 2)	Platform team	Slack #alerts#security-alerts
Failed authentication spike (>10 in 1h)	Auth service logs + rate limit table	Platform team	SlackManual #alertsmonitoring
CloudflareAML WAFtransaction block spikeflagging	CloudflareTransaction dashboardmonitoring rules	PlatformCompliance team	Email
Audit log anomalies (unusual DELETE patterns)	LoggedAction monitoring	Security team	Slack #alertsdashboard
Third-party notification	Vendor contacts usDrop	SecurityCISO email	[email protected][email protected]
User-reported	Support ticket / App contact form	Support team	Escalate to securityCISO
Penetration test finding	External pen tester	Security team	Direct report to CISO
Sumsub KYC alert	Sumsub webhook	Platform team	Sumsub dashboard
BankID anomaly	BankID Norge AS notification	CISO	Direct notification

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

---

3. Response Team Roles & Contacts

Alem

Role	Primary	BackupContact	EmailBackup
Incident Commander	CEOAlem Bašić (Alem)CEO/CISO)	Engineering+47 Lead40 47 42 51 / [email protected]	[email protected]TBD
Security Lead / CISO	ComplianceAlem ArchitectBašić	Engineering+47 Lead40 47 42 51 / [email protected]	[email protected]TBD
Engineering Lead	LeadTBD Developer(hire required)	—TBD	[email protected]TBD
DPO (GDPR/ZZPL/ZZLP)GDPR)	TBD (appointment required)	Compliance Architect[email protected]	[email protected]TBD
Legal Counsel	ExternalTBD (TBD)engagement required)	—TBD	[email protected]TBD
Communications Lead	CEO	—Bašić (until comms hire)	[email protected]	TBD
AML Compliance Officer	TBD (appointment required)	TBD	TBD

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

within72h

Jurisdiction	AuthorityParty	Contact	When
CroatiaDatatilsynet (HR)GDPR supervisory authority)	AZOPwww.datatilsynet.no —/ Agencijatelefon: za22 zaštitu39 osobnih69 podataka00	[email protected] / https://azop.hr/prijavapovrede	P1/P2P1 within 72h (GDPRif Art. 33)breach
SerbiaFinanstilsynet (RS)PSD2/DORA authority)	Poverenik za informacije od javnog značaja i zaštitu podataka o ličnosti[email protected]	[email protected] / https://www.poverenik.rs	P1/P2P1 within 72h4h (ZZPLif Art.major 56)incident
Bosnia & HerzegovinaEFE (BA)Enheten for finansiell etterretning — AML)	AZLPVia Altinn	Suspicious transactions
NorCERT / NCSC	www.nsm.no	P1 cyberattacks
FinansCERT	finanscert.no	Financial sector incidents
Cyber insurance	TBD — Agencijapolicy zanot zaštituyet ličnih podataka BiH	[email protected] / https://www.azlp.baobtained	P1/P2
Forensics firm	TBD — retainer not yet in place	P1
Police (bestKripos practice)cybercrime)	02800	Confirmed criminal activity

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} □ Assign to security lead(Slack)
  □ Start incident log (chronological — chronological, everything goes in the log)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,authentication, Railwaytransactions, DB,KYC, CloudflareAML R2, SEF/HR-FISK connections)data)
  □ Is the attack/leak ongoing?
  □ What data categories potentially affected?
    (tax- IDs, IBAN, invoice data, user credentials)
  □ Which jurisdictions are affected?Fødselsnummer (RS,national BA,ID)? HR,→ orCRITICAL multiple)— Datatilsynet notification likely
    - Bank account data? → CRITICAL
    - Transaction data? → HIGH
    - Email/phone only? → MEDIUM

Step 1.3 — CLASSIFY INCIDENT (P1/P2/P3/P4)
  □ Assign severity:severity P1using /criteria P2in / P3 / P4
  □ Notify Incident Commander (CEO)§1
  □ If P1/P2: ActivateNotify fullall IRT roles immediately
  □ If P3/P4: Notify Security LeadCISO

Step 1.4 — EVIDENCE PRESERVATION (CRITICAL — before containment if safe)
  □ Export RailwaySentry logsevents (30-dayfor the incident time window around incident)
  □ Export Cloudflaredatabase query logs
  □ ExportTake Sentrysnapshot errorof timelineapplication □ Query LoggedAction: SELECT * FROM logged_actions WHERE action_timestamp > [incident_start]logs
  □ Screenshot anomaloussystem metricsstate
  □ Export AWS CloudTrail logs (Phase 2 — when on AWS)
  □ DO NOT wipe or restart affected systems until forensicsevidence completecollected

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

---

Phase 2: Containment (1–4 hours)

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

Step 2.1 — IMMEDIATE CONTAINMENT
  □ Revoke allcompromised JWTuser refresh tokenssessions (DELETEserver-side FROMsession refresh_tokensrevocation)
  —□ forcesRevoke re-logincompromised forAPI allkeys users)/ JWT_SECRET rotation if compromised
  □ Block malicious IP addresses at WAF/Cloudflare WAF(Phase 2)
  □ Disable compromised APIvulnerable endpoint if applicable (feature flag or route removal)
  □ RotateIf JWT_SECRETactive andexfiltration: JWT_REFRESH_SECRETtake (allservice offline temporarily

Step 2.2 — DROP-SPECIFIC CONTAINMENT ACTIONS
  □ If auth compromise: Revoke ALL active sessions invalidated)(UPDATE sessions SET revoked=1)
  □ RotateIf FIELD_ENCRYPTION_KEYKYC ifdata databasebreach: fieldNotify encryptionSumsub compromised(legal/dpa-sumsub.md contact)
  □ IsolateIf affectedbanking Railwaydata servicesbreach: ifNotify activeNeonomics/Swan exfiltration(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.23 — SCOPE ASSESSMENT
  □ Which data was accessed/exfiltrated?
  (query LoggedAction + Railway logs)
  □ Which data subjects affected? (query: SELECT COUNT(*) and list affected organizationIds)
  □ What jurisdictionsare affected? (RSquery datausers subjects?table BA?for HR?)affected records)
  □ What time period?period does the breach cover? (from:from ___ to:to ___)
  □ WereWas taxdata IDstransferred (PIB/JMBG/OIB/JIB)outside or IBAN exposed?
  □ Were authentication credentials (password hashes) exposed?Norway/EEA?
  □ Draft scope statement for DPO and DPO/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.defined.

---

Phase 3: Eradication (4–24 hours)

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

Step 3.1 — ROOT CAUSE ANALYSIS
  □ How did the attacker gain access? (entry vector)
  □ What vulnerability was exploited?
    - Auth bypass?
    - SQL injection? JWT(all bypass?queries are parameterized — check for gaps)
    - Compromised credentials?credential?
    Cloudflare- misconfiguration?)Dependency □vulnerability?
    Was- thereInsider a vulnerability in Prisma query construction?
  □ Was org-scoping WHERE clause bypassed?threat?
  □ How long wasdid accessthe maintained?attacker have access?
  □ Were other organizations'systems datareachable accessible?from compromised system?

Step 3.2 — REMEDIATE ROOT CAUSE
  □ Apply security patch □or Fixconfiguration vulnerability (e.g., missing org-scope, Zod bypass, rate limit bypass)fix
  □ Remove anyunauthorized unauthorizedaccounts or session tokens
  □ Rotate: JWT_SECRET, database entries or backdoors
  □ Rotatepasswords, all secrets and API keys
  □ Update vulnerable dependency (per remediation SLAs: Critical → 24h, High → 7 days)

Step 3.3 — VERIFICATION
  □ RunSecurity Playwrightteam security test suite
  □ Verify org-scoping isolation tests pass
  □ Verify RBAC tests pass
  □ Confirmconfirms 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
  □ DeployRestore patchedfrom versionknown-good state or deploy fresh build
  □ Rotate ALL credentials on(JWT_SECRET, affectedDB systemspasswords, □third-party EnableAPI enhanced monitoring for 30 days post-recoverykeys)
  □ Verify data integrity (compare LoggedAction against expected state)backups
  □ Re-enable services inincrementally stages(not all at once)
  □ Deploy with enhanced logging verbosity

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 CEOmanagement (Alem Bašić)
  □ Prepare regulatory notifications (see §5)
  □ Prepare customeruser 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)days for P1/P2)
  □ Blameless post-mortem meeting
  □ Complete timeline of events (minute-by-minute)
  □ Root cause analysis (5 Whys)
  □ What went wellwell?
  /□ whatWhat failedfailed? (detection gaps, response gaps, communication gaps)
  □ 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)
  □ AML notification to EFE if requiredbreach □involved DPAAML-relevant customer notifications
  □ Insurance claim fileddata

Step 5.3 — REMEDIATION TRACKING
  □ All action items in issue tracker
  □ Weekly review for 4 weeks
  □ Update DPIAthreat model with lessonsnew learnedattack vector
  □ Update this responseplan planbased on lessons learned

---

5. Notification Requirements

5.1 CroatiaDatatilsynet — AZOPGDPR Supervisory Authority (GDPR Art. 33 — 72 hours)

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

Breach likely to result in a risk to rights and freedoms of natural persons

Deadline: Within 72 hours of becoming aware of the breach

Required only if: Breach is likely to result in risk to rights and freedoms of data subjects

What to report (notGDPR confirmedArt. 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: Datatilsynet Notification portal: https://www.datatilsynet.no/personvern-pa-ulike-omrader/virksomheter-og-sikkerhet/brudd-pa-personopplysningssikkerhet/ Submitted by: DPO (once appointed) — aware)interim: Alem Bašić

Partial notification allowed: Submit what's known within 72h, supplement laterlater.

Authority: AZOP — Agencija za zaštitu osobnih podataka Portal: https://azop.hr/prijavapovrede Email: [email protected] DPO submits: [email protected]

Required information:

• Nature of breach (categories, number of data subjects, number of records)
• DPO contact details
• Likely consequences
• Measures taken or proposed

5.2 SerbiaFinanstilsynet — PoverenikDORA (ZZPLICT Art.Incident 56 — 72 hours)Reporting

Legal basis: ZakonDORA oArt. zaštiti19 podataka o ličnosti, Article 56 Required if: Breach likely to result(applicable in riskNorway toest. rights2026 andH2) freedoms/ of individuals Deadline: Within 72 hours of becoming awareIKT-forskriften

Authority: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

Report	Deadline	Content
Initial	4 hours after classification as major	Incident type, affected services, initial scope, measures taken
Intermediate	72 hours	Updated scope, preliminary root cause, containment status
Final	1 month	Full description, root cause, consequences, lessons learned

Contact: Poverenik za informacije od javnog značaja i zaštitu podataka o ličnosti Portal: https://www.poverenik.rs Email: [email protected] Address: Bulevar kralja Aleksandra 15, 11000 Belgrade, Serbia[email protected]

5.3 Bosnia & HerzegovinaGDPR — AZLPData (72Subject hours — best practice)Notification

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: [email protected] Address: Hamdije Čemerlića 2/VI, 71000 Sarajevo, Bosnia & Herzegovina

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

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

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

Method: Direct emailEmail to affected users —+ individual,in-app notpush publicnotification announcement+ SMS if available

FinancialNot required if: Data was encrypted and key not compromised OR post-breach measures ensure high risk no longer likely

5.4 AML — EFE Notification

When: If breach involved AML-relevant data breach(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 customer if STR (suspicious transaction report) has been or will be filed — assessTIPPING HIGHOFF riskis if:

• Tax IDsprohibited (PIB/JMBG/OIB/JIB)hvvl. 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

§28)

5.5 Multi-JurisdictionContractual Notification ChecklistObligations

Identify










by□IfCroatianaffected→ 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)
□ Ifcustomers→notifyper DPA contract terms
□ Document all notifications with timestamp and reference number
Obligation
Parties
Timeline
Method
Sumsub DPA notification
Sumsub
Per DPA — see □legal/dpa-sumsub.md
Direct allvia affectedSumsub support
Swan DPA notification
Swan
Per DPA — see legal/dpa-swan.md
Direct via Swan support
BankID notification
BankID Norge AS
Immediate if BankID data subjectsinvolved
Direct countrycontact


Neonomics usersnotification
Neonomics
Per DPA
Direct affectedcontact




6. Communication Templates
6.1 Internal Incident Alert
Subject: [INCIDENT P{SEVERITY}] Security Incident — Bilko — {DATE} {TIME} UTC

Team,

SecurityWe incidenthave detected.identified a security incident. 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)Bašić
Incident channel: #incident-{DATE}-{N} 72h(Slack)

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

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

Next update: {TIME} UTC

6.2 Data Subject Notification Template (CroatianGDPR /Art. English)34)
Subject: Važna sigurnosna obavijest o vašem računu / Important security notice Poštovaniregarding {IME}your /Drop account

Dear {FIRST_NAME},

BilkoWe (bilko.io)are vaswriting obavještavato oinform sigurnosnomyou incidentuof kojia jesecurity mogaoincident utjecatithat namay vašhave račun.affected Štoyour se dogodilo /account.

What happened:
DanaOn approximately {DATUM}DATE}, saznaliwe smobecame zaaware neovlašteniof pristupa našimsecurity sustavimaincident kojiinvolving jeunauthorized
mogaoaccess izložitito vašesystems osobnecontaining podatke.personal Kojiinformation podaciassociated suwith zahvaćeniyour /Drop Dataaccount.

potentiallyWhat affected:information was involved:
The following information may have been accessed: {KATEGORIJE_PODATAKA}DATA_CATEGORIES}
Što[e.g., smoname, poduzeliemail /address, phone number, transaction history]

What we did:have done:
- {MJERA_1}Contained the security incident and eliminated the threat
- {MJERA_2}Revoked Štoall trebateactive učinitisessions /(you will need to log in again)
- Notified the Norwegian Data Protection Authority (Datatilsynet)
- Enhanced monitoring and security measures

What you should do:
- PromijeniteLog lozinkuback na bilko.io / Changeinto your passwordDrop ataccount bilko.ioand verify your account details
- OmogućiteMonitor dvofaktorskuyour autentikacijubank /accounts Enablefor two-factorany authenticationunauthorized transactions
- PratiteContact sumnjiveyour aktivnostibank /if Monitoryou fornotice any suspicious activity
Za- višeIf informacijayou /have concerns: contact [email protected]

For more information:
DPO:Data [email protected]Protection Privacy:Officer: bilko.io/privacy[email protected]
IspričavamoPrivacy sePolicy: zahttps://getdrop.no/personvern
uzrokovanuDatatilsynet: neugodnost.www.datatilsynet.no

We take the security of your information very seriously and sincerely apologize for
any concern this may cause.

BilkoRegards,
timDrop /— BilkoALAI TeamHolding DPO:AS
[email protected]Data Protection Officer: {DPO_NAME}

6.3 RegulatoryDatatilsynet Notification Draft (GDPR Art. 33 — for AZOP, Poverenik, AZLP)33)
To: {AUTHORITY_NAME} — {AUTHORITY_EMAIL}Datatilsynet
From: {DPO_NAME}, DPO — BilkoALAI Holding AS (bilko.io)Drop)
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 processed by Bilko.data. The breach {is/was} {ONGOING/CONTAINED}.

2. Categories and approximate number of data subjects and approximate numbers:
   - Data subjects: {NUMBER} (estimated)concerned:
   - Categories: {userDATA_CATEGORIES account— datae.g., /name, taxemail, IDstransaction (PIB/JMBG/OIB/JIB)data, / IBAN / invoice data}fødselsnummer}
   - Records: {NUMBER} (estimated)
   - Countries ofEstimated affected data subjects: {RSNUMBER}
   /- BAEstimated /affected HR}records: {NUMBER}

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]
   Organization:Phone: Bilko{DPO_PHONE}

(bilko.io)

4.5. Likely consequences:consequences of the breach:
   {ASSESSMENTCONSEQUENCES — e.g., "Tax ID exposure creates risk of identity theft;theft IBAN exposure creates risk ofrisk, financial fraud"}harm, 5.reputational damage}

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

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

[DPO Signature]

6.4 Finanstilsynet Initial Report Template (DORA Art. 19)

To: [email protected]
From: CISO — ALAI Holding AS (Drop)
Date: {DPO_NAME}DATE} [email protected]{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.


7. Evidence Preservation Procedures

Principle: COLLECT BEFORE CONTAIN — evidence collection priority unless ongoing harm is severe.
Evidence collection checklist:
□ RailwayExport logSentry export:error allevents: services,Full 30-daytime window around+ 24h before incident
□ CloudflareExport logapplication export:logs: WAFAuthentication, events,transaction, API access logs
□ Sentry:Export errorrate_limits eventstable exportsnapshot
□ LoggedActionExport query:sessions alltable: mutationsAll active sessions during incident window
SELECT□ *Export FROMaffected logged_actionsusers/transactions: WHEREScoped action_timestampto BETWEENbreach '{start}' AND '{end}'window
□ PostgreSQL:Export pg_stat_activityAWS snapshot,CloudTrail connectionlogs history(Phase 2 — when on AWS)
□ AuthenticationNetwork logs:traffic failedcapture login(tcpdump) attempts,if tokenattack usageis ongoing
□ Screenshot: System state, Sentry dashboard, affected endpoints

Chain of custody:
- All evidence files: SHA-256 hash all exported filescomputed immediately after collection
- Record:Hash filename,log: hash, collector, timestampevidence/chain-of-custody.txt
- Storage: Write-protected encrypted archive,volume, access restrictedlogged
to- IRTCustody transfers: Documented with timestamps


8. Forensic Analysis Requirements































Incident Level
Forensic Approach
Provider
P1 (Critical)
External forensics firm engaged within 4 hours
TBD — retainer required
P2 (High)
Internal log analysis + external if complex
Internal first, escalate
P3 (Medium)
Internal log analysis
Security team
P4 (Low)
Root cause review
Security engineer

Evidence retention: All forensic evidence retained minimum 5 years post-incident (per legal/hendelseshaandtering.md §8.3).


9. Lessons Learned Process

Post-mortem deadline: 5 business days for P1/P2; 15 business days for P3/P4

Mandatory post-mortem components:


Complete incident timeline (minute-by-minute)

Root cause analysis (5 Whys)

What went well (preserve these practices)

What went poorly (specific improvement areas)

Action items (specific, assigned, time-bound)

Detection gap analysis (how long before detection?)

Response gap analysis (where did we slow down?)

Prevention roadmap (systemic fixes)

Was this response plan adequate? Update if not.



10. Drill Schedule
run







Drill Type
Frequency
Participants
Scenario




Tabletop exercise
Quarterly
Full IRT + CEOmanagement
TaxRansomware ID/ Data breach / IBANInsider exposure / credential stuffingthreat


NotificationGDPR 72h notification drill
Semi-annual
DPO + Legal + Communications
72-hourPractice multi-jurisdictionfull Datatilsynet notification dryflow
DORA notification drill
Semi-annual
CISO + Engineering
Practice Finanstilsynet initial/intermediate/final report


Technical response drill
Annual
Engineering + Security
SimulatedLive org-scopesimulation bypasson inisolated stagingenvironment



Last drill: Not yet conducted — schedule first tabletop within 30 days of productteam launchformation
Drill coordinator: ComplianceAlem ArchitectBašić ([email protected])until dedicated security team hired)

Approval









Role
Name
Date
Signature




Author
ComplianceALAI ArchitectSecurity Team
2026-02-23



DPO
TBD — appointment required
CISO
Alem Bašić




Legal Counsel
TBD




CEO
Alem Bašić