If a security questionnaire is standing between you and shipping, this is the page you wanted. The short answer is that SOC 2 Type II attestations do exist in this category, and that they resolve less of the review than either you or the vendor would like.
Who claims what
| Provider | Public compliance claim |
|---|---|
| Linq | SOC 2 Type II; states message content is encrypted and inaccessible to them; advertises a 99.95% uptime SLA |
| Sendblue | SOC 2 Type II; states HIPAA support |
| Blooio | States it is not SOC 2 certified; describes HMAC-signed webhooks, TLS and least-privilege access |
| LoopMessage | No SOC 2 claim found on their public pages |
| Miss Blue | No SOC 2 claim found on their public pages |
| Tuco AI | No SOC 2 claim found on their public pages |
Blooio's answer is the most useful one on that table
Saying plainly "we are not SOC 2 certified, and here is what we do instead" is more informative than a badge. A vendor that will tell you an inconvenient truth on their own website will probably tell you one during an incident, and that is worth more than the certificate.
What SOC 2 actually attests to
A SOC 2 report is an independent auditor's opinion on whether a company operated the controls it said it would, against the Trust Services Criteria, over a defined period. Type I is a point in time; Type II covers a window, usually three to twelve months, and is the one worth asking for.
- It does cover: access control, change management, incident response, vendor management, monitoring, and whether people actually followed the process.
- It does not cover: whether the product is a good idea, whether the business model is durable, or whether a third party has authorised what the company does.
The thing to be clear-eyed about
A SOC 2 Type II report says a company runs its own controls well. It says nothing about Apple's position, because Apple is not a party to it. Every provider in this category reaches iMessage by means Apple has not sanctioned, and an auditor examining access reviews and change tickets is not examining that. If your reviewer's real objection is the Apple relationship, no report resolves it — and that objection deserves a direct answer.
The questions to ask
- "Send me the Type II report under NDA." Not the badge, not the trust page, the report. It exists or it does not, and you will know within a day.
- "What period does it cover, and which criteria?" A report covering a window that ended eighteen months ago is a historical document. Security alone is a much narrower scope than Security plus Availability plus Confidentiality.
- "What is in scope?" Sometimes the corporate systems are audited and the messaging infrastructure is not. Ask specifically whether the sending fleet is in scope.
- "Show me the exceptions." Every real report has some. A vendor who will walk you through theirs is a vendor with a functioning security team.
- "Who can read message content, and under what circumstances?" Encryption in transit is table stakes. What matters is whether staff can read a customer's thread, and what is logged when they do.
- "What is your retention, and can we set it?" Message bodies sitting in a vendor's database forever is a liability you inherit.
- "Will you sign a DPA, and do you sub-process outside our region?"
- "What happens to our numbers and message history if we leave?"
If you are in a regulated industry
Healthcare, financial services and legal all have constraints that sit above SOC 2. A vendor stating HIPAA support should be asked to sign a BAA — the willingness to sign is the actual test, not the claim on the page.
Separately, and importantly: the content of your messages is usually the bigger exposure. A dental practice sending "your crown is ready" has a very different profile from one sending a diagnosis. The healthcare messaging rules are covered here, and the general compliance page is here.
How to write it up for your reviewer
The evaluation that gets approved is the honest one. Something close to:
Apple publishes no iMessage API, so every vendor in this category reaches the channel through unofficial means. We accept that risk because the channel is additive rather than load-bearing: customer records stay in our own systems, SMS remains a working fallback, and the failure mode is degraded outreach rather than lost contact. The vendor holds a SOC 2 Type II report covering the sending infrastructure, we have reviewed the exceptions, and we have a signed DPA and a documented exit path for our numbers.
That paragraph passes review far more often than a badge does, because it demonstrates you understood the risk rather than outsourced the question.
The security review pack
- SOC 2 Type II report, current period, messaging infrastructure in scope.
- Exceptions reviewed, with the vendor's remediation.
- Signed DPA, sub-processor list, data residency confirmed.
- Retention policy for message content, configurable if possible.
- Documented access controls for who can read threads.
- Incident notification commitment with a time bound.
- Written exit plan: number portability and data export.
- A named fallback channel, tested, in case the line stops delivering.