Trust & security
Transparency by design, scoped to how you deploy.
SmishAlert runs in one of three deployment modes. The mode the buyer picks determines exactly what we see — and what we don't. Procurement has nothing to ask twice.
The deployment-mode model
Three modes. Same iOS binary. The customer’s configuration picks the one.
The mode is delivered via MDM configuration (or by the personal-use default if there is no MDM context). What you review here is what users experience on day one.
Personal
On-device only. Privacy-maximal. The free path.
Individual iPhone and Android users, BYOD employees who haven't been enrolled by their org, and anyone using the consumer App Store / Play Store download. The default mode unless an MDM configuration says otherwise.
What we see
- — Only messages and screenshots the user explicitly reports to SmishAlert
- — Report timestamp, classification, and the body and sender for content they submit
What we never see
- — Any unknown-sender message the user did not report (and on Android, unknown-sender messages even if reportable have to be reported manually)
- — Anything from contacts or known senders
- — Photos, location, address book, or other phone data
- — Third-party messaging apps (WhatsApp, Signal, Slack, Teams) unless the user screenshots and submits
Value
- Spam and promotional clutter sorted out of the inbox
- One-tap reporting when something looks suspicious
- No telemetry sent off the device unless the user reports a message
Limitations
- — SmishAlert can only see what employees voluntarily report — meaning the org gets no defensible measurement of workforce exposure, only the visible tip of it.
- — Assessment-grade data is not produced in this mode. A pilot run entirely in Personal mode tells the buyer about reporting culture, not actual exposure.
Workforce
Every unknown sender reviewed. The system of record.
Organizations of 200–2,500 employees running an assessment or an annual subscription on a managed iOS and Android fleet. Pushed via MDM. The default mode for everything SmishAlert sells.
What we see
- — iOS: every unknown-sender SMS / iMessage body and sender number (via the Message Filter extension)
- — Android: every message the employee reports (Share Sheet, in-app upload, screenshots of third-party apps)
- — Device metadata on both platforms: carrier, OS version, app version (no advertising IDs)
- — Classification verdicts and campaign clusters across the deployment
What we never see
- — Anything from contacts or known senders (those messages never enter the filter pipeline)
- — Photos, location, address book, browsing, or other phone data
- — Third-party messaging apps unless the employee screenshots and submits
- — Employees who aren't enrolled in the deployment
Value
- Defensible measurement of workforce exposure — the assessment deliverable
- Campaign-level correlation across employees, not singleton reports
- Audit-grade record of every unknown-sender message reaching enrolled users
- Disposition-back to employees in near real-time, which is the differentiator competitors don't have
Limitations
- — Requires a managed device deployment (MDM) and employee notice consistent with the org's acceptable-use policy.
- — Unknown-sender auto-capture is currently iOS-only via the Message Filter extension. Android employees in the same deployment participate via employee-initiated reporting that lands in the same Workforce dashboard; Android filter parity tracks platform APIs.
Compliance
Full messaging stream, monitored in real time.
Regulated industries with formal record-keeping and supervision requirements — broker-dealers and RIAs under FINRA/SEC, healthcare under HIPAA, payroll providers under DOL, government contractors. A design-partner program today, not generally available.
What we see
- — Full messaging stream for enrolled, opted-in users — with formal consent and supervisor-visible disclosure to employees
- — Classification verdicts including policy and regulatory flags (insider trading patterns, harassment language, off-platform business communications)
- — Retention horizon set by the customer to satisfy their applicable rule (e.g., 3-year SEC, 7-year FINRA)
What we never see
- — Anything outside the supervised messaging policy the customer has configured
- — Personal-mode users in the same tenant (mode is per-enrollment)
Value
- Regulator-grade record-keeping equivalent to FINRA-compliant communications archiving
- Real-time supervision — competitors record but don't actively analyze, leaving issues to surface in retrospective audits
- Single system of record for both social engineering targeting employees and policy violations originating from them
Limitations
- — Design-partner only. Spec is firming up; not on the standard order form yet.
- — Requires employee notice and consent, works-council coordination where applicable, and explicit configuration of the supervised messaging policy. We will not enable this mode by default.
How this affects the pilot
Workforce mode isn’t a sales preference. It’s how the pilot produces real numbers.
The 30-day exposure pilot is delivered in Workforce mode by default. A pilot run entirely in Personal mode (BYOD-only, on-device-only) cannot produce pilot-grade data — it measures reporting culture rather than actual exposure.
In Personal mode, SmishAlert only sees messages an employee chooses to report. That measures awareness and reporting culture — both useful, neither defensible to a board. In Workforce mode, every unknown-sender message reaching enrolled employees is classified and correlated, so the executive readout describes what actually hit the workforce rather than what someone bothered to flag.
Every SmishAlert pilot is configured in Workforce mode by default, delivered via MDM (Jamf, Addigy, Intune, or any provider supporting iOS Message Filtering). Pilots run on a mix of managed and BYOD devices are scoped during the kickoff call — when most users would land in Personal mode, we tell the buyer the pilot will be unreliable rather than take the deal.
What we collect — and what we never touch
The procurement-grade summary.
This table is the version of our data scope you can paste into a SIG-Lite or CAIQ. Fuller field-by-field detail and hashing steps are available under NDA.
| Data class | Personal mode | Workforce mode | Compliance mode |
|---|---|---|---|
| Unknown-sender SMS / iMessage body | Only if user reports | Yes — captured + classified (iOS) | Yes |
| Known-sender / contact messages | Never | Never | Yes (with consent + supervision policy) |
| Sender phone number / handle | Only on reports | Yes — unknown senders (iOS) | Yes |
| Device metadata (carrier, OS, app version) | Reports only | Yes | Yes |
| Photos, location, address book | Never | Never | Never |
| Other messaging apps (WhatsApp, Signal, Slack, Teams, etc.) | Only if user screenshots and submits | Only if user screenshots and submits | Per supervised messaging policy |
| Employees not enrolled in deployment | N/A | Never | Never |
Platform notes. On iOS, unknown-sender SMS and iMessage flow into SmishAlert through the native Message Filter extension — that’s where the “captured + classified” behavior in Workforce mode comes from. On Android today, message capture is employee-initiated only (Share Sheet, in-app screenshot upload, or the SmishAlert reporting flow) — those reports land in the same Workforce dashboard and feed the same campaign correlation. Android filter parity is on the roadmap pending platform APIs.
Screenshot path. In any mode and on any platform, if an employee screenshots a message from a third-party app (WhatsApp, Signal, Slack, Teams, etc.) and submits it via the SmishAlert Share Sheet or in-app upload, we see and process the screenshot they sent. That employee-initiated path is the only way we touch content from apps that don’t pass through the iOS Message Filter.
Architecture
On-device classification first. Server review only where the mode requires it.
In every mode, our on-device CoreML classifier is the first verdict. In Workforce and Compliance, the iOS Message Filter network defer API sends unknown-sender content to SmishAlert for the second-pass classification and campaign correlation. Apple’s defer contract governs what transits the wire; we summarize the obligations under Privacy & Data Standards.
SmishAlert separates background fingerprints (campaign-correlation telemetry) from explicit user reports (full-content path). Field-by-field fingerprint specs and hashing steps are available under NDA for procurement — email support@smishalert.ai.
Subprocessors
The vendors that operate the service.
Updated as vendors change. Request the current DPA for procurement packets.
| Vendor | Purpose | Notes |
|---|---|---|
| Neon | PostgreSQL database (tenant and reporting data) | Configured per Neon project; detail under NDA |
| Stripe | Payments and billing | United States (Stripe infrastructure) |
| Google Firebase | Authentication and mobile/backend integration | Google Cloud regions per project configuration |
| PostHog | Product analytics (consent-gated on web) | US or EU project per deployment |
| Intercom | Support chat (when enabled) | Intercom infrastructure |
Encryption
- — HTTPS/TLS for data in transit between clients and SmishAlert APIs.
- — Encrypted connections to managed PostgreSQL (Neon).
- — Secrets and keys managed per cloud-provider best practices; least-privilege access for production.
Retention
Default retention for reported content is 90 days. Enterprise agreements can define custom retention (e.g., 30-day minimum or 7-year regulated record-keeping). Schedules are documented in the Privacy Policy.
Data Processing Addendum
A DPA is available on request for organizational customers. Email support@smishalert.ai with your entity name and procurement contact.
Compliance roadmap
SOC 2 Type II program is in flight. We’ll publish report availability under NDA when the first audit cycle completes. HITRUST and FFIEC alignment work follows.
Ready to evaluate
Book a scoping call for a Workforce-mode pilot.
The fastest path from procurement review to an executive readout. Credit toward an annual subscription if you move forward.
Or take the 2-minute self-evaluation — no email required.