[ ] Essential entity (Annex I)
[x] Important entity (Annex II) — valideerleeftijd is a digital service (API) used by client companies for age-gating; as a provider of digital services it falls under Annex II (digital providers / ICT service management)
[ ] Out of scope

Sector: ICT service management / Digital services — the system provides a trust service (age verification) built on PSD2/Open Banking infrastructure. Client companies may operate in regulated sectors (alcohol, gambling, adult content).

2. Governance (Art. 20)

[x] Management body has approved cybersecurity policy
[ ] Cybersecurity training provided to management — to be scheduled
[x] Responsible person / CISO designated — GloryLabs technical lead acts as responsible person

3. Risk Management Measures (Art. 21)

3.1 Policies

[x] Information security policy documented
[x] Risk assessment policy in place — DPIA covers risk assessment; technical risk register maintained
[ ] Incident handling policy in place — to be formalised
[ ] Business continuity / disaster recovery policy in place — to be documented

3.2 Technical measures

| Measure | Status | Notes | |---------|--------|-------| | Multi-factor authentication | ✅ | MFA required for all internal systems and cloud consoles; API clients authenticate via API key | | Encryption at rest | ✅ | Redis encrypted at rest; no other persistent data store | | Encryption in transit | ✅ | TLS 1.3 enforced on all API endpoints and bank AISP calls | | Vulnerability management / patching | ✅ | Dependency scanning in CI/CD pipeline; Node.js and Spring Boot dependencies updated regularly | | Network segmentation | ✅ | Redis not exposed to public internet; internal network only | | Endpoint protection | ⬜ | Developer workstation EDR policy to be standardised | | Logging & monitoring (SIEM) | ✅ | API gateway logs centralised; alerts on anomalous request rates; no PII in logs | | Penetration testing | ⬜ | Planned before production go-live | | Secure SDLC | ✅ | Code review required; SAST in CI pipeline; secrets scanning enabled | | Access control (least privilege) | ✅ | Role-based access; API keys scoped to client; internal access restricted by role | | Backup & restore tested | ✅ | Redis is ephemeral by design; no backup needed for session data; configuration and code backed up in version control | | Supply chain security | ✅ | Third-party dependencies reviewed; DPA required from Tink/Klarna and Redis provider |

3.3 Organisational measures

[x] Asset inventory maintained — API services, Redis instance, PSD2 provider connection documented
[x] Third-party / supplier risk assessed — Tink/Klarna and Redis provider assessed; DPAs to be signed
[ ] Security awareness training for all staff — to be scheduled
[x] Acceptable use policy — in place for internal development access

4. Incident Reporting (Art. 23)

Early warning (24h): On detection of a significant incident (e.g. suspected unauthorised access to the Redis store, API compromise, or PSD2 token theft), the responsible person is notified immediately and an early warning is filed with the competent authority within 24 hours via the authority's online portal.

Notification (72h): A full incident notification is submitted to RDI (Rijksinspectie Digitale Infrastructuur) within 72 hours, including nature of the incident, affected systems, estimated number of affected data subjects (if any), and initial mitigation steps taken.

Final report (1 month): A final incident report is submitted within one month, detailing root cause, full scope, corrective actions taken, and measures to prevent recurrence.

Competent authority: RDI (Rijksinspectie Digitale Infrastructuur) — responsible for digital service providers under NIS2 in the Netherlands CSIRT: NCSC-NL (Nationaal Cyber Security Centrum)

5. Supply Chain Security (Art. 21.2d)

| Supplier | Criticality | Security assessment done? | DPA / SLA in place? | |----------|------------|--------------------------|---------------------| | Tink / Klarna Open Banking (PSD2 AISP) | High — critical path for age verification; outage blocks all verifications | Tink/Klarna is a licensed PSD2 institution under EBA supervision; security assessment via their compliance documentation | DPA to be signed; SLA to be confirmed | | Redis cloud provider (e.g. Redis Cloud / AWS ElastiCache) | High — session store; outage blocks all active flows | Cloud provider SOC 2 / ISO 27001 assessed | DPA to be confirmed | | Node.js / Spring Boot runtime + dependencies | Medium — supply chain attack via dependencies | SAST and dependency scanning in CI; npm audit / Maven dependency check | N/A (open source; managed via internal policy) |

6. Business Continuity (Art. 21.2c)

[x] RTO defined: 4 hours — target for restoring API availability following an infrastructure failure
[x] RPO defined: 0 — no persistent personal data; Redis session data is ephemeral; active sessions during an outage are simply re-initiated by the user
[ ] DR plan documented (see processes/disaster-recovery.md) — to be documented
[ ] DR tested: not yet performed — planned before go-live

7. Gaps & Remediation

| Gap | Priority | Owner | Target date | |-----|----------|-------|-------------| | Incident handling policy not yet formalised | High | GloryLabs | 2026-05-01 | | Business continuity / DR plan not yet documented | High | GloryLabs | 2026-05-01 | | Penetration test not yet performed | High | GloryLabs | 2026-06-01 | | DPA with Tink/Klarna Open Banking not yet signed | High | GloryLabs | 2026-04-15 | | DPA with Redis cloud provider not yet signed | Medium | GloryLabs | 2026-04-15 | | Security awareness training not yet scheduled | Medium | GloryLabs | 2026-05-15 | | Developer endpoint EDR policy not standardised | Low | GloryLabs | 2026-06-01 |

Reacties

Nog geen reacties

Athena — valideerleeftijd/compliance/nis2.md

NIS2 Assessment

1. Scope