Trust Center

1. Overview

SlackBridge, a Square Post Labs Inc. product, bridges messages between Slack and Microsoft Teams in real time. This Trust Center is the single place to understand how we protect your data: our security controls, privacy posture, compliance status, the subprocessors we rely on, and how to report a security issue.

2. Compliance & Certifications

We take a controls-first approach and are transparent about where we stand today.

Our attestation status Roadmap

SlackBridge does not currently hold its own SOC 2 or ISO 27001 attestation. An independent third-party penetration test and formal attestations are on our roadmap, and we will update this page as that work completes.

Certified infrastructure In place

Our production infrastructure runs on cloud and payments providers that independently maintain SOC 2 Type II, ISO 27001, ISO 27018, and PCI DSS Level 1 certifications. We inherit those infrastructure-layer controls and enforce our own application- and endpoint-layer controls on top. (Specific providers are listed on our Subprocessors page.)

Frameworks we align to

• An OWASP-aligned secure software development lifecycle (SDLC).
• SOC 2 Trust Service Criteria (Security, Availability, and Confidentiality) as the basis for our control set.
• A documented written policy set, reviewed at least annually (see Policies & Documentation).

3. Data Protection & Privacy

We minimize what we hold and protect what we must.

• No message content at rest. In-flight messages are relayed and discarded; only non-reversible one-way fingerprints and message-ID mappings are retained to keep threads in sync.
• Data minimization. We collect only what the bridge functionally requires (organization and contact emails, display names, and platform identifiers) and nothing more.
• Encryption in transit. All connections use modern TLS; non-HTTPS external requests are rejected.
• Encryption at rest. Stored OAuth tokens are encrypted with AES-256-GCM; encryption keys are managed as secrets and never live in source code.
• Per-tenant isolation. Every record is namespaced by organization, so one customer's data cannot address another's.
• No card data. Payments are handled by a PCI DSS Level 1 provider; card details never touch our systems.

For how we handle personal data, see our Privacy Policy.

4. Security Controls

We apply defense in depth, so no single failure is catastrophic. We describe our controls by category rather than by product name.

Identity & access

• OAuth-only authentication, so there are no SlackBridge-managed passwords to phish or breach. End-user identity (and MFA / conditional access) is governed by your own Slack and Microsoft identity providers.
• Layered administrative access, all of which must be satisfied: network allowlisting, a zero-trust identity layer, mandatory MFA, and an explicit owner/admin email allowlist.
• Least-privilege, tiered permissions for every account, token, and API integration.
• Quarterly access reviews, and immediate revocation on personnel change.

Network & application

• Edge WAF and DDoS protection, plus a full security-header set (HSTS, Content-Security-Policy with frame-ancestors 'none', X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy).
• Cryptographic (HMAC) signature verification on all inbound webhooks, with timestamp and replay protection.
• Double-submit CSRF protection on all state-changing requests.
• Outbound requests are HTTPS-only with SSRF egress filtering that blocks private ranges and cloud-metadata endpoints (covered by automated tests).
• Sliding-window rate limiting with fail-safe behavior.

Detection & monitoring

• Security-event logging (auth failures, rate-limit and replay events, CSRF failures) with spike-threshold alerting.
• A tamper-evident, hash-chained audit log for security-relevant lifecycle events, with an independent integrity copy in object storage.
• Self-hosted SIEM/XDR with host intrusion detection and file-integrity monitoring on managed systems.
• Centrally-managed, full-disk-encrypted staff endpoints with enforced patching and remote wipe.

A deeper technical walkthrough is on our Security & Compliance page.

5. Application Security & SDLC

Every change flows through version control and a gated pipeline with blocking, automated security checks before any immutable deploy.

• Blocking CI security gates on every deploy: static analysis (SAST, OWASP-aligned rules), secret scanning, and dependency-vulnerability auditing. A high-severity finding fails the build.
• Automated dependency-update proposals weekly; a deliberately minimal, lockfile-pinned dependency footprint.
• Immutable, reproducible deploy artifacts with scoped, encrypted deploy credentials.
• A large automated test suite (unit, integration, and cross-viewport end-to-end browser tests) gates every release.
• Remediation SLAs: Critical and High within 7 days; Medium by the next release or within 30 days; Low on a best-effort basis.

6. Subprocessors & Data Residency

We use a small set of subprocessors, each scoped to the minimum data required. Our full, current list, naming each provider and the specific data categories it handles, is published and kept up to date here:

Data residency

Our infrastructure runs across a globally distributed edge network with replication for durability and availability. We do not pin data to a specific jurisdiction by default; regional residency requirements can be evaluated case-by-case; contact us to discuss.

7. Vulnerability Disclosure Policy

We welcome reports from security researchers and the public, and we will work with you in good faith to verify and remediate confirmed issues.

Scope

In scope

• The SlackBridge web application and API at slackbridge.com (and its API endpoints).

Out of scope (please do not test or report)

• Denial-of-service (DoS/DDoS), volumetric, or resource-exhaustion attacks.
• Social engineering, phishing, or pretexting against our staff, customers, or partners.
• Physical attacks against offices, facilities, or personnel.
• Vulnerabilities in third-party platforms we integrate with or rely on, including the Slack and Microsoft platforms and our underlying cloud provider. Please report those to the respective vendor.
• Findings requiring a compromised device, a rooted/jailbroken environment, or a man-in-the-middle position you control.
• Automated-scanner output with no demonstrated, exploitable impact (e.g., missing best-practice headers or version banners) absent a concrete attack scenario.

How to report

Email [email protected] with a clear description and potential impact, the affected URL/endpoint/component, step-by-step reproduction details, any proof-of-concept, and your name or handle if you would like credit. One issue per report, please.

Safe harbor

We will not pursue or support legal action against researchers who, in good faith, find and report vulnerabilities in line with this policy. Good faith means: staying within the in-scope targets; avoiding privacy violations, data destruction, and service disruption; accessing only the minimum data needed to demonstrate an issue; and not publicly disclosing before we have remediated and agreed on a coordinated timeline. If unsure whether an action is permitted, ask us first.

Our commitments

• Acknowledge your report within 3 business days.
• Triage, validate, and assign a CVSS-aligned severity.
• Remediate confirmed issues under our SLAs (Critical/High within 7 days; Medium by next release or within 30 days; Low best-effort).
• Coordinate disclosure with you and keep you reasonably informed through remediation.

We do not currently operate a paid bug-bounty program, but with your permission we are glad to publicly credit researchers whose valid reports help us improve.

8. Policies & Documentation

We maintain a written policy set governing our security program. Summaries are public; the full policy documents and detailed control descriptions are available to customers and prospects under NDA.

• Information Security Policy (with Acceptable Use and Access Control)
• Vulnerability Management & Patch-SLA Policy
• Incident Response Plan
• Business Continuity & Disaster Recovery Plan
• Data Classification Policy

9. Business Continuity

Our production stack is fully serverless and globally distributed, providing automatic multi-region replication and failover with no single point of failure that we operate. Configuration data is held in replicated, encrypted-at-rest storage; message content is intentionally not stored and so requires no backup. A written Business Continuity & Disaster Recovery plan documents our recovery objectives and procedures, with a target annual review-and-test cadence.

10. Security Contact

To report a vulnerability, request security documentation, or ask a question about our posture:

Security: [email protected]
Acknowledgement: within 3 business days
Service status: status.slackbridge.com