Skills Compliance
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.
npx rulebase-skills install cx-subject-access-requestWhen to use it
Reach for this when someone says any of these — they are the phrases the skill itself triggers on:
- “handle this SAR”
- “subject access request”
- “customer wants all their data”
- “a customer asked for their call recordings”
How it works
The method, in the order the skill runs it. The full procedure — tables, worked examples and the edge cases — is in the skill itself.
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.
Employee SARs are the sharper case
An employee — or a former one — requesting their own data will typically want QA evaluations, coaching records, performance documentation and any internal discussion about them. This lands differently from a customer SAR.
Third-party data: the redaction decision
The general position is that the requester is entitled to their own personal data, not to someone else's. In a support transcript these are interleaved line by line, so: Third parties the requester named.
The exemptions are not yours to apply
Most regimes have exemptions — legal privilege, ongoing investigations, crime prevention, management forecasting, others — and some allow refusal of manifestly excessive requests.
Related skills
Free and open source, and vendor-neutral — it reads the conversations from whichever helpdesk you already run. Browse all 149 skills · connect your helpdesk over MCP · source on GitHub
