[ ] Essential entity (Annex I)
[ ] Important entity (Annex II)
[x] Out of scope — auditPic is a mobile application used internally by audit organisations for evidence capture. It is not a digital infrastructure provider, trust service provider, or online marketplace. The underlying infrastructure (Firebase/Google) is itself subject to NIS2 as an essential cloud provider; auditPic as a service built on top of it does not independently qualify as an essential or important entity under NIS2 Annex I or II.

Note: Individual audit organisations deploying auditPic in regulated sectors (e.g. healthcare, financial services, critical infrastructure) may themselves be subject to NIS2 and should conduct their own assessment.

Sector: Enterprise software / mobile application — not directly classified under NIS2 sector categories. If deployed in healthcare (Annex I) or financial services (Annex II) audit contexts, the audit organisation is the regulated entity, not GloryLabs.

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 security responsible

3. Risk Management Measures (Art. 21)

3.1 Policies

[x] Information security policy documented
[x] Risk assessment policy in place — DPIA covers risk assessment
[ ] Incident handling policy in place — to be formalised
[ ] Business continuity / disaster recovery policy in place — Firebase managed availability; GloryLabs DR plan to be documented

3.2 Technical measures

| Measure | Status | Notes | |---------|--------|-------| | Multi-factor authentication | ✅ | MFA available and recommended via Firebase Auth; enforced for admin accounts; auditor MFA configurable per organisation | | Encryption at rest | ✅ | Firebase Storage and Firestore encrypted at rest by Google (AES-256) | | Encryption in transit | ✅ | All Firebase SDK communications over TLS 1.3; enforced by Firebase | | Vulnerability management / patching | ✅ | Flutter and Firebase SDK dependency updates tracked; Dependabot/Renovate in CI pipeline | | Network segmentation | ✅ | Firebase Security Rules enforce data access boundaries between audits and users; App Check prevents unauthorised clients | | Endpoint protection | ⬜ | Auditor mobile devices not centrally managed; MDM policy for audit organisations to be recommended | | Logging & monitoring (SIEM) | ✅ | Firebase App Check and Auth logs; Firestore write audit trail via timestamps; Crashlytics for app health | | Penetration testing | ⬜ | Planned; Firebase Security Rules to be formally tested | | Secure SDLC | ✅ | Code review required; SAST in CI; Flutter best practices followed; no sensitive data in code | | Access control (least privilege) | ✅ | Firebase Security Rules: auditors access own audits only; admin role for cross-audit access; UID-based rules | | Backup & restore tested | ✅ | Firebase Storage multi-region replication; Firestore point-in-time recovery available; tested in staging | | Supply chain security | ✅ | Firebase/Google supply chain under Google's own NIS2/ISO 27001 compliance programme; Flutter dependencies reviewed |

3.3 Organisational measures

[x] Asset inventory maintained — Firebase project, Storage bucket, Firestore database, Auth project, Crashlytics documented
[x] Third-party / supplier risk assessed — Google/Firebase assessed; DPA in place; SOC 2 / ISO 27001 certified
[ ] Security awareness training for all staff — to be scheduled
[x] Acceptable use policy — in place for internal development access; auditor usage guidelines to be provided to deploying organisations

4. Incident Reporting (Art. 23)

Note: As auditPic is assessed as out of scope for NIS2 direct obligations, the following describes the recommended incident handling posture aligned with NIS2 principles.

Early warning (24h): On detection of a significant incident (e.g. Firebase Security Rules bypass, unauthorised access to audit photos, account compromise), GloryLabs notifies affected audit organisations within 24 hours and documents the incident.

Notification (72h): If the incident involves a personal data breach, notification to the Autoriteit Persoonsgegevens (AP) within 72 hours per GDPR Art. 33. If the audit organisation is itself a NIS2-regulated entity, they notify their competent authority independently.

Final report (1 month): Full incident report provided to affected audit organisations within one month of detection.

Competent authority: Autoriteit Persoonsgegevens (AP) — for GDPR breach notifications. NIS2 competent authority (RDI) if reclassification as Important Entity is determined. CSIRT: NCSC-NL for guidance; sector-specific CSIRT if deployed in regulated sector.

5. Supply Chain Security (Art. 21.2d)

| Supplier | Criticality | Security assessment done? | DPA / SLA in place? | |----------|------------|--------------------------|---------------------| | Google LLC (Firebase — Auth, Storage, Firestore, Crashlytics) | Critical — all core data processing depends on Firebase | Yes — Google is ISO 27001, SOC 2 Type II, ISO 27017, ISO 27018 certified; NIS2 compliance as cloud provider | Yes — Google Cloud Data Processing Addendum (DPA) with SCCs | | Flutter (Google/open source) | Medium — client-side framework; no server-side data access | Open source; maintained by Google; Flutter security advisories monitored | N/A (open source) | | Dart pub.dev dependencies | Medium — third-party packages could introduce vulnerabilities | Dependency review policy; pinned versions; audit before adding new packages | N/A (open source) |

6. Business Continuity (Art. 21.2c)

[x] RTO defined: 8 hours — target for restoring app functionality following a Firebase service disruption (primarily dependent on Google SLA)
[x] RPO defined: 1 hour — Firestore point-in-time recovery; Firebase Storage replication provides near-zero RPO for stored photos
[ ] DR plan documented (see processes/disaster-recovery.md) — to be documented; largely dependent on Firebase managed availability
[ ] DR tested: not yet performed — Firebase failover behaviour to be validated in staging

7. Gaps & Remediation

| Gap | Priority | Owner | Target date | |-----|----------|-------|-------------| | Incident handling policy not formalised | High | GloryLabs | 2026-05-01 | | Business continuity / DR plan not documented | High | GloryLabs | 2026-05-01 | | Firebase Security Rules penetration test not performed | High | GloryLabs | 2026-06-01 | | Security awareness training not scheduled | Medium | GloryLabs | 2026-05-15 | | MDM guidance for auditor devices not provided to deploying organisations | Medium | GloryLabs | 2026-06-01 | | ~~Automated photo retention / deletion workflow not implemented~~ | ~~Medium~~ | ~~GloryLabs~~ | Resolved 2026-05-09 — DELETE /api/v1/auth/me cascades to photos, tokens, MinIO; daily RetentionService enforces per-photo retention_days. |

Reacties

Nog geen reacties

Athena — auditPic/compliance/nis2.md

NIS2 Assessment

1. Scope