A2P SMS Routing Policy Changes: Logging, Evaluation, and Rollback

What a change log can resolve—and what it cannot prove

A routing policy determines how a class of traffic is handled within a defined scope. A change log makes it possible to reconstruct which configuration was proposed, who was involved, why it was changed, and when it was due to take effect. Its main value is operational traceability and subsequent review.

A change log does not, by itself, prove that a route improved, that a message was received on a device, or that a change in results was caused by the modification. Assessing impact requires separate measurements, comparable criteria, and a cautious interpretation of concurrent factors.

• Use the history to answer what changed, who approved it, what its scope was, and which version was active.
• Use quality evidence to assess observed results. Link it to the change, but do not combine it with the configuration log.
• Treat results as observations subject to measurement and contextual limitations, not as automatic proof of causation.

Separate rules, provider conditions, and evidence

For a review to be useful, identify the routing rule, applicable operating conditions, and evidence used to assess the change separately. For example, a selected route and its criteria belong to the configuration; restrictions or conditions communicated by the provider should be documented as context; metrics and evaluation samples belong in the quality record.

Do not assume that a provider note, a rule version, and a delivery result are the same kind of evidence. If conditions change over time, record their source and the period to which they apply. This helps avoid comparing apparently identical configurations under different conditions.

• Keep an identifiable version of the rule and describe what behavior changes.
• Record relevant known conditions, their source, and their period of validity, without presenting them as guarantees.
• Link quality reports using references, dates, and scope; keep them as separate records.

Minimum fields for reconstructing a decision

As an operational control practice, each modification should have a unique identifier and a description that allows it to be compared with the previous version. Include the reason, the person responsible for proposing it, who reviewed it, who approved it, and the dates of creation, approval, and effective implementation. These fields are a management recommendation, not a regulatory requirement established by the available sources.

Add the change status—for example, proposed, approved, active, rolled back, or closed—and links or references to the evaluation, approval, and rollback plan. If the change is implemented partially or in stages, document each stage separately.

• Identifier and previous/new version.
• Scope and specific description of the modification.
• Reason and expected outcome, phrased as a testable hypothesis.
• Proposer, reviewers, and approving person or role.
• Proposal, approval, activation, and, where applicable, rollback dates.
• References to reviewed restrictions, evaluation, approval, and post-change checks.

Define the affected destinations, operators, senders, and traffic

A description such as “improve the route” does not show which messages were affected. Define the scope using the dimensions your operation tracks and can verify: destinations, operators where identified, senders, traffic type, and the connection or system involved. Also state exclusions and applicable conditions.

If an element cannot be determined precisely, note that limitation rather than inferring it. A broad change may affect different groups of messages; in that case, divide the scope into units that can be evaluated or explicitly document that the evaluation will be aggregated.

• Record the included destinations and operators at the level of identification actually available.
• Specify relevant senders and traffic classes, such as OTP, transactional, or legitimate, consent-based marketing traffic.
• Describe exceptions, activation conditions, and the systems or connections involved.
• Record what is excluded from the change to avoid overstating its scope.

Review, testing, and approval workflow

A controlled workflow reduces ambiguity between the person proposing a change and the person accepting its activation. The specific sequence depends on the organization; it could be structured around proposal, restriction review, technical evaluation, approval, activation, and monitoring. This sequence should not be presented as a universal official procedure.

Before approval, confirm that the change is scoped, that a recoverable previous version exists, and that post-change checks and the person responsible for responding if something does not work as expected have been defined. If it cannot be tested safely under the available conditions, document that limitation and consider postponing the change or reducing its scope.

• Proposal: record the reason, scope, hypothesis, and starting version.
• Review: check the operational and contractual restrictions the organization knows about for that scope.
• Evaluation: agree on which observations will be reviewed, over what period, and with what limitations.
• Approval: document approval before activation, in line with the applicable internal controls.
• Monitoring: record when the change was activated, who checked the results, and what decision was made.

Compare before-and-after results with caution

The comparison should cover a scope consistent with the change: the same relevant groups of destinations, operators, senders, and traffic, as far as the data allows. Record the observation period, measurement sources, definitions used, and any known incident that could affect interpretation. If conditions are not comparable, say so.

Review several indicators relevant to the operation, such as observed delivery, DLR consistency, latency, or availability, when those data are available and interpreted within their limitations. A reported DLR is not necessarily equivalent to verified receipt on the device. A difference observed after a change does not, by itself, prove that the change caused it.

Frame the result as an observation—for example, “a variation in the defined indicator was observed during the period reviewed.” Attributing a cause would require an evaluation design that reasonably rules out other factors; do not assume a simple before-and-after comparison achieves this.

• Define indicators, sources, periods, and review criteria in advance.
• Keep the scope the same, or document differences that prevent direct comparison.
• Note incidents and simultaneous changes that could influence the results.
• Distinguish reported DLRs from independent confirmation of receipt on the device.
• Record findings and limitations without turning a temporal correlation into causation.

Prepare a verifiable rollback

Plan the rollback before activating a change rather than improvising when an incident occurs. Document which condition will trigger a review or rollback, who can make that decision, who will carry it out, and which reference version would be restored. The condition should be observable and appropriate to the risk; there is no need to invent a threshold if the organization has not defined one.

After a rollback, confirm which configuration is active, when it was applied, and whether the intended scope was restored. Record subsequent observations and any remaining differences. Rolling back a rule does not guarantee that effects already produced will be reversed or that other concurrent incidents will disappear.

• Define the review or rollback condition and who is authorized to trigger it.
• Identify the version to restore and the person responsible for carrying out the action.
• Record the time, scope, and outcome of the rollback.
• Check the active configuration and reassess relevant indicators.

Periodic audits and proportionate record retention

Periodically review a sample of changes to check whether the history makes it possible to reconstruct the decision and whether references to evaluations remain understandable. Look for missing fields, undocumented approvals, changes outside the described scope, and results with no identifiable period or source.

Set record-retention periods according to the operational, contractual, and legal requirements that apply to your organization. No universal duration can be recommended here without knowing the jurisdiction, obligations, and data sensitivity. Limit the content to what is needed for control and restrict access in line with internal policies.

• Check that every active or closed change has a clear status, scope, owners, and dates.
• Verify that quality evidence can be located without confusing it with the configuration.
• Document exceptions and corrective actions.
• Set access and retention in line with applicable obligations, without keeping unnecessary personal data.