Data Protection Impact Assessment (DPIA)

Data Protection Impact Assessment (DPIA)

Project: DropBilko — PSD2Balkan Pass-ThroughAccounting Payment AppSaaS Processing Activity: AllMulti-Tenant personalAccounting dataData processingProcessing in(invoices, Dropexpenses, paymentVAT, servicetax filings) Version: 1.0 Date: 2026-02-23 Author: SecurityCompliance Architect DPO: DPOTBD ([email protected])[email protected]) Status: Draft Reviewers: DPO, Legal Counsel, CTOEngineering Lead Classification: Confidential Document-ID: DPIA-DROP-001

Document History

accountingSaaSdata

Version	Date	Author	Changes
0.1	2026-02-1223	ALAICompliance Holding ASArchitect	Initial DPIA assessment— (legal/dpia-vurdering.md)
1.0	2026-02-23	Security Architect	Formalized in compliance template formatprocessing

---

DPIA Trigger Checklist

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

#	Trigger	Applies?	Notes
1	Systematic andprofiling extensive evaluation of personal aspects (profiling,/ automated decision-makingdecisions with legal/significantlegal effects)effects	YESNO	AutomatedNo fraudprofiling detectionor andautomated AML transaction monitoring — flags transactions with legal/financial consequences for data subjectsdecisions
2	Large-scale processing of special category data (health, religion, ethnicity)	NO	No health/religion/ethnicityFinancial data processedis not Art. 9 special category
3	Systematic monitoring of publicly accessible areas (CCTV, tracking)	NO	Not applicableN/A
4	Processing of biometricBiometric or genetic data	NO	BankID is not biometric in Drop's processing scopeN/A
5	ProcessingData of data concerningabout vulnerable datasubjects subjects(children, patients)	YESPARTIAL	GeneralEmployees populationsubmitting includingexpense financially vulnerable users; minimum age 18 enforcedclaims via BankIDemployer's fødselsnummerBilko account
6	Innovative use of technology with unpredictable privacy impact	YESNO	OpenStandard Bankingcloud PSD2accounting AISP/PISP integration; BankID OIDC — new technology combinationSaaS
7	Cross-border transfer outside EEA without adequate protection	YES	RemittanceSerbian to(ZZPL) Serbia,and BiH,BiH Turkey,(ZZLP) Pakistandata subjects — nodata adequacyprocessed decisionson EU servers
8	Large-scaleProcessing processingthat of financialprevents data subjects from exercising rights	YESNO	TransactionSelf-service data,endpoints bank account numbers, cross-border payment flowsprovided

DPIA Required: YES Reason: TriggersCross-border 1, 5, 6, 7, and 8 confirmed. Processingtransfer of RS/BA data subjects to EU-hosted infrastructure; processing of national tax IDs (PIB/JMBG/OIB/JIB) as sensitive identifiers; financial data atfor scalethousands withof cross-border transfers to non-EEA countriesorganizations and automatedtheir decision-making (fraud/AML systems).

Regulatory basis: GDPR Art. 35, personopplysningsloven (LOV-2018-06-15-38), Datatilsynets retningslinjer for DPIAcounterparties.

---

1. Processing Activity Description

1.1 Activity Overview

Activity Name: DropMulti-Tenant PaymentAccounting Service — FullData Processing Scope System/Product: Drop — PSD2 pass-through payment appBilko (getdrop.no)bilko.io) Business Unit: ALAI Holding AS (org.nr. 932 516 136)Product Processing Owner: CEOEngineering /Lead Compliance Officer([email protected])

Description of Processing: DropBilko isprocesses afinancial paymentand servicepersonal fordata allon residentsbehalf of Norway.business Itorganizations uses(data acontrollers) pass-throughin modelSerbia, underBosnia PSD2& —Herzegovina, Dropand never holds customer money. Processing includes:Croatia:

1. User registrationaccount and identity verification via BankID OIDCdata — collectionemail, offull name, fødselsnummerbcrypt-hashed (nationalpassword, ID),TOTP birthdate (age verification), mobile numbersecret
2. PSD2Organization AISPdata — readinglegal name, tax ID (PIB/JIB/OIB), address, banking details
3. Contact data — customer/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 accounttransactions, balancesdouble-entry fromdebit/credit
user's
7. Audit banktrail via— Openall Bankingmutations APIlogged (with explicit user consent)
ID,
8. PSD2IP, PISPtimestamp, —old/new initiating payments from user's bank account (remittance to 30+ countries, QR payments in-store)
9. KYC/AML compliance — customer due diligence per hvitvaskingsloven, transaction monitoring, PEP/sanctions screening
10. Transaction history — storing remittance and QR payment records per bokføringslovenvalues

Trigger / Business Justification: ProvideSMBs in the Balkans lack affordable, accessiblecompliant internationalcloud remittanceaccounting software. Processing this data is necessary to deliver the contracted accounting service and QRmeet paymentlegal servicesobligations forunder allRS/BA/HR residents of Norway, compliant with PSD2, hvitvaskingsloven,accounting and GDPR.tax laws.

1.2 Processing Operations

EU RailwayEU

Operation	Data Category	Technology	Location
Collection (BankID)registration)	Name,Email, fødselsnummer,name, birthdatepassword	BankIDHTTPS OIDCPOST, Zod validation	Norwaybilko.io (BankID— NorgeVercel AS)EU
Collection (user-entered)invoicing)	MobileContact number,data, email,tax recipientIDs, detailsamounts	Next.jsHTTPS API	Norwayapi.bilko.io — Railway EU West
Storage	All categories	PostgreSQL AES-256	Railway EU West (AWS App Runner)Frankfurt/Paris)
Storage (identity)files)	EncryptedReceipt fødselsnummer, name, KYC statusPDFs/JPGs	SQLiteCloudflare →R2 PostgreSQLAES-256	EEACloudflare (AWS)
Storage (transactions)	Amount, corridor, timestamp, recipient	SQLite → PostgreSQL	EEA (AWS)region
Processing (AISP)	BankVAT balance,calculations, account numberreports	PSD2Express APIAPI, →Prisma user's bankORM	EEA
Processing (PISP)	Payment instruction, amount, recipient IBAN	Open Banking API	EEA → remittance destinationWest
Sharing (remittance)	SenderInvoice name, recipient name/IBAN, amountPDFs	SWIFTSendGrid / correspondent bankemail	EEAEU → Serbia/BiH/HR/otherregion
KYC/AMLE-invoice processingsubmission	Name,Invoice fødselsnummer, PEP/sanctions statusXML	SumsubUBL +2.1 internalSEF rules/ HR-FISK	EEASerbia (Sumsub)SEF) / Croatia (FINA)
Deletion / Anonymization	AllUser categoriesPII	AutomatedSoft retentiondelete job+ anonymization	EEARailway EU West

---

2. Necessity & Proportionality Assessment

2.1 Purposes of Processing

IDs

Purpose	Specific Description	Legitimate?
UserAccount authentication	BankIDVerify OIDC to verifyuser identity andfor ageorganization (≥18)access	YES — mandatorycontract fornecessity financial(Art. services; hvitvaskingsloven § 126.1.b)
PaymentInvoice executiongeneration	PISPCreate fromlegally user'scompliant bankinvoices accountwith fortax remittance/QR	YESrequired —by core service delivery
Balance reading	AISP to show user their bank balance	YES — explicit consent; Art. 6(1)(a)
KYC/AML compliance	Customer due diligence, transaction monitoringlaw	YES — legal obligation;obligation hvitvaskingsloven §§ 4, 10-18
Transaction history	Records for user and for accounting	YES — bokføringsloven § 13; (Art. 6(1)(6.1.c)
FraudVAT preventioncalculation and reporting	AutomatedCalculate fraudVAT detectionat onRS transactions20% / BA 17% / HR 25%	YES — legal obligation (Art. 6.1.c)
Financial record keeping	Double-entry books required by accounting law	YES — legal obligation (Art. 6.1.c)
Audit trail	Immutable log of financial mutations	YES — legal obligation + legitimate interest;interest PSD2 (Art. 956.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

collected

Data Element	Collected	Strictly Necessary?	Alternative If Not Necessary
name	YES	YES — required for identity, required on wire transfers (FATF Rec. 16)	N/A
fødselsnummer (national ID)	YES	YES — required for unique identification per hvitvaskingsloven § 12(1)(a)	N/A — BankID provides it
birthdate	YES (derived from fødselsnummer)	YES — age verification ≥18, required	Only birthdate stored (not full fødselsnummer in plaintext)
mobile_number	YES	YES — authentication factor, notification	N/A
email	YES	YES — accountlogin management,+ receiptsinvoice delivery	N/A
bank_account_number	YES (via AISP)	YES — balance display; PISP requires source account	Masked in API responses (last 4 only)
account_balance	YES (AISP, session only)	YES — user requested feature; PSD2 consent	Not persisted; ephemeral read only
ip_addressfullName	YES	YES — fraudrequired prevention,on rate limiting, GDPR accountability	Hashed/pseudonymized in logs after 3 months
device_id	YES	YES — session binding, fraud detectioninvoices	N/A
transaction_historypasswordHash	YES	YES — bokføringsloven § 13; customer transparencyauthentication	RetentionN/A limited(bcrypt to 5 yearshash)
kyc_documentstotpSecret	YES (EDD cases)	YES — hvitvaskingsloven §§ 17-182FA	OnlyN/A
organizationTaxId (PIB/JIB/OIB)	YES	YES — legally required on invoices	N/A
organizationIban	YES	YES — payment reference	N/A
contactTaxId (PIB/JMBG/OIB/JIB)	YES	YES — VAT law requires buyer tax ID	N/A
contactIban	YES	PARTIAL — needed only for payment features	Collect only when EDDpayment requiredactive
clientIp (audit log)	YES	YES — security, fraud detection	Retain max 30 days for security entries
userAgent	NO	NO — not collected	Not collected
deviceId	NO	NO — not collected	Not collected

Fields recommended for removal / minimization:

• ip_address in logs: Pseudonymize after 3 months
• user_agent: Retain for security analysis only, not customer-facing

2.3 Lawful Basis

Processing Activity	Lawful Basis	Justification
UserAccount registration + BankID verificationmanagement	Contract (— Art. 6(1)(b)) + Legal obligation (Art. 6(1)(c))6.1.b	RequiredNecessary to provide the service + hvitvaskingsloven § 12
PaymentInvoice execution/ (PISP)expense / transaction processing	ContractLegal (obligation — Art. 6(1)(b))6.1.c	CoreZakon serviceo deliveryPDV + Zakon o računovodstvu
AccountVAT balancecalculation readingand (AISP)reporting	ConsentLegal (obligation — Art. 6(1)(a))6.1.c	PSD2Mandatory requiresunder explicitRS/BA/HR consenttax for AISPlaws
KYC/AMLAudit data collectiontrail	Legal obligation (+ Legitimate interest — Art. 6(1)(c))6.1.c + 6.1.f	HvitvaskingslovenAccounting §§law 4,+ 10-18,fraud 30detection
FraudIP detectionaddress and monitoringlogging	Legitimate interest (— Art. 6(1)(f))6.1.f	LIA:Security fraudmonitoring, prevention30-day necessity outweighs privacy intrusion; data minimizedretention
TechnicalE-invoice logssubmission (IP, device)SEF/HR-FISK)	LegitimateLegal interestobligation (— Art. 6(1)(f))6.1.c	LIA:Mandatory securityelectronic and accountability; pseudonymized after 3 monthssubmission
TransactionData historyretention storagebeyond erasure	Legal obligation (— Art. 6(1)(c))6.1.c	Bokføringsloven10-11 §year 13retention — 5-yearper accounting retentionlaw

---

3. Data Subjects & Categories of Data

3.1 Data Subject Groups

Group	Description	Estimated Volume	Vulnerability Level
NorwegianBusiness residentsowners (users)/ admins	AllSMB Dropowners usersusing — BankID-verified, age ≥18Bilko	Up1-10 toper all Norwegian residentsorganization	Medium (financial data)Low
MerchantsAccountants	BusinessesProfessional usingaccountants Dropon QRclient paymentsaccounts	Smaller1-5 subsetper organization	Low
Employees	Submitting expense claims via employer's account	Variable	Low-Medium
Remittance recipientsCounterparties	IndividualsCustomers/suppliers inappearing 30+on countries receiving moneyinvoices	External —to minimal data heldBilko	Low (onlyfinancial namerisk +if IBAN stored)breached)

3.2 Personal Data Categories

account

Category	Data Elements	Sensitivity	RetentionClassification
Identity (Norwegian)Contact	Name, fødselsnummeremail, (encrypted), BankID referencephone	High — unique national identifierStandard	5L3 years after account closureConfidential
ContactAuthentication	Mobile number (+47)bcrypt(password), emailTOTP secret	StandardHigh	DurationL4 ofRestricted
Tax identity	PIB, JMBG, OIB, JIB	High	L4 Restricted
Financial — transactions	Amount,Invoice corridor,amounts, timestamp,IBAN, currencybank transactions	High	5L3 years (bokføringsloven)
Financial — banking (AISP)	Account number (last 4 shown), balance (session)	High	Not persisted; session only
Recipient data	Name, IBAN/account number, country	Standard	5 years
KYC/AML	Risk classification, PEP status, EDD documents	Restricted	5 years (hvvl. § 30)
Technical	IP address, device ID, session tokens	Standard	IP: 3 months; session: 24hConfidential
Behavioral / Audit	LoginIP times,address, transactionaction patternstimestamps, (forold/new AML)values	Standard	5L2 yearsInternal
Attachments	Receipt PDFs, invoice attachments	Standard-High	L3 Confidential

---

4. Data Processing Purposes & Legal Basis

ID,ID/address, years)

Processing Purpose	Personal Data Used	Legal Basis	Retention Period
User authentication (BankID)	Name,email, fødselsnummer,passwordHash, birthdate	Contract + Legal obligation	Account duration + 5 years
Remittance execution	Name, recipient IBAN, amount, currencytotpSecret	Contract (Art. 6(1)(6.1.b))	5Until yearsaccount (bokføringsloven § 13)deletion
QRInvoice paymentcreation executionand delivery	Amount,org merchantname, ref,tax timestamp	Contractcontact (Art.name/tax 6(1)(b))	5 years
Balance display (AISP)	Account number (masked), balance	Consent (Art. 6(1)(a))	Session only — not persisted
KYC customer due diligence	Name, fødselsnummer, risk classificationamounts	Legal obligation (Art. 6(1)(6.1.c))	510 years after(RS) account/ closure11 years (hvvl.HR/BA §RS 30)entity)
AMLVAT transaction monitoringcalculation	Transaction patterns,Invoice amounts, corridorstax rates, tax IDs	Legal obligation (Art. 6(1)(6.1.c))	510-11 years
FraudExpense detectionmanagement	IP,Amounts, devicedescriptions, ID,receipt behavioral patternsimages	LegitimateLegal interestobligation (Art. 6(1)(f))6.1.c)	310-11 years after event
Technical operations	IP address, system logs	Legitimate interest (Art. 6(1)(f))	6 months (technical); 12 months (auth logs)
Legal complianceFinancial reporting	TransactionAll data, identityfinancial data	Legal obligation (Art. 6(1)6.1.c)	10-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 relevantSEF/FINA lawrequirements
Transactional email	email, invoice PDF	Contract (minArt. 56.1.b)	Not stored by Bilko
Data export (portability)	All data	GDPR Art. 20 / ZZPL Art. 37	On demand

---

5. Data Flow Mapping

flowchart TD
    DS([Drop User / Data Subject]Subject\nBusiness user]) -->|BankIDRegisters OIDC|/ BANKID[BankIDCreates Norgeinvoice| AS\nNorwayCOLLECT[Web App\nbilko.io — Name,Vercel fødselsnummer,EU]
    birthdate]
    BANKIDCOLLECT -->|id_token|HTTPS POST Zod validated| API[DropExpress API\nAWS App Runnernapi.bilko.io — Norway/EEA]Railway DSEU -->|Mobile, email, recipient details| APIWest]
    API -->|EncryptedPrisma fødselsnummer\nName,ORM contact, KYC status|AES-256| DB[(PostgreSQL\nEEAnRailway —EU AES-256)West\nFrankfurt/Paris)]
    API -->|PaymentReceipt instruction\nSenderupload| nameR2[(Cloudflare +R2\nEU recipientregion IBANAES-256)]
    + amount| PISP[Open Banking PISP\nUser's bank — EEA]
    PISPDB -->|WireAppend-only| transfer\nSenderAUDIT[(LoggedAction\nImmutable nameaudit + recipient IBAN| CORR[Correspondent Bank\nDestination country]
    CORR -->|Payment to recipient| RECIP([Recipient\nSerbia / BiH / HR / Other])trail)]
    API -->|BalanceInvoice reademail| request|SG[SendGrid\nEU AISP[Open Banking AISP\nUser's bank — EEA]
    AISP -->|Balance + masked account| APIregion]
    API -->|KYCUBL check|2.1 SUMSUB[Sumsub\nKYC/AMLXML| —SEF[SEF EEA]efaktura.gov.rs\nSerbia]
    API -->|ErrorUBL events|2.1 SENTRY[Sentry\nErrorHR-CIUS| monitoringFINA[HR-FISK — EEA]
    API -->|Uptime + logs| BETTERSTACK[BetterStack\nLog monitoring — EEA]fina.hr\nCroatia]
    DB -->|On erasure request|deletion| ANON[Anonymization job\nPersonal dataAnonymization\nPII removed]
    DB -->|On data request|export| EXPORT[DataJSON export to user\nJSON/CSV]data subject]
    ANON --> DB

    style DB fill:#ffcccc,stroke:#cc0000
    style CORRAUDIT fill:#ffe4cc
    style SUMSUB fill:#ffe4cc#ffe4cc,stroke:#cc6600

Data processors (GDPR Art. 28):

Processor	Service	Data Shared	Country	DPA Status
BankID Norge ASRailway	NorwegianPostgreSQL eID authenticationhosting	Name,All fødselsnummer,accounting birthdatedata	NorwayEU West	RequiredPending — sign before launch
AWS (Amazon Web Services)Vercel	ApplicationFrontend hosting + database	AllBrowser app datarequests	EEAGlobal (Frankfurt)/ EU edge	AWS DPA (standard)
Sumsub	KYC/AML identity verification	Name, fødselsnummer, KYC docs	EEA	RequiredPending
Cloudflare	WAFCDN, +WAF, CDN + DDoSR2	IP addresses, requestreceipt metadatafiles	EEAEU edgeregion	Cloudflare DPAPending
SentrySendGrid	ErrorTransactional monitoringemail	AnonymizedEmail, errorinvoice data, no PII in eventsPDFs	EEAEU	Sentry DPA
BetterStack	Uptime + log monitoring	System logs (PII masked)	EEA	BetterStack DPAPending

---

6. Risk Assessment Matrix

6.1 Risk Scoring Scale

Score	Likelihood	Severity
1	Remote	Negligible
2	Unlikely	Limited — short-term minor impact
3	Possible	Significant — real non-negligible impact
4	Likely	Severe — serious impact on rights

Risk Score = Likelihood (1-5) × Severity

(1-5).
• Score 1-4:6: LowLow; | 5-8: Medium | 9-7-12: High |Medium; 13-16:19: Critical
High;

20-25: Critical.

6.2 RiskRisks to Data Subjects

limitation decisions necessary period

Risk ID	Risk to Data Subjects	Likelihood	Severity	Score	Existing Controls	Residual Risk
R1	Unauthorized access to financial data /(tax breachIDs, 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	TLS 1.3, AES-256, RBAC, bcrypt,org-scope, sessioninput revocationvalidation	MEDIUM → 4 after controls
R2R5	DataFinancial useddata manipulation (tampered invoices)	2	5	10	Immutable LoggedAction, RBAC delete permissions	LOW (after mitigation)
R6	PII retained beyond statednecessary purpose (purpose creep)period	12	3	6	Soft delete + anonymization; financial data by law	LOW
R7	Cross-border transfer (RS/BA data to EU) without protection	3	3	Purpose9	Railway policy,EU auditWest; logs,ZZPL DPAArt. contracts65; data stays in EEA	MEDIUM
R8	User unable to exercise erasure (locked by retention law)	3	2	6	Clear policy in privacy notice; PII anonymized	LOW
R3R9	InaccurateReceipt with sensitive data causing(medical wrongreceipts) financialexposed	2	3	6	Encrypted R2 storage; RBAC accountant+ access	LOW
R10	Audit log IP retention enabling tracking	2	2	4	BankID30-day providesIP verifiedretention identity;for balancesecurity; readlonger fromfor bank directlyfinancial	LOW
R4R11	DataSEF/HR-FISK retainedstate beyondsubmission	1	2	2	4Legal obligation — mandated by law	Automated retention/deletion policy	LOW
R5	Cross-border transfer without adequate protection (Serbia, BiH)	3	3	9	SCCs + TIA + data minimization + encryption in transit	MEDIUM → 6 after SCCs
R6	Automated AML/fraud decision adversely affects data subject	2	2	4	Manual review on automated blocks; klageadgang (complaint right)	LOW
R7	BankID session compromise / phishing	1	4	4	BankID Level 4, session timeout, device binding, anti-phishing info	LOW
R8	Fødselsnummer exposure — high-sensitivity data	2	4	8	AES-256-GCM field-level encryption, separate KMS key, compliance-only access	MEDIUM → 4 after controls
R9	Third-country government data access (Serbia, BiH authorities)	2	3	6	Minimal data transferred; only name + IBAN; SCCs; TIA	MEDIUM
R10	Data subject unable to exercise rights (erasure)	2	2	4	DPO process, 30-day SLA; AML retention exceptions documented	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	ImplementSentry audit_logerror tabletracking for+ allRailway sensitiveanomaly operationsmonitoring	EngineeringPlatform	Pre-productionPhase 1	Planned
R1R2	ExternalTax penetrationIDs testL4 Restricted — never in JWT, never in logs	SecurityEngineering	2026-Q3Phase 1	Designed
R3	Integration tests: cross-tenant requests must return 403	Engineering	Phase 1	Planned
R4	Vitest RBAC tests on all protected endpoints	Engineering	Phase 1	Planned
R5	ExecuteLoggedAction SCCsPostgreSQL withtrigger all— non-EEAappend-only, correspondentno banksDELETE	Legal / DPOEngineering	Pre-launchPhase 1	In progressDesigned
R5R7	ConductPrivacy Transfernotice Impactstates AssessmentsRailway forEU Serbia,West BiH,data Turkey,residency; PakistanZZPL Art. 65 transfer basis	ComplianceLegal/DPO	Pre-launchPhase 1	In progressPlanned
R5R7	MinimizeVerify transferredRailway dataregion —= senderEU nameWest only,before no fødselsnummerlaunch	EngineeringPlatform	✓Phase Architecture decision1	DonePlanned
R8	SeparatePrivacy KMSnotice keyexplains forlegal fødselsnummerretention —basis not shared with other dataclearly	EngineeringLegal/DPO	Phase 21	Planned
R9	TIAR2 perfiles countryaccessible assessingonly surveillanceto laworg members with accountant+ role	DPOEngineering	Pre-launchPhase 1	Planned
R9	Consider pseudonymization of sender reference for non-EEA wires (where legally permissible)	Legal	Review	PlannedDesigned

Residual risk after mitigation:conclusion: All residual risks assessed asare LOW or MEDIUM (max 6).MEDIUM. No CRITICAL or HIGH residual risksrisks. remainProcessing aftermay plannedproceed mitigations.subject to DPO approval and Phase 1 mitigations being implemented before first paying customer.

DPO Conclusion: ☐ Acceptable — proceed with| processing☐ (subjectConditional — pending Phase 1 mitigations | ☐ Escalate to plannedsupervisory mitigations being implemented before launch)authority

---

8. DPO Consultation Record

DPO Name: DPO / personvernombudTBD ([email protected])[email protected]) Consultation Date: 2026-02-12To (initial);be ongoingscheduled before first paying customer

DPO Input:

DPIA[To confirmsbe thatcompleted processingafter ofDPO fødselsnummer, bank account data, and cross-border transfers creates medium-level risks manageable with described controls. BankID integration is privacy-enhancing (reduces need to collect separate identity documents). Key pre-launch requirements: SCCs with non-EEA correspondent banks, TIAs for Serbia/BiH/Turkey/Pakistan, audit_log implementation, and formal registration with Datatilsynet behandlingsprotokoll (Art. 30).appointment]

DPO Recommendation:

• Approved — risks acceptable and adequately mitigated
•  Conditional approval — subject to implementingPhase 1 mitigations before production launch
• Rejected — redesign required
• Escalate to supervisory authority

DPO Signature: _________________________ Date: _____________

---

9. Supervisory Authority Consultation (if required)

Consultation Required: NO (pending DPO review) Reason: AfterNo plannedCRITICAL mitigations,or noHIGH residual risks. MEDIUM risks exceed the HIGH threshold. GDPR Art. 36 prior consultation not required. Datatilsynet will be engaged as part of standard Finanstilsynetfor licensingcloud process.accounting SaaS.

If required — relevant authorities by jurisdiction:

• HR: AZOP — [email protected] — https://azop.hr
• RS: Poverenik — [email protected] — https://www.poverenik.rs
• BA: AZLP — [email protected] — https://www.azlp.ba

---

10. DPIA Review Schedule

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

• BankIDNew integrationcountry implementedlaunch (RS Phase 2)
2,
• OpenHR Banking AISP/PISP integration implemented (Phase 2)2, BA Phase 3)
• New remittancegovernment corridor addedintegration (newSEF, TIAHR-FISK, required)CPF)
• RealData KYC/AMLbreach systemor integrated (Sumsub production)
• Migration from SQLite to PostgreSQL completednear-miss
• New regulationsdata entercategories intoor force (DORA, updated hvitvaskingsloven)processors
• AnyRegulatory datachanges breach(ZZPL relatedamendment, toBiH thisreform, processingGDPR updates)

Review Owner: DPO ([email protected]) Review Log:

Date	Reviewer	Changes Made	Outcome
2026-02-1223	ALAICompliance Holding ASArchitect	Initial DPIA (dpia-vurdering.md)	Approved with conditions
2026-02-23	Security Architect	Formalized in compliance template	Draft — awaiting DPO review pending

---

Approval

Role	Name	Date	Signature
Author	SecurityCompliance Architect	2026-02-23
DPO
ProcessingEngineering OwnerLead	CEO / Daglig leder
Legal Counsel
ManagementCEO