Security & Compliance

Security & Compliance at SyncRivo

Messages route in real time over TLS, and message content is not stored on the normal relay path. Every integration uses OAuth 2.0, and a BAA is available for Enterprise customers.

Request Security Documentation Report a Vulnerability

Need a BAA, DPA, or a security questionnaire? Visit the Trust Center →

Compliance Documents

Agreements available to customers. SyncRivo does not currently hold a SOC 2 report or ISO 27001 certificate; we provide a security questionnaire and architecture review on request.

HIPAA

BAA Available

Business Associate Agreement for Enterprise customers

Encrypted in transit (TLS), OAuth tokens encrypted at rest, message content not stored on the normal relay path, and an activity log.

Contact sales to sign a BAA before processing PHI.

HIPAA Details

GDPR

DPA Available

Data Processing Agreement and sub-processor list available

SyncRivo acts as a data processor under GDPR. SyncRivo is hosted in the US on Google Cloud (us-central1).

EU customers can request a signed DPA.

GDPR Details

Security Controls

The technical and organizational controls SyncRivo uses to protect your data and integrations.

Encryption

TLS for all data in transit
Provider OAuth tokens encrypted at rest
Message content not stored on the normal relay path (only message IDs)

Authentication & authorization

OAuth 2.0 per integration — scoped, revocable tokens only
Sign in with Google or email + password
Optional MFA (TOTP, passkeys)
Owner, admin and member roles for every organization

Isolation & multi-tenancy

Organization-scoped data; cross-organization bridges only after both admins accept
Organization suspension kill switch stops all relaying
Activity log and security event history (JSON export)

Infrastructure

Hosted in the US on Google Cloud (us-central1)
MongoDB Atlas with encryption at rest and in transit
Webhook signature verification on all five platforms

Logging & incident response

Security event history for sign-ins, role changes and exports
Documented incident response policy

Vulnerability management

Responsible disclosure program — security@syncrivo.ai
Coordinated disclosure with 90-day embargo for researchers

Message Content Not Stored on the Relay Path

SyncRivo is a message router, not a message store. When a message arrives via webhook, SyncRivo transforms it and delivers it to the target platform in real time — message content is not stored on the normal relay path; only message IDs are kept.

This design keeps message content on your chat platforms rather than in the bridge, which simplifies data-subject requests. If you enable the optional retry queue, undelivered messages are held temporarily until they can be delivered.

What SyncRivo does store: channel mapping configurations, OAuth tokens (encrypted at rest), routing rules, message IDs, directory data for synced users, and activity metadata (no message content).

How Your Messages Flow Through SyncRivo

Every message follows the same in-memory routing path. Message content is not stored on the normal relay path.

Message arrives via webhook

The source platform (e.g., Slack) sends a signed webhook event to SyncRivo's ingestion endpoint over TLS. SyncRivo verifies the platform signature before processing — unsigned or malformed events are rejected immediately.

Identity resolved, content not stored

SyncRivo looks up the routing rule for the source channel and resolves the destination. The message payload is processed in memory; message content is not stored on the normal relay path. Routing metadata (channel and message IDs, timestamps) is recorded without message content.

Message transformed in-memory

SyncRivo translates platform-specific formatting — @mentions, thread context, file references — into the target platform's schema. This transformation occurs entirely in memory within the request lifecycle.

Delivery to target platform

The transformed message is delivered to the destination platform (e.g., Microsoft Teams) via the platform's official API over TLS. SyncRivo uses scoped OAuth 2.0 tokens that are encrypted at rest — not hardcoded secrets.

Activity recorded (no content)

SyncRivo records the message IDs needed to keep threads, edits and reactions in sync, plus delivery activity for the activity log. If the optional retry queue is enabled, undelivered messages are held temporarily until they can be delivered.

Shared Responsibility Model

Security is a partnership. Here's how responsibilities are divided between SyncRivo and the customer.

SyncRivo is responsible for

Physical and logical security of cloud infrastructure (GCP)
Encryption of OAuth tokens and routing configuration at rest
Patching and vulnerability management of the SyncRivo platform
Incident detection, response, and notification to affected customers

Customer is responsible for

OAuth scope selection and token revocation when users leave
Access control to the SyncRivo dashboard (who can create/delete connections)
Compliance obligations specific to your industry (e.g., HIPAA BAA must be signed)
Content appropriateness in channels being bridged
Review of sub-processor list and DPA terms before onboarding
Incident reporting obligations under your applicable regulations

Responsible Disclosure

If you discover a security vulnerability in SyncRivo, please email security@syncrivo.ai. We triage all reports within 24 hours and coordinate disclosure with a 90-day embargo window. We do not take legal action against good-faith security researchers.

Read Vulnerability Disclosure Policy

Security FAQs

Common questions from enterprise security and procurement teams.

Not on the normal relay path. SyncRivo is a real-time message router, not a message archive. Message content is processed in memory and delivered to the target platform in real time — messages typically arrive within seconds. SyncRivo keeps only message IDs so threads, edits and reactions stay in sync, and files pass through memory only. If you enable the optional retry queue, undelivered messages are held temporarily until they can be delivered. What SyncRivo does store: routing configurations (which channels are bridged to which), provider OAuth tokens encrypted at rest, message IDs, directory data for synced users, and activity metadata. eDiscovery requests, litigation holds and data-subject access requests for message content are handled at the source platform where the message is actually retained.

SyncRivo is hosted in the US on Google Cloud (us-central1), using Cloud Run for compute and MongoDB Atlas for configuration storage. SyncRivo does not currently offer EU or other regional data residency. The sub-processor list is published at /sub-processors, and a Data Processing Agreement (DPA) is available.

Each platform connection uses OAuth 2.0 tokens scoped to the permissions the bridge needs, which your Slack, Teams, Google, Webex or Zoom admins approve when installing the app. Tokens are encrypted at rest, sent only over TLS, and are not echoed in API responses. Customers can revoke access at any time from the SyncRivo dashboard or directly from the source platform's app management screen, which disables the bridge.

A Business Associate Agreement (BAA) is available for Enterprise customers, and it must be signed before any Protected Health Information (PHI) is processed through SyncRivo. Relevant safeguards include TLS in transit, provider OAuth tokens encrypted at rest, message content not stored on the normal relay path, owner/admin/member roles with optional MFA, and an activity log and security event history. Healthcare organizations can bridge clinical Slack or Teams channels with administrative platforms while keeping PHI inside their existing EHR/EMR boundary. Contact the SyncRivo sales team to start the BAA process.

SyncRivo maintains a documented incident response policy. In the event of a confirmed security incident affecting customer data, SyncRivo notifies affected customers consistent with GDPR Article 33 and HIPAA Breach Notification Rule timelines. Notifications include the nature of the incident, the categories of affected data, the likely consequences, the measures taken or proposed, and a designated contact for follow-up questions.