Incident Response Plan

Last updated: March 25, 2026

1. Purpose and scope

This plan describes how Bungaflow (operated by Redor AS) detects, responds to, and recovers from security incidents and data breaches.

It applies to all systems, data, and personnel involved in operating the Bungaflow platform.

2. Definitions

  • Security incident: Any event that compromises the confidentiality, integrity, or availability of the Bungaflow platform or its data.
  • Data breach (personal data): A breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data (GDPR Art. 4(12)).
  • Severity levels: S1 Critical, S2 Major, S3 Minor (as defined in our SLA).

3. Detection and reporting

  • Automated monitoring: Error tracking (Sentry), uptime monitoring, CI/CD security scanning (Gitleaks, Dependabot).
  • Logging: Activity logs for all data modifications in the application.
  • Internal reporting: Team members report suspected incidents immediately to the incident lead.
  • External reporting: Users can report security concerns to security@bungaflow.com.
  • Responsible disclosure: We welcome security researchers reporting vulnerabilities responsibly.

4. Incident classification

LevelImpactExamples
S1 CriticalData breach with personal data exposure, full service outage, active exploitationDatabase leak, credential compromise, ransomware
S2 MajorPartial service degradation, potential data exposure, vulnerability with high riskAuth bypass, injection vulnerability, partial outage
S3 MinorLimited impact, no data exposure, low-risk vulnerabilityInformation disclosure (non-personal), minor misconfiguration

5. Response procedures

Phase 1: Identification (0–1 hour)

  • Confirm the incident is real (not a false positive)
  • Classify severity level
  • Assign incident lead
  • Begin documentation in incident log

Phase 2: Containment (1–4 hours for S1/S2)

  • Short-term: Isolate affected systems (revoke access, block IPs, disable features)
  • Preserve evidence (logs, snapshots)
  • Assess blast radius (which data/users affected)

Phase 3: Eradication (4–24 hours for S1/S2)

  • Remove the cause (patch vulnerability, rotate credentials, update dependencies)
  • Verify fix with security review
  • Deploy via CI/CD pipeline with automated checks

Phase 4: Recovery (24–48 hours for S1/S2)

  • Restore normal operations
  • Monitor for recurrence
  • Verify data integrity

Phase 5: Post-incident review (within 5 business days)

  • Root cause analysis
  • Timeline of events
  • What went well, what can improve
  • Action items and preventive measures
  • Update this plan if needed

6. GDPR breach notification

In accordance with GDPR Articles 33 and 34:

To supervisory authority (Datatilsynet)

Within 72 hours of becoming aware, unless unlikely to result in risk to individuals. Notification includes: nature of breach, categories and approximate number of data subjects, contact details, likely consequences, measures taken.

To affected data subjects

Without undue delay when the breach is likely to result in high risk to their rights and freedoms. Clear, plain language describing: nature of breach, contact details, likely consequences, measures taken and recommended actions.

To data controllers

If Bungaflow processes data on behalf of a controller (see our Data Processing Agreement), the controller is notified within 48 hours.

7. Communication

  • Internal: Incident lead coordinates all internal communication.
  • Affected customers: Direct email notification for S1/S2 incidents affecting their data.
  • Public: Status page update for service-affecting incidents.
  • Media: All media inquiries directed to contact@bungaflow.com.
  • No disclosure of technical details that could enable further exploitation.

8. Security measures in place (preventive)

  • Encryption: TLS in transit, AES-256-GCM for sensitive fields at rest.
  • Authentication: Supabase Auth with OAuth and magic links (no stored passwords).
  • Authorization: Role-based access control (Admin/Lite) with server-side verification.
  • Headers: HSTS, X-Frame-Options, Content-Security-Policy.
  • CI/CD: Automated linting, type checking, build verification, and secret scanning (Gitleaks) on every code change.
  • Dependencies: Automated vulnerability scanning via Dependabot.
  • Data minimization: Only necessary data collected, cascade delete on account removal.
  • Sub-processor vetting: All sub-processors have DPA and security certifications (SOC 2 Type II, ISO 27001).

For full details, see our Privacy Policy.

9. Roles and responsibilities

  • Incident lead: Coordinates response, makes containment decisions, communicates with stakeholders.
  • Development team: Implements technical fixes, deploys patches.
  • Data protection: Assesses GDPR implications, handles authority notifications.

Contact: security@bungaflow.com

10. Review and updates

  • This plan is reviewed at least annually.
  • Updated after every S1/S2 incident based on lessons learned.
  • All team members are familiar with this plan.