cx-subject-access-requestlisted

# Subject access requests against support data A subject access request against a support operation is harder than against most systems, for one reason: **support data is full of other people's personal data, mixed into the same records.** A conversation is about the requester, and it also contains the agent, the third party they mentioned, and sometimes another customer entirely. So there are two failure directions and both are real: - **Under-disclosure** — withholding what the person is entitled to. The failure that generates complaints and regulatory attention. - **Over-disclosure** — releasing a third party's personal data. A breach in itself, and unrecoverable once sent. This produces the material and the redaction proposal. **The response, the legal determination, and the sending are not yours** — they belong to whoever owns data protection. ## Find everything, which is the hard part Support data about one person is scattered, and the parts people forget are usually the ones that matter most to the requester. Search every store, on every identifier: - **Conversations across every channel**, including ones under a different email or phone number. This needs identity resolution, and a SAR is one of the few places where under-matching is a compliance failure rather than a conservative choice. - **Internal notes.** Frequently the part the requester most wants and the part most often omitted. Notes are personal data about them if they are about them, and a