What your security team will want to know
A support desk holds your customers' words, their attachments and the credentials to your mailboxes. Here is how SupaDesk protects each of them - written to answer a questionnaire, not to reassure in the abstract.
How does SupaDesk secure customer data?
Each SupaDesk workspace has its own database schema, and every request is resolved to exactly one workspace before any data is read. Mailbox tokens and authenticator secrets are encrypted at rest, data travels over TLS, permissions are enforced on the server for every request, irreversible actions need a fresh authenticator code, inbound attachments are virus-scanned, and customer HTML is sanitised and rendered in a sandbox. Customer content is never used to train AI models.
- One database schema per workspace - never shared tables.
- Mailbox tokens and MFA secrets encrypted at rest.
- TLS in transit on every endpoint.
- Server-side permissions; step-up MFA for irreversible actions.
- Attachments scanned; HTML sanitised and sandboxed; links checked.
- AI off by default; content never used for training.
Isolation and data handling
- Per-workspace schema
- Each workspace has its own database schema. The workspace is part of the connection itself, so a pooled connection can never point at another customer's data.
- Resolved first
- Every request, queued job and webhook resolves exactly one workspace from the master record before any workspace data is opened - and refuses rather than guesses.
- File storage
- Raw email, attachments and generated files are stored under a per-workspace root, so another workspace's file key does not resolve.
- Nothing lost silently
- Inbound mail is stored before it is processed; a message that cannot be parsed is quarantined and shown to administrators, never dropped.
Credentials and encryption
- Mailbox tokens
- Gmail and Microsoft 365 tokens are encrypted at rest and refreshed one at a time behind a lock. There is never a plain-text token column.
- Sign-in scopes
- Signing in with Google or Microsoft requests identity only. Reading a mailbox is a separate, explicit connection with its own consent.
- MFA secrets
- Authenticator secrets are encrypted, and nothing is stored until the first code proves the setup.
- In transit
- TLS on every endpoint. Session tokens never travel in a URL.
Access control
- Permissions
- About fifty permission keys, each protecting a server endpoint. A test fails the build if one protects nothing.
- Visibility
- Ticket scopes limit who sees which tickets - assigned, team, department or all - in lists, search, notifications and links alike.
- Step-up MFA
- Deleting a ticket, releasing a suppressed address and similar actions ask for a fresh authenticator code, usable once.
- No lock-outs
- Removing the last administrator is refused, and nobody can suspend themselves. Every user is invited; nobody is handed a password.
Inbound email safety
- Attachments
- Virus-scanned before they can be downloaded, and always served as a download. Pending or failed scans stay locked.
- HTML
- Sanitised on arrival into a copy beside the original; only the sanitised copy is served, in a sandboxed frame with a strict content policy.
- Images
- Remote images are off until an agent asks for them, so senders cannot track when a message was opened.
- Links
- Clicks go through a checker that shows the real destination, flags common disguises and optionally consults Google Web Risk.
AI and your content
- Off by default
- Every AI feature is off until an administrator switches it on, and using it needs its own permission.
- Scope
- Summaries read the customer conversation, never internal notes. The AI never sends or saves a reply.
- Training
- Customer content is not used to train shared or third-party models.
- Cost control
- AI is paid in credits reserved before each call and refunded if it fails.
Audit and monitoring
- Domain audit
- Ticket, message, approval and settings changes are recorded as events with the actor and time.
- Approvals
- Each approval decision records the approver, time, IP address and browser, against the exact content signed.
- Activity
- Each ticket carries a user-facing timeline of what changed and who changed it.
- Health
- Mailbox health, delivery failures and bounces are surfaced in the product rather than left in logs.
Where we are, and where we are not
Claiming a certification you do not hold is the fastest way to fail a procurement review. Here is the current position.
Data processing agreement
A DPA covering processor obligations and sub-processor disclosure is available on request.
Security architecture summary
A written description of isolation, encryption and access control, suitable for a vendor review.
SOC 2 Type II
Not yet started. We will publish a date when the observation window begins, and will not claim it before the report exists.
ISO/IEC 27001
Not yet started. We will not claim it before the certificate is issued.
Reporting a vulnerability
Email security@supadesk.in with reproduction steps. We acknowledge within two working days, keep you updated while we fix it, and credit researchers who ask to be named. Please do not test against another customer's workspace.
Questions people ask before they start
Need the full security pack?
We will send the architecture summary, sub-processor list, DPA and a completed standard questionnaire - usually the same working day.
Questions first? Email sales@supadesk.in or call +91 8585953085.