A2P SMS Routing Evidence: Retention, Access, and Deletion

What Counts as Evidence of a Routing Decision

Routing evidence is the information needed to explain what decision was made, which rule or criterion was used, when it was applied, and who authorized or changed it. Its purpose is to reconstruct the context of an operational decision, review, or dispute—not to retain everything generated by systems.

It may be relevant to document policy versions, evaluation parameters, test results, approvals, and implemented changes. This is a proposed inventory that each organization should validate against its systems and obligations; it is not a universal technical list of required fields for all A2P SMS platforms.

General system logs, DLRs, and traffic data serve different purposes. A DLR may describe a status reported by the network or an intermediary, but on its own it does not prove verified receipt on the device. Nor does every traffic record constitute evidence of why a route was selected.

• Design question: Which data explains the decision, and which only describes subsequent activity?
• Retain the provenance and context needed to interpret evidence, not just an isolated result.
• Document the limitations of each source, especially when a status comes from a DLR.

Separate Policy, Approvals, Tests, and Message Data

It is useful to classify information before setting retention periods. A starting structure distinguishes four groups: policy configuration and changes; approvals and responsible parties; tests or evaluations; and traffic data, which may contain identifiers, content, or other personal data. Classification should reflect what each system actually records.

Evidence of a rule may be retained without storing message content if a reference, version, or aggregated result is sufficient. However, do not assume that anonymization, aggregation, or content deletion is always possible without affecting an investigation; check this against the processes and systems involved.

Keeping these categories separate helps prevent an audit need from automatically becoming a justification for retaining traffic data indefinitely.

• Policy: the rule applied, version, scope, and effective time, if recorded by the system.
• Approval: the decision, approving role, and enough context to understand it.
• Test: method, conditions, result, and known limitations.
• Traffic: operational fields needed for their purpose, assessed separately for potential sensitivity.

Create a Useful, Limited Inventory

The inventory should describe actual data and processes, not a theoretical template. For each data set, identify its purpose, sensitivity, functional owner, source system, users who need access, and relationship to other evidence. If a field has no documented operational or compliance purpose, review whether it needs to be collected or retained.

The available information does not identify a technical source that establishes mandatory fields for reconstructing an A2P routing decision. Therefore, the examples in this guide are design questions, not a standard or regulatory requirement.

• What decision or activity does this data set explain?
• What is its source, and how does it relate to the policy version in effect?
• Does it include content, identifiers, or personal data, or could it be reduced to a reference?
• Who is responsible for maintaining it, and who should be able to access it?
• What dependencies does it have on exports, reports, or third-party systems?

Justify Retention Periods Without Assuming One Universal Period

There is no universal retention period for A2P SMS routing evidence that can be applied without analyzing the context. The duration should be justified by the intended use and checked against the legal, regulatory, and contractual obligations that apply to the parties and jurisdictions involved. The sources available here do not support setting a specific period.

For each category, document why retention is needed, what event starts or ends that need, and who reviews the period. A policy rule may have a different retention need from a traffic record. Avoid automatically copying the general retention period for logs or DLRs: those records may have different purposes and risks.

If a dispute, investigation, or applicable obligation requires information to be preserved, the preservation process should have a defined scope and assigned owners. The organization should determine how that preservation interacts with the ordinary policy and when it can be reviewed or lifted.

• Link each retention period to a documented purpose and verified obligations for the specific case.
• Distinguish ordinary operational retention from any exceptional preservation.
• Review periods when purposes, contracts, applicable regulations, or systems change.
• Do not present an internal recommendation as a universal legal requirement.

Control Access with Defined Permissions

Access should be based on specific tasks. As a design principle, assign permissions by role and grant only what is needed to administer policies, approve changes, analyze incidents, or conduct reviews. Separating the person proposing a change from the person approving it may be useful, but should be tailored to the organization's size, risks, and actual controls.

Log queries and modifications when systems allow it and there is a defined purpose for doing so. These logs are data too: include them in the inventory, limit access, and set a retention review for them. The available evidence does not support claiming that a particular A2P platform provides these controls natively.

• Define roles and permitted actions; avoid broad permissions without justification.
• Review accounts and permissions periodically, especially after role changes.
• Assess the separation of change proposal, approval, and execution.
• Treat access logs as information that also needs a defined purpose and governance.

Design Verifiable Deletion, Including Copies and Exports

A deletion policy should specify what information is erased or made unavailable, who authorizes the operation, how its execution is recorded, and how retention exceptions are handled. Before deleting, check whether applicable obligations or documented preservation requirements affect the data set.

The scope does not necessarily end at the primary repository: review exports, reports, secondary storage, and backups. Do not promise that backups are deleted immediately; their lifecycle and handling depend on each organization's architecture and procedures. If a copy cannot be selectively modified, document how access is controlled and how data that should no longer be available is prevented from being reused.

Verification may rely on evidence of the process—for example, a record of the request, scope, execution, result, and exceptions—provided the technical solution can produce it. Do not claim that a deletion flag means physical removal from all copies without having verified that behavior.

• Identify repositories, exports, and copies before starting the process.
• Record scope, owner, date, result, and any exception.
• Check what “deletion” means technically in each system.
• Define how to prevent information that should no longer be available from being restored or reused.

Respond to an Audit or Dispute with Context and Provenance

A robust response does not depend on accumulating unlimited data, but on being able to explain the origin and meaning of the available evidence. Prepare a procedure for locating the relevant policy version, linking it to the relevant approval and tests, and explaining what traffic data was retained, why, and with what limitations.

If information is missing or a source cannot confirm a fact, say so. For example, distinguish a status reported by a DLR from independently verified receipt on the device. If information is provided to an auditor or counterparty, apply the relevant permissions and contractual and legal restrictions; do not share additional data for convenience.

• Identify who requested the evidence, the scope, and the authority for the request.
• Gather the versions, approvals, tests, and references needed to explain the decision.
• Record the source, period covered, and data limitations.
• Minimize the traffic information shared and document what is provided.

Checklist for Implementing a Reviewable Policy

Start with a limited scope: identify the decision processes you want to be able to reconstruct and the systems involved. Then validate the inventory with operations, security, privacy, and compliance before setting permissions and retention periods.

The policy should be able to change as needs or obligations change. Assign a review owner and retain the rationale for changes; do not turn an initial configuration into a permanent rule without reassessing it.

• Define which decisions and processes the policy covers.
• Inventory data, sources, sensitivity, purpose, and owners.
• Separate decision evidence from general logs, DLRs, and traffic data.
• Justify each retention period based on its purpose and applicable obligations, without imposing a universal period.
• Assign role-based access and review permissions.
• Document exceptional preservation, deletion, backups, and exports.
• Prepare an audit response that preserves provenance and explains limitations.
• Set a periodic review and assign an owner to maintain the policy.