cx-erasure-planlisted

# Building a data-subject erasure plan > **Operational guidance, not legal advice.** Whether erasure applies, what > exemptions exist, and what you must retain are jurisdiction- and > sector-specific. Have compliance review the plan before anything is applied. Read-only. It produces a plan for review; a platform mutation skill applies it. ## The two distinctions that determine everything Most erasure implementations get one of these wrong, and both failures are serious in opposite directions. **1. Is the subject the requester, or merely mentioned?** | | Remedy | | --- | --- | | Subject is the **requester** — it is their conversation | You may erase the record | | Subject is **mentioned** in someone else's conversation | **Redact the mention only. Never delete.** | Deleting another customer's conversation because this subject appears in it destroys a different data subject's record and your own legitimate business record. This plan never proposes it, and the applier refuses it even if the plan is hand-edited. **2. Is the conversation open or closed?** On Zendesk — and similarly elsewhere — **comments in a closed conversation cannot be redacted at all.** Most erasure requests land on closed conversations, so this is not an edge case, it is the common case. That produces a four-way matrix, and one cell has no automated remedy: | | Open / solved | Closed | | --- | --- | --- | | **Requester** | Redact the identifying text | Delete the whole conversation — the only optio