< 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
-
STOP: Don’t delete evidence
-
CONTAIN: Isolate affected systems
-
NOTIFY: Contact Security Contact (founder/CTO) immediately
-
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
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
Customer-Facing Legal Documents
Security Questions: support@beekeeperstudio.io
Security Incidents: [Founder/CTO] - Immediate response required
Policy Questions: [Founder/CTO]
Data Protection Inquiries: support@beekeeperstudio.io