Data Protection Impact Assessment (DPIA)

Data Protection Impact Assessment (DPIA)

Project: BilkoDrop — BalkanFintech AccountingPayment SaaSApp (ALAI Holding AS) Processing Activity: Multi-TenantAll Accountingpersonal Datadata Processingprocessing (invoices,in expenses,Drop VAT,payment tax filings)services Version: 1.0 Date: 2026-02-23 Author: ALAI Compliance ArchitectTeam DPO: TBD — appointment required ([email protected])[email protected] — planned) Status: Draft — DPO Review Required Reviewers: DPO, Legal Counsel, Engineering LeadCTO Classification: Confidential

Document History

SaaSdataprocessing

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

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 profilingand /extensive evaluation of personal aspects (profiling, automated decisionsdecision-making with legallegal/significant effectseffects)	NOYES	NoAutomated profilingAML/fraud ortransaction automated decisionsmonitoring
2	Large-scale processing of special category data (health, religion, ethnicity)	NO	FinancialNo datahealth, isreligion, notor Art. 9other special category data
3	Systematic monitoring of publicly accessible areas	NO	N/ANot applicable
4	BiometricProcessing of biometric or genetic data	NOPARTIAL	N/ABankID uses biometric identity verification (handled by BankID — not Drop)
5	DataProcessing aboutof data concerning vulnerable data subjects (children, patients)	PARTIALYES	EmployeesGeneral submittingpopulation expenseincluding claimspotentially viavulnerable employer's Bilko accountindividuals
6	Innovative use of technology with unpredictable privacy impact	NOYES	StandardOpen cloudBanking accounting(PSD2 SaaSPISP/AISP), BankID OIDC integration, QR payments
7	Cross-border transfer outside EEA without adequate protection	YES	SerbianRemittance (ZZPL)to and30+ BiH (ZZLP) data subjectscountries — dataSerbia, processedBosnia, onTurkey, EUPakistan serverslack adequacy decisions
8	Processing data that prevents data subjects from exercising rights	NO	Self-serviceNot endpoints providedapplicable

DPIA Required: YES Reason: Cross-borderMultiple transfertriggers ofapply: RS/BAautomated datatransaction subjectsmonitoring, toinnovative EU-hostedOpen infrastructure;Banking processingtechnology, of national tax IDs (PIB/JMBG/OIB/JIB) as sensitive identifiers;large-scale financial data forprocessing, thousandscross-border oftransfers organizationsto andnon-adequate their counterparties.countries.

---

1. Processing Activity Description

1.1 Activity Overview

Activity Name: Multi-TenantDrop AccountingPayment Services — All Personal Data Processing System/Product: BilkoDrop (bilko.io)getdrop.no) — Remittance + QR Payment App Business Unit: ProductALAI Holding AS — Drop product Processing Owner: EngineeringCEO Lead/ CISO ([email protected])[email protected])

Description of Processing: BilkoDrop processesis financiala andpayment personalapplication datafor onall behalfresidents of businessNorway organizations (data controllers) in Serbia, Bosnia & Herzegovina, and Croatia:providing:

1. User account dataRemittance — email,international fullmoney name,transfers bcrypt-hashedto password,30+ TOTPcountries secretvia PSD2 PISP
2. OrganizationQR dataPayments — legalin-store name,QR taxcode IDpayments (PIB/JIB/OIB),via address,PSD2 banking detailsPISP
3. ContactAccount dataInformation — 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 —reading bank transactions,balances double-entryvia debit/credit
PSD2
7. Audit trail — all mutations logged with user ID, IP, timestamp, old/new valuesAISP

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: SMBsProviding inaccessible, thelow-cost Balkanspayment lackand affordable,remittance compliant cloud accounting software. Processing this data is necessaryservices to deliverall theNorwegian contractedresidents. accountingNorwegian-registered serviceresidents andcan meetsend legalmoney obligationsabroad underat RS/BA/HRlower accountingfees andthan taxtraditional laws.services. Financial inclusion for all communities.

1.2 Processing Operations

+

Operation	Data Category	Technology	Location
Collection (registration)— Registration	Email,Identity (name, passwordfødselsnummer, DOB), contact (phone, email)	HTTPSBankID POST,OIDC, Zodweb validationform	bilko.ioNorway — Vercel EU(EEA)
Collection (invoicing)— AISP	ContactFinancial data,(bank taxaccount IDs,number, amountsbalance)	HTTPSPSD2 Open Banking API (Neonomics)	api.bilko.ioNorway (EEA)
Collection — RailwayPISP	Financial (bank account, amount, recipient)	PSD2 Open Banking API (Neonomics)	Norway (EEA)
Collection — KYC/AML	Identity documents, PEP status, risk profile	Sumsub SDK	EU West(EEA)
Storage	All categoriesabove	SQLite (MVP) → PostgreSQL AES-256(Phase 2)	Railway EU WestNorway (Frankfurt/Paris)
Storage (files)	Receipt PDFs/JPGs	Cloudflare R2 AES-256	Cloudflare EU regionEEA)
Processing — AML monitoring	VATTransaction calculations,patterns, reportsamounts, corridors	ExpressAutomated API,rules Prisma ORMengine	RailwayNorway EU West(EEA)
Sharing — Remittance	InvoiceSender PDFsname, recipient name/account, amount	SendGridSWIFT/correspondent emailbanks	EUEEA region
E-invoice submission	Invoice XML	UBL 2.1 SEF / HR-FISK	Serbia (SEF) / Croatia (FINA)non-EEA
Deletion / Anonymization	UserAll PIIcategories	SoftAutomated deletedeletion +jobs anonymization(planned Phase 2)	RailwayNorway EU West(EEA)

---

2. Necessity & Proportionality Assessment

2.1 Purposes of Processing

requiredbylaw risk

Purpose	Specific Description	Legitimate?
AccountIdentity authenticationverification	Verify user identityis forwho organizationthey accessclaim, minimum age 18, Norwegian residency	YES — contractrequired necessityby (Art.hvitvaskingsloven 6.1.b)§ 12 and PSD2 SCA
InvoicePayment generationinitiation (PISP)	CreateInitiate legallypayments compliantfrom invoicesuser's bank account	YES — core service delivery
Account information (AISP)	Read bank balances for user dashboard	YES — core service delivery, with taxexplicit IDsconsent
AML/transaction monitoring	Detect and prevent money laundering	YES — legal obligation (Art.hvvl. 6.1.c)§§ 24-25)
VATKYC calculationcompliance	Customer identification and reporting	Calculate VAT at RS 20% / BA 17% / HR 25%assessment	YES — legal obligation (Art.hvvl. 6.1.c)§§ 10-18)
FinancialFraud record keepingdetection	Double-entryDetect booksunauthorized required by accounting lawtransactions	YES — legallegitimate obligationinterest (PSD2 Art. 6.1.c)2)
AuditTechnical traillogging	ImmutableSystem logerror oftracking, financialdebugging, mutationssecurity	YES — legal obligation + legitimate interest (Art.security 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)requirement)

2.2 Data Minimization Assessment

Device — marketing

Data Element	Collected	Strictly Necessary?	AlternativeJustification
emailFull name	YES	YES — login + invoice delivery	N/AIdentity verification (hvvl. § 12), payment routing
fullNameFødselsnummer (11 digits)	YES	YES — required on invoices	N/AUnique identification (hvvl. § 12(1)(a)), age verification (min 18)
passwordHashDate of birth	YES (derived from fødselsnummer)	YES	Age verification
Email address	YES	YES — authentication	N/AAccount (bcryptnotifications, hash)login
totpSecretPhone number (+47)	YES	YES — 2FA	N/ANorwegian residency verification, 2FA (planned)
organizationTaxIdBank (PIB/JIB/OIB)account number	YES	YES — legally required on invoices	N/AAISP balance reading, PISP payment initiation
organizationIbanTransaction data (amount, recipient, currency)	YES	YES — payment reference	N/AService delivery, AML monitoring, Bokføringsloven § 13
contactTaxIdIP (PIB/JMBG/OIB/JIB)address	YES	YES — VAT law requires buyer tax ID	N/ASecurity monitoring, rate limiting, fraud detection
contactIban	YES	PARTIAL — needed only for payment features	Collect only when payment active
clientIp (audit log)ID	YES	YES	Session security,management, fraud detection	Retain max 30 days for security entries
userAgentKYC documents (passport, national ID)	YES	YES	Hvitvaskingsloven § 12 identity verification
PEP status	YES	YES	Hvitvaskingsloven § 18
Marketing preferences	NO	NO — not collected	Not collected
deviceId	NO	NO — notno collected	Not collectedprocessing

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

2.3 Lawful Basis

transaction 10,

Processing Activity	Lawful Basis	Justification
Account managementcreation, identity verification	Contract — (Art. 6.1.bb)	NecessaryRequired tofor provideservice thedelivery
Payment initiation (PISP)	Contract (Art. 6.1.b)	Core service
InvoiceBank /account expensereading /(AISP)	Consent (Art. 6.1.a)	PSD2 requires explicit PSU consent
AML/KYC processing	Legal obligation — (Art. 6.1.cc)	ZakonHvitvaskingsloven o§§ PDV4, + Zakon o računovodstvu10-18
VATTransaction calculation and reportingmonitoring	Legal obligation — (Art. 6.1.cc)	MandatoryHvitvaskingsloven under§§ RS/BA/HR tax laws24-25
AuditFraud traildetection	Legal obligation + Legitimate interest — (Art. 6.1.c + 6.1.ff)	AccountingPSD2 lawArt. + fraud detection2
IP addressSecurity logging	Legitimate interest — (Art. 6.1.ff)	Security monitoring, 30-day retention
E-invoice submission (SEF/HR-FISK)	Legal obligation —DORA Art. 6.1.c	Mandatorysecurity electronic submission
Data retention beyond erasure	Legal obligation — Art. 6.1.c	10-11 year retention per accounting lawrequirement

---

3. Data Subjects & Categories of Data

3.1 Data Subject Groups

target:10,000—Year

Group	Description	Estimated Volume	Vulnerability Level
BusinessRegistered owners / adminsusers	SMBAdults owners(18+) usingresiding Bilkoin Norway, all backgrounds	1-10TBD per(launch organization	Low
Accountants	Professional accountants on client accounts	1-5 per organization	Low
Employees	Submitting expense claims via employer's account	Variable1)	Low-Medium
CounterpartiesMerchants	Customers/suppliersLegal appearingentities onregistering invoicesfor QR payment acceptance	ExternalTBD to(launch Bilkotarget: 500 — Year 1)	Low
Payment recipients	Persons abroad receiving remittances	TBD	Low (financialdata riskminimized if— breached)name + account only)

3.2 Personal Data Categories

+2

Category	Data Elements	Sensitivity	ClassificationRetention
ContactIdentity	Name,Full email,name, phonefødselsnummer, date of birth	StandardHigh (L4 for fødselsnummer)	L35 Confidentialyears after account closure (hvvl. §30)
AuthenticationContact	bcrypt(password),Email, TOTPphone secretnumber	HighStandard (L3)	L4Duration Restricted
Tax identity	PIB, JMBG, OIB, JIB	High	L4 Restrictedyears
Financial	InvoiceBank amounts,account IBAN,number, bankbalance transactions(AISP), transaction history	High (L3-L4)	L35 Confidentialyears (Bokføringsloven)
KYC/AML	Identity documents, PEP status, risk profile	High (L4)	5 years after account closure (hvvl. §30)
Behavioral / Audit	Transaction patterns, device ID, IP address, action timestamps, old/new valuesaddress	Standard (L3)	L212-24 Internalmonths (security logs), 5 years (AML)
AttachmentsBiometric	ReceiptNone PDFs,collected invoicedirectly attachments(BankID handles)	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, passwordHash, totpSecretphone	Contract (Art. 6.1.b)	UntilDuration account+ deletion2 years
InvoiceBankID creationSCA and deliveryverification	orgName, 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	Sender name, tax ID, contactrecipient name/taxaccount, ID/address,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, amounts	Legal obligation (Art. 6.1.c) — hvvl. §§ 24-25	10 years (RS) / 11 years (HR/BA RS entity)
VAT calculation	Invoice amounts, tax rates, tax IDs	Legal obligation (Art. 6.1.c)	10-115 years
ExpenseFraud managementdetection	Amounts,Transaction descriptions,patterns, receiptIP, imagesdevice ID	LegalLegitimate obligationinterest (Art. 6.1.c)f)	10-112 years
FinancialSecurity reportinglogging	AllIP, financialuser_id, action, timestamp	Legitimate interest (Art. 6.1.f)	12 months auth logs, 24 months security
Suspicious Transaction Reporting (EFE)	Identity + transaction data	Legal obligation (Art. 6.1.c) — hvvl. §26	10-115 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

flowchartUser TD→ DS([DataBankID Subject\nBusiness(SCA user])authentication)
     -->|Registers→ /Drop CreatesPlatform invoice| COLLECT[Web App\nbilko.io(Norway — VercelAWS EU]EEA)
         COLLECT├── -->|HTTPSRegistration POSTdata Zod→ validated|PostgreSQL API[ExpressDB API\napi.bilko.io(Norway)
         ├── KYC data → Sumsub (EU EEA) → Drop DB
         ├── AISP: Bank 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 — 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]
    ANON --> DB

    style DB fill:#ffcccc,stroke:#cc0000
    style AUDIT fill:#ffe4cc,stroke:#cc6600Norway)

Data processors (GDPR Art. 28):

SCCs

Processor	Service	Data Shared	Country	DPA StatusSigned
RailwayBankID Norge AS	PostgreSQLIdentity verification	Name, fødselsnummer	Norway (EEA)	Required — planned
Sumsub	KYC/AML document verification	ID documents, biometric liveness	EU (EEA)	Yes — legal/dpa-sumsub.md
Neonomics	PSD2 AISP/PISP	Bank account data, payment instructions	EU (EEA)	Required — planned
Swan	Banking/payment rails	Transaction data	EU (EEA)	Yes — legal/dpa-swan.md
AWS	Infrastructure hosting	All accountingdata data(encrypted)	EU West(EEA — Frankfurt/Ireland)	PendingAWS — sign before launchDPA
VercelSentry	FrontendError hostingmonitoring	BrowserError requestscontext, user IDs	Global / EU edge(EEA)	PendingYes — legal/dpa-sentry.md
CloudflareCorrespondent banks	CDN,Remittance WAF, R2routing	IPSender addresses,name, receiptamount, filesrecipient	EUNon-EEA region(per corridor)	Pending
SendGrid	Transactional email	Email, invoice PDFs	EU	Pendingrequired

---

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).| ScoreLow: 1-6:4 Low;| 7-12:Medium: Medium;5-8 | High: 9-12 | Critical: 13-19: High; 20-25: Critical.16

6.2 RisksRisk to Data Subjects

nosecondary Manualcomplaint IP

Risk ID	Risk to Data Subjects	Likelihood	Severity	Score	Existing Controls	Residual Risk
R1	Unauthorized access to financial data (tax IDs, IBAN, invoice amounts)breach)	2	54	108	TLS 1.3, AES-256,bcrypt, RBAC,JWT org-scopedhttpOnly, queriesparameterized SQL, session revocation	MEDIUM
R2	TaxData IDbreach (PIB/JMBG/OIB/JIB)exposing theftPII enablingor identity fraudfødselsnummer	2	54	108	L4Encryption Restricted,at RBAC,rest noplanned, JWTaccess exposure, bcryptcontrols	MEDIUM
R3	Cross-tenantUnlawful profiling through transaction data	1	3	3	Purpose limitation, data accessminimization, (IDOR)	2	5	10	org-scoped WHERE on all queries, UUID PKsuse	LOW (after mitigation)
R4	InvoiceThird-country transfer without adequate protection (remittance corridors)	3	3	9	SCCs planned, data exposureminimization to(name wrong+ partyaccount only in transfer)	HIGH → MEDIUM with TIA
R5	False positive — legitimate transaction blocked by AML rules	2	2	4	8	RBAC,review org-scope,within input24h, validation	MEDIUM
R5	Financial data manipulation (tampered invoices)	2	5	10	Immutable LoggedAction, RBAC delete permissionshandling	LOW (after mitigation)
R6	PIIData retained beyond necessarylegal periodrequirement	2	2	4	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	Soft deleteSCCs + anonymization;TIA financial+ data by law	LOW
R7	Cross-border transfer (RS/BA data to EU) without protection	3	3	9	Railway EU West; ZZPL Art. 65; data stays in EEAminimization	MEDIUM
R8	User unable to exercise erasure (locked by retention law)	3	2	6	Clear policy in privacy notice; PII anonymized	LOW
R9	ReceiptIdentity withfraud sensitive— datasomeone (medicalimpersonating receipts) exposeduser	2	3	6	Encrypted R2 storage; RBAC accountant+ access	LOW
R10	Audit log IP retention enabling tracking	2	21	4	30-day4	BankID retentionLevel forHigh security;(eIDAS), longerNorwegian forBankID financialonly	LOW
R11	SEF/HR-FISK state submission	1	2	2	Legal obligation — mandated by law	ACCEPTABLE

---

7. Mitigation Measures

Risk ID	Mitigation Measure	Owner	Deadline	Status
R1	Field-level AES-256-GCM encryption for tax IDs and IBAN at application layerfødselsnummer	Engineering	Phase 2	Planned
R1	SentryAWS errorKMS trackingkey +management Railwayfor anomalydatabase monitoringencryption keys	Platform	Phase 12	Planned
R2	TaxPostgreSQL IDswith L4TDE Restricted(Transparent —Data neverEncryption) invia JWT,AWS never in logsRDS	EngineeringPlatform	Phase 12	DesignedPlanned
R3R2	IntegrationPenetration tests:test cross-tenantbefore requestsproduction must return 403launch	EngineeringSecurity	Phase 1Pre-launch	Planned
R4	VitestSCCs RBAC tests onwith all protectedremittance endpointscorridor correspondent banks	EngineeringLegal	Phase 12	Planned
R5R4	LoggedActionTransfer PostgreSQLImpact triggerAssessments —per append-only,destination no DELETEcountry	EngineeringDPO/Legal	Phase 1	Designed
R7	Privacy notice states Railway EU West data residency; ZZPL Art. 65 transfer basis	Legal/DPO	Phase 12	Planned
R7R4	VerifyMinimize Railwaytransferred regiondata =(name, EUaccount, Westamount beforeONLY launch— no fødselsnummer)	PlatformEngineering	MVP	Implemented
R6	Automated data retention + deletion jobs (5-year AML, 2-year other)	Engineering	Phase 12	Planned
R8	PrivacyTIA noticefor explainshigh-risk legalcorridors retention(Pakistan, basisTurkey, clearlySerbia, Bosnia)	Legal/DPODPO/Legal	Phase 12	Planned
R9	R2 files accessible only to org members with accountant+ role	Engineering	Phase 1	Designed

Residual risk conclusion:after mitigation: All residual risks areassessed as LOW or MEDIUM. No CRITICALHIGH or HIGHCRITICAL residual risks.risks Processing may proceed subject to DPO approval andafter Phase 12 mitigations beingare implemented before first paying customer.implemented.

DPO Conclusion: ☐ Acceptable — proceed | ☐ Conditional — pendingProcessing Phasemay 1proceed mitigationsfor |MVP ☐(no Escalatelive transactions). Prior to supervisorylive authoritytransactions: BankID SCA required, KYC implemented, SCCs in place, DPO appointed.

---

8. DPO Consultation Record

DPO Name: TBD ([email protected])— DPO appointment required before Phase 2 launch Consultation Date: ToTBD beDPO scheduledInput: beforePending first paying customerappointment

DPO Input:

Recommendation

(required

[Tobefore belive completed after DPO appointment]

DPO Recommendation:transactions):

• Approved — risks are acceptable and adequately mitigated
• Conditional approval — subject to implementing Phase 12 mitigations
• Rejected — requires redesign required
•  Escalate to supervisory authority

DPO Signature: _________________________ Date: _____________

---

9. Supervisory Authority Consultation

Consultation Required: NO — based on current risk assessment (pendingall DPOresidual review)risks LOW-MEDIUM after mitigation) Reason:Basis: GDPR Art. 35(7) — Residual risks after mitigations are acceptable. No CRITICALprior orconsultation HIGHwith residualDatatilsynet risks. MEDIUM risks standard for cloud accounting SaaS.required.

Monitoring: If requiredPhase —2 relevantimplementation authoritiesreveals bynew jurisdiction:risks (e.g., from real-world transaction data), this assessment will be reviewed and Datatilsynet consultation may be required.

• 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-2312 (annual) orOR when:when any of the following occurs:

• NewBankID countryintegration launchimplemented (RS Phase 2,2)
HR
• Live PhasePSD2 2,AISP/PISP BAtransactions Phase 3)commenced
• New governmentremittance integrationcorridors (SEF,added
HR-FISK,
• Sumsub CPF)or KYC vendor changed
• Data breach orincident near-missrelated to this processing
• NewChange datain categoriesapplicable Norwegian or processorsEU regulations
• RegulatoryDORA changesimplementation in Norway (ZZPLexpected amendment,2026 BiH reform, GDPR updates)H2)

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

Review Log:

Date	Reviewer	Changes Made	Outcome
2026-02-2312	Compliance ArchitectAgent (ALAI)	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	ComplianceALAI ArchitectSecurity Team	2026-02-23
DPO	TBD — appointment required
EngineeringProcessing LeadOwner	Alem Bašić (CEO/CISO)
Legal Counsel	TBD
CEOManagement	Alem Bašić