Project: Europe Login — Dutch Business Identity & Authentication Platform Version: 1.0 Date: 2026-03-27 Status: Draft Owner: GloryLabs
What does this system do? Europe Login is a Dutch business identity and authentication platform functioning as an e-Herkenning alternative. It acts as an OAuth2/OIDC identity provider that authenticates company representatives on behalf of their employer. The system verifies Dutch company registrations via the KvK (Kamer van Koophandel) API, stores company representatives with their roles (BESTUURDER, GEMACHTIGDE, GEVOLMACHTIGDE), and issues JWT tokens at three assurance levels (BASIS, MIDDEN, HOOG). It processes BSN (Burger Service Nummer) as the primary identity anchor for natural persons acting on behalf of legal entities.
Why is a DPIA required?
The BSN is a national identification number classified as a special category under Dutch law (Wet algemene bepalingen burgerservicenummer) and treated with equivalent protection to Art. 9 GDPR data. The system processes BSNs at scale across all business authentication events and introduces a new technical infrastructure (custom OIDC provider) for a domain previously served by government-regulated parties.
| Category | Data fields | Purpose | Legal basis (Art. 6) | Retention | |----------|------------|---------|----------------------|-----------| | Company representative identity | BSN (encrypted), first name, last name, email address | Authentication and authorisation of company representatives | Art. 6(1)(b) — execution of a contract (service agreement with the company) | Duration of active mandate + 1 year after termination | | Company data | KvK number, company name, legal form, active/inactive status | Verification that the company exists and is active before issuing authentication tokens | Art. 6(1)(b) — execution of a contract | Duration of service agreement + 1 year | | Authentication session data | JWT tokens, token issuance timestamps, assurance level, IP address | Providing authenticated sessions and audit trail | Art. 6(1)(b) / Art. 6(1)(f) legitimate interest (security) | 90 days rolling | | Redis session cache | Session identifiers, token metadata | Short-lived session management and token revocation | Art. 6(1)(b) | TTL-based, maximum 24 hours |
| Category | Data fields | Explicit consent obtained? | |----------|------------|---------------------------| | BSN (Dutch national identifier — special category under Wabb / treated equivalent to Art. 9 GDPR) | BSN of each company representative | No — processing is based on legal obligation and execution of contract; explicit consent is not the applicable basis. A lawful basis under Art. 87 GDPR juncto Wabb applies. |
| Group | Estimated count | Vulnerable? | |-------|----------------|-------------| | Company representatives (BESTUURDER, GEMACHTIGDE, GEVOLMACHTIGDE) | Up to tens of thousands per deployed instance | No | | System administrators / operators | < 10 | No |
BSN and personal details of company representatives are entered by the company administrator when registering a representative in the Europe Login portal. KvK numbers are submitted by the user and validated in real time against the KvK API. No data is collected from data subjects without their knowledge; representatives are notified at registration.
Is the processing necessary for the stated purpose? Yes. Authenticating company representatives without BSN would not achieve a sufficient assurance level to function as a trustworthy e-Herkenning alternative. BSN is the only national identifier that unambiguously links a natural person to a legal entity mandate in the Dutch administrative system.
Could the purpose be achieved with less data or less intrusive means? Not at the MIDDEN and HOOG assurance levels. At BASIS level, KvK number and email may suffice for low-risk use cases. The system is designed so that BSN is only required for MIDDEN and HOOG assurance flows, applying data minimisation by assurance level.
Is the retention period proportionate? Yes. Active mandate data is needed for the duration of the service. The 1-year post-termination retention serves legitimate dispute resolution purposes and aligns with standard contractual retention practices. Session and log data is retained for 90 days for security auditing, which is proportionate given the authentication context.
| Risk | Likelihood (1-5) | Impact (1-5) | Score | Mitigation | |------|-----------------|--------------|-------|------------| | Unauthorised access to BSN data | 2 | 5 | 10 | AES encryption at rest; BSN never logged or transmitted in plaintext; JWT does not include BSN; RBAC; Kubernetes Secrets for encryption key | | Data breach / leak via API | 2 | 5 | 10 | TLS enforced on all endpoints; no BSN in API responses; OWASP ZAP security testing before releases; input validation | | Data loss (PostgreSQL) | 2 | 4 | 8 | Database hosted on TransIP VPS with backup capability; Kubernetes persistent volumes; DR plan to be documented | | Unlawful processing (BSN without valid basis) | 1 | 5 | 5 | Processing basis documented; BSN processing limited to authenticated and registered representatives only; inactive companies rejected | | Inaccurate data (stale KvK / representative data) | 3 | 3 | 9 | KvK validation on every authentication attempt; company administrators responsible for maintaining representative list | | Profiling / discrimination | 1 | 3 | 3 | No profiling logic; system is stateless between sessions; assurance level is not retained beyond the session | | JWT token theft / replay | 2 | 4 | 8 | Short-lived JWTs; Redis-backed revocation list; TLS in transit; token bound to assurance level |
Residual risk after mitigation: Medium — primarily driven by the inherent sensitivity of BSN data. Residual risk is acceptable given the technical controls in place, subject to completion of the DR plan and formal DPA agreements with processors.
bsn-encryption-key)| Processor | Country | Processing activity | DPA in place? | |-----------|---------|---------------------|--------------| | TransIP B.V. | Netherlands | VPS hosting — PostgreSQL and Redis data storage, k3s cluster | No — to be concluded | | Kamer van Koophandel (KvK API) | Netherlands | Real-time company registration validation (KvK number lookup only; no personal data shared) | No — public API; KvK is a data controller in its own right for its registry data | | GitHub / GHCR | USA (Microsoft) | Container image registry (no personal data in images) | Standard GitHub DPA applies; no personal data processed |
| Right | How it is fulfilled | |-------|---------------------| | Access (Art. 15) | Company administrators can view representative data in the portal. Direct requests from representatives can be submitted to GloryLabs; response within 30 days. | | Rectification (Art. 16) | Company administrators can update representative details. Direct rectification requests handled by GloryLabs support. | | Erasure (Art. 17) | Representatives can be removed by the company administrator. Erasure requests from individuals handled by GloryLabs; BSN and personal fields deleted, authentication logs anonymised. | | Restriction (Art. 18) | Processing can be restricted by disabling a representative record without deletion; to be implemented as an administrative feature. | | Portability (Art. 20) | Representative data can be exported in JSON format by the company administrator via the portal API. | | Object (Art. 21) | Objections to processing based on legitimate interest (Art. 6(1)(f)) can be submitted to GloryLabs. Processing based on contract execution (Art. 6(1)(b)) cannot be objected to without terminating the service. |
DPO consulted: No — GloryLabs does not currently have a formally appointed DPO. Given the scale and nature of processing (BSN at potential scale), appointment of a DPO should be assessed. Date: — Outcome: Pending
Prior consultation with AP required (Art. 36)? To be determined — residual risk is currently assessed as Medium. If risk cannot be reduced below high after DR and DPA remediation, prior consultation with the Autoriteit Persoonsgegevens (AP) will be required.
| Role | Name | Date | Signature | |------|------|------|-----------| | Author | GloryLabs | 2026-03-27 | | | Reviewer | | | | | Approver | | | |
| Version | Date | Author | Changes | |---------|------|--------|---------| | 1.0 | 2026-03-27 | GloryLabs | Initial version |
Reacties