Data Protection Impact Assessment (DPIA)

Data Protection Impact Assessment (DPIA)

Project: DropBilko — FintechBalkan PaymentAccounting App (ALAI Holding AS)SaaS Processing Activity: AllMulti-Tenant personalAccounting dataData processingProcessing in(invoices, Dropexpenses, paymentVAT, servicestax filings) Version: 1.0 Date: 2026-02-23 Author: ALAI Compliance TeamArchitect DPO: TBD — appointment required ([email protected] — planned)[email protected]) Status: Draft — DPO Review Required Reviewers: DPO, Legal Counsel, CTOEngineering Lead Classification: Confidential

Document History

accountingSaaSdata

Version	Date	Author	Changes
0.1	2026-02-1223	Compliance Agent (ALAI)Architect	Initial DPIA draft— (legal/dpia-vurdering.md)
1.0	2026-02-23	Security Architect (ALAI)	English compliance template formatprocessing

Source document: legal/dpia-vurdering.md — DPIA-DROP-001 (v1.0, approved 2026-02-12)

---

DPIA Trigger Checklist

A DPIA is required under GDPR Art. 35 if ANY of the following apply:

#	Trigger	Applies?	Notes
1	Systematic andprofiling extensive evaluation of personal aspects (profiling,/ automated decision-makingdecisions with legal/significantlegal effects)effects	YESNO	AutomatedNo AML/fraudprofiling transactionor monitoringautomated decisions
2	Large-scale processing of special category data (health, religion, ethnicity)	NO	NoFinancial health,data religion,is ornot otherArt. 9 special category data
3	Systematic monitoring of publicly accessible areas	NO	Not applicableN/A
4	Processing of biometricBiometric or genetic data	PARTIALNO	BankID uses biometric identity verification (handled by BankID — not Drop)N/A
5	ProcessingData of data concerningabout vulnerable datasubjects subjects(children, patients)	YESPARTIAL	GeneralEmployees populationsubmitting includingexpense potentiallyclaims vulnerablevia individualsemployer's Bilko account
6	Innovative use of technology with unpredictable privacy impact	YESNO	OpenStandard Bankingcloud (PSD2accounting PISP/AISP), BankID OIDC integration, QR paymentsSaaS
7	Cross-border transfer outside EEA without adequate protection	YES	RemittanceSerbian to(ZZPL) 30+and countriesBiH (ZZLP) data subjects — Serbia,data Bosnia,processed Turkey,on PakistanEU lack adequacy decisionsservers
8	Processing data that prevents data subjects from exercising rights	NO	NotSelf-service applicableendpoints provided

DPIA Required: YES Reason: MultipleCross-border triggerstransfer apply:of automatedRS/BA transactiondata monitoring,subjects innovativeto OpenEU-hosted Bankinginfrastructure; technology,processing large-scaleof national tax IDs (PIB/JMBG/OIB/JIB) as sensitive identifiers; financial data processing,for cross-borderthousands transfersof toorganizations non-adequateand countries.their counterparties.

---

1. Processing Activity Description

1.1 Activity Overview

Activity Name: DropMulti-Tenant Payment Services — All PersonalAccounting Data Processing System/Product: DropBilko (getdrop.no) — Remittance + QR Payment Appbilko.io) Business Unit: ALAI Holding AS — Drop productProduct Processing Owner: CEOEngineering / CISOLead ([email protected])[email protected])

Description of Processing: DropBilko isprocesses afinancial paymentand applicationpersonal fordata allon residentsbehalf of Norwaybusiness providing:organizations (data controllers) in Serbia, Bosnia & Herzegovina, and Croatia:

1. RemittanceUser account data — internationalemail, moneyfull transfersname, tobcrypt-hashed 30+password, countriesTOTP via PSD2 PISPsecret
2. QROrganization Paymentsdata — in-storelegal QRname, codetax paymentsID via(PIB/JIB/OIB), PSD2address, PISPbanking details
3. AccountContact Informationdata — readingcustomer/supplier names, tax IDs, email, phone, IBAN
4. Invoice data — invoice numbers, dates, amounts, VAT, payment status
5. Expense data — amounts, categories, descriptions, receipt attachments
6. Transaction data — bank balancestransactions, viadouble-entry PSD2debit/credit
AISP
7. Audit trail — all mutations logged with user ID, IP, timestamp, old/new values

Drop operates a pass-through model: it never holds customer funds. All payments are initiated directly from the user's bank account via Open Banking APIs. User authentication occurs via BankID (OIDC, security level "høyt" — eIDAS High).

Trigger / Business Justification: ProvidingSMBs accessible,in low-costthe paymentBalkans lack affordable, compliant cloud accounting software. Processing this data is necessary to deliver the contracted accounting service and remittancemeet serviceslegal toobligations allunder NorwegianRS/BA/HR residents.accounting Norwegian-registeredand residentstax can send money abroad at lower fees than traditional services. Financial inclusion for all communities.laws.

1.2 Processing Operations

Railway non-EEA

Operation	Data Category	Technology	Location
Collection — Registration(registration)	IdentityEmail, (name, fødselsnummer, DOB), contact (phone, email)password	BankIDHTTPS OIDC,POST, webZod formvalidation	Norwaybilko.io (EEA)— Vercel EU
Collection — AISP(invoicing)	FinancialContact (bankdata, accounttax number,IDs, balance)amounts	PSD2 Open BankingHTTPS API (Neonomics)	Norway (EEA)
Collectionapi.bilko.io — PISP	Financial (bank account, amount, recipient)	PSD2 Open Banking API (Neonomics)	Norway (EEA)
Collection — KYC/AML	Identity documents, PEP status, risk profile	Sumsub SDK	EU (EEA)West
Storage	All abovecategories	SQLite (MVP) → PostgreSQL (Phase 2)AES-256	NorwayRailway EU West (EEA)Frankfurt/Paris)
Storage (files)	Receipt PDFs/JPGs	Cloudflare R2 AES-256	Cloudflare EU region
Processing — AML monitoring	TransactionVAT patterns,calculations, amounts, corridorsreports	AutomatedExpress rulesAPI, enginePrisma ORM	NorwayRailway (EEA)EU West
Sharing — Remittance	SenderInvoice name, recipient name/account, amountPDFs	SWIFT/correspondentSendGrid banksemail	EEAEU +region
E-invoice submission	Invoice XML	UBL 2.1 SEF / HR-FISK	Serbia (SEF) / Croatia (FINA)
Deletion / Anonymization	AllUser categoriesPII	AutomatedSoft deletiondelete jobs+ (planned Phase 2)anonymization	NorwayRailway (EEA)EU West

---

2. Necessity & Proportionality Assessment

2.1 Purposes of Processing

IDsrequiredby

Purpose	Specific Description	Legitimate?
IdentityAccount verificationauthentication	Verify user isidentity whofor theyorganization claim, minimum age 18, Norwegian residencyaccess	YES — requiredcontract bynecessity hvitvaskingsloven(Art. § 12 and PSD2 SCA6.1.b)
PaymentInvoice initiation (PISP)generation	InitiateCreate paymentslegally fromcompliant user's bank account	YES — core service delivery
Account information (AISP)	Read bank balances for user dashboard	YES — core service delivery,invoices with explicittax consent
AML/transaction monitoring	Detect and prevent money launderinglaw	YES — legal obligation (hvvl.Art. §§ 24-25)6.1.c)
KYCVAT compliancecalculation and reporting	CustomerCalculate identificationVAT andat riskRS assessment20% / BA 17% / HR 25%	YES — legal obligation (hvvl.Art. §§ 10-18)6.1.c)
FraudFinancial detectionrecord keeping	DetectDouble-entry unauthorizedbooks transactionsrequired by accounting law	YES — legitimatelegal interestobligation (PSD2 Art. 2)6.1.c)
TechnicalAudit loggingtrail	SystemImmutable errorlog tracking,of debugging,financial securitymutations	YES — legal obligation + legitimate interest (securityArt. requirement)6.1.c + 6.1.f)
E-invoice submission	Submit to SEF (Serbia) and HR-FISK (Croatia)	YES — legal obligation (Art. 6.1.c)
Invoice email delivery	Deliver invoices to customers	YES — contract necessity (Art. 6.1.b)

2.2 Data Minimization Assessment

ID processing

Data Element	Collected	Strictly Necessary?	JustificationAlternative
Full nameemail	YES	YES — login + invoice delivery	Identity verification (hvvl. § 12), payment routingN/A
Fødselsnummer (11 digits)fullName	YES	YES — required on invoices	Unique identification (hvvl. § 12(1)(a)), age verification (min 18)N/A
Date of birth	YES (derived from fødselsnummer)	YES	Age verification
Email addresspasswordHash	YES	YES — authentication	AccountN/A notifications,(bcrypt loginhash)
Phone number (+47)totpSecret	YES	YES — 2FA	Norwegian residency verification, 2FA (planned)N/A
BankorganizationTaxId account number(PIB/JIB/OIB)	YES	YES — legally required on invoices	AISP balance reading, PISP payment initiationN/A
Transaction data (amount, recipient, currency)organizationIban	YES	YES — payment reference	Service delivery, AML monitoring, Bokføringsloven § 13N/A
IPcontactTaxId address(PIB/JMBG/OIB/JIB)	YES	YES — VAT law requires buyer tax ID	Security monitoring, rate limiting, fraud detectionN/A
DevicecontactIban	YES	PARTIAL — needed only for payment features	Collect only when payment active
clientIp (audit log)	YES	YES	Session— management,security, fraud detection	Retain max 30 days for security entries
KYC documents (passport, national ID)	YES	YES	Hvitvaskingsloven § 12 identity verification
PEP status	YES	YES	Hvitvaskingsloven § 18
Marketing preferencesuserAgent	NO	NO — not collected	Not collected
deviceId	NO	NO — nonot marketingcollected	Not collected

Fields recommended for removal: None identified. All fields are necessary for regulatory compliance or service delivery.

2.3 Lawful Basis

/ security

Processing Activity	Lawful Basis	Justification
Account creation, identity verificationmanagement	Contract (— Art. 6.1.b)b	RequiredNecessary forto serviceprovide delivery
Payment initiation (PISP)	Contract (Art. 6.1.b)	Corethe service
BankInvoice account/ readingexpense (AISP)	Consent (Art. 6.1.a)	PSD2 requires explicit PSU consent
AML/KYCtransaction processing	Legal obligation (— Art. 6.1.c)c	HvitvaskingslovenZakon §§o 4,PDV 10-18+ Zakon o računovodstvu
TransactionVAT monitoringcalculation and reporting	Legal obligation (— Art. 6.1.c)c	HvitvaskingslovenMandatory §§under 24-25RS/BA/HR tax laws
FraudAudit detectiontrail	Legal obligation + Legitimate interest (— Art. 6.1.f)c + 6.1.f	PSD2Accounting Art.law 2+ fraud detection
SecurityIP address logging	Legitimate interest (— Art. 6.1.f)f	DORASecurity monitoring, 30-day retention
E-invoice submission (SEF/HR-FISK)	Legal obligation — Art. 10,6.1.c	Mandatory requirementelectronic submission
Data retention beyond erasure	Legal obligation — Art. 6.1.c	10-11 year retention per accounting law

---

3. Data Subjects & Categories of Data

3.1 Data Subject Groups

10,000—Year1)

Group	Description	Estimated Volume	Vulnerability Level
RegisteredBusiness usersowners / admins	AdultsSMB (18+)owners residingusing in Norway, all backgroundsBilko	TBD1-10 (launchper target:organization	Low
Accountants	Professional accountants on client accounts	1-5 per organization	Low
Employees	Submitting expense claims via employer's account	Variable	Low-Medium
MerchantsCounterparties	LegalCustomers/suppliers entitiesappearing registeringon for QR payment acceptanceinvoices	TBDExternal (launchto target: 500 — Year 1)	Low
Payment recipients	Persons abroad receiving remittances	TBDBilko	Low (datafinancial minimizedrisk —if name + account only)breached)

3.2 Personal Data Categories

2years

Category	Data Elements	Sensitivity	RetentionClassification
IdentityContact	FullName, name,email, fødselsnummer, date of birthphone	High (L4 for fødselsnummer)Standard	5L3 years after account closure (hvvl. §30)Confidential
ContactAuthentication	Email,bcrypt(password), phoneTOTP numbersecret	Standard (L3)High	DurationL4 +Restricted
Tax identity	PIB, JMBG, OIB, JIB	High	L4 Restricted
Financial	BankInvoice accountamounts, number,IBAN, balancebank (AISP), transaction historytransactions	High (L3-L4)	5L3 years (Bokføringsloven)
KYC/AML	Identity documents, PEP status, risk profile	High (L4)	5 years after account closure (hvvl. §30)Confidential
Behavioral / Audit	Transaction patterns, device ID, IP addressaddress, action timestamps, old/new values	Standard (L3)	12-24L2 months (security logs), 5 years (AML)Internal
BiometricAttachments	NoneReceipt collectedPDFs, directlyinvoice (BankID handles)attachments	—Standard-High	—L3 Confidential

---

4. Data Processing Purposes & Legal Basis

Processing Purpose	Personal Data Used	Legal Basis	Retention Period
User registration and authentication	Name, fødselsnummer, email, phonepasswordHash, totpSecret	Contract (Art. 6.1.b)	DurationUntil +account 2 yearsdeletion
BankIDInvoice SCAcreation verificationand delivery	Name, fødselsnummer (via BankID)	Contract + Legal obligation	Session only
AISP bank balance reading	Bank account number, balance	Consent (Art. 6.1.a)	Until consent withdrawn
PISP payment initiation	Bank account, amount, recipient details	Contract (Art. 6.1.b)	5 years (Bokføringsloven)
Remittance — cross-border transfer	Senderorg name, recipienttax ID, contact name/account,tax amount	Contract (Art. 6.1.b)	5 years
KYC identity verification	Full identity data, documents, PEP status	Legal obligation (Art. 6.1.c) — hvvl. §§ 10-18	5 years (hvvl. §30)
Transaction monitoring (AML)	Transaction data, patterns,ID/address, amounts	Legal obligation (Art. 6.1.c) — hvvl. §§ 24-25	510 years (RS) / 11 years (HR/BA RS entity)
VAT calculation	Invoice amounts, tax rates, tax IDs	Legal obligation (Art. 6.1.c)	10-11 years
FraudExpense detectionmanagement	TransactionAmounts, patterns,descriptions, IP,receipt device IDimages	LegitimateLegal interestobligation (Art. 6.1.f)c)	210-11 years
SecurityFinancial loggingreporting	IP,All user_id, action, timestamp	Legitimate interest (Art. 6.1.f)	12 months auth logs, 24 months security
Suspicious Transaction Reporting (EFE)	Identity + transactionfinancial data	Legal obligation (Art. 6.1.c) — hvvl. §26	510-11 years
Audit trail	userId, IP, timestamp, changedFields	Legal obligation + Legitimate interest	Financial: 10-11 years; IP/security: 30 days
E-invoice (SEF/HR-FISK)	Invoice XML with buyer/seller data	Legal obligation (Art. 6.1.c)	Per SEF/FINA requirements
Transactional email	email, invoice PDF	Contract (Art. 6.1.b)	Not stored by Bilko
Data export (portability)	All data	GDPR Art. 20 / ZZPL Art. 37	On demand

---

5. Data Flow Mapping

Userflowchart →TD
    BankIDDS([Data (SCASubject\nBusiness authentication)user]) →-->|Registers Drop/ PlatformCreates (Norwayinvoice| COLLECT[Web App\nbilko.io — AWSVercel EEA)EU]
    ├──COLLECT Registration-->|HTTPS POST Zod validated| API[Express API\napi.bilko.io — Railway EU West]
    API -->|Prisma ORM AES-256| DB[(PostgreSQL\nRailway EU West\nFrankfurt/Paris)]
    API -->|Receipt upload| R2[(Cloudflare R2\nEU region AES-256)]
    DB -->|Append-only| AUDIT[(LoggedAction\nImmutable audit trail)]
    API -->|Invoice email| SG[SendGrid\nEU region]
    API -->|UBL 2.1 XML| SEF[SEF efaktura.gov.rs\nSerbia]
    API -->|UBL 2.1 HR-CIUS| FINA[HR-FISK fina.hr\nCroatia]
    DB -->|On deletion| ANON[Anonymization\nPII removed]
    DB -->|On export| EXPORT[JSON export to data →subject]
    PostgreSQLANON --> DB

    (Norway)
         ├── KYC data → Sumsub (EU EEA) → Dropstyle DB ├──fill:#ffcccc,stroke:#cc0000
    AISP:style BankAUDIT balance → Neonomics → User's bank → Drop dashboard
         ├── PISP: Payment instruction → Neonomics → User's bank → Recipient bank
         │        └── For remittance: → Correspondent bank → Recipient country bank
         ├── Errors → Sentry (EU EEA)
         └── Suspicious transactions → EFE (Altinn — Norway)fill:#ffe4cc,stroke:#cc6600

Data processors (GDPR Art. 28):

Processor	Service	Data Shared	Country	DPA SignedStatus
BankID Norge ASRailway	IdentityPostgreSQL verificationhosting	Name,All fødselsnummeraccounting data	NorwayEU (EEA)West	RequiredPending — plannedsign before launch
SumsubVercel	KYC/AMLFrontend document verificationhosting	IDBrowser documents, biometric livenessrequests	Global / EU (EEA)edge	Yes — legal/dpa-sumsub.mdPending
NeonomicsCloudflare	PSD2CDN, AISP/PISPWAF, R2	BankIP accountaddresses, data,receipt payment instructionsfiles	EU (EEA)region	Required — plannedPending
SwanSendGrid	Banking/paymentTransactional railsemail	TransactionEmail, datainvoice PDFs	EU (EEA)	Yes — legal/dpa-swan.md
AWS	Infrastructure hosting	All data (encrypted)	EU (EEA — Frankfurt/Ireland)	AWS DPA
Sentry	Error monitoring	Error context, user IDs	EU (EEA)	Yes — legal/dpa-sentry.md
Correspondent banks	Remittance routing	Sender name, amount, recipient	Non-EEA (per corridor)	SCCs requiredPending

---

6. Risk Assessment Matrix

6.1 Risk Scoring Scale

Score	Likelihood	Severity
1	Remote — unlikely to occur	Negligible — minimal impact
2	Unlikely — exceptional circumstances	Limited — short-term, minor inconvenience
3	Possible — could occur	Significant — real impact on rights
4	Likely — will probably occur	Severe — serious impact on rights and freedoms

Risk Score = Likelihood (1-5) × Severity |(1-5). Low:Score 1-46: |Low; Medium:7-12: 5-8 | High: 9-12 | Critical:Medium; 13-1619: High; 20-25: Critical.

6.2 RiskRisks to Data Subjects

legal requirement

Risk ID	Risk to Data Subjects	Likelihood	Severity	Score	Existing Controls	Residual Risk
R1	Unauthorized access to financial data (breach)tax IDs, IBAN, invoice amounts)	2	5	10	TLS 1.3, AES-256, RBAC, org-scoped queries	MEDIUM
R2	Tax ID (PIB/JMBG/OIB/JIB) theft enabling identity fraud	2	5	10	L4 Restricted, RBAC, no JWT exposure, bcrypt	MEDIUM
R3	Cross-tenant data access (IDOR)	2	5	10	org-scoped WHERE on all queries, UUID PKs	LOW (after mitigation)
R4	Invoice data exposure to wrong party	2	4	8	TLSRBAC, 1.3,org-scope, bcrypt,input JWT httpOnly, parameterized SQL, session revocationvalidation	MEDIUM
R2R5	DataFinancial breachdata exposingmanipulation PII(tampered or fødselsnummerinvoices)	2	45	810	EncryptionImmutable atLoggedAction, restRBAC planned,delete access controlspermissions	MEDIUMLOW (after mitigation)
R3R6	UnlawfulPII profilingretained throughbeyond transactionnecessary dataperiod	12	3	36	PurposeSoft limitation,delete + anonymization; financial data minimization,by no secondary uselaw	LOW
R4R7	Third-countryCross-border transfer (RS/BA data to EU) without adequate protection (remittance corridors)	3	3	9	SCCsRailway planned,EU West; ZZPL Art. 65; data minimization (name + account onlystays in transfer)EEA	HIGH → MEDIUM with TIA
R5R8	FalseUser positiveunable —to legitimateexercise transactionerasure blocked(locked by AMLretention ruleslaw)	3	2	6	Clear policy in privacy notice; PII anonymized	LOW
R9	Receipt with sensitive data (medical receipts) exposed	2	3	6	Encrypted R2 storage; RBAC accountant+ access	LOW
R10	Audit log IP retention enabling tracking	2	2	4	Manual30-day reviewIP withinretention 24h,for complaintsecurity; handlinglonger for financial	LOW
R6R11	DataSEF/HR-FISK retainedstate beyondsubmission	1	2	2	4Legal obligation — mandated by law	Automated deletion planned Phase 2	LOW
R7	BankID session compromise via phishing/MitM	1	4	4	BankID security (handled by BankID Norge AS), session timeout	LOW
R8	Third-country authorities accessing data via remittance partners	2	3	6	SCCs + TIA + data minimization	MEDIUM
R9	Identity fraud — someone impersonating user	1	4	4	BankID Level High (eIDAS), Norwegian BankID only	LOWACCEPTABLE

---

7. Mitigation Measures

Risk ID	Mitigation Measure	Owner	Deadline	Status
R1	Field-level AES-256-GCM encryption for fødselsnummertax IDs and IBAN at application layer	Engineering	Phase 2	Planned
R1	AWSSentry KMSerror keytracking management+ forRailway databaseanomaly encryption keysmonitoring	Platform	Phase 21	Planned
R2	PostgreSQLTax withIDs TDEL4 (TransparentRestricted Data— Encryption)never viain AWSJWT, RDSnever in logs	PlatformEngineering	Phase 21	PlannedDesigned
R2R3	PenetrationIntegration testtests: beforecross-tenant productionrequests launchmust return 403	SecurityEngineering	Pre-launchPhase 1	Planned
R4	SCCsVitest withRBAC tests on all remittanceprotected corridor correspondent banksendpoints	LegalEngineering	Phase 21	Planned
R4R5	TransferLoggedAction ImpactPostgreSQL Assessmentstrigger per— destinationappend-only, countryno DELETE	DPO/LegalEngineering	Phase 21	Designed
R7	Privacy notice states Railway EU West data residency; ZZPL Art. 65 transfer basis	Legal/DPO	Phase 1	Planned
R4R7	MinimizeVerify transferredRailway dataregion (name,= account,EU amountWest ONLYbefore — no fødselsnummer)launch	Engineering	MVP	Implemented
R6	Automated data retention + deletion jobs (5-year AML, 2-year other)	EngineeringPlatform	Phase 21	Planned
R8	TIAPrivacy fornotice high-riskexplains corridorslegal (Pakistan,retention Turkey,basis Serbia, Bosnia)clearly	DPO/LegalLegal/DPO	Phase 21	Planned
R9	R2 files accessible only to org members with accountant+ role	Engineering	Phase 1	Designed

Residual risk after mitigation:conclusion: All residual risks assessed asare LOW or MEDIUM. No HIGHCRITICAL or CRITICALHIGH residual risksrisks. afterProcessing may proceed subject to DPO approval and Phase 21 mitigations arebeing implemented.implemented before first paying customer.

DPO Conclusion: ☐ Acceptable — proceed | ☐ Conditional — Processingpending mayPhase proceed1 formitigations MVP| (no☐ live transactions). PriorEscalate to livesupervisory transactions: BankID SCA required, KYC implemented, SCCs in place, DPO appointed.authority

---

8. DPO Consultation Record

DPO Name: TBD — DPO appointment required before Phase 2 launch([email protected]) Consultation Date: TBDTo DPObe Input:scheduled Pendingbefore appointmentfirst paying customer

DPO RecommendationInput:

(required

before

[To livebe transactions):completed after DPO appointment]

DPO Recommendation:

• Approved — risks are acceptable and adequately mitigated
• Conditional approval — subject to implementing Phase 21 mitigations
• Rejected — requiresredesign redesignrequired
•  Escalate to supervisory authority

DPO Signature: _________________________ Date: _____________

---

9. Supervisory Authority Consultation

Consultation Required: NO —(pending basedDPO onreview) currentReason: riskNo assessmentCRITICAL (allor HIGH residual risksrisks. LOW-MEDIUM after mitigation) Basis: GDPR Art. 35(7) — Residual risks afterstandard mitigationsfor arecloud acceptable.accounting No prior consultation with Datatilsynet required.SaaS.

Monitoring: If Phaserequired 2— implementationrelevant revealsauthorities newby risksjurisdiction:

(e.g.,

from
• HR: real-worldAZOP transaction— data),[email protected] this— assessmenthttps://azop.hr
will
• RS: bePoverenik reviewed— and[email protected] Datatilsynet— consultationhttps://www.poverenik.rs
may
• BA: beAZLP required.
  — [email protected] — https://www.azlp.ba

---

10. DPIA Review Schedule

Next scheduled review: 2027-02-1223 (annual) ORor when any of the following occurs:when:

• BankIDNew integrationcountry implementedlaunch (RS Phase 2)
2,
• LiveHR PSD2Phase AISP/PISP2, transactionsBA commencedPhase 3)
• New remittancegovernment corridorsintegration added
(SEF,
• SumsubHR-FISK, or KYC vendor changedCPF)
• Data breach incidentor related to this processingnear-miss
• ChangeNew indata applicable Norwegiancategories or EU regulationsprocessors
• DORARegulatory implementation in Norwaychanges (expectedZZPL 2026amendment, H2)BiH reform, GDPR updates)

Review Owner: DPO (once[email protected]) appointed)

Review Log:

Date	Reviewer	Changes Made	Outcome
2026-02-1223	Compliance Agent (ALAI)Architect	Initial DPIA (legal/dpia-vurdering.md)	Draft
2026-02-23	Security Architect (ALAI)	English compliance template format	Draft — awaiting DPO review

---

Approval

Role	Name	Date	Signature
Author	ALAICompliance Security TeamArchitect	2026-02-23
DPO	TBD — appointment required
ProcessingEngineering OwnerLead	Alem Bašić (CEO/CISO)
Legal Counsel	TBD
ManagementCEO	Alem Bašić