Privacy and Data Standards
Version 1.0 · April 2026
SmishAlert is a recipient-side security company. We protect the people who receive messages, not the brands attackers impersonate. That position has architectural consequences. We run on the recipient's device, evaluate content the recipient owns, and operate in a layer most security tools do not reach. That position carries meaningful responsibility.
These standards describe how we treat recipient data. They define what stays on the device, what leaves the device, what we never collect, and what employers can and cannot see. They reflect our operating principles. Specific obligations are defined in customer agreements and our Privacy Policy.
Our Core Principles
Five principles guide every product decision we make and every customer agreement we sign.
Principle 1: Protect the Recipient First
Our customer is the buyer. Our user is the recipient. When those interests conflict, the recipient's privacy comes first. A buyer cannot purchase visibility into an employee's personal messages, and we will not configure the product to provide that visibility.
Principle 2: Process Locally, Transmit Sparingly
Smishing detection runs on the device. The classification model lives on the phone, the message is evaluated on the phone, and the verdict is rendered on the phone. Background telemetry to the cloud is limited to the minimum signal required to maintain campaign intelligence and product quality. Message content only leaves the device when the user explicitly reports a message.
Principle 3: Background Telemetry Is Fingerprints, Not Contents
Background telemetry transmits fingerprints: hashed structural representations of normalized messages, template skeletons, sender metadata stripped of raw identifiers, on-device verdicts, and coarse timestamps. These signals are useful for detecting attack campaigns across our user base. These signals are structurally incapable of reconstructing a message. User-initiated reports are a separate path with their own rules, covered below.
Principle 4: Personal and Managed Devices Get Different Policies
A personal or BYOD device is not a managed device. Our admin console treats them as distinct policy axes. Personal and unconsented BYOD devices default to minimal telemetry and zero content disclosure. Managed devices and consented BYOD devices may permit richer signal under explicit, logged organizational policy. The user always has visibility into which mode applies to their device and what that mode permits.
Principle 5: Transparency Over Assertion
Recipients can see what is collected about them. Admins see aggregate intelligence, not individual message narratives. A current list of subprocessors is maintained on our Trust page. Data flows are documented there and in this policy. Trust is earned through auditability, not assertions.
What We Will Never Do
The following commitments are absolute. They are not subject to customer override, contractual exception, or admin configuration.
Message Content
Message body content is among the most sensitive data on a phone. We architect around that. There is exactly one path by which message content leaves the device: a user explicitly reporting it. Everything else is governed by the commitments below.
No background transmission of message content
Background processing on personal and unconsented BYOD devices never transmits message bodies. Classification happens on-device, and only verdicts and structural fingerprints leave automatically.
Message bodies are stored only when reported
We do not retain message bodies on our servers as part of background processing. The only message content stored on our infrastructure is content the user has explicitly reported, or content reviewed under an explicit and logged managed-device policy. Both paths are visible to the user.
No reading outside the classification path
Our message filter extension exists to evaluate inbound messages for smishing. It does not scan, log, or analyze messages for any other purpose. There is no marketing analytics layer, no ad targeting, and no secondary use of this classification path.
No sale or onward transfer of message data
Recipient message data, fingerprints, reported content, and behavioral data are never sold, shared with third parties, or repurposed beyond the scope of the customer agreement.
Reporting
User-initiated reporting is the one path by which message content leaves the device. We are explicit about how that path works.
Reporting is always user-initiated
We never report a message on a user's behalf without their action. There is no auto-report mode. There is no admin-triggered reporting against a specific user's device. There is no silent background reporting.
Reported content is transmitted and stored
When a user reports a message, the message body, sender metadata, and contextual data are transmitted to our infrastructure and stored for campaign analysis and threat intelligence. Storage follows the retention schedule documented in our Privacy Policy.
Reported content informs aggregate intelligence
Reported messages contribute to campaign intelligence and detection quality. Individual reports are not shared with other customers as identifiable content. Patterns and fingerprints derived from reports may inform protections delivered to other users.
Identity and Device Data
We collect the minimum identity and device data required to operate the product. Nothing more.
No address books or contact lists
We do not request, access, or transmit the recipient's contact list. Sender identification is performed against message metadata, not against the user's social graph.
No raw phone numbers read from the device
The user's phone number is sourced from our authenticated identity layer, not read from the device OS. Permissions like READ_PHONE_STATE and READ_PHONE_NUMBERS are not requested.
No cross-tenant identity linking
We do not link a recipient's identity across employers, organizations, or tenants. A user who moves between SmishAlert customers is not tracked across that boundary.
Minimum necessary permissions
Every permission requested is documented, mapped to a specific product function, and removed when no longer required. We have removed permissions in past releases when the product no longer needed them.
Admin Visibility
The admin console exists so security teams can see attack campaigns. It does not exist so employers can read employee message content.
No individual content disclosure from personal or unconsented BYOD devices
Admins never see the body of an individual message from a personal device or from a BYOD device without explicit user consent. Aggregate campaign intelligence is the only output.
No silent policy changes
Changes to what is collected on a user's device are surfaced to the user in the app. A managed-device policy that expands collection cannot be activated without user visibility.
No persistent per-user message reading rights
There is no admin role anywhere in the product that grants standing access to read individual recipient messages. Incident-level content review on managed devices is logged, scoped, and time-bounded.
Reporting and telemetry are separate decisions
A user reporting a suspicious message is one decision. Background telemetry collection is another. These are configured separately, surfaced separately, and consented to separately.
Data Lifecycle
The data we do collect has a documented life and a documented end.
Documented retention and destruction
Telemetry, fingerprints, and operational logs follow a published retention schedule. Customer data is destroyed at agreement termination according to that schedule.
No model training from background telemetry without consent
Background telemetry is not used to train models or improve our product without explicit, separately-granted opt-in. The default is no. User-initiated reports are treated separately and may be used to improve detection for all users, as covered in the Reporting section.
Listed subprocessors only
We publish the list of subprocessors involved in our data flow. No new subprocessor is added without notice to customers.
These standards reflect what the product does today and what we commit to maintaining as it grows. We expect to update them as the product evolves. Versions and dates are tracked above.