{
  "id": "OPS-256",
  "slug": "ops-256",
  "title": "A recurring programme should expire consent that has gone quiet",
  "statement": "A recurring programme should describe expiring an opt-in after a long period of subscriber inactivity, with one final notification permitted.",
  "rationale": "A subscriber list that only grows eventually consists mostly of numbers that have changed hands, and every one of those is an unconsented message waiting to be sent. Expiry is the cheap version of the reassigned-number problem: it removes the numbers nobody has heard from, which is the same population, without a database lookup. Brands resist it because it shrinks a number they report on.",
  "layer": "OPERATIONAL",
  "layerSlug": "operational",
  "object": "campaign.message_flow",
  "severity": "MEDIUM",
  "detectability": [
    "AI_FORM"
  ],
  "failureClass": "RETRY_FIELD",
  "authorities": [
    "CTIA",
    "AWS"
  ],
  "applicabilityText": "Applies to every 10DLC registration.",
  "universal": true,
  "remediation": "State an inactivity window after which an opt-in expires — eighteen months is the published figure — and describe the single final message that may be sent before removal. Done when the flow says what happens to a subscriber who never engages.",
  "example": "Subscribers with no engagement for 18 months receive one final notice and are then removed from the programme.",
  "notes": "Registration-side twin: the expiry job runs long after approval. What we judge is whether the programme has a policy for it, which is the part a reviewer can also see.",
  "phase": "approval",
  "automated": true,
  "url": "https://ekas.io/rules/10dlc/operational/ops-256/",
  "markdown": "https://ekas.io/rules/10dlc/operational/ops-256.md",
  "registry": "https://ekas.io/rules/10dlc/",
  "updated": "2026-07-25",
  "licence": "CC BY 4.0 — https://creativecommons.org/licenses/by/4.0/"
}
