We’d rather show our work than wave a badge. Below is how CommSync actually protects your data, in specifics — from encryption to isolation to how to report a vulnerability.
Our approach to security
CommSync sits between you and every conversation your business has, so we treat the security of your messages, contacts, and credentials as foundational rather than a feature. We design for least privilege, encrypt sensitive data, isolate each workspace, and lean on infrastructure providers with strong, independently audited security programs.
This page describes the safeguards we have in place today. Security is never “finished,” and no system can be guaranteed perfectly secure, but the measures below reflect how we build and operate the Service.
Encryption in transit and at rest
Traffic between your browser or client and CommSync is encrypted in transit with TLS. Data at rest is encrypted as well:
- In transit
- HTTPS/TLS for all application and API traffic, and encrypted connections to our database, queue, and storage backends.
- Application data at rest
- Stored in managed Postgres (Neon) with encryption at rest provided by the platform.
- File attachments at rest
- Stored in Amazon S3 with server-side encryption (SSE, AES-256) at the bucket level.
Credentials, passwords, and keys
The most sensitive data you entrust to us gets dedicated, application-level protection on top of at-rest encryption:
- Connected-channel credentials. The mailbox (IMAP/SMTP) and SMS API secrets you provide are encrypted with authenticated AES-256-GCM encryption before they are stored, using a key held outside the database.
- Passwords.Account passwords are hashed with bcrypt — we never store them in plaintext and cannot recover them.
- API keys. Programmatic API keys are shown once at creation and stored only as a SHA-256 hash, so the raw key cannot be read back from our systems.
- Outbound webhooks. Webhook payloads we send are signed with HMAC-SHA256 so your endpoints can verify they genuinely came from CommSync.
Access control and tenant isolation
Every request is authenticated and authorized against the data it is allowed to touch. Workspaces are isolated from one another, and within a workspace access is governed by roles:
- Role-based access. Owners and admins have broad access; members are granted access to specific channels. The Service checks these permissions on every protected action.
- Workspace isolation.Threads, messages, and attachments are scoped to the workspace that owns them, and realtime updates are delivered only to authorized rooms — never broadcast on a shared channel.
- Least privilege internally. Access to production systems is limited to personnel who need it to operate the Service.
Application security
- Input validation. Requests are validated against strict schemas before they are processed.
- Safe rendering. Inbound email HTML is sanitized and rendered in an isolated context, which protects against cross-site scripting from message content.
- Separation of concerns. Our frontend never talks to the database directly; all data access flows through a controlled API tier with authentication and authorization.
- Abuse protection. Sensitive endpoints are rate-limited, and inbound webhooks are verified before they are trusted.
- Dependency hygiene. We track and update third-party dependencies to address known vulnerabilities.
Infrastructure and subprocessors
We build on established cloud providers and handle data through a small set of vetted subprocessors. These providers maintain their own industry-standard compliance programs (such as SOC 2, ISO 27001, and PCI-DSS) for the layers they operate:
- Database & storage
- Managed Postgres (Neon) and Amazon S3.
- Payments
- Stripe (PCI-DSS Level 1) — we do not store full card numbers.
- Messaging & email
- Skyetel and JustCall for SMS; Twilio SendGrid for system email.
- Monitoring
- Better Stack for uptime monitoring, which does not receive message content.
For the full picture of how data is shared, see our Privacy Policy.
Monitoring, availability, and backups
We monitor the health of the Service continuously. Application components expose health checks, background workers report heartbeats, and an independent, off-site monitor watches availability and alerts us to problems. You can see live status on our status page.
Our managed database platform maintains automated backups and point-in-time recovery, which we rely on for durability and disaster recovery.
Data retention and deletion
You control your data. Items you move to Trash are permanently removed after roughly 30 days, and deleting your account removes your personal data and per-user content, subject to short operational backup windows and any retention required by law. More detail is in our Privacy Policy.
Reporting a vulnerability
We welcome reports from security researchers and treat them seriously. If you believe you have found a vulnerability, please email [email protected] with details and steps to reproduce. We ask that you:
- Give us a reasonable opportunity to investigate and remediate before public disclosure;
- Avoid privacy violations, data destruction, or service degradation, and only interact with accounts you own or have permission to test;
- Do not run automated scanning that could disrupt the Service or other users.
Acting in good faith under these guidelines, we will not pursue action against you, and we’re glad to credit researchers who help us improve.
Your role in security
Security is shared. Please protect your account with a strong, unique password, keep your devices secure, scope and rotate API keys you create, and ensure your messaging practices comply with applicable law and carrier requirements (see our Terms of Service). Tell us right away at [email protected] if you suspect any unauthorized access.
If anything here is unclear, we’re glad to explain it in plain language. Email [email protected] or use our contact page.