menu
save_alt Download

Logging and Monitoring Policy

Effective February 9, 2026

< Back

Purpose

This policy defines logging and monitoring for Beekeeper Studio cloud services, enabling security monitoring, incident detection, and operational troubleshooting while protecting customer data privacy.

Our Architecture: Beekeeper Studio is a desktop database client. Customer database queries and results are processed locally. This policy covers logging for our cloud services (account management, billing, license validation, support systems, and optional workspace sync). See Data Flow Diagram.

Key Use Cases:

  • Security monitoring and threat detection
  • Incident detection and response (Incident Response Plan)
  • Compliance auditing
  • Operational troubleshooting

Scope

This policy applies to:

  • Cloud production systems and infrastructure
  • Cloud services processing customer data (accounts, workspaces, support)
  • Authentication and authorization systems
  • Administrative access and privileged operations
  • Application code and APIs
  • Does NOT apply to: Customer database queries (we don’t see these)

1. Logging Principles

1.1 Purpose Limitation

Logs are collected for legitimate business purposes only:

  • Security monitoring - Detect unauthorized access and security threats
  • Incident response - Investigate and respond to security incidents
  • Compliance auditing - Meet NDPA and regulatory requirements
  • Operational troubleshooting - Debug application issues and errors
  • Performance optimization - Identify bottlenecks and inefficiencies

Logs are never used for:

  • Targeted advertising or marketing
  • Profiling users for non-security purposes
  • Selling or sharing with third parties (except as required by law)

1.2 Data Minimization

Collect only necessary information:

  • Log events required for security and operations
  • Avoid logging sensitive data (passwords, credit cards, PII)
  • Redact or mask sensitive data automatically
  • Aggregate and anonymize when possible

Retention minimization:

  • Retain logs only as long as needed for purpose
  • Delete logs after retention period expires
  • Separate security logs from operational logs (different retention)

1.3 Privacy by Design

Automatic redaction:

  • Passwords and authentication tokens
  • Credit card numbers and payment data
  • API keys and secrets
  • Customer data in cloud workspaces

Access controls:

  • Logs accessible only to authorized personnel (MFA required)
  • Role-based access with audit trail
  • Just-in-time access for investigations

2. Authentication and Authorization Logging

2.1 User Authentication Events

Always Log:

  • ✅ Successful login (user ID, timestamp, IP address, user agent)
  • ✅ Failed login attempts (username attempted, IP address, reason for failure)
  • ✅ Password reset requests (user ID, timestamp, IP address)
  • ✅ Password changes (user ID, timestamp, initiated by user or admin)
  • ✅ Account lockouts (user ID, timestamp, reason)
  • ✅ Multi-factor authentication events (enrollment, verification, bypass)
  • ✅ Session creation and termination (session ID, duration, IP address)
  • ✅ API key creation, rotation, and deletion

Retention: 12 months (security investigation purposes)

2.2 Authorization and Access Control

Always Log:

  • ✅ Permission changes (user ID, permission granted/revoked, changed by)
  • ✅ Role assignments (user ID, role assigned, assigned by admin)
  • ✅ Access denied events (user ID, resource attempted, reason)
  • ✅ Privilege escalation (user ID, privilege level, authorized by)

Retention: 12 months

3. Administrative and Production Access Logging

3.1 Administrative Actions

Always Log:

  • ✅ Admin user actions (create, modify, delete users or accounts)
  • ✅ System configuration changes (settings, feature flags, environment variables)
  • ✅ Database schema changes (migrations, indexes, table modifications)
  • ✅ Security setting changes (encryption settings, access controls)
  • ✅ Backup operations (backup created, restored, deleted)
  • ✅ Data export and deletion requests (requester, scope, completion status)
  • ✅ Deployment events (version deployed, deployed by, rollback events)

Retention: 1 year (compliance auditing)

3.2 Production Database Access

Always Log:

  • ✅ Direct database connections (user, timestamp, source IP, database name)
  • ✅ Schema queries (SHOW TABLES, DESCRIBE, etc.)
  • ✅ Data modification queries (INSERT, UPDATE, DELETE) - metadata only
  • ✅ Bulk operations (scope, record count, initiated by)
  • ✅ Failed query attempts (user, query type, error message)

Important - Privacy Protection:

  • ❌ Do NOT log actual query results containing customer data
  • ❌ Do NOT log SELECT query results
  • ✅ Do log query metadata (table accessed, operation type, row count affected)

Retention: 90 days (operational troubleshooting)

3.3 Infrastructure Access

Always Log:

  • ✅ Heroku dashboard access (user, actions performed, apps accessed)
  • ✅ Heroku console access (heroku run sessions, user, timestamp)
  • ✅ GitHub deploy actions (trigger, user, deployment target)
  • ✅ CI/CD pipeline executions (trigger, user, deployment target)
  • ✅ Secret access (secret name accessed, user, timestamp) - never log secret values

Retention: 12 months

4. Critical System Changes Logging

Always Log:

  • ✅ SSL/TLS certificate changes (certificate renewed, expired, revoked)
  • ✅ Encryption key rotation (key ID, rotation timestamp, initiated by)
  • ✅ Heroku config var changes (variable added/removed, changed by)
  • ✅ GitHub repository permission changes (collaborator added/removed)
  • ✅ Two-factor authentication settings (requirement enabled/disabled)

Retention: 1 year (security audit trail)

4.2 Application Configuration Changes

Always Log:

  • ✅ Feature flag changes (flag enabled/disabled, affected users, changed by)
  • ✅ Environment variable changes (variable name, changed by, timestamp)
  • ✅ API rate limit changes (endpoint, old/new limits, changed by)
  • ✅ Webhook configurations (URL added/removed, events subscribed)
  • ✅ Third-party integration changes (integration enabled/disabled, config)

Retention: 12 months

4.3 Data Operations

Always Log:

  • ✅ Bulk data exports (requester, data scope, record count, format)
  • ✅ Data deletion operations (requester, scope, record count, NDPA reference if applicable)
  • ✅ Data retention policy changes (policy modified, changed by, effective date)
  • ✅ Backup restoration (backup source, restore target, initiated by, timestamp)

Retention: 1 year (compliance)

5. Application and API Logging

5.1 API Request Logging

Always Log:

  • ✅ API endpoint accessed (method, path, query parameters)
  • ✅ Request metadata (user ID, IP address, user agent, timestamp)
  • ✅ Response status code and response time
  • ✅ Authentication method (API key, session, OAuth token)
  • ✅ Rate limiting events (requests throttled, user ID, endpoint)

Privacy Protection:

  • ❌ Do NOT log request/response bodies containing customer data
  • ❌ Do NOT log authorization headers or tokens
  • ✅ Do log token IDs (not the actual token)

Retention: 90 days

5.2 Application Error Logging

Always Log:

  • ✅ Unhandled exceptions (error type, stack trace, user ID if available)
  • ✅ Database connection errors (connection pool exhaustion, timeouts)
  • ✅ External service failures (subprocessor unavailable, API errors)
  • ✅ Validation errors (input rejected, user ID, field name)

Automatic Redaction:

  • Passwords in error messages
  • API keys and tokens in stack traces
  • Customer data in error context

Retention: 90 days (operational troubleshooting)

5.3 Performance Monitoring

Always Log:

  • ✅ Slow queries (query duration >1 second, user ID, query type)
  • ✅ High memory usage events (threshold exceeded, process, timestamp)
  • ✅ API response time percentiles (p50, p95, p99 per endpoint)
  • ✅ Database connection pool metrics (active, idle, waiting)

Retention: 30 days (performance optimization)

6. Security Event Logging

6.1 Potential Security Threats

Always Log:

  • ✅ Multiple failed login attempts (potential brute force)
  • ✅ Unusual access patterns (geographic anomalies, time-of-day anomalies)
  • ✅ Suspicious user agent strings (bots, scanners)
  • ✅ SQL injection attempts (malformed queries detected)
  • ✅ XSS attempts (script tags in input)
  • ✅ Rate limit violations (excessive requests, potential DoS)
  • ✅ Invalid token usage (expired, revoked, or malformed tokens)

Retention: 12 months

Alerting: Immediate notification to security team for high-severity events

6.2 Data Breach Indicators

Always Log:

  • ✅ Unauthorized data access (user accessing data outside their permissions)
  • ✅ Mass data exports (large export requests, unusual patterns)
  • ✅ Privilege escalation attempts (user trying to elevate permissions)
  • ✅ Account takeover indicators (login from new location after password reset)
  • ✅ Abnormal query patterns (queries accessing many records, unusual tables)

Retention: 12 months

Alerting: Immediate escalation to incident commander per Incident Response Plan

7. Log Retention Periods

7.1 Retention Schedule

Log Category Retention Period Purpose
Authentication logs 12 months Security investigation
Authorization logs 12 months Access control auditing
Administrative actions 1 year Compliance auditing
Cloud database access 90 days Operational troubleshooting
Infrastructure access 12 months Security auditing
Security changes 1 year Security audit trail
Application config 12 months Change tracking
Data deletion operations 1 year Compliance evidence
API requests 90 days Troubleshooting
Application errors 90 days Bug fixing
Performance metrics 30 days Optimization
Security threats 12 months Threat analysis

For Educational Institutions: Logs support NDPA Section 5.3 (cybersecurity framework) and Section 5.4 (breach investigation)

7.2 Extended Retention

Logs may be retained beyond standard periods for:

  • Legal hold - Litigation, investigation, or regulatory inquiry
  • Active incident - Investigation ongoing, evidence preservation
  • Compliance audit - LEA or regulatory audit in progress

Legal counsel must approve extended retention and document justification.

7.3 Log Deletion

Automated deletion:

  • Logs older than retention period automatically deleted
  • Daily cron job checks and purges expired logs
  • Deletion verified monthly by operations team

Manual deletion prohibited except:

  • Under legal hold release (approved by legal counsel)
  • Customer data deletion request (per Data Retention Policy)
  • Erroneous logging of sensitive data (security incident response)

8. Log Review Procedures

8.1 Automated Monitoring

Real-Time Alerts:

  • Failed login spike (>10 failures in 5 minutes from same IP)
  • Privilege escalation attempts
  • Mass data export (>1000 records)
  • Database connection from new IP address
  • Heroku owner account changes or new admin access
  • Critical system errors (>5 errors per minute)

Alert Destinations:

  • Slack #security-alerts channel
  • Email to security contact
  • PagerDuty for critical incidents (24/7)

Response SLA:

  • Critical alerts: Review within 15 minutes
  • High alerts: Review within 1 hour
  • Medium alerts: Review within 4 hours
  • Low alerts: Daily review

8.2 Scheduled Reviews

Daily (automated alerts only):

  • Respond to automated security alerts as they occur
  • No manual log reviews required

Monthly (1st Friday, 1 hour during Monthly Compliance Hour):

  • Review failed login summary (past 30 days)
  • Check administrative actions log
  • Review application error trends
  • Verify backup completion logs
  • Check log retention compliance

Quarterly (during Compliance Day):

  • Access audit (production systems, Heroku, GitHub)
  • Review and update monitoring alert rules
  • Assess log storage capacity
  • Security metrics summary for executive team

See Also: Compliance Actions Calendar

8.3 Manual Investigation

Triggered by:

  • Security incident (per Incident Response Plan)
  • Customer complaint or support ticket
  • LEA audit request (NDPA compliance)
  • Regulatory inquiry

Investigation Process:

  1. Define scope (time range, users, systems)
  2. Query relevant logs from centralized storage
  3. Document findings and timeline
  4. Preserve logs if evidence needed
  5. Report to incident commander or legal counsel

Tools:

  • Papertrail for application and infrastructure logs
  • Heroku log aggregation for application logs
  • Honeybadger for error logs
  • Custom SQL queries for database audit logs

9. Log Storage and Security

9.1 Centralized Log Storage

Infrastructure:

  • Papertrail (application and infrastructure logs via Heroku log drain)
  • Heroku Postgres logs (database audit logs)
  • Honeybadger (application errors)

Access Control:

  • Role-based access (engineers, security, executives)
  • Multi-factor authentication required
  • Read-only access by default
  • Write access limited to logging services
  • Audit trail of all log access

9.2 Log Security

Encryption:

  • ✅ Logs encrypted at rest (Papertrail managed encryption)
  • ✅ Logs encrypted in transit (TLS 1.2+)

Integrity:

  • Immutable log storage (append-only)
  • Tampering detection (checksum verification)
  • Version control for log configuration

Availability:

  • Replicated across multiple availability zones
  • Daily backup of critical logs
  • Disaster recovery: 24-hour RPO, 4-hour RTO

9.3 Log Aggregation

Log Pipeline:

  1. Application/system generates log
  2. Log forwarded to Papertrail (via Heroku log drain) or Honeybadger
  3. Automatic redaction applied (passwords, tokens)
  4. Log indexed for searching
  5. Alerting rules evaluated (Papertrail alerts)
  6. Papertrail handles retention per configured policy

Log Format Standardization:

  • JSON format for structured logs
  • ISO 8601 timestamps (UTC)
  • Standard field names (event_type, user_id, timestamp, etc.)
  • Correlation IDs for request tracing

10. Sensitive Data Redaction

10.1 Automatic Redaction Rules

Always Redact:

  • ❌ Passwords (even hashed passwords in logs)
  • ❌ API keys, tokens, secrets
  • ❌ Credit card numbers (PCI DSS requirement)
  • ❌ Social Security Numbers
  • ❌ Database connection strings (contain passwords)
  • ❌ OAuth tokens and refresh tokens
  • ❌ Encryption keys

Redaction Method:

// Before redaction
{"password": "SuperSecret123!"}

// After redaction
{"password": "[REDACTED]"}

10.2 PII Protection

Minimize logging of:

  • Names of individuals (log user IDs instead)
  • Email addresses (hash or truncate: user@…)
  • IP addresses (log only for security events)
  • Query results containing student data

When PII must be logged:

  • Log user ID reference, not actual PII
  • Redact after retention period expires
  • Flag for deletion in data deletion requests
  • Document legal justification

10.3 Query Result Protection

Database queries:

  • ❌ Never log SELECT query results
  • ✅ Log query metadata (table, operation, row count)
  • ❌ Never log student data from queries
  • ✅ Log query performance metrics

Example:

// Good - Metadata only
{
  "query_type": "SELECT",
  "table": "students",
  "rows_returned": 150,
  "duration_ms": 45
}

// Bad - Contains actual data
{
  "query": "SELECT * FROM students",
  "results": [{"name": "John Doe", "ssn": "123-45-6789"}]
}

11. Compliance and Auditing

11.1 Compliance

General Compliance:

  • Supports security incident investigation
  • Provides audit trail for customer reviews
  • Documents data deletion operations
  • Enables breach notification response

For Educational Institutions: NDPA Compliance

This logging policy supports NDPA requirements:

Data Security: Logging as part of cybersecurity framework, monitoring of administrative access

Data Breach: Audit trail for breach investigation, supports 72-hour notification requirement

Audit Rights: Logs available for LEA audits, 7-year retention for compliance evidence

11.2 Log Availability for Customer Audits

Customer/LEA Audits:

  • Logs available upon request with 14-day notice
  • Format: JSON export or CSV summary
  • Redacted to protect other customers’ data

Request Process:

  1. Customer sends audit request to support@beekeeperstudio.io
  2. Define scope (date range, log types)
  3. Extract and redact logs
  4. Legal review (if needed)
  5. Deliver via secure method (encrypted email, SFTP)

11.3 Log Evidence Preservation

For incident response:

  • Relevant logs immediately copied to incident folder
  • Chain of custody documented
  • Write-protected to prevent tampering
  • Retained per Incident Response Plan

For legal proceedings:

  • Legal hold applied to relevant logs
  • Extended retention until legal counsel releases
  • Additional copies stored offline
  • Certified by security contact

12. Roles and Responsibilities

Security Contact / CTO (typically founder):

  • Owns logging and monitoring policy
  • Reviews security alerts
  • Responds to incidents
  • Provides logs for customer audits

Technical Team:

  • Implements and maintains logging infrastructure
  • Monitors log storage capacity
  • Troubleshoots logging issues
  • Follows secure logging practices (no sensitive data)

Note: For 1-3 person teams, one person may fulfill multiple roles

13. Log Monitoring Tools

13.1 Current Tools

Papertrail (Solarwinds):

  • Purpose: Centralized log aggregation and search
  • Scope: All Heroku application and infrastructure logs
  • Retention: Per Papertrail plan (configurable)
  • Access: DevOps and security teams

Heroku Metrics:

  • Purpose: Application performance monitoring
  • Scope: Web dynos, worker processes, database metrics
  • Retention: Per Heroku plan
  • Access: Developers and operations

Honeybadger:

  • Purpose: Application error tracking
  • Scope: Unhandled exceptions, errors
  • Retention: 90 days
  • Access: Developers

13.2 Monitoring Dashboards

Security Dashboard:

  • Failed login attempts (last 24 hours)
  • Suspicious IP addresses
  • Privilege escalation attempts
  • Data breach indicators

Operational Dashboard:

  • Application error rate
  • API response times
  • Database performance
  • System resource usage

Compliance Dashboard:

  • Administrative actions summary
  • Data deletion operations
  • LEA data access logs
  • Audit log completeness

14. Incident Response Integration

This logging policy supports the Incident Response Plan:

Phase 1: Detection

  • Security alerts trigger incident creation
  • Logs provide initial incident context
  • Automated correlation of related events

Phase 2: Containment

  • Logs identify affected systems and users
  • Timeline reconstruction from log analysis
  • Scope determination through log queries

Phase 3: Eradication

  • Logs verify threat removal
  • Access logs checked for persistence mechanisms
  • Security event logs monitored for reinfection

Phase 4: Recovery

  • Logs verify successful system restoration
  • Enhanced monitoring of recovered systems
  • Baseline established from clean state

Phase 5: Post-Incident Review

  • Complete log timeline provided for review
  • Lessons learned applied to monitoring rules
  • Gaps identified in logging coverage

15. Policy Exceptions

15.1 Requesting Exceptions

Exceptions to this policy require:

  1. Written justification (business or technical reason)
  2. Risk assessment (impact of reduced logging)
  3. Compensating controls (alternative monitoring)
  4. Security Contact approval
  5. CEO approval for material exceptions
  6. Annual review of exception

15.2 Temporary Exceptions

For debugging or troubleshooting:

  • Increased logging verbosity (more detail)
  • Logging of specific data elements
  • Maximum 7-day duration
  • Automatic reversion to normal logging
  • Additional logs deleted after troubleshooting

15.3 Permanent Exceptions

Rare cases where policy cannot be followed:

  • Document in exception registry
  • Review quarterly
  • Assess for security impact
  • Implement compensating controls

16. Policy Review and Updates

Review Schedule

Quarterly (during Compliance Day):

  • Review log retention compliance
  • Check monitoring alert effectiveness
  • Update redaction rules if needed

Annually (November, during Compliance Week):

  • Full policy review and update
  • Assess new logging technologies
  • Update based on incidents and lessons learned

Trigger-Based:

  • After security incident
  • After customer audit
  • When new systems added

Change Management

  1. Draft policy changes (Security Contact)
  2. Technical review (contractors, if applicable)
  3. Executive approval (CEO/CTO)
  4. Update logging implementation
  5. Verify compliance

Security Policies

Contact

Logging Technical Issues: support@beekeeperstudio.io

Security Monitoring Questions: support@beekeeperstudio.io

Customer Audit Log Requests: support@beekeeperstudio.io (Subject: “Audit - Log Request - [Organization]”)

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, added cross-references to legal documents, streamlined review schedule.

Appendix A: Log Event Types Quick Reference

Event Category Event Types Retention Alert?
Authentication login_success, login_failure, password_reset 12 months >10 failures
Authorization access_denied, permission_change, role_assigned 12 months privilege_escalation
Admin Actions user_modified, config_change, deployment 1 year none
Database query_executed, schema_change, connection 90 days new_ip
Infrastructure heroku_access, github_deploy, console_session 12 months admin_change
Security brute_force, sql_injection, xss_attempt 12 months all
Data Operations data_export, data_deletion, backup_restore 1 year mass_export
API api_request, rate_limit_exceeded 90 days excessive_requests
Errors application_error, database_error, timeout 90 days error_spike

Appendix B: Sensitive Data Redaction Regex Patterns

Common patterns automatically redacted from logs:

Password patterns:
- password\s*=\s*['"]?[^'"&\s]+
- pwd\s*=\s*['"]?[^'"&\s]+
- pass\s*=\s*['"]?[^'"&\s]+

API Key patterns:
- api_key\s*=\s*['"]?[A-Za-z0-9_-]{20,}
- token\s*=\s*['"]?[A-Za-z0-9_-]{20,}
- Bearer\s+[A-Za-z0-9_-]+

Credit Card patterns:
- \b\d{4}[\s-]?\d{4}[\s-]?\d{4}[\s-]?\d{4}\b

Social Security Numbers:
- \b\d{3}-\d{2}-\d{4}\b

Database Connection Strings:
- postgres://.*:.*@.*
- mysql://.*:.*@.*

Replacement: [REDACTED] or ***

Appendix C: Log Query Examples

Find all failed login attempts for a user

SELECT * FROM auth_logs
WHERE event_type = 'login_failure'
  AND user_id = 'user_12345'
  AND timestamp > NOW() - INTERVAL '7 days'
ORDER BY timestamp DESC;

Find all administrative actions in last 30 days

SELECT * FROM admin_logs
WHERE timestamp > NOW() - INTERVAL '30 days'
ORDER BY timestamp DESC;

Find suspicious access patterns (logins from multiple countries)

SELECT user_id, COUNT(DISTINCT location_country) as country_count
FROM auth_logs
WHERE event_type = 'login_success'
  AND timestamp > NOW() - INTERVAL '24 hours'
GROUP BY user_id
HAVING country_count > 2;

Find all data deletion operations for LEA audits

SELECT * FROM data_operations_logs
WHERE event_type = 'data_deletion_request'
  AND requester_type = 'LEA'
  AND ndpa_reference LIKE '%TCSD%'
ORDER BY timestamp DESC;

Appendix D: Monitoring Alert Configuration

Critical Alerts (Immediate Response)

Brute Force Login:

  • Condition: >10 failed logins from same IP in 5 minutes
  • Action: Lock account, alert security team, block IP temporarily

Privilege Escalation:

  • Condition: User attempts admin action without permission
  • Action: Alert security team, review user account

Mass Data Export:

  • Condition: Export request >1000 records
  • Action: Alert security team, requires manual approval

Heroku Admin Change:

  • Condition: New owner/admin added to Heroku app, or GitHub admin access granted
  • Action: Immediate alert to CEO and security team

High Alerts (1-Hour Response)

Failed Database Connection:

  • Condition: Heroku Postgres connection errors or unusual access patterns
  • Action: Investigate via Heroku dashboard and logs

Rate Limit Exceeded:

  • Condition: API rate limit hit repeatedly
  • Action: Review for abuse or legitimate need

Application Error Spike:

  • Condition: >5 errors per minute for 5 minutes
  • Action: Investigate and resolve

Medium Alerts (4-Hour Response)

Slow Query:

  • Condition: Query duration >5 seconds
  • Action: Review for optimization

High Disk Usage:

  • Condition: Log storage >80% capacity
  • Action: Purge old logs or increase capacity