Freeck

Mentions Légales & Sécurité

Retour à l'accueil

Incident Response Procedure

Incident Response Procedure – Freeck

Last updated: 2025-02-10

This procedure defines how security incidents and personal-data breaches are handled.

1. Definition of an Incident

An incident includes (non-exhaustive):

  • Unauthorized access to Firebase data
  • Firestore rules misconfiguration
  • Exposure of personal data
  • Compromise of QR signing keys
  • Offline data tampering
  • Data loss affecting users
  • Suspicious authentication behavior

2. Severity Levels

Level 1 – Minor

  • No personal data involved
  • Local bug or small issue

Action: Fix in upcoming release, document internally.

Level 2 – Medium

  • Potential but unconfirmed security flaw
  • Limited exposure risk

Action:

  • Investigate within 48 hours
  • Patch if needed
  • Document incident and resolution

Level 3 – Major (Personal Data Breach)

  • Confirmed personal-data breach
  • Key compromise or large-scale incident

Action:

  • Immediate containment (revoke keys, tighten rules, disable features)
  • Assess scope and impacted data
  • Notify users if breach is likely to result in a high risk to their rights
  • Notify the Belgian DPA (APD) within 72 hours when required (GDPR Art. 33)
  • Perform full post-mortem

3. Incident Response Workflow

  1. Detection

    • Monitoring (Firebase, logs)
    • User reports
    • Internal QA findings

  2. Assessment

    • Identify affected components (Firestore, Auth, offline DB…)
    • Determine severity level
    • Decide on immediate containment steps

  3. Containment

    • Revoke compromised tokens/keys
    • Temporarily disable affected functionality
    • Adjust Firestore rules if needed

  4. Eradication

    • Fix root cause (code/infra)
    • Validate that vulnerability is closed
    • Clean up residual malicious data if any

  5. Recovery

    • Restore normal service
    • Monitor for regressions

  6. Notification

    • Users (when high risk to rights/freedoms)
    • Authorities (when required under GDPR)

  7. Post-Incident Review

    • Document incident details, timeline, root cause, and fixes
    • Update this procedure or architecture to prevent recurrence

4. Responsibilities

  • The developer (controller) is responsible for handling incidents end-to-end.
  • All incidents of Level 2 and 3 must be recorded in an internal log.

5. Contact

security@[domain]