A2P SMS Provider Assessment: From Due Diligence to Operational Controls
A guide to assessing the provider entity and each route separately, recording evidence and uncertainties, and setting approval conditions proportionate to risk.
Two different assessments: provider and route
Due diligence on a provider company and approval of an A2P SMS route address different questions. The first examines who you are contracting with, what responsibilities the company accepts, and how it manages its operations. The second concerns a specific combination of service, destination, traffic type, and usage conditions.
A favorable assessment of the company does not, by itself, show that a route is suitable for a particular destination or use case. Conversely, successful operational testing on a route does not replace a review of the entity, the contract, or the declared supply chain. Keep separate records and specify which evidence may serve both assessments.
- Provider record: identity, contracting capacity, responsibilities, security, compliance, support, and declared subcontracting.
- Route record: destinations and services covered, declared route provenance, restrictions, operating conditions, and evidence available for that configuration.
- Relationship record: identify which entity provides each part of the service and who is responsible for incidents.
Define the scope before requesting evidence
A review without an explicit scope produces answers that are difficult to compare. Before requesting documentation, record the service under review, intended destinations, legitimate traffic to be sent, and the responsibilities each party is expected to assume. Do not assume that a general response covers every route, subsidiary, or service.
Also describe the limits of the assessment: which destinations are excluded, which claims require additional evidence, and which aspects could not be verified. If the scope changes, preserve the history and decide whether a new review is needed.
- Identify the contracting entity and, as declared, the entities involved in providing the service.
- Define the service, destinations, traffic type, and each party’s functions.
- Record assumptions, exclusions, and open questions before granting approval.
Create a traceable evidence matrix
The matrix helps distinguish a claim from the evidence supporting it. For each item, record what is claimed, which document or record was reviewed, who provided it, which entities or services it covers, and when it was checked. Add an internal owner, status, and any outstanding questions.
Do not attribute a broader scope to a source than it actually has. A document may describe a general policy without proving that it applies to a specific route; a commercial statement is not equivalent to independent validation. If the evidence is insufficient, explicitly record the uncertainty rather than turning it into a favorable conclusion.
- Practical fields: domain, claim, source, review date, scope, owner, status, and notes.
- Possible statuses: pending, evidence received, reviewed with reservations, unverified, or closed; define their meanings internally.
- Keep versions and dates so changes between reviews can be identified.
- Separate primary documents, provider statements, and operational observations; do not present them as equivalent evidence.
Review identity, contract, and supply chain
Check that the entity you are negotiating with is clearly identified and that the proposed contractual scope matches the service under review. Review who assumes the relevant obligations, how operational responsibilities are allocated, and what mechanisms are in place to communicate changes that may affect the service.
Where relevant to the decision, ask for a description of third-party involvement in the supply chain. Record what has been declared and what could not be corroborated. Available documentation may have limitations: do not infer direct control, authorization, or contracting capacity from a commercial presentation.
- Compare the entity names in commercial and contractual documentation.
- Identify the responsibilities and communication channels set out in the agreement.
- Record declared dependencies or subcontracting and how changes are notified.
- Refer discrepancies for legal or procurement review, as appropriate under your organization’s process.
Assess each route’s provenance and restrictions
Ask for a description of the route’s provenance and the usage restrictions that apply to the service under review. Relate the answers to the destinations, traffic, and responsibilities defined at the outset. Declared information alone does not prove a route’s technical behavior or suitability for every use.
Document how changes to route provenance, availability, or usage conditions are communicated, and who should receive those notifications. If the information is not sufficient to establish a route’s scope, keep it pending or limit approval to what is actually described. Do not extrapolate conclusions from one destination or configuration to others.
- Record the destination, service, permitted use, and information source separately.
- Ask for clarification of restrictions and changes that require a new review.
- Define what available operational evidence will be observed and what uncertainties will remain.
- Do not treat a single test or commercial description as a guarantee of future delivery.
Security, data, and incident management
Tailor security questions to the service and the data actually involved. Document what information is shared, what controls the provider says it uses to manage access to credentials, and who is responsible for communicating and managing relevant incidents. Do not conclude that a control exists or works merely because it was mentioned in a conversation.
Check the available evidence and its scope: a general policy may not detail the components or teams included in the service. If you cannot verify an important aspect, record the limitation and decide whether it calls for a condition, further review, or a risk decision by the internal owner.
- Clarify which credentials or data are exchanged and for what purpose.
- Ask about incident owners, communication channels, and escalation procedures.
- Record which controls are described, what evidence was reviewed, and what remains unverified.
- Limit access to sensitive documentation in accordance with your organization’s policies.
Traffic governance and complaint handling
The provider assessment should consider how responsibilities for legitimate traffic are allocated. Clarify which party manages applicable requirements for the sender, consent, and message classification, and how complaints are handled. Specific obligations depend on the context and applicable rules; do not replace them with a general statement from the provider.
Define what information is needed to investigate a complaint and how it will be exchanged within the agreed framework. Keep messages, lists, and sending processes under your organization’s controls, and do not assume that a route independently validates consent or the legitimacy of a message.
- Assign the sender’s and provider’s responsibilities in writing.
- Clarify the process for receiving, escalating, and documenting complaints.
- Record the traffic type and authorized uses within the assessed scope.
- Refer regulatory questions to compliance owners or legal counsel.
Operational support and service evidence
Assess whether support channels, escalation, and incident communications are appropriate for the planned operation. Record agreed commitments and available monitoring methods, but do not confuse them with guaranteed outcomes. A promised response time does not prove that a message will be delivered or that an incident will be resolved within a specific timeframe.
Where operational records are available, define what they show and what they do not. For example, a delivery status reported by a system should not automatically be presented as independent confirmation that a message was received on a handset. Agreeing how statuses and their limitations are explained helps reduce misinterpretation.
- Confirm channels, contacts, escalation paths, and incident communication formats.
- Document which records can be accessed, their scope, and known limitations.
- Separate contractual commitments, reported data, and observed outcomes.
- Agree how incidents will be recorded and what information is needed to analyze them.
Frequently asked questions
Does approving a provider mean all of its routes are approved?
No. Assessing the entity and reviewing each route have different scopes. Document destinations, services, restrictions, and available evidence separately.
What should we do when the provider cannot provide evidence for a claim?
Record the claim as unverified, note the source consulted, and decide whether to request more information, limit the scope, impose a condition, or withhold approval for that item.
How should we set initial traffic limits?
There is no universal limit that can be inferred from the available information. Set internal limits in proportion to the risk and approved scope, with an owner, rationale, adjustment conditions, and review.
Which events should trigger a review?
You can establish reviews for relevant changes to the entity, contract, declared supply chain, route provenance or restrictions, support owners, or security conditions. Define these events according to your process and record when they are reviewed.
Does an operational test guarantee future message delivery?
No. An observation applies to a particular scope and point in time and should not be interpreted as a future guarantee. Document what was observed, the supporting evidence, and its limitations.
Sources consulted
- Serie de especificaciones 3GPP3GPP
- Recomendación E.164Unión Internacional de Telecomunicaciones (UIT-T)
- Recursos sobre redesGSMA