A ChatOps auditor bot stores Webex message bodies and location observations for troubleshooting. Which storage-privacy control limits long-term blast radius?
Select an answer to reveal the explanation.
Short Explanation
Old ChatOps bodies and location crumbs are still privacy fuel if you never throw them out. A retention and deletion policy shrinks how big a leak can become.
Full Explanation
Retention and deletion policies ensure location and message data do not live indefinitely. Finite retention limits how much personal content an incident can expose and aligns storage with the stated civic purpose rather than accidental forever-archives. Keeping every observation and message body forever to maximize “forensic nostalgia” maximizes privacy risk without a defined operational need and complicates e-discovery scope. Disabling deletion APIs so operators can never reduce stored personal content blocks lawful deletion and routine hygiene workflows when a citizen or policy demands removal. Treating retention as irrelevant because ChatOps bodies are “never considered stored data” is false once logs, search indexes, or databases persist those bodies beyond the chat UI. Exam caveat: deletion must cover replicas—search indexes, backups, and cold storage—or “deleted” primary rows still linger in secondary copies that auditors will find. Operational check: insert a labeled test ChatOps or location record, wait for the policy window or trigger deletion, and confirm both primary and secondary stores no longer return that payload. Record the outcome in the release or incident notes so the next operator inherits evidence, not tribal knowledge.