Trust & transparency
Where your data lives, who touches it, and how it leaves.
The questions a security review asks, answered in one place. Last updated 20 September 2026. When something changes, this page changes first.
Where data lives
- Files and transfer server
- AWS Asia Pacific (Mumbai), a dedicated transfer server with its own storage volume per deployment; each workspace has its own storage root.
- Application and database
- AWS Asia Pacific (Mumbai). The database holds accounts, workspaces, share links, receipts, comments and the audit trail — never file contents.
- Backups
- Database and configuration every 6 hours to encrypted, versioned object storage in Mumbai and Singapore; daily volume snapshots kept 7 days with encrypted copies in Singapore. Details below.
- Status page
- A separate small host in Mumbai, so status.boita.io stays up when the product does not.
- Custom domains
- Share pages and portals on your own hostname are served by the same Mumbai application; certificates are issued automatically and stored on our edge.
Sub-processors
Third parties that process data on our behalf. We notify workspace owners by email 30 days before adding one.
| Provider | Purpose | Location |
|---|---|---|
| Amazon Web Services | Hosting, storage, backups, DNS, email health checks | India (Mumbai); Singapore for backup copies |
| Resend | Transactional email (codes, share invitations, receipts, alerts) | United States |
| Razorpay | Payments and invoices (card and bank details never reach us) | India |
| Meta (WhatsApp Business Platform) | Support chat and, once enabled, WhatsApp notifications you opt into | Global |
| Apple and Google | App distribution and push notifications to the mobile app | Global |
| Expo (EAS) | Mobile app builds and over-the-air updates | United States |
| Sentry | Crash reports from the mobile app (no file contents, no share links) | United States |
| GitHub | Source code and continuous integration (no customer data) | United States |
Encryption and keys
- In transit
- Every transfer session is encrypted end to end by the transfer engine (AES-256). Web, API, share pages and the browser/phone transfer path use HTTPS with TLS 1.2 or newer only.
- At rest — object storage
- Backups and configuration copies are stored with server-side encryption (AES-256); the configuration archive is additionally encrypted with a key held only in our secrets store.
- At rest — server volumes
- Encryption by default is now enforced for every new volume and snapshot. The two volumes created before that policy (the transfer server and the application host) are scheduled for migration to encrypted volumes in a maintenance window announced on the status page.
- Sender-side encryption
- Password-protected deliveries can be encrypted on the sender’s machine, so the files are unreadable to us until the recipient enters the passphrase.
- Keys
- Per-workspace credentials and integrations are encrypted with a master key that lives only in the server environment and the Founder’s offline secrets store, never in the code repository. Transfer credentials are short-lived tokens minted per operation.
- Passwords
- Argon2id. Two-factor codes and recovery codes are stored hashed. Sessions are rotating refresh tokens with reuse detection.
Retention and deletion
What is deleted when, and how you can verify it. These are commitments, not defaults.
- Files you delete
- Go to the trash and are removed from the storage server after the plan’s trash retention period: 7 days on Free, 30 days on Pro, Studio and Enterprise. Restore is possible until then. Purges are recorded in the audit trail.
- Share links
- Expire on the date you set (plan maximum applies) or when you revoke them; an expired or revoked link stops new and resumed downloads at once. The receipt — who opened, who downloaded, checksums — is kept for the life of the workspace.
- Portal uploads
- Are ordinary files in your workspace from the moment they land; the same rules apply.
- Versions
- Kept until their expiry, then purged the same way as trash.
- Legal hold
- While a hold is on, nothing in its scope is purged, whatever the retention setting.
- Closed workspace
- Ask support to close a workspace (self-serve closure is on the roadmap): files are purged from the storage server within 30 days, and the storage root and its credentials are removed. Invoices and billing records are kept for 8 years as Indian tax law requires, then deleted.
- Backups
- Database dumps expire after 35 days, configuration copies after 90, volume snapshots after 7 (both regions). A deleted file therefore leaves the last snapshot no later than 7 days after its purge date and never exists in a database dump (dumps hold no file contents).
- Logs
- Application logs about 30 days; web access logs 180 days (CERT-In direction). Neither holds file contents.
- Proof of deletion
- On request, we provide a signed statement listing the workspace, the storage root, the purge date and the snapshot expiry date that completed the deletion. Write to the privacy address below.
How we run the service
- Status and incidents
- Live component health at status.boita.io, with announcements during incidents and maintenance. Every incident gets a written, blameless post-mortem with follow-ups tracked; summaries are published on the status page.
- Backups and recovery
- Database and configuration every 6 hours to two regions; daily volume snapshots with cross-region copies. Recovery is rehearsed every month with an automated restore drill that verifies row counts against production. Recovery point objective: 6 hours for the database, 24 hours for file data. Recovery time objective: 15 minutes for a database restore, 3 hours for a full regional failover.
- Monitoring
- Website, app, API, database, background jobs, transfer service, transfer port, browser transfers, certificate expiry, disk and storage headroom, webhook lag and transfer failure rate are checked continuously; failures page the on-call founder by email and chat within three minutes.
- Access
- Two-factor authentication is mandatory for Boita staff; the transfer server’s management API is unreachable from the internet; support works from metadata and staff have no default access to your files.
- Vulnerability reports
- To security@boita.io. We acknowledge within 2 business days and do not pursue good-faith researchers.
- Compliance
- SOC 2 Type II is in progress (platform onboarding started September 2026). Independent penetration testing and TPN alignment follow on the same programme. DPDP Act and CERT-In obligations are reflected in the retention table above.
Related: Security, Data processing, Privacy policy. Privacy requests: support@boita.io.
Need the questionnaire filled in?
Send us your security questionnaire or DPA; most answers are on this page and we return the rest within five business days.