Skip to main content
When a client’s security team or an auditor asks how Thread handles data, you need specifics, not reassurance. This lesson is the map to the pages that answer those questions precisely — what’s stored, how it’s encrypted, what Magic AI sends and where, who the sub-processors are, and exactly what the Teams and Slack apps can touch. Cite these directly; don’t paraphrase from memory.
Keep claims tight. Reference the facts on these pages as written, and confirm anything about Thread’s own certifications or attestations with your Thread account team before you put it in a questionnaire. The pages below cover data handling and permissions — they are not a certification list.

Encryption and what’s stored

Data & encryption is the baseline answer to “how is our data protected?”
  • At rest: Thread is hosted on AWS; instances, databases, and their storage volumes are encrypted.
  • In transit: Thread talks to your PSA, Slack, and Microsoft APIs over HTTPS only.
  • Data minimization: Thread stores only what it needs to keep the PSA and chat connected — API keys, boards and statuses, companies and contacts, tickets, and channel/user identifiers. The page spells out what is deliberately not stored, including financial information.
That last point is the one clients probe hardest, so send them the page rather than summarizing it — the “what we do not store” list is the reassuring part, and it’s more credible in Thread’s own words.

Magic AI privacy and security

AI is where security reviews now spend most of their time, so know this cold. Magic AI privacy & security documents how the AI features handle data:
  • Magic AI runs on an isolated Azure OpenAI Service instance — separated from every other customer, with content filtering on inputs and outputs.
  • No partner or customer data is stored in Azure, and none of it is used to train or improve the models — not by Microsoft, not by Thread. Prompt data exists only in memory for the duration of the call.
  • The data sent for a prompt is a short, fixed list: contact first/last name, contact type, the date the action ran, and the issue’s summary, initial description, and conversation transcript.
When a security questionnaire asks “what data leaves our environment for AI processing?”, the fixed field list on that page is your answer. Quote it — a specific, bounded list lands far better than “only what’s necessary.”

Sub-processors

For a DDQ or vendor review, Thread sub-processors list is the page to point to. It names each sub-processor and its purpose — AWS and Microsoft Azure for hosting and AI, plus the payment, CRM, analytics, and operations providers. Link it directly so the client is always reading the current list rather than a copy that goes stale.

Network allowlisting

Clients with locked-down networks need Thread’s addresses before anything will connect. Thread IP addresses and domains to allowlist has both halves:
  • Outgoing IPs — the addresses Thread connects from when it calls a client’s PSA. Allowlist these on their side.
  • Incoming domains — the domains Inbox and Messenger (including websocket connections) need reachable for clients running the apps.
Hand this page to the network team verbatim; the websocket note in particular is easy to miss and a common cause of “Messenger won’t connect.”

App permissions — Teams and Slack

When a client asks “what can the Thread app actually see and do?”, the permission references answer scope by scope. Both pages frame permissions as least-privilege and scoped to ticket work — Thread doesn’t use them for workspace-wide monitoring or analytics. That’s usually the exact concern a security reviewer is trying to rule out, so lead with it.

Next

You know the data story. Now put the operational bench to work — the runbooks that turn all of this into daily response and audit prep.

Your security & compliance runbooks

The Skill Library security and audit bench — incident response, identity, alerts, and evidence.