Europe Login provides digital identity and authentication services for businesses, positioning it within the scope of digital infrastructure / ICT service management under NIS2 Annex II. As an authentication provider replacing or complementing e-Herkenning — a government-adjacent digital identity scheme used for access to Dutch public and semi-public services — the system is considered a provider of trust services and digital identity infrastructure. NIS2 applicability should be confirmed with legal counsel and, if applicable, notified to the Rijksinspectie Digitale Infrastructuur (RDI).

Sector: ICT service management / Digital infrastructure (trust services, authentication services) — Annex II NIS2

2. Governance (Art. 20)

[ ] Management body has approved cybersecurity policy
[ ] Cybersecurity training provided to management
[ ] Responsible person / CISO designated

Current status: GloryLabs is in early development. Governance structure for cybersecurity is not yet formalised. These items are identified as priority gaps — see Section 7.

3. Risk Management Measures (Art. 21)

3.1 Policies

[ ] Information security policy documented
[ ] Risk assessment policy in place
[ ] Incident handling policy in place
[ ] Business continuity / disaster recovery policy in place

All four policies are identified as gaps. The DPIA (see dpia.md) covers part of the risk assessment for personal data. A broader information security policy encompassing availability, integrity, and confidentiality of the authentication service is required.

3.2 Technical measures

| Measure | Status | Notes | |---------|--------|-------| | Multi-factor authentication | 🟡 | MFA for end users at MIDDEN/HOOG assurance levels is a core product feature; MFA for admin/operator access to infrastructure not yet documented | | Encryption at rest | ✅ | BSN encrypted with AES at rest; Kubernetes Secrets used for key storage; PostgreSQL on encrypted VPS volume | | Encryption in transit | ✅ | TLS enforced on all API endpoints; inter-service communication within k3s cluster uses TLS; JWT tokens signed (HS256/RS256) | | Vulnerability management / patching | 🟡 | OWASP ZAP security testing (make test-security) before major releases; automated dependency updates not yet confirmed; k3s and OS patching cadence not documented | | Network segmentation | 🟡 | k3s namespaces (europe-login / europe-login-staging) provide logical separation; network policies between namespaces not yet documented | | Endpoint protection | ⬜ | Endpoint protection on developer workstations and VPS not yet documented | | Logging & monitoring (SIEM) | 🟡 | Authentication events logged; centralised log aggregation and alerting (SIEM) not yet implemented | | Penetration testing | 🟡 | OWASP ZAP automated DAST scanning in place; manual penetration test not yet scheduled | | Secure SDLC | ✅ | Pre-commit test hooks enforced; 90% branch coverage requirement on new code; feature branch / PR workflow; no direct commits to main; secrets via environment variables only; no credentials in code | | Access control (least privilege) | 🟡 | RBAC via representative roles (BESTUURDER, GEMACHTIGDE, GEVOLMACHTIGDE); JWT-scoped claims; admin access to k3s cluster via kubeconfig — least-privilege policy not formally documented | | Backup & restore tested | ⬜ | PostgreSQL backup strategy and restore testing not yet documented or tested | | Supply chain security | 🟡 | Container images built from source and pushed to private GHCR registry with immutable SHA tags; base image provenance and SBOM not yet verified |

3.3 Organisational measures

[ ] Asset inventory maintained — no formal asset inventory exists; the infrastructure comprises a TransIP VPS running k3s, PostgreSQL, and Redis, with frontend and backend containers in GHCR
[ ] Third-party / supplier risk assessed — TransIP and KvK API identified as key suppliers; formal risk assessment not yet completed
[ ] Security awareness training for all staff — not yet scheduled
[ ] Acceptable use policy — not yet documented

4. Incident Reporting (Art. 23)

Early warning (24h): No formal procedure exists. To be established: an internal alert triggered by automated monitoring (to be implemented) or manual detection, escalated to the designated responsible person within 2 hours, with early warning submitted to NCSC-NL within 24 hours.

Notification (72h): To be established: a formal notification process to the competent authority (RDI) within 72 hours of a confirmed significant incident, including preliminary assessment of impact, affected parties, and initial containment measures.

Final report (1 month): To be established: a comprehensive incident report submitted within 1 month, covering root cause analysis, full impact assessment, remediation steps taken, and recurrence prevention measures.

Competent authority: Rijksinspectie Digitale Infrastructuur (RDI) — primary NIS2 supervisory authority for digital infrastructure and ICT service providers in the Netherlands. CSIRT: NCSC-NL (Nationaal Cyber Security Centrum) — national CSIRT for the Netherlands.

5. Supply Chain Security (Art. 21.2d)

| Supplier | Criticality | Security assessment done? | DPA / SLA in place? | |----------|------------|--------------------------|---------------------| | TransIP B.V. | High — primary infrastructure (VPS, storage) | No — to be completed | DPA: not yet concluded; SLA: standard TransIP hosting terms | | KvK API (Kamer van Koophandel) | Medium — company validation on every authentication | No — public government API | No DPA required (KvK as independent controller); API usage governed by KvK API terms | | GitHub / GHCR (Microsoft) | Medium — CI/CD pipeline and container registry | No formal assessment | GitHub DPA in place via standard terms; GHCR_TOKEN (PAT) with read:packages scope used | | Spring Boot / Angular / PostgreSQL / Redis | Medium — open source components | No formal SBOM | Open source; license compliance to be verified; dependency vulnerability scanning to be added to CI |

6. Business Continuity (Art. 21.2c)

[ ] RTO defined: Target RTO is 4 hours (production authentication service); not yet formally documented
[ ] RPO defined: Target RPO is 1 hour (maximum data loss on PostgreSQL); not yet formally documented
[ ] DR plan documented (see processes/disaster-recovery.md) — disaster recovery process not yet documented
[ ] DR tested: No DR test has been performed; k3s on TransIP VPS is single-node; no multi-region or failover configuration currently in place

Business continuity is a significant gap given that Europe Login is an authentication dependency for downstream services. Single-node k3s deployment on TransIP VPS introduces a single point of failure. Remediation plan required — see Section 7.

7. Gaps & Remediation

| Gap | Priority | Owner | Target date | |-----|----------|-------|-------------| | Information security policy not documented | High | GloryLabs management | Q2 2026 | | Incident handling policy not documented | High | GloryLabs management | Q2 2026 | | No designated CISO / responsible person | High | GloryLabs management | Q2 2026 | | Business continuity / DR plan not documented | High | GloryLabs engineering | Q2 2026 | | TransIP DPA not concluded | High | GloryLabs legal | Q2 2026 | | PostgreSQL backup not tested | High | GloryLabs engineering | Q2 2026 | | No centralised log aggregation / SIEM | Medium | GloryLabs engineering | Q3 2026 | | Penetration test (manual) not yet scheduled | Medium | GloryLabs management | Q3 2026 | | Asset inventory not maintained | Medium | GloryLabs engineering | Q2 2026 | | Endpoint protection not documented | Medium | GloryLabs management | Q3 2026 | | Supply chain / SBOM not verified | Medium | GloryLabs engineering | Q3 2026 | | Management cybersecurity training | Medium | GloryLabs management | Q3 2026 | | Network policy (k3s namespace isolation) | Low | GloryLabs engineering | Q3 2026 |

Reacties

Nog geen reacties

Athena — europeLogin/compliance/nis2.md

NIS2 Assessment

1. Scope