menu
save_alt Descargar

Information Security Policy

Effective February 9, 2026

< Back

Purpose

This policy establishes Beekeeper Studio’s approach to protecting customer data and securing our systems and infrastructure.

Framework: Based on NIST Cybersecurity Framework and CIS Critical Security Controls.

Audience: All team members with access to company systems or customer data.

1. Overview

1.1 Our Architecture

Beekeeper Studio is a desktop database client. Our architecture consists of:

  • Desktop Application: Installed locally on user devices, connects directly to customer databases
  • Cloud Services: Account management, billing, license validation, support systems, and optional workspace sync
  • Customer Control: Database queries and results remain under customer control (direct connections, processed locally)

Data Flow: See Data Flow Diagram for complete architecture overview.

1.2 What Data We Handle

We collect and process:

  • Account Data: Email, name, subscription information (see Privacy Policy)
  • Billing Data: Payment information (processed by Stripe, we never see card numbers)
  • Support Data: Support tickets, error logs, diagnostic information
  • Workspace Data (Optional Feature): Saved queries, connection configs, preferences (if customer uses cloud workspace sync)
  • Telemetry (Opt-in): Anonymized usage statistics for product improvement

What We Don’t Handle: Customer database queries and results (except when customers voluntarily share via support tickets or cloud workspaces).

1.3 Our Security Commitment

We protect customer data through:

  • Strong authentication (MFA on all production systems)
  • Encryption at rest and in transit
  • Regular security updates and monitoring
  • Clear data handling procedures
  • Fast incident response
  • Compliance with applicable privacy laws
  • Cyber liability insurance ($1MM coverage for data breach/loss)

2. Customer Data Protection

2.1 Data Ownership

All customer data remains the property of our customers.

We are a service provider. We do not own or control:

  • Customer databases (we never access these)
  • Database credentials (encrypted locally or in cloud workspace)
  • Query results (processed locally unless saved to cloud workspace)
  • Account information (customer property, we process on their behalf)

2.2 Purpose Limitation

We use customer data only to:

  • Provide our contracted services (database client tool, account management, support)
  • Process billing and subscriptions
  • Respond to support requests
  • Improve our product (with opt-in anonymized telemetry only)

We never use customer data for:

  • Targeted advertising
  • Marketing to third parties
  • Selling or sharing data
  • Creating user profiles for non-service purposes

2.3 Data Deletion and Export

Upon customer request, we will:

  • Delete account data within 60 days
  • Export customer data within 60 days (account info, workspace data, support history)
  • Provide data in structured format (JSON, CSV)
  • Provide written certification of deletion

Process: See Data Retention and Deletion Policy

2.4 For Educational Institutions (NDPA Compliance)

When serving educational institutions under National Data Privacy Agreements:

Additional Protections:

  • Workspace data containing student information receives highest classification
  • Support access to student data logged and monitored
  • Breach notification within 72 hours
  • Data deletion within 60 days upon request
  • No use of student data for advertising or profiling

Compliance: We act as “school official” under FERPA with legitimate educational interest when handling student data per NDPA agreements.

Note: Most Beekeeper Studio usage involves zero student data on our servers (direct database connections). NDPA protections apply primarily to cloud workspace feature and support interactions.

3. Data Classification

Level Examples Handling Storage
Regulated Student data (NDPA customers), GDPR personal data Highest protection, encryption required, access logged, 72-hour breach notification Cloud workspace (encrypted)
Confidential Customer credentials, workspace configs, support tickets Encryption required, limited access, logged Cloud services (encrypted)
Internal Company docs, internal processes Standard protection, internal-only Internal systems
Public Marketing materials, public docs, open source code Standard protection Public repositories

Rule: When in doubt, treat as Confidential or higher.

Data Location: See Data Flow Diagram for complete data storage and processing locations.

4. Access Control

4.1 Authentication Requirements

All systems require:

  • Strong passwords (12+ characters, unique)
  • Multi-factor authentication (MFA) on all production systems
  • Password manager use (1Password, Bitwarden)

MFA required on:

  • Production database access
  • AWS console
  • GitHub (especially admin access)
  • Heroku
  • Any system with customer data

Target: 100% MFA compliance on privileged access

4.2 Access Principles

  • Least privilege: Minimum access needed for job function
  • Need-to-know: Only access data required for role
  • Time-limited: Admin access only when needed
  • Role-based: Access tied to role, removed when role changes

4.3 Access Reviews

  • Quarterly: Review all privileged access (10-minute check)
  • Annual: Review all user access
  • Immediate: Revoke access upon termination

Process: See Access Review and Management Policy

5. Data Security

5.1 Encryption

At Rest (stored data):

  • Cloud databases encrypted
  • Backups encrypted
  • Disk encryption on all devices (FileVault, BitLocker, LUKS)
  • Workspace data encrypted at rest

In Transit (data moving):

  • TLS 1.2+ for all connections
  • HTTPS only (no HTTP)
  • Desktop app connections use database-native encryption (TLS/SSL)

5.2 Data Handling Guidelines

DO:

  • ✅ Use company-approved cloud storage (Google Drive, GitHub)
  • ✅ Encrypt sensitive data before sharing
  • ✅ Lock screen when away from device
  • ✅ Report lost/stolen devices immediately
  • ✅ Use database-native encryption for customer connections

DON’T:

  • ❌ Store customer data on personal devices
  • ❌ Share credentials or passwords
  • ❌ Use personal email for company business
  • ❌ Access customer workspaces without authorization
  • ❌ Take screenshots of customer data without permission
  • ❌ Connect to customer databases without explicit support authorization

5.3 Endpoint Management

Beekeeper Studio is a small, fully remote team. We do not use centralized Mobile Device Management (MDM) software. Instead, endpoint security is maintained through:

  • Mandatory full-disk encryption on all devices (Section 5.1)
  • Required anti-malware/endpoint protection per Acceptable Use Policy
  • Mandatory MFA on all accounts (Section 4.1)
  • Prompt security patching required by policy
  • Immediate reporting and response for lost/stolen devices

This is a compensating control appropriate for our team size and fully remote structure.

5.4 Workspace Data and Malware Scanning

Cloud workspace data consists of structured text — saved queries, connection configurations, and user preferences. It does not include executable files, binary uploads, or user-generated file attachments. File-based malware scanning is therefore not applicable to workspace data. If file upload capabilities are added in the future, malware scanning will be implemented.

6. Vulnerability Management

6.1 Automated Scanning

Tools in use:

  • Dependabot (automatic dependency scanning)
  • GitHub Security Advisories
  • npm audit (Node.js dependencies)
  • Docker Scout (container scanning)

6.2 Patch Timelines

Severity Timeline Action
Critical 7 days Patch immediately, test, deploy
High 30 days Schedule patch, test, deploy
Medium 90 days Include in regular updates
Low 180 days Include in regular updates

Emergency: If actively exploited, patch within 24-48 hours.

Process: See Vulnerability and Patch Management Policy

7. Logging and Monitoring

7.1 What We Log

Automated logging for:

  • Authentication attempts (success/failure)
  • Administrative actions (user changes, permission grants)
  • Cloud service access (account API, workspace sync)
  • Application errors (via Honeybadger)
  • Infrastructure events (via Papertrail and Heroku metrics)
  • Support access to customer data (full audit trail)

What We Don’t Log:

  • Database query contents (except when voluntarily provided in support tickets)
  • Query results
  • Customer database credentials (stored encrypted, not logged)

7.2 Monitoring Approach

Automated alerts for:

  • Failed login attempts (5+ from same IP)
  • New admin user created
  • MFA disabled
  • Critical application errors
  • Backup failures
  • High-severity vulnerabilities
  • Unusual support access patterns

Rule: Alert-driven monitoring, not manual log review.

7.3 Retention

  • Security logs: 12 months
  • Audit logs: 1 year
  • Operational logs: 90 days

Details: See Logging and Monitoring Policy

8. Incident Response

8.1 What is an Incident?

  • Unauthorized access to cloud services or customer data
  • Data breach or potential breach
  • Ransomware or malware infection
  • Lost or stolen device with company data
  • Compromised credentials
  • Unauthorized support access to customer workspaces

8.2 Immediate Actions

  1. STOP: Don’t delete evidence
  2. CONTAIN: Isolate affected systems
  3. NOTIFY: Contact Security Contact (founder/CTO) immediately
  4. DOCUMENT: Write down everything

8.3 Breach Notification

If customer data potentially exposed:

  • Notify affected customers within 72 hours
  • For NDPA customers: Notify LEAs within 72 hours
  • Use Breach Notification Template
  • Document everything for post-incident review

Process: See Incident Response Plan

9. Third-Party Security (Subprocessors)

9.1 Current Subprocessors

See Subprocessor List and Data Flow Diagram

9.2 Vendor Requirements

All vendors must:

  • Provide adequate security protections
  • Have SOC 2 or ISO 27001 certification (preferred)
  • Sign Data Processing Agreement
  • Comply with GDPR and applicable privacy laws
  • For NDPA customers: Comply with NDPA terms

New vendors: 30-day customer notice before data sharing (NDPA requirement for educational customers)

10. Backups and Disaster Recovery

10.1 What We Backup

Cloud Services Data:

  • Production databases (account data, workspace data)
  • Application configurations
  • Subscription and billing records

Customer Responsibility:

  • Local workspace files (stored on customer device)
  • Customer database backups (their responsibility, we never access)
  • Desktop application configuration (stored locally)

10.2 Our Backup Schedule

  • Production database: Daily automated backups
  • Retention: 90 days rolling
  • Storage: Heroku Postgres managed backups + offsite backups in AWS S3 (encrypted)
  • Testing: Quarterly backup restoration tests
  • RPO: 24 hours max data loss
  • RTO: 4 hours max downtime

11. Training and Awareness

11.1 New Team Members

Before system access:

  • Sign Employee Confidentiality Agreement (Day 1)
  • Review security policies (Within 30 days)
  • Set up MFA on all accounts (Day 1)
  • Understand customer data access restrictions

11.2 Annual Training

All team members:

  • 1-hour team meeting or self-paced review
  • Security updates and lessons learned
  • Policy acknowledgment
  • Customer data handling best practices

12. Compliance

12.1 Privacy Laws

We comply with:

  • GDPR (European Union) - See GDPR Compliance
  • CCPA (California)
  • COPPA (Children’s privacy) - See Privacy Policy
  • FERPA (Educational records, when applicable)
  • NDPA (National Data Privacy Agreement, for educational customers)
  • State-level privacy laws (Utah, Colorado, Virginia, etc.)

12.2 Customer-Specific Compliance

Educational Institutions (NDPA):

  • Act as “school official” under FERPA
  • 72-hour breach notification
  • No sale of student data
  • No targeted advertising using student data
  • Data deletion within 60 days

Enterprise Customers:

  • Data Processing Agreements available
  • SOC 2 readiness (see below)
  • Custom security reviews supported

13. Policy Management

13.1 Review Schedule

  • Annual review: First week of November (during compliance week)
  • Update as needed: When regulations change or architecture changes
  • Version control: All policies in Git with dated versions

13.2 Communication

When policies update:

  • Notify all team members within 7 days
  • Highlight what changed
  • Require acknowledgment of receipt
  • Allow questions before enforcement

SOC 2 Readiness Notes

What we have now (covers most SOC 2 Security criteria):

  • ✅ Documented security policies
  • ✅ Access control with MFA
  • ✅ Encryption at rest and in transit
  • ✅ Vulnerability management
  • ✅ Incident response procedures
  • ✅ Vendor management
  • ✅ Logging and monitoring
  • ✅ Data classification
  • ✅ Risk assessment (annual, part of security audit)
  • ✅ Business continuity plan
  • ✅ Acceptable use policy
  • ✅ Penetration testing (annual internal, automated tooling)

What we’d add for SOC 2 (when pursuing enterprise customers):

  • 🔄 Security awareness training platform
  • 🔄 Third-party penetration testing (upgrade from internal)
  • 🔄 Continuous control monitoring (GRC platform like Vanta or Drata)
  • 🔄 External SOC 2 Type II audit ($25k-$50k annually)

Timeline: Start SOC 2 readiness at 10-15 employees or when pursuing large enterprise/government customers.

Quick Reference

Daily

  • Use strong passwords + MFA
  • Lock screen when away
  • Report suspicious activity immediately
  • Never access customer databases without authorization

Monthly (1st Friday)

  • Review Dependabot alerts (15 min)
  • Check for critical vulnerabilities >7 days
  • Verify backups successful

Quarterly (First Friday after quarter end)

  • Review access (10 min)
  • Test backup restoration (30 min)
  • Review subprocessors (30 min)

Annual (November, first week)

  • Complete security self-audit
  • Review and update all policies
  • Team training session
  • Policy acknowledgment

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, removed school-specific assumptions, added cross-references to legal documents.

Security Policies

Contact

Security Questions: support@beekeeperstudio.io
Security Incidents: [Founder/CTO] - Immediate response required
Policy Questions: [Founder/CTO]
Data Protection Inquiries: support@beekeeperstudio.io