How we handle trust, by design.

All SMS sent through TIM-built systems use carrier-verified, brand-registered numbers with documented opt-in capture and double-confirmation flows. Every recipient is associated with a timestamped consent record stored alongside the message log, satisfying the evidentiary bar regulators expect for a TCPA defense.

Opt-out handling is automatic and immediate. STOP and HELP keywords are honored across every campaign without operator action; reactivation requires a fresh consent capture. Every outgoing message carries the sender identification required by TCPA and the message-frequency disclosure made at the point of opt-in. Opt-in records are retained for four years, the minimum statute-of-limitations window for TCPA claims.

TIM is enrolled in The Campaign Registry (TCR), the carrier-mandated registry that governs application-to-person SMS in the United States. Each campaign we run on behalf of a client organization is brand-verified and campaign-approved before any message reaches a wireless carrier, satisfying the requirements of Verizon, AT&T, T-Mobile, and the other US Tier-1 networks.

Carrier verification is the difference between a message that actually reaches a recipient’s phone and one that gets silently filtered as unverified traffic. We carry the registration overhead so the client organization doesn’t have to.

TIM-operated SMS platforms run on Microsoft Azure infrastructure. The sub-processors we rely on to deliver the service are:

• Microsoft Azure — application hosting, identity, secrets, telemetry, and storage. Microsoft holds SOC 2 Type II, ISO 27001, and HIPAA attestations across the services we depend on; see trust.microsoft.com for the canonical list.
• Azure Communication Services — the SMS delivery API. Operates inside the same Microsoft trust boundary as the rest of the platform.
• US Tier-1 wireless carriers — Verizon, AT&T, T-Mobile, and their MVNO partners — for last-mile delivery of every text. Carrier delivery receipts are captured and retained as the audit trail of record.

Delivery receipts, opt-in records, and message logs are retained for the TCPA-mandated four-year minimum. Access is granted to Managed Identities, not to humans; production credentials never exist outside of Azure Key Vault.

Every message produces a carrier delivery receipt, captured by Azure Communication Services and retained alongside the opt-in record for the same recipient. If a challenge is ever raised — by a regulator, by a recipient, by a carrier — the receipt plus the consent record together form the evidentiary chain that closes the question.

This is the audit trail most DIY SMS tools require the operator to assemble after the fact, and that most assemble incorrectly. We build it into the platform so it’s present whether or not anyone asks.

Every platform we build runs on Microsoft Azure, which holds SOC 2 Type II attestation across the services we depend on (App Service, Communication Services, Application Insights, Managed Identity, Key Vault, Blob Storage). Microsoft’s Trust Center is the canonical reference: trust.microsoft.com.

To be precise: Technology In Ministry LLC is not itself SOC 2 audited today. Our platforms inherit the controls of the Microsoft services they run inside, and our own organizational SOC 2 attestation is on the roadmap rather than currently held. We’d rather state that plainly than imply otherwise.

Authentication uses Managed Identity exclusively in production — there are no service credentials to rotate, leak, or store in environment variables. Secrets live in Azure Key Vault; access is granted to Managed Identities, not to humans.

Where money moves, we delegate to Square, a PCI-DSS Level 1 service provider. Card numbers never touch the platforms we build — Square’s tokenized payment SDK handles card capture in a hosted iframe, and our systems only ever see the resulting tokens, receipts, and reconciliation records.

This is the same architecture that powers payments for Refresh 2026 and the district-funded grant infrastructure. Your organization gets the audit trail and the settlement reporting without inheriting the PCI compliance scope. TIM itself is not a PCI-DSS entity and has no need to become one under this design.

The applications we build run inside your Azure subscription, against your databases, billed to your credit card. We can host on our subscription during development, but production deployments transfer to the customer’s subscription before launch. There is no “our cloud” that your data lives in by default.

Code is delivered to a customer-owned GitHub or Azure DevOps repository. If our engagement ends, you keep the code, the data, and the operational instructions to run everything yourself. There is no lock-in by design.

Application observability uses Azure Application Insights — first-party Microsoft telemetry, scoped to the platform’s own performance and error reporting. We do not deploy third-party analytics (Google Analytics, Segment, Mixpanel, Heap) on TIM platforms by default, and we recommend against doing so.

The reasoning is part performance (no third-party JS in the critical path), part privacy (no third-party data sharing to defend in front of a board), and part positioning (“owned, not rented” applies to telemetry as much as to everything else).