menu
save_alt Λήψη

Incident Response Plan

Effective February 9, 2026

< Back

Purpose

This plan defines how Beekeeper Studio responds to security incidents affecting our cloud services and customer data.

Our Architecture: Beekeeper Studio is a desktop database client. Customer database queries and results are processed locally on customer devices. This plan focuses on incidents affecting our cloud services (account management, billing, license validation, support systems, and optional workspace sync). See Data Flow Diagram for complete architecture.

Critical Timeline: 72 hours to notify affected customers of data breaches (NDPA requirement for educational institutions)

1. What is a Security Incident?

1.1 Incidents We Must Respond To

Definitely an incident:

  • Unauthorized access to cloud services (AWS, Heroku, production databases)
  • Data breach (customer account data, workspace data, or support data accessed by unauthorized party)
  • Ransomware or malware infection on systems with access to customer data
  • Lost or stolen device containing customer data or credentials
  • Compromised credentials (passwords, API keys, access tokens)
  • Successful phishing attack leading to cloud service access
  • Unauthorized access to customer workspaces (optional cloud feature)

Probably an incident (investigate):

  • Multiple failed login attempts to production systems
  • Unusual access patterns to customer account data or workspaces
  • Unexpected system behavior in cloud services

Not usually an incident:

  • Single failed login attempt
  • Dependabot vulnerability alert (handled via patch process)
  • Service outage due to infrastructure issue (no data exposure)
  • Desktop app crashes (no cloud data involved)

2. Incident Severity Levels

Level Definition Example Response Time
Critical Customer data exposed or likely exposed Cloud database breach, stolen laptop with unencrypted workspace data Immediate (within 1 hour)
High Potential data exposure, system compromise Compromised admin account, successful phishing Within 4 hours
Medium Security control failure, no data exposure yet Backup failure, MFA disabled Within 24 hours
Low Minor security issue, no risk to data Failed login attempts Within 3 days

If unsure: Treat as High and escalate.

Note: Customer database breaches (where customers connect their own databases) are not Beekeeper Studio incidents since we never access customer databases. However, if the breach is due to compromised credentials stored in our cloud workspace feature, that is our incident.

3. Incident Response Team

Incident Commander: Founder/CTO

  • Overall response coordination
  • Decision-making
  • Customer/LEA communication

Technical Response: Software Engineer

  • System containment and investigation
  • Evidence collection
  • Remediation

External Support (as needed):

  • Security incident response firm
  • Legal counsel
  • AWS/Heroku support

Contact Information

Keep updated in Bitwarden:

Incident Commander: [Your name, phone, email]
Technical Response: [Contractor name, phone, email]
Legal Counsel: [Lawyer name, firm, phone]

AWS Support: [Account details]
Heroku Support: [Account details]

4. Incident Response Process (6 Phases)

Phase 1: Detection and Activation (0-1 hour)

Detection sources:

  • Automated security alerts
  • Team member reports
  • Customer reports
  • External notification

Immediate actions:

  1. Document time and what was detected
  2. Assess severity (use table above)
  3. Activate Incident Commander
  4. Start incident log (Google Doc or markdown)

Incident Log Format:

# Incident Response Log - [Date]

## Detection
- Time: [timestamp]
- Detected by: [person/system]
- Initial symptoms: [what we saw]
- Severity: [Critical/High/Medium/Low]

## Timeline
[Keep running log with timestamps]

## Evidence
[Links to logs, screenshots]

## Communications
[Record all notifications]

Phase 2: Containment (1-4 hours)

Goal: Stop the incident from spreading, preserve evidence

Containment actions:

If compromised account:

  • Reset password immediately
  • Revoke all sessions
  • Review access logs
  • Check for unauthorized changes

If malware/ransomware:

  • Isolate affected systems
  • DO NOT delete anything (preserve evidence)
  • Snapshot systems
  • Assess what data accessed

If data breach (cloud services):

  • Identify scope (what data: account info, workspace data, support tickets)
  • Identify affected customers
  • Preserve evidence (logs, snapshots)
  • Contain access (revoke credentials, patch vulnerability)
  • Start 72-hour notification clock (if applicable)

If lost/stolen device:

  • Verify encryption enabled
  • Remote wipe if possible (if device managed)
  • Revoke all credentials for that user
  • Assess what data was on device (customer data, credentials, access tokens)
  • Notify affected customers if their data was on device

Phase 3: Investigation (4-24 hours)

Key questions:

  1. How did it happen? (root cause)
  2. What data was accessed? (scope)
  3. Who was affected? (customers, students)
  4. When did it start? (timeline)
  5. Is it contained? (no ongoing access)

For data breaches, document:

  • Exact data fields exposed (account info, workspace data, billing info, support tickets)
  • Number of affected customers
  • Date/time range of exposure
  • Whether data was encrypted at rest
  • Whether data was actually exfiltrated or just accessible
  • Which cloud services were affected (AWS, Heroku, etc.)

Phase 4: Eradication (24-48 hours)

Goal: Remove threat completely, fix vulnerabilities

  • Patch vulnerability
  • Remove malware
  • Reset all potentially compromised credentials
  • Remove any backdoors
  • Verify attacker no longer has access

Phase 5: Recovery (48-72 hours)

Goal: Restore normal operations, verify security

  • Restore systems from clean backups if needed
  • Bring systems online gradually
  • Test functionality
  • Monitor closely for reinfection
  • Resume normal operations

Phase 6: Notification (Must complete within 72 hours for customer data breaches)

CRITICAL: If customer data potentially exposed, must notify affected customers within 72 hours of discovery.

Who to notify:

Incident Type Notify Timeline
Customer data breach (any customer data) Affected customers 72 hours
Incident contained, no data exposed No external notification Internal only

Notification process:

  1. Hour 0-48: Investigation and documentation
  2. Hour 48-60: Draft notification using Breach Notification Template
  3. Hour 60-72: Send notifications (email + phone call if critical)

Breach notification must include:

  • Date and time of breach discovery
  • Description of what happened
  • Types of data affected (account info, workspace data, etc.)
  • Number of customers affected
  • Contact information for questions
  • Mitigation steps taken
  • Steps customers should take (if any)

Template: See Breach Notification Template

For Educational Institutions (NDPA Customers)

When notifying educational institutions under NDPA agreements:

Additional requirements (NDPA Section 5.4):

  • Must specify if student data was affected
  • Include number of students affected (if known)
  • Notify LEA (school/district), not individual students
  • LEA determines whether to notify parents/students

What counts as “student data”:

  • Only data in cloud workspaces containing student information
  • Support tickets containing student information
  • Does NOT include: customer database connections (we never access these)

5. Post-Incident Review (Within 7 days)

Post-incident meeting (30-60 minutes):

Agenda:

  1. What happened (summary)
  2. What went well
  3. What could improve
  4. Root cause
  5. Action items to prevent recurrence

Deliverable: Post-Incident Report

# Post-Incident Report - [Date]

## Summary
- Severity: [level]
- Impact: [what data, how many users]
- Resolution: [what we did]

## Timeline
- Detection: [time]
- Containment: [time]
- Resolution: [time]

## Root Cause
[What vulnerability allowed this]

## What Went Well
- [Positive 1]
- [Positive 2]

## What Could Improve
- [Gap 1]
- [Gap 2]

## Action Items
- [ ] [Fix 1 - owner - due date]
- [ ] [Fix 2 - owner - due date]

## Lessons Learned
[Key takeaway]

6. Specific Incident Types (Quick Reference)

Compromised Credentials

  1. Reset password immediately
  2. Revoke all sessions
  3. Review access logs
  4. Notify user
  5. Enable MFA

Ransomware

  1. Isolate affected systems
  2. DO NOT pay ransom
  3. DO NOT delete anything
  4. Restore from backups

Data Breach (Cloud Services)

  1. Identify scope (what data: accounts, workspaces, support)
  2. Identify affected customers
  3. Contain access
  4. Preserve evidence
  5. Start 72-hour notification clock

Lost/Stolen Device

  1. Verify encryption enabled
  2. Remote wipe if possible
  3. Revoke credentials
  4. Assess data on device

Phishing Success

  1. Reset compromised credentials
  2. Review account activity
  3. Scan device for malware
  4. Educate user

7. Communication Templates

Internal Alert (Slack/Email)

SECURITY INCIDENT - [Severity]

Time: [timestamp]
Type: [brief description]
Impact: [known or suspected]
Status: [Investigating / Contained / Resolved]

Actions Required:
- [Action 1]
- [Action 2]

Contact: [Incident Commander]

Customer Breach Notification

Use Breach Notification Template (see template)

Must include all required fields within 72 hours. For NDPA customers, include additional student data fields as specified above.

8. Prevention and Preparedness

Preventive Controls

  • MFA on all production systems
  • Encryption at rest and in transit
  • Dependabot vulnerability scanning
  • Regular backups

Detective Controls

  • Automated alerts for suspicious activity
  • Honeybadger error monitoring
  • Papertrail log monitoring

Preparedness

  • Quarterly: Review and update contact info
  • Annual: Conduct tabletop exercise (simulate incident)
  • Annual: Test backup restoration

9. External Resources

When to call for help:

  • Ransomware or widespread malware
  • Unsure how to contain or eradicate
  • Customer data exposure
  • Beyond technical capability

Cost: $200-$500/hour typically

Free resources:

  • AWS Security Hub
  • FBI Internet Crime Complaint Center (ic3.gov)

  • US-CERT (us-cert.gov)

Quick Reference Card

SECURITY INCIDENT QUICK REFERENCE

1. DETECT - Document, assess severity, identify affected cloud services
2. CONTAIN - Stop spread, preserve evidence
3. INVESTIGATE - What data? Who affected? Root cause?
4. ERADICATE - Patch, remove threat
5. RECOVER - Restore systems, monitor
6. NOTIFY - Customers: 72 hours if data breach
7. REVIEW - Post-incident meeting within 7 days

CRITICAL: 72-hour customer notification for data breaches
Additional NDPA requirements for educational institutions

Incident Commander: [Name, Phone]
Security Contact: support@beekeeperstudio.io

Document Information

Version: 2.0
Effective Date: 2026-02-09
Last Reviewed: 2026-02-09
Next Review Due: 2027-02-09
Owner: CTO / Security Contact
Approved By: CEO

Changes from v1.0: Clarified desktop app architecture, made NDPA requirements optional section, added cross-references to legal documents.

Security Policies

Appendix: Incident Response Checklist

Critical Data Breach Response (72-Hour Timeline)

Hour 0-4: Detection and Containment

  • Document detection time
  • Activate Incident Commander
  • Assess severity (customer data exposed?)
  • Identify what cloud services affected
  • Contain breach
  • Preserve evidence
  • Start incident log

Hour 4-24: Investigation

  • Review logs (AWS, Heroku, application logs)
  • Identify exact data exposed (accounts, workspaces, support)
  • Identify affected customers
  • Determine timeline
  • Verify containment

Hour 24-48: Eradication

  • Patch vulnerability
  • Reset compromised credentials
  • Remove backdoors or unauthorized access
  • Test and verify fix

Hour 48-60: Notification Prep

  • Draft customer notification using template
  • Include NDPA-specific fields if applicable
  • Legal review (if needed)
  • Executive approval
  • Verify customer contact information

Hour 60-72: Send Notifications

  • Email to affected customers
  • Phone call if critical breach
  • Document all notifications sent
  • Provide resources and support contact

Post-Incident

  • Monitor for continuing issues
  • Post-incident review (within 7 days)
  • Update policies
  • File documentation