Security

Security is fundamental to BusyBot. This page describes the technical and organisational measures we take to protect your data and maintain the integrity of the Service. If you discover a security vulnerability, please see our responsible disclosure process below.

1. Infrastructure Security

1.1 Cloud Hosting

BusyBot is hosted on Amazon Web Services (AWS) in the us-east-1 region, with failover capacity in us-west-2. AWS maintains a comprehensive suite of compliance certifications including SOC 1/2/3, ISO 27001, and PCI DSS. Physical access to data centres is strictly controlled by AWS.

1.2 Network Security

• All services run within private Virtual Private Clouds (VPCs) with strict security group rules.
• Public-facing endpoints are protected by AWS Web Application Firewall (WAF) and AWS Shield Standard for DDoS mitigation.
• Internal service-to-service communication is restricted by network ACLs and never exposed to the public internet.
• SSH access to production servers is prohibited; all changes are deployed via automated CI/CD pipelines.

1.3 Availability and Uptime

We target 99.9% uptime for the Service. Our infrastructure uses auto-scaling groups, load balancers, and multi-AZ database deployments to ensure resilience. Planned maintenance windows are communicated via our status page at status.busybot.ai.

2. Data Encryption

2.1 Encryption in Transit

All data transmitted between your browser, the BusyBot dashboard, the embedded widget, and our servers is encrypted using TLS 1.2 or TLS 1.3. We enforce HTTPS for all endpoints and use HTTP Strict Transport Security (HSTS) with a minimum 1-year max-age. Weak cipher suites and SSLv3/TLS 1.0/1.1 are disabled.

2.2 Encryption at Rest

All customer data — including conversation history, uploaded knowledge-base files, and account information — is encrypted at rest using AES-256. Database volumes (Amazon RDS) and object storage (S3) are encrypted using AWS Key Management Service (KMS) with customer-managed key rotation.

2.3 Secrets Management

Application secrets, API keys, and database credentials are stored in AWS Secrets Manager and rotated automatically. Secrets are never committed to source control or included in container images.

3. Access Controls

3.1 Principle of Least Privilege

All BusyBot employees and systems are granted only the minimum permissions necessary to perform their function. IAM roles and policies are reviewed quarterly and audited via AWS Access Analyzer.

3.2 Employee Access to Customer Data

BusyBot employees do not access customer conversation data or account content unless required to resolve a specific support request with your explicit consent, or as required by law. All such access events are logged and reviewed.

3.3 Multi-Factor Authentication

MFA is mandatory for all BusyBot employee accounts and AWS console access. We encourage all customers to enable MFA on their BusyBot accounts, which can be configured under Account → Security Settings in the dashboard.

3.4 Single Sign-On (SSO)

Scale-plan customers can configure SAML 2.0 SSO to manage access through their existing identity provider (e.g., Okta, Azure AD, Google Workspace).

4. Application Security

4.1 Secure Development Lifecycle

Security is integrated into every stage of our development process:

• Code reviews are required for all changes before merging to production.
• Automated static analysis (SAST) and dependency vulnerability scanning run on every pull request.
• Third-party dependencies are monitored continuously via Dependabot and Snyk.
• Container images are scanned for known vulnerabilities before deployment.

4.2 Penetration Testing

We engage independent security firms to conduct annual penetration tests of our web application and infrastructure. Findings are triaged by severity and remediated within defined SLAs: critical issues within 24 hours, high within 7 days, medium within 30 days.

4.3 Common Vulnerability Protections

Our application is designed to mitigate the OWASP Top 10 and includes protections against:

• SQL injection and NoSQL injection via parameterised queries and ORM usage.
• Cross-site scripting (XSS) via output encoding and Content Security Policy (CSP) headers.
• Cross-site request forgery (CSRF) via CSRF tokens on all state-changing operations.
• Broken authentication via rate limiting, account lockout, and MFA enforcement.
• Insecure direct object references via server-side authorisation checks on all resources.

5. Data Backup and Recovery

Customer data is backed up continuously using point-in-time recovery for our relational databases (RDS), with a 35-day retention window. S3 buckets containing uploaded files are replicated to a secondary region. Our Recovery Time Objective (RTO) is 4 hours and Recovery Point Objective (RPO) is 1 hour.

6. Compliance

BusyBot's security programme is designed to support compliance with:

• GDPR (EU General Data Protection Regulation) — as a data processor for your end-user data.
• CCPA (California Consumer Privacy Act) — for residents of California.
• SOC 2 Type II — we are currently undergoing our SOC 2 Type II audit. Enterprise customers may request our SOC 2 Type I report under NDA.

A copy of our Data Processing Agreement (DPA) is available for customers who require one for GDPR compliance. Please contact legal@busybot.ai to request a DPA.

7. Incident Response

We maintain a documented incident response plan that includes detection, containment, eradication, recovery, and post-incident review phases. In the event of a confirmed data breach affecting your account, we will notify you within 72 hours of becoming aware, as required under GDPR Article 33.

8. Responsible Disclosure

We welcome reports from security researchers. If you discover a potential security vulnerability in BusyBot, please report it responsibly:

• Email: security@busybot.ai (PGP key available on request)
• Do not publicly disclose the issue until we have had a reasonable opportunity to investigate and remediate.
• Do not access, modify, or delete data belonging to other users.
• Provide a clear description of the vulnerability and steps to reproduce.

We aim to acknowledge all reports within 2 business days and will keep you informed of our investigation progress. We do not currently operate a paid bug bounty programme, but we are happy to provide public acknowledgement for valid findings upon request.