Security & Compliance

Last Updated: October 9, 2025

Security & Compliance

Last Updated: October 9, 2025

Our Commitment to Security

At backend.chat, security is not an afterthought—it's built into every layer of our platform. We use industry-standard practices to protect your data, maintain platform integrity, and ensure reliable service.

This page outlines our security measures, compliance posture, and roadmap.

Security Concerns? Email us at [email protected] (use subject line: "Security Issue")

1. Data Encryption

1.1 Encryption in Transit

All data transmitted to and from backend.chat is encrypted using TLS 1.3 (Transport Layer Security).

  • HTTPS only: Our API and dashboard require HTTPS
  • WebSockets: Secure WebSocket connections (WSS://)
  • API calls: All API endpoints use TLS 1.3
  • Widget: Widget only works on HTTPS websites (enforced)

Cipher suites: We support only modern, secure cipher suites:

  • TLS_AES_128_GCM_SHA256
  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256

TLS version: We do NOT support outdated protocols:

  • ❌ SSL 2.0, SSL 3.0
  • ❌ TLS 1.0, TLS 1.1
  • ✅ TLS 1.2 (minimum)
  • ✅ TLS 1.3 (preferred)

1.2 Encryption at Rest

Sensitive data stored in our databases is encrypted at rest.

  • API Keys: Encrypted using AES-256-GCM before storage
  • Passwords: Hashed using bcrypt with salt (12 rounds)
  • Database: PostgreSQL with transparent data encryption (TDE) for sensitive columns
  • Backups: Encrypted backups using AES-256
  • AI API Keys (OpenAI, Anthropic): Encrypted using AES-256-GCM

What is NOT encrypted at rest:

  • Conversation messages (stored in plain text for search and AI processing)
  • Knowledge base documents (plain text for RAG retrieval)
  • Analytics data (aggregated metrics)

Why? Searchability and AI functionality require plain-text access. We rely on strong access controls and network isolation instead.

1.3 Key Management

  • Encryption keys: Stored separately from data, managed via secrets management system
  • Key rotation: Scheduled every 90 days for API keys
  • Access to keys: Restricted to authorized personnel only
  • Future: Hardware Security Module (HSM) for enterprise customers

2. Access Controls

2.1 Authentication

User Authentication:

  • Passwords: Minimum 8 characters (we recommend 12+)
  • Hashing: bcrypt with 12 rounds of salting
  • Session tokens: JWT (JSON Web Tokens) with 24-hour expiration
  • API keys: UUID-based, organization-scoped
  • Future: Multi-Factor Authentication (MFA) via TOTP or SMS

Agent Authentication:

  • Email + password authentication
  • JWTs for session management
  • Role-based access control (RBAC)

2.2 Authorization (RBAC)

Role-Based Access Control ensures users only see what they're authorized to access.

Roles:

  • Owner: Full access (billing, team management, deletion)
  • Admin: Manage team, configure settings, view all conversations
  • Agent: View and respond to conversations assigned to them
  • Viewer: Read-only access (analytics, conversation history)

Enforcement:

  • Checked on every API request
  • Database-level row-level security (RLS)
  • Cannot be bypassed via direct database access

2.3 Multi-Tenant Isolation

Organization-level data isolation:

  • Each organization has a unique UUID
  • All data is scoped to organization_id
  • SQL queries enforce tenant filtering (WHERE organization_id = ?)
  • No cross-tenant data leakage

Database isolation:

  • PostgreSQL row-level security (RLS) policies
  • Application-level enforcement (double-check)
  • Automated tests for tenant isolation

3. Infrastructure Security

3.1 Hosting and Cloud Security

Current infrastructure:

  • Application Hosting: Hivelocity (Texas, United States)
  • Database: DigitalOcean Managed PostgreSQL (New York, United States - nyc1/nyc3)
  • Cache: Redis on Hivelocity (Texas, United States)
  • Certifications: DigitalOcean maintains SOC 2 Type II, ISO 27001, PCI-DSS compliance

Network security:

  • Firewalls: Web Application Firewall (WAF) to block malicious traffic
  • DDoS protection: Rate limiting and DDoS mitigation services
  • Private networking: Database and cache servers not exposed to public internet
  • VPN access: Internal admin tools require VPN

Self-hosted deployments:

  • Customers control their own infrastructure
  • We provide security guidelines and best practices
  • See "Self-Hosting Security" section below

3.2 Database Security

PostgreSQL security:

  • Access: Database not accessible from public internet
  • Authentication: Password + certificate-based auth
  • Encryption: TLS connections to database, AES-256 encryption at rest
  • Backups: Automated daily backups, encrypted and stored securely
  • Retention: 30-day backup retention

Redis security:

  • Access: Not exposed to public internet, only accessible via private network
  • Authentication: Password-protected
  • Encryption: TLS for connections
  • Persistence: Disabled for cache, enabled for critical session data

3.3 Application Security

Secure coding practices:

  • Input validation: All user inputs sanitized
  • SQL injection prevention: Parameterized queries (prepared statements)
  • XSS prevention: HTML escaping, Content Security Policy (CSP) headers
  • CSRF protection: CSRF tokens on all state-changing requests
  • Rate limiting: API endpoints limited to prevent abuse
  • CORS: Strict CORS policies (only allowed origins)

Dependency management:

  • Regular dependency updates (weekly scan)
  • Automated vulnerability scanning (Dependabot, Snyk)
  • No use of deprecated or unmaintained libraries

3.4 Monitoring and Logging

What we log:

  • Access logs: API requests, login attempts, admin actions
  • Error logs: Application errors, crashes
  • Security events: Failed login attempts, authorization failures, suspicious activity
  • Audit logs: Data access, modifications, deletions

Log retention:

  • Access logs: 90 days
  • Security logs: 1 year
  • Audit logs: 2 years (or longer for enterprise customers)

Monitoring tools:

  • Real-time alerting for security events
  • Intrusion detection system (IDS)
  • Anomaly detection (unusual traffic patterns, brute-force attempts)

4. Security Testing and Audits

4.1 Vulnerability Scanning

Automated scanning:

  • Weekly scans: Dependency vulnerabilities (npm, Go modules)
  • Daily scans: Docker image vulnerabilities
  • Continuous: Code scanning with static analysis tools (SAST)

Manual testing:

  • Quarterly penetration testing (future)
  • Annual third-party security audit (future)

4.2 Penetration Testing

Current status: Internal security reviews

Roadmap:

  • Q2 2025: First external penetration test
  • Annually thereafter: Third-party pen testing
  • Scope: Web application, API, infrastructure

4.3 Bug Bounty Program

Status: Not yet launched

Planned: Q3 2025

  • Responsible disclosure program
  • Rewards for valid security vulnerabilities
  • Details to be announced

In the meantime: Report security issues to [email protected] (Subject: "Security Vulnerability")

5. Incident Response

5.1 Security Incident Process

If a security incident occurs, we will:

  1. Detect and Contain (0-24 hours)

    • Identify the incident (automated alerts, user reports)
    • Contain the threat (isolate affected systems)
    • Preserve evidence (logs, forensics)

  2. Investigate (24-72 hours)

    • Determine the scope and impact
    • Identify root cause
    • Assess data exposure

  3. Notify (Within 72 hours)

    • You: Email notification if your data may be affected
    • Authorities: Report to CERT-In (India), DPAs (EU), state AGs (US) as required
    • Public: Public disclosure if widespread impact

  4. Remediate (1-2 weeks)

    • Fix vulnerabilities
    • Restore services
    • Implement additional safeguards

  5. Post-Incident Review (2-4 weeks)

    • Lessons learned
    • Update security measures
    • Improve processes

5.2 Data Breach Notification

Timelines:

  • To customers: Within 72 hours of confirmed breach
  • To regulators: Within 72 hours (GDPR, DPDP Act) or as required by law
  • To affected individuals: As required by law (varies by jurisdiction)

What we'll tell you:

  • Nature of the breach
  • Data affected (categories, approximate number of records)
  • Potential consequences
  • Measures taken to address the breach
  • Recommendations for affected users (e.g., change passwords)

Contact for breaches: [email protected] or dedicated incident response email (to be announced)

6. Employee and Vendor Security

6.1 Employee Access

Background checks:

  • Employees with access to production systems undergo background checks

Training:

  • Security awareness training for all employees (annually)
  • Secure coding training for developers
  • GDPR and privacy training

Access management:

  • Principle of least privilege (access only to what's needed)
  • Regular access reviews (quarterly)
  • Immediate revocation upon termination

6.2 Vendor Security

Third-party risk management:

  • Subprocessors: Vetted for security and privacy practices
  • Data Processing Agreements (DPAs): Required for all data processors
  • Audits: Review SOC 2 reports for critical vendors
  • See our Subprocessor List for current vendors

7. Compliance Posture

7.1 Current Compliance

We comply with:

✅ India - Information Technology Act, 2000

  • Reasonable security practices (Section 43A)
  • Sensitive personal data protection (SPDI Rules 2011)

✅ GDPR-Ready (European Union)

  • Standard Contractual Clauses (SCCs) for data transfers
  • Data Processing Agreement (DPA) available
  • Data subject rights (access, deletion, portability)
  • 72-hour breach notification

✅ CCPA-Ready (California, USA)

  • Privacy Policy disclosures
  • Right to access and delete
  • No sale of personal information
  • Consumer request processing

✅ Privacy Best Practices

  • Encryption, access controls, logging
  • Regular security reviews
  • Incident response plan

7.2 Future Compliance (Roadmap)

In progress:

  • India DPDP Act 2023 (expected enforcement 2025)
    • Consent management framework
    • Data localization (for sensitive data if required)
    • Parental consent for children's data

Planned certifications:

  • SOC 2 Type II (Security, Availability)

    • Target: Q4 2025
    • Scope: Cloud-hosted platform
    • Auditor: TBD

  • ISO 27001 (Information Security Management)

    • Target: 2026
    • For enterprise customers

  • HIPAA (Healthcare compliance - if needed)

    • Target: 2026 (if we have healthcare customers)

7.3 Regional Compliance

Data localization:

  • Currently hosted in [specify region]
  • Self-hosting option: For customers requiring data to stay in specific countries (EU, India, etc.)
  • Future: Regional cloud deployments (EU, India, US)

Cross-border transfers:

  • GDPR: Standard Contractual Clauses (SCCs)
  • India DPDP Act: Will comply with government guidelines when published

8. Self-Hosting Security

8.1 Security Responsibilities (Self-Hosted)

When you self-host backend.chat, you are responsible for:

Infrastructure:

  • ✅ Server security (patching, firewalls, access controls)
  • ✅ Network security (VPN, VLANs, DDoS protection)
  • ✅ Physical security (for on-premises deployments)

Application:

  • ✅ Keeping backend.chat software up-to-date
  • ✅ Applying security patches promptly
  • ✅ Configuring environment variables securely
  • ✅ Protecting API keys and secrets

Data:

  • ✅ Database backups and encryption
  • ✅ Access controls (RBAC, IAM)
  • ✅ Compliance with local regulations

Monitoring:

  • ✅ Logging and monitoring for security events
  • ✅ Incident response procedures
  • ✅ Regular security audits

We provide:

  • ✅ Security documentation and best practices
  • ✅ Software updates (you must apply them)
  • ✅ Security advisories (for critical vulnerabilities)

We do NOT provide:

  • ❌ Managed infrastructure
  • ❌ 24/7 monitoring
  • ❌ Incident response (you must handle it)

8.2 Self-Hosting Best Practices

Recommendations:

  1. Use HTTPS: Always deploy with TLS certificates (Let's Encrypt, commercial CA)
  2. Firewall rules: Restrict database and Redis access to application servers only
  3. Regular updates: Apply security patches within 7 days of release
  4. Backups: Daily encrypted backups, stored securely
  5. Monitoring: Set up alerts for failed logins, API errors, unusual traffic
  6. Secrets management: Use environment variables or secrets managers (HashiCorp Vault, AWS Secrets Manager)
  7. Access control: Use VPN for admin access, restrict SSH to specific IPs
  8. Docker security: Scan Docker images for vulnerabilities, use non-root users

See our full self-hosting guide: [Link to documentation when available]

9. Privacy and Data Protection

See our Privacy Policy for detailed information on:

  • Data collection and usage
  • Data retention and deletion
  • User rights (access, deletion, portability)
  • International data transfers
  • Third-party data sharing

See our Subprocessor List for:

  • AI providers (OpenAI, Anthropic)
  • Infrastructure providers
  • Payment processors (future)

10. Contact Us

Security Issues

Email: [email protected] Subject: "Security Vulnerability" or "Security Incident"

Please include:

  • Description of the issue
  • Steps to reproduce (for vulnerabilities)
  • Potential impact
  • Your contact information (for follow-up)

Response time:

  • Critical vulnerabilities: 24 hours
  • High severity: 48 hours
  • Medium/Low: 7 days

Responsible Disclosure: We appreciate responsible disclosure:

  • Do not exploit vulnerabilities beyond proof-of-concept
  • Do not disclose publicly until we've had time to fix (we aim for 90 days)
  • Do not access or modify other users' data

Compliance Questions

Email: [email protected] Subject: "Compliance Question"

For questions about:

  • GDPR compliance
  • CCPA compliance
  • SOC 2 status
  • Data Processing Agreements (DPAs)
  • Vendor security assessments

Security Whitepaper / Questionnaire

Enterprise customers often require security documentation.

Available upon request:

  • Security whitepaper (PDF)
  • Completed security questionnaires (SIG, CAIQ, etc.)
  • SOC 2 report (when available)
  • Penetration test reports (redacted, for qualified customers)

Email: [email protected] with subject "Enterprise Security Documentation"

11. Transparency and Reporting

11.1 Security Advisories

Future: We will publish security advisories for:

  • Critical vulnerabilities
  • Major security updates
  • Data breaches (if any)

Where: Security page on our website, email notifications to customers

11.2 Transparency Report (Future)

Planned: Annual transparency report covering:

  • Number of law enforcement requests received
  • Types of data requested
  • Number of accounts affected
  • Government data access requests
  • Takedown requests (DMCA, etc.)

12. Security Roadmap

Q2 2025

  • ✅ Implement Multi-Factor Authentication (MFA)
  • ✅ Launch bug bounty program
  • ✅ First external penetration test

Q3 2025

  • ✅ Enhanced logging and SIEM integration
  • ✅ Automated security testing in CI/CD pipeline

Q4 2025

  • ✅ SOC 2 Type II audit
  • ✅ ISO 27001 certification process begins

2026

  • ✅ Regional data residency (EU, India hosting options)
  • ✅ HIPAA compliance (for healthcare customers)
  • ✅ Enhanced DDoS protection (Cloudflare Enterprise)

13. Additional Resources

Last Updated: October 9, 2025

Questions? Email [email protected]

This Security & Compliance page is provided for informational purposes. We continuously improve our security measures and may update this page without notice. For the most current information, please check this page regularly or contact us.

Trust is earned. We work hard every day to earn yours.