Athena — auditPic/compliance/bio.md

BIO Assessment — Baseline Informatiebeveiliging Overheid

Project: auditPic Date: 2026-03-27 Status: Draft

BIO is based on ISO 27001/27002 and applies to Dutch government and government-adjacent systems.

Note: auditPic is a commercial mobile application, not a government system. This BIO assessment is conducted for completeness and because audit organisations in the (semi-)public sector (e.g. municipalities, healthcare institutions, educational institutions) may deploy auditPic in contexts where BIO compliance is expected of their tooling suppliers.


1. Informatieclassificatie

| Informatietype | Beschikbaarheid | Integriteit | Vertrouwelijkheid | Classificatie | |----------------|----------------|-------------|-------------------|--------------| | Auditfoto's (mogelijk met persoonsgegevens) | Hoog — verlies of onbeschikbaarheid ondermijnt het auditdoel | Hoog — integriteit is de kern van de dienst; SHA-256 hash borgt dit | Hoog — foto's kunnen gezichten, locaties, gevoelige contexten bevatten | Hoog | | Auditmetadata (audit-ID, auditor, tijdstempel, hash) | Hoog — nodig voor traceerbaarheid | Hoog — auditspoor mag niet manipuleerbaar zijn | Midden — metadata is minder direct gevoelig dan de foto's zelf | Midden | | SHA-256 hashes | Midden — verlies vereist herberekening uit foto | Hoog — hash mag nooit overschreven worden anders verlies je het integriteitsbewijs | Laag — hash is pseudoniem, geen directe persoonsgegevens | Midden | | Gebruikersaccounts (Firebase Auth) | Hoog — uitval blokkeert toegang tot de app | Hoog — accountcompromittering leidt tot onbevoegde toegang | Hoog — e-mailadres is persoonsgegeven | Midden | | Crashrapporten (Crashlytics, geanonimiseerd) | Laag — verlies heeft beperkte impact | Midden — integriteit relevant voor diagnose | Laag — geen PII | Basis |


2. Controls Assessment

A.5 — Informatiebeveiligingsbeleid

| Control | Status | Maatregel | |---------|--------|-----------| | 5.1 Beleid voor informatiebeveiliging | ✅ | Informatiebeveiligingsbeleid gedocumenteerd; jaarlijkse review ingepland |

A.6 — Organisatie van informatiebeveiliging

| Control | Status | Maatregel | |---------|--------|-----------| | 6.1 Interne organisatie | ✅ | Verantwoordelijk persoon aangewezen; rollen en verantwoordelijkheden gedocumenteerd | | 6.2 Mobiele apparatuur en telewerken | ⬜ | Auditors gebruiken mobiele apparaten; MDM-beleid voor auditorganisaties in voorbereiding; richtlijnen voor schermvergrendeling en encryptie op te stellen |

A.8 — Beheer van bedrijfsmiddelen

| Control | Status | Maatregel | |---------|--------|-----------| | 8.1 Verantwoordelijkheid voor bedrijfsmiddelen | ✅ | Firebase-project, Storage-bucket, Firestore-database, Auth-project, Crashlytics-project gedocumenteerd in inventarislijst | | 8.2 Informatieclassificatie | ✅ | Classificatieschema vastgesteld (zie sectie 1 hierboven); foto's classificatie Hoog | | 8.3 Behandeling van media | ✅ | Foto's uitsluitend opgeslagen in Firebase Storage (versleuteld); geen export naar onbeveiligde lokale opslag via de app; geen fysieke media |

A.9 — Toegangsbeveiliging

| Control | Status | Maatregel | |---------|--------|-----------| | 9.1 Bedrijfseisen voor toegangsbeveiliging | ✅ | Toegangsbeleid gedocumenteerd; Firebase Security Rules als primair toegangscontrole-mechanisme | | 9.2 Beheer van toegangsrechten | ✅ | Onboarding via Firebase Auth; accountverwijdering bij uitdiensttreding; admin-rol voor beheertaken; auditors zien alleen eigen audits | | 9.3 Verantwoordelijkheden van gebruikers | ✅ | Gebruikersrichtlijnen; auditors verantwoordelijk voor eigen accountbeveiliging; MFA aanbevolen | | 9.4 Toegangsbeveiliging voor systemen en toepassingen | ✅ | Firebase Security Rules UID-gebaseerd; Firebase App Check voorkomt ongeautoriseerde clients; MFA beschikbaar |

A.10 — Cryptografie

| Control | Status | Maatregel | |---------|--------|-----------| | 10.1 Cryptografische beheersmaatregelen | ✅ | SHA-256 voor foto-integriteit (on-device berekend); AES-256 versleuteling in rust via Firebase; TLS 1.3 in transport; cryptografiebeleid gedocumenteerd |

A.12 — Beveiliging van de bedrijfsvoering

| Control | Status | Maatregel | |---------|--------|-----------| | 12.1 Bedieningsprocedures en verantwoordelijkheden | ✅ | Runbooks voor Firebase-beheer, deploymentproces en incidentrespons gedocumenteerd | | 12.2 Bescherming tegen malware | ✅ | Dependency scanning in CI/CD; SAST op Flutter-code; geen server-side code buiten Firebase Rules | | 12.3 Back-up | ✅ | Firebase Storage multi-region replicatie; Firestore point-in-time recovery; code in versiebeheer met offsite backup | | 12.4 Verslaglegging en monitoren | ✅ | Firebase Auth-activiteitslogs; Firestore schrijfgeschiedenis via timestamps; Crashlytics voor app-gezondheid; geen PII in logs | | 12.6 Beheer van technische kwetsbaarheden | ✅ | Flutter/Dart dependency updates via Dependabot; Firebase SDK versies gemonitord; security advisories bijgehouden |

A.13 — Communicatiebeveiliging

| Control | Status | Maatregel | |---------|--------|-----------| | 13.1 Beheer van netwerkbeveiliging | ✅ | Firebase Security Rules als netwerkniveau toegangscontrole; App Check blokkeert ongeautoriseerde clients; geen directe database-toegang vanuit internet | | 13.2 Informatietransport | ✅ | TLS 1.3 afgedwongen door Firebase SDK; certificaatvalidatie ingebouwd; foto's nooit via onbeveiligde kanalen verzonden |

A.14 — Acquisitie, ontwikkeling en onderhoud van informatiesystemen

| Control | Status | Maatregel | |---------|--------|-----------| | 14.1 Beveiligingseisen voor informatiesystemen | ✅ | Beveiligingseisen (SHA-256 integriteit, Security Rules, App Check) gedocumenteerd in architectuur; PSD2-equivalent: Firebase Auth als vertrouwensanker | | 14.2 Beveiliging in ontwikkelings- en ondersteunende processen | ✅ | Verplichte code review; SAST in CI; branch protection; geen hardcoded credentials; Firebase-configuratie via omgevingsvariabelen | | 14.3 Testgegevens | ✅ | Aparte Firebase-testomgeving; geen productiedata in tests; testfoto's bevatten geen echte personen |

A.16 — Beheer van informatiebeveiligingsincidenten

| Control | Status | Maatregel | |---------|--------|-----------| | 16.1 Beheer van informatiebeveiligingsincidenten | ⬜ | Incidentresponsproces in concept; formalisering gepland; specifieke aandacht voor scenario van ongeautoriseerde toegang tot auditfoto's |

A.17 — Informatiebeveiligingsaspecten van BCM

| Control | Status | Maatregel | |---------|--------|-----------| | 17.1 Continuïteit van informatiebeveiliging | ⬜ | BCM-plan in ontwikkeling; RTO 8 uur; RPO 1 uur; Firebase managed availability als fundament | | 17.2 Redundantie | ✅ | Firebase Storage multi-region; Firestore multi-region beschikbaar; app is stateless op device (foto's direct naar Storage) |

A.18 — Naleving

| Control | Status | Maatregel | |---------|--------|-----------| | 18.1 Naleving van wettelijke en contractuele eisen | ✅ | GDPR-naleving geborgd via DPIA; Google DPA met SCC in plaats; auditorganisaties geïnformeerd over hun eigen bewaarverplichtingen; retentiebeleid per sector te bepalen | | 18.2 Beoordeling van informatiebeveiliging | ⬜ | Firebase Security Rules penetratietest gepland; interne jaarlijkse audit te plannen |


3. Gaps & Verbeteracties

| Control | Gap | Prioriteit | Eigenaar | Streefdatum | |---------|-----|-----------|----------|-------------| | 16.1 | Incidentresponsproces niet formeel gedocumenteerd en niet geoefend | Hoog | GloryLabs | 2026-05-01 | | 17.1 | BCM/DR-plan niet gedocumenteerd | Hoog | GloryLabs | 2026-05-01 | | 18.2 | Firebase Security Rules penetratietest niet uitgevoerd | Hoog | GloryLabs | 2026-06-01 | | 6.2 | MDM-beleid voor auditapparaten niet voltooid | Midden | GloryLabs | 2026-06-01 | | 12.x | Automatisch retentie/verwijderingsworkflow voor foto's niet geïmplementeerd | Midden | GloryLabs | 2026-07-01 |

Reacties

Nog geen reacties