Rationale: Mahmoud Consultancy B.V. is an SME operating a niche IT staffing platform. Under NIS2 (EU 2022/2555, implemented in NL via Cyberbeveiligingswet), the platform does not currently meet the size thresholds for mandatory classification as an important or essential entity (fewer than 50 employees, annual turnover below €10M). However, given the SNA keurmerk requirements and the processing of personal data on IT professionals, the risk management measures prescribed by NIS2 Art. 21 are adopted voluntarily as best practice. This assessment should be re-evaluated if the platform scales significantly or if Mahmoud Consultancy B.V. is designated by a competent authority.

2. Governance (Art. 20)

[x] Management body has approved cybersecurity policy — managing director of Mahmoud Consultancy B.V. has reviewed and accepted the security posture described in this document and in bio.md
[ ] Cybersecurity training provided to management — planned Q2 2026; GloryLabs to provide a tailored briefing covering platform-specific risks
[x] Responsible person / CISO designated — GloryLabs acts as technical security owner; Mahmoud Consultancy B.V. managing director is the accountable business owner

3. Risk Management Measures (Art. 21)

3.1 Policies

[x] Information security policy documented — see bio.md and this document
[x] Risk assessment policy in place — documented in dpia.md §5; reviewed annually or after significant changes
[x] Incident handling policy in place — documented in processes/incident-response.md; covers detection, containment, AP notification (72h), client notification
[ ] Business continuity / disaster recovery policy in place — DR plan in processes/disaster-recovery.md is a stub; full plan due Q2 2026

3.2 Technical measures

| Measure | Status | Notes | |---------|--------|-------| | Multi-factor authentication | 🟡 | MFA enforced for all GloryLabs admin/SSH access via 1Password; MFA for candidate/employer end-user accounts planned Q3 2026 | | Encryption at rest | ✅ | LUKS full-disk encryption on TransIP VPS; PostgreSQL data files and Redis snapshots on encrypted volume | | Encryption in transit | ✅ | TLS 1.3 enforced on all Ingress endpoints via Let's Encrypt (cert-manager in k3s); Gmail SMTP over STARTTLS; internal k3s service-to-service via mTLS (planned, currently plain within cluster network) | | Vulnerability management / patching | 🟡 | TransIP VPS OS auto-updates enabled for security patches; k3s node patched monthly; container base images rebuilt on new Spring Boot / Angular releases; no formal CVE scanning pipeline yet — Trivy scan planned Q2 2026 | | Network segmentation | 🟡 | k3s NetworkPolicy restricts pod-to-pod traffic; VPS firewall (UFW) limits inbound to ports 80/443/22; Redis and PostgreSQL not exposed outside cluster; single-node cluster limits further segmentation | | Endpoint protection | 🟡 | GloryLabs developer machines use macOS with XProtect + 1Password; no MDM policy enforced yet — planned Q3 2026 | | Logging & monitoring (SIEM) | 🟡 | Application-level audit logs in PostgreSQL; k3s pod logs via stdout (no centralised aggregation yet); Grafana/Loki stack planned Q2 2026 | | Penetration testing | ⬜ | Not yet performed; planned external pentest Q3 2026 before production go-live | | Secure SDLC | 🟡 | Code review required for all PRs; GitHub Actions CI with build and lint checks; OWASP dependency-check planned; no formal threat modelling process yet | | Access control (least privilege) | ✅ | Spring Boot RBAC: CANDIDATE / EMPLOYER / ADMIN roles enforced at API level; database access via dedicated service account (not superuser); k3s RBAC configured; SSH key-only access to VPS | | Backup & restore tested | 🟡 | Daily PostgreSQL pg_dump to TransIP object storage; backup existence verified weekly; full restore test not yet documented — scheduled Q2 2026 | | Supply chain security | 🟡 | Container images pinned to SHA digests in k3s manifests; Bitnami Sealed Secrets for k8s secret management; Firecrawl DPA pending; SBOM generation not yet implemented |

3.3 Organisational measures

[x] Asset inventory maintained — see §5 Supply Chain table and verwerkingsregister.md; infrastructure components documented in project wiki
[x] Third-party / supplier risk assessed — see §5 below and dpia.md §7; Firecrawl DPA gap identified
[ ] Security awareness training for all staff — planned Q2 2026 for both Mahmoud Consultancy B.V. staff and GloryLabs developers
[x] Acceptable use policy — included in GloryLabs developer onboarding documentation; Mahmoud Consultancy staff policy in progress

4. Incident Reporting (Art. 23)

Note: As an out-of-scope entity, NIS2 mandatory reporting timelines do not currently apply. The following procedures are adopted voluntarily and align with GDPR Art. 33 obligations, which do apply.

Early warning (24h): On detection of a significant incident (data breach, service compromise, ransomware, DDoS), GloryLabs notifies the managing director of Mahmoud Consultancy B.V. within 4 hours via direct phone call and Signal message. An initial internal incident ticket is opened in the project tracker with severity classification.

Notification (72h): If the incident involves personal data, Mahmoud Consultancy B.V. (as verwerkingsverantwoordelijke) notifies the Autoriteit Persoonsgegevens via the AP online meldloket within 72 hours of becoming aware of the breach, per GDPR Art. 33. GloryLabs provides technical detail to support the notification. If NIS2 mandatory reporting ever applies, notification goes to NCSC-NL / RDI within 24h (early warning) and 72h (full notification).

Final report (1 month): A post-incident report is produced by GloryLabs within 30 days, covering root cause, impact assessment, affected data subjects, remediation steps taken, and preventive measures. Report is shared with Mahmoud Consultancy B.V. and retained for 5 years.

Competent authority: Autoriteit Persoonsgegevens (AP) for GDPR; NCSC-NL / RDI (Rijksinspectie Digitale Infrastructuur) if NIS2 scope is triggered in future

CSIRT: NCSC-NL (as national CSIRT); no sector-specific CSIRT applies at current scale

5. Supply Chain Security (Art. 21.2d)

| Supplier | Criticality | Security assessment done? | DPA / SLA in place? | |----------|------------|--------------------------|---------------------| | TransIP B.V. | High — sole hosting provider for VPS and backups | Yes — TransIP ISO 27001 certified; NEN 7510 certified; Dutch company subject to GDPR | Yes — TransIP verwerkersovereenkomst; SLA included in hosting contract | | Google (Gmail SMTP / Workspace) | Medium — transactional email delivery | Yes — Google Workspace security whitepaper reviewed; SOC 2 Type II; ISO 27001 | Yes — Google Workspace DPA + SCCs | | Firecrawl | Medium — job scraping; outage = reduced vacancy data only | No — assessment pending | No — DPA required before production | | GitHub (GHCR) | Medium — CI/CD pipeline and image registry | Yes — GitHub SOC 2 Type II; Microsoft security programme | Partial — GitHub DPA available; no personal data in images | | 1Password | High — secrets management; compromise = full platform credential exposure | Yes — 1Password SOC 2 Type II; end-to-end encryption; zero-knowledge architecture | No personal data stored; 1Password business DPA available; to be signed Q2 2026 | | Bitnami (VMware/Broadcom) | Medium — Sealed Secrets for k8s | Yes — open-source component; no external data transmission | No external data transmission; supply chain via signed Helm chart |

6. Business Continuity (Art. 21.2c)

[x] RTO defined: 4 hours — target time to restore platform availability after a full VPS failure (based on restoring from backup to a new TransIP VPS instance)
[x] RPO defined: 24 hours — maximum acceptable data loss, aligned with daily backup frequency; target improvement to 1 hour with WAL streaming replication (planned Q3 2026)
[ ] DR plan documented — processes/disaster-recovery.md stub exists; full runbook due Q2 2026
[ ] DR tested: Not yet tested — first DR drill scheduled Q2 2026 alongside backup restore test

Single points of failure identified:

Single k3s node on a single TransIP VPS — no automatic failover
Single PostgreSQL instance — no replica; only backup-based recovery
Gmail SMTP as sole outbound email provider

Mitigation roadmap: Multi-node k3s and PostgreSQL streaming replication are on the Q3 2026 roadmap as the platform scales to production.

7. Gaps & Remediation

| Gap | Priority | Owner | Target date | |-----|----------|-------|-------------| | Firecrawl DPA / SCCs not signed | High | Mahmoud Consultancy B.V. + GloryLabs | Q2 2026 — before production go-live | | No centralised log aggregation (Grafana/Loki) | Medium | GloryLabs | Q2 2026 | | No automated container vulnerability scanning (Trivy) | Medium | GloryLabs | Q2 2026 | | DR plan not documented or tested | High | GloryLabs | Q2 2026 | | Backup restore not formally tested | High | GloryLabs | Q2 2026 | | MFA not enforced for end-user accounts | Medium | GloryLabs | Q3 2026 | | No external penetration test performed | High | Mahmoud Consultancy B.V. + GloryLabs | Q3 2026 (before go-live) | | Security awareness training not yet delivered | Medium | GloryLabs | Q2 2026 | | mTLS not yet active for in-cluster service communication | Low | GloryLabs | Q3 2026 | | SBOM / software supply chain inventory not generated | Low | GloryLabs | Q3 2026 | | No MDM for developer endpoint management | Low | GloryLabs | Q3 2026 |

Reacties

Nog geen reacties

Athena — mahmoud-consultancy/compliance/nis2.md

NIS2 Assessment

1. Scope