menu
save_alt Descargar

Access Review and Management Policy

Effective February 9, 2026

< Back

Purpose

This policy establishes procedures for granting, reviewing, and revoking access to Beekeeper Studio cloud services.

Our Architecture: Beekeeper Studio is a desktop database client. This policy covers access to our cloud services (AWS, GitHub, Heroku, support systems). See Data Flow Diagram.

Key Principles:

  • Least privilege (minimum access needed)
  • MFA on all production systems (100% compliance)
  • Quarterly access reviews
  • Immediate revocation upon termination

Scope

Applies to:

  • All team members (employees and contractors)
  • Cloud production systems (Heroku, App/Admin, GitHub)
  • Administrative accounts and privileged access
  • API keys and service accounts
  • Does NOT apply to: Customer database access (we don’t access these)

1. Access Management Principles

1.1 Least Privilege

Definition: Users granted minimum access necessary to perform job duties.

Implementation:

  • Default to no access, grant only when justified
  • Role-based access control (RBAC) over individual permissions whenever possible
  • Time-limited access for temporary needs
  • Separate accounts for administrative vs. regular tasks

Examples:

  • Developers have read access to production, write access to staging
  • Customer support has read-only access to customer data
  • Database administrators have full access to databases
  • Marketing team has no access to production systems

1.2 Separation of Duties

Definition: No single person has complete control over critical processes.

Implementation:

  • Code review required before production deployment
  • Separate approvers for financial transactions
  • Multi-person approval for security-sensitive changes
  • Audit trail for all privileged actions

Examples:

  • Developer cannot deploy their own code to production
  • Person requesting payment cannot approve payment
  • Security configuration changes require peer review

1.3 Need-to-Know Basis

Definition: Access granted only to data and systems required for job function.

Implementation:

  • Compartmentalize access by role and team
  • Limit access to customer data to those who need it
  • Restrict student data access to authorized personnel
  • Document justification for access requests

1.4 Defense in Depth

Definition: Multiple layers of access controls.

Implementation:

  • Platform-level controls (Heroku managed networking, VPN)
  • Application-level controls (authentication, authorization)
  • Data-level controls (encryption, field-level permissions)
  • Monitoring and alerting on access patterns

2. Access Types and Classification

2.1 User Access Levels

Access Level Description Examples MFA Required Review Frequency
Administrative Full system control Root, sudo, AWS admin Yes (required) Quarterly
Privileged Elevated permissions Database admin, deploy access Yes (required) Quarterly
Standard Regular job functions Developer, support agent Recommended Annual
Read-Only View-only access Auditor, contractor No Annual
Service Account Automated access CI/CD, monitoring tools N/A (API keys) Quarterly

2.2 System Classifications

System Type Data Sensitivity Access Restrictions Examples
Production High (customer/student data) MFA required, logged Production databases, APIs
Staging Medium (test data) MFA recommended, logged Staging environment
Development Low (synthetic data) Standard auth, not logged Local dev environments
Internal Tools Low-Medium Standard auth Slack, GitHub, Google Workspace

2.3 Data Access Classifications

Customer/Student Data:

  • Highest protection level
  • Access logged and monitored
  • Access limited to authorized personnel only
  • NDPA compliance required for student data
  • Note: We don’t handle customer databases (eg: student data) as part of Beekeeper Studio services

Internal Business Data:

  • Standard protection level
  • Access based on role
  • Logged for audit purposes

Public Data:

  • Minimal protection
  • Generally accessible to employees
  • Website content, public documentation

3. Access Request and Approval Process

3.1 Standard Access Request

Process (via Slack #access-requests channel):

  1. Team member posts request in #access-requests with: system, access level, and reason
  2. CTO approves with a reply or ✅ reaction
  3. Access provisioned and confirmed in the thread
  4. Slack thread serves as the audit trail

Example Slack message:

Requesting access:
- System: Heroku production (collaborator)
- Level: Read-only
- Reason: Investigating customer support ticket #1234
- Duration: Permanent / Temporary until [date]

3.2 Privileged Access Request

Additional requirements (same Slack channel, but needs explicit CTO reply — not just a reaction):

  • MFA enrollment confirmed before access granted
  • Time-limited access preferred (quarterly renewal)

Examples of Privileged Access:

  • Production database write access
  • Heroku owner/admin access
  • heroku run console access to production
  • GitHub admin access to repositories
  • Deployment permissions
  • Customer data export capabilities

3.3 Emergency Access

Definition: Immediate access needed for incident response or critical outage.

Process:

  1. Requestor contacts CTO via phone or Slack DM
  2. CTO grants verbal/written approval
  3. Temporary access provisioned immediately
  4. Request documented in #access-requests within 24 hours
  5. Access revoked after emergency resolved (max 7 days)

4. Multi-Factor Authentication (MFA) - Required

4.1 MFA Required On All Production Systems

100% MFA Compliance Target:

  • AWS console
  • GitHub
  • Heroku
  • Production databases (if manual access exists)
  • Google Workspace (email)
  • Stripe (payments)
  • Beekeeper Studio Cloud admin panel

4.2 MFA Methods

Use Authenticator Apps (Google Authenticator, Authy, 1Password)

Avoid: SMS (can be intercepted)

4.3 MFA Compliance

Checked: During quarterly access review (10 minutes)

Enforcement: Non-compliant accounts disabled after 7-day warning

5. Access Reviews

5.1 Quarterly Access Review (10-15 Minutes)

When: First Friday after quarter end (during quarterly compliance day)

What to Review:

  • AWS IAM users and roles
  • GitHub organization members
  • Heroku collaborators
  • Production database access (if manual accounts exist)
  • Service accounts and API keys
  • Production admin panel access

Simple Checklist:

  1. List all AWS IAM users → Still need access? MFA enabled?
  2. List all GitHub org members → Still on team?
  3. List all Heroku collaborators → Still need access?
  4. Check for inactive accounts (no login 90+ days) → Disable
  5. Verify MFA enabled on all production access → 100% target
  6. List all super admins in the admin panel -> Still need access?

Time Estimate: 10-15 minutes for 1-5 person team

Documentation: Simple spreadsheet or GitHub issue noting review date and any changes made

5.2 Automated Monitoring

Real-Time Alerts (for heroku and admin panel):

  • Failed login attempts (>5 in 15 minutes)
  • New admin user created
  • MFA disabled
  • Login from new country

Monthly Check (during monthly compliance hour):

  • Any new accounts created?
  • Any permissions changed?

See Also: Compliance Actions Calendar for schedule

6. Access Revocation

6.1 Team Member Termination

Timeline: Access revoked immediately upon termination

Simple Checklist (15-30 minutes):

  • Disable Google Workspace (email, drive)
  • Remove from GitHub organization
  • Remove from AWS IAM
  • Remove from Heroku
  • Remove from Slack
  • Revoke any API keys they had access to
  • Collect hardware security keys (if applicable)
  • Document in simple log (who, when, what revoked)
  • Disable production admin panel access

For Contractors:

  • Revoke on contract end date
  • Same checklist as above
  • Update Subprocessor Inventory if they were a vendor with data access

6.2 Role Changes

Timeline: Update within 5 business days

Process: Remove old access, grant new access, document change

7. Service Accounts and API Keys

7.1 Service Account Management

Definition: Non-human accounts used by applications, scripts, or automation.

Creation Process:

  1. Submit service account request with purpose
  2. Security Contact reviews and approves
  3. IT/DevOps creates account with minimal permissions
  4. Document account in service account register
  5. Owner assigned for each service account

Requirements:

  • Descriptive naming convention (e.g., svc-backup-s3, ci-deploy-production)
  • Purpose and owner documented
  • No interactive login (API keys/tokens only)
  • Regular password/key rotation (every 90 days)
  • Monitoring for unusual activity

7.2 API Key Management

Best Practices:

  • Never commit API keys to code repositories
  • Store keys in secret management system (AWS Secrets Manager, HashiCorp Vault)
  • Rotate keys every 90 days when appropriate
  • Separate keys for each environment (dev, staging, production)
  • Revoke immediately if exposed

Key Rotation Process:

  1. Generate new API key
  2. Update application configuration
  3. Deploy new configuration
  4. Verify new key working
  5. Revoke old key
  6. Log rotation in access register

Exposed Key Response:

  1. Revoke compromised key immediately (within 15 minutes)
  2. Generate new key
  3. Update all systems using key
  4. Review logs for unauthorized usage
  5. Assess if incident response needed
  6. Incident report filed

7.3 Service Account Reviews

Quarterly Review:

  • List all service accounts
  • Verify owner and purpose still accurate
  • Check for inactive accounts (no API calls in 90 days)
  • Confirm key rotation compliance
  • Review permissions (can they be reduced?)

Remediation:

  • Delete unused service accounts
  • Reduce over-privileged accounts
  • Force key rotation if overdue
  • Update documentation

8. Access Register and Documentation

8.1 Access Register

Purpose: Centralized record of all access grants, changes, and revocations.

Contents:

  • User/account name
  • System/resource accessed
  • Access level granted
  • Date granted
  • Granted by (approver)
  • Business justification
  • Review date (for periodic reviews)
  • Revocation date (if applicable)

Format: Slack #access-requests channel serves as the primary audit trail. For quarterly reviews, the current state of access is documented in the compliance spreadsheet.

8.2 Documentation Requirements

For Each Access Type:

  • Clear description of what access includes
  • Prerequisites (training, MFA enrollment, etc.)
  • Approval requirements
  • Review frequency
  • Revocation criteria

For Each System:

  • System owner/administrator
  • Data classification (production, staging, etc.)
  • Access levels available (read-only, read-write, admin)
  • MFA requirement (yes/no)
  • Logging and monitoring (enabled/disabled)

9. Role-Based Access Control (RBAC)

9.1 Standard Roles

  1. Engineer:
    • Production read access (if required)
    • Staging write
    • Source control
    • Heroku & AWS consoles as needed
    • L2 customer support portal
  2. Sales & Marketing:
    • Customer support
    • CRM
    • Marketing systems
    • Website source code
  3. Executives
    • Full admin access as needed in emergency

9.2 Role Assignment Process

New Hire:

  1. HR creates account in SSO/directory
  2. Manager assigns role based on job title
  3. Standard role access auto-provisioned
  4. Additional access requests follow standard Slack process

Role Updates:

  • Triggered by job title change, promotion, or transfer
  • Manager initiates role change request
  • IT/DevOps updates role assignment
  • Access automatically adjusted based on new role
  • Old access reviewed and removed if not needed

10. Monitoring and Compliance

10.1 Access Monitoring

Real-Time Alerts:

  • Failed authentication attempts (>5 in 15 minutes)
  • Successful login from new location/device
  • Privilege escalation (user gains admin rights)
  • Access outside normal business hours
  • Mass data export or deletion

Monthly Reports:

  • Access review status
  • Overdue access renewals
  • Dormant accounts (no login in 60+ days)
  • Non-compliant MFA accounts

10.2 Compliance Metrics

Key Performance Indicators:

  • % of privileged accounts with MFA enabled (Target: 100%)
  • % of quarterly reviews completed on time (Target: 100%)
  • Average time to revoke access after termination (Target: <1 hour)
  • Number of dormant accounts (Target: <5)
  • % of access requests approved within SLA (Target: >90%)

Audit Evidence:

  • Access review sign-offs (quarterly and annual)
  • Access grant approvals
  • Termination checklists
  • MFA enrollment records
  • Access register snapshots

10.3 Audit Support

For LEA/NDPA Audits:

  • Provide access review documentation
  • Demonstrate MFA enforcement
  • Show access register for student data systems
  • Evidence of timely access revocation
  • Proof of periodic reviews

Audit Timeline:

  • Request received: Acknowledge within 48 hours
  • Gather documentation: 7 days
  • Legal review: 3 days
  • Deliver to auditor: 14 days total

11. Training and Awareness

11.1 New Employee Training

Onboarding Security Training:

  • Password policy and best practices
  • MFA enrollment and usage
  • Accessing company systems securely
  • Recognizing phishing and social engineering
  • Reporting security incidents
  • Data classification and handling

Access-Specific Training:

  • Request process for additional access
  • Proper use of privileged access
  • Logging and monitoring awareness
  • Consequences of access policy violations

11.2 Privileged User Training

Additional Topics:

  • Principle of least privilege
  • Separation of duties
  • Secure coding practices
  • Incident response procedures
  • Data privacy and NDPA obligations

Frequency: Annual refresher required

11.3 Managers Training

Responsibilities:

  • Reviewing and approving access requests
  • Conducting periodic access reviews
  • Identifying when access should be revoked
  • Recognizing access policy violations

Frequency: Annual training, updated for policy changes

12. Policy Violations and Enforcement

12.1 Violations

Examples of Policy Violations:

  • Sharing account credentials
  • Using personal account for business access
  • Accessing systems without authorization
  • Failing to enable MFA when required
  • Retaining access after role change (privilege creep)
  • Using privileged access for non-business purposes

12.2 Consequences

First Violation (Minor):

  • Written warning
  • Mandatory security training
  • Enhanced monitoring of account

Second Violation or Serious Violation:

  • Access suspended pending investigation
  • HR disciplinary action
  • Potential termination

Criminal Activity:

  • Immediate termination
  • Law enforcement notification
  • Legal action

12.3 Incident Response

Access policy violations may trigger Incident Response Plan:

  • Unauthorized access to customer/student data → Critical Incident
  • Credential sharing leading to compromise → High Incident
  • MFA non-compliance → Medium incident

Security Policies

Policy Review

Quarterly (during Compliance Day): Review access (10-15 minutes)

Annually (November): Full policy review and update

Trigger-Based: After security incident or team changes

Contact

Access Questions: support@beekeeperstudio.io

Access Issues: 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: Focused on essential controls (MFA, quarterly reviews, termination), removed complex role matrices, streamlined to 10-15 minute quarterly reviews, added cross-references to legal documents.

Appendix: Quarterly Access Review Template

Q[X] 202[Y] Access Review

Date: [Date]
Reviewer: [Name]
Time Spent: ~10-15 minutes

Checklist:

  • AWS IAM users listed → All still needed? MFA enabled?
  • GitHub org members listed → All still on team?
  • Heroku collaborators listed → All still needed?
  • Any inactive accounts (90+ days)? → Disabled
  • Any non-MFA accounts? → Enabled or disabled

Changes Made:

  • [List any access revoked, MFA enabled, accounts disabled]

Notes:

  • [Any findings or concerns]

Completed: [Initials, Date]