Athena — auditPic/compliance/processes/data-flow.md

Process Documentation

Process: Audit Photo Capture and Integrity Verification Data Flow Project: auditPic Owner: GloryLabs Date: 2026-03-27


1. Purpose

This process describes how data moves through auditPic — from auditor login through photo capture, on-device SHA-256 hashing, upload to Firebase, QR code generation, and external integrity verification — with explicit documentation of where personal data is created, stored, and how the integrity chain is maintained.

2. Scope

Systems involved:

  • Flutter mobile app (Android/iOS) — installed on auditor's device
  • Firebase Auth (user authentication)
  • Firebase Storage (photo storage)
  • Firestore (audit metadata and hash storage)
  • Firebase Crashlytics (anonymised crash reporting)
  • QR code scanner (external verifier's device)

Data involved:

  • Auditor credentials (email, UID)
  • Audit photos (JPEG/PNG, potentially containing personal data)
  • SHA-256 hash of each photo (computed on device)
  • Audit metadata (audit ID, auditor UID, timestamp, GPS if enabled, audit type, status)
  • QR code payload (hash + audit ID)
  • Anonymised crash telemetry

People involved:

  • Auditor (app user, field operative)
  • Audit administrator / manager (reviews audits in app or backend)
  • Verifier (external party who verifies photo integrity via QR code)
  • Individuals incidentally appearing in photos (data subjects)

3. Trigger

An auditor opens auditPic, logs in, and initiates a new audit session to capture photo evidence at a physical location.

4. Process Steps

| Step | Actor | Action | System | Output | |------|-------|--------|--------|--------| | 1 | Auditor | Opens app and logs in | Firebase Auth | JWT issued; user authenticated with UID | | 2 | Auditor | Creates a new audit or opens an existing one | Firestore | Audit document created {audit_id, auditor_uid, timestamp, status: in_progress} | | 3 | Auditor | Takes a photo via app camera | Flutter app (device camera) | Raw photo file in device memory | | 4 | Flutter app | Computes SHA-256 hash of photo bytes on-device | Flutter app (dart:crypto) | SHA-256 hash string | | 5 | Flutter app | Uploads photo to Firebase Storage | Firebase Storage | Photo stored at path: /audits/{audit_id}/photos/{photo_id} | | 6 | Flutter app | Writes metadata + hash to Firestore | Firestore | Document: {photo_id, audit_id, auditor_uid, timestamp, gps (if enabled), sha256_hash, storage_path} | | 7 | Flutter app | Generates QR code from {audit_id, photo_id, sha256_hash} | Flutter app (QR library) | QR code displayed on screen; exportable as image | | 8 | Auditor | Marks audit as complete | Firestore | Audit document status updated to: completed | | 9 | Verifier | Scans QR code and downloads photo from Storage | Firebase Storage + Flutter/web verifier | Photo retrieved | | 10 | Verifier | Re-computes SHA-256 hash of downloaded photo | Verifier device | Hash recomputed | | 11 | Verifier | Compares recomputed hash with hash from QR code (and/or Firestore) | Firestore (optional lookup) | Match = integrity confirmed; mismatch = tampered | | 12 | Admin | Reviews completed audits; manages retention | Firestore + Firebase Storage | Audits archived or deleted per retention policy |

5. Data Flow

Auditor Device                Firebase Auth        Firebase Storage       Firestore
      |                            |                       |                   |
      |-- login() ---------------->|                       |                   |
      |<-- UID + JWT --------------|                       |                   |
      |                            |                       |                   |
      |-- create audit ------------|---------------------->|------------------>|
      |   {audit_id, auditor_uid,  |                       |                   |
      |    timestamp}              |                       |                   |
      |                            |                       |                   |
   [Auditor takes photo]           |                       |                   |
      |                            |                       |                   |
      | compute SHA-256 on-device  |                       |                   |
      | [hash computed in memory]  |                       |                   |
      |                            |                       |                   |
      |-- upload photo ------------|---------------------->|                   |
      |   /audits/{id}/photos/{id} |                       | photo stored      |
      |                            |                       |                   |
      |-- write metadata -----------|----------------------|------------------>|
      |   {photo_id, sha256,       |                       |                   |
      |    storage_path,           |                       |                   |
      |    timestamp, gps?}        |                       |                   |
      |                            |                       |                   |
      | generate QR code           |                       |                   |
      | {audit_id, photo_id, hash} |                       |                   |
      |                            |                       |                   |
      |-- mark audit complete ------|----------------------|------------------>|
      |                            |                       |                   |
                                                           |                   |
Verifier Device                                            |                   |
      |                            |                       |                   |
      |-- scan QR code             |                       |                   |
      |   {audit_id, photo_id,     |                       |                   |
      |    expected_hash}          |                       |                   |
      |                            |                       |                   |
      |-- download photo -----------|---------------------->|                   |
      |<-- photo file -------------|                       |                   |
      |                            |                       |                   |
      | recompute SHA-256          |                       |                   |
      | compare with QR hash       |                       |                   |
      |                            |                       |                   |
      |-- (optional) lookup hash --|---------------------->|------------------>|
      |<-- stored hash ------------|                       |                   |
      |                            |                       |                   |
      | MATCH: integrity confirmed |                       |                   |
      | MISMATCH: tamper detected  |                       |                   |

Key data protection properties:

  • Photo is hashed on the auditor's device before upload; the hash is the integrity anchor
  • Photos are stored in Firebase Storage with access controlled by Firebase Security Rules (auditors see own audits; admins see all; unauthenticated users see nothing)
  • The QR code contains only the hash and audit identifiers — no photo content, no personal data
  • GPS coordinates are optional; when disabled, no location data is stored
  • Crashlytics receives no photo content and no PII

6. Error Handling

| Failure scenario | Response | |-----------------|----------| | Firebase Auth failure (login fails) | App shows error; user retries; no data written | | Upload to Firebase Storage fails | App retries with exponential backoff; photo held in local queue; user notified if persistent failure | | Firestore write fails after photo upload | App retries; inconsistency logged; admin can reconcile orphaned photos via admin panel | | SHA-256 hash mismatch on verification | Verifier notified of tamper detection; audit record flagged; audit organisation notified | | GPS permission denied | GPS field omitted from metadata; audit continues without location data | | Crashlytics unavailable | App continues normally; crash report queued locally and retried | | Account deletion before audit completion | Audit record orphaned; admin must reassign or archive; orphaned-audit cleanup process to be implemented |

7. Related Documents

  • ../dpia.md — Data Protection Impact Assessment for auditPic
  • ../verwerkingsregister.md — Art. 30 GDPR processing register
  • ../nis2.md — NIS2 security assessment
  • ../bio.md — BIO controls assessment

Reacties

Nog geen reacties