Module 5 · Privacy tour

Privacy on the clock: privacy-legal

34 min

What it does

Where litigation-legal runs a docket and commercial-legal reviews contracts, privacy-legal runs a privacy program. In its own words, it “triages processing activities, generates PIAs, reviews DPAs as controller or processor, drafts DSAR responses within statutory timelines, and monitors policy drift against practice.”

Two words in there do a lot of work. “As controller or processor”: the same plugin gives near-opposite advice depending on which side of the data you sit on — and getting that backwards inverts every recommendation. And “within statutory timelines”: privacy work runs on clocks the law sets, not deadlines you choose. This module is built around one of those clocks.

Source: plugin.json · privacy-legal/ on GitHub

Under the hood

Nine skills, grouped by job — the full inventory is in the privacy-legal fact sheet; three ideas define the plugin:

Controller or processor — the question that decides everything

Before it reviews a single clause, the plugin asks whose data is this, and are we the one who decides what happens to it (controller) or the one handling it for someone else (processor)? The dpa-review skill keeps two near-opposite playbooks — what you require as a controller vs. what you accept as a processor — and the skill is blunt that “getting this wrong inverts every recommendation.” Sablefield is both: a controller of its app users' data, a processor of some data on its customers' behalf. You'll feel that split in the Guided exercise, when it turns out the request might not even be Sablefield's to answer.
Source: dpa-review skill

The clock — privacy runs on the law's calendar, not yours

A data-subject access request (DSAR) arrives, and a statutory deadline starts running the day it lands — not the day you verify who sent it, not the day you get around to it. The dsar-response skill enforces that with a rule it states plainly: send two letters, not one — a prompt acknowledgment now, then the substantive response by the deadline — because “a single combined letter sent on day 45 is a process failure.” The clock is the spine of this module.
Source: dsar-response skill

No research connector — so the plugin makes its uncertainty loud

Privacy law moves fast and varies by state and country, but privacy-legal bundles no case-law or statute connector (just Slack and Google Drive). It compensates honestly: every cite it can't verify is tagged [model knowledge — verify], stable references carry a dated [settled — last confirmed 2026-05-10]-style stamp, and the plugin ships a references/currency-watch.md list of the rules most likely to have moved since training. The reviewer note's Sources line is the one place this status lives — so you always know whether a deadline came from a live source or from memory.
Source: .mcp.json · privacy-legal/CLAUDE.md

№ The story — a request lands, and the clock starts

An email hits privacy@sablefield.com. Renata Calderón, a maintenance technician who uses the Sablefield GripSense app on the warehouse floor — at a Tellermark Health fulfillment site in California — writes: “Send me everything you have on me, then delete my account.” She's exercising her California privacy rights, she mentions the legal deadline, and she's writing from her personal email, not the one on her account. The clock just started. Go.

Guided — answer the DSAR before the clock runs out

Guided · from inbox to acknowledgment letter

You'll need the plugin installed. No setup handy? Read along — the exhibit shows what you'd see.

1. Install and set up — same rule as every plugin: nothing works before the setup interview. This is two steps, not one (you added the marketplace back in Module 1). First, install the plugin:

/plugin install privacy-legal@claude-for-legal

Then load the plugin — type /reload-plugins (or close and reopen Claude Code). It isn't live until you do; if your next command comes back “command not found,” this is the step you skipped. Now run the setup interview — it asks “quick or full?”; take the 2-minute quick version (a handful of questions — who you are, your role, which side of a DPA you sit on, which regulations apply, and what's connected):

/privacy-legal:cold-start-interview

No privacy practice of your own? Play the part — answer as Sablefield's lawyer:

Quick version, please. I'm a lawyer, in-house — the only one at Sablefield Robotics (Series-B industrial robotics, Delaware corp, Nashville HQ). We're mostly a data controller — our robots stream telemetry to a mobile app, and we hold app-user and employee data — but also a processor of some data on our customers' behalf. Regulations that apply: GDPR (small EU team + EU customers) and CCPA/CPRA (California operations). Documents in Google Drive, Slack in use; no privacy tooling like OneTrust connected.

One thing quick setup won't know: where user data actually lives. So before the DSAR skill can search, it has to ask you — and the last line of the prompt in step 3 answers it.

2. Get the request — the email Renata just sent:

⬇ Calderón DSAR email (Word) or plain text (.md)

3. Run the DSAR workflow. Send the command on its own:

/privacy-legal:dsar-response

Then attach the email and tell it: “Handle this DSAR — we're Sablefield. Walk the request through classify, verify, locate, and exemptions, and draft what goes out today. Where does our app-user data live? The GripSense app backend, the telemetry store, support tickets in Zendesk, and the HR system.” (That last part tells it where to look.)

4. Watch what it does before drafting. It classifies the request, checks identity, finds the clock, and surfaces two things a hurried human would miss — that the sender's email doesn't match the account, and that the data might be Tellermark's to control, not Sablefield's. Here's what comes back, shortened for the page:

Exhibit — the internal analysis, then the letter that goes out today

PRIVILEGED & CONFIDENTIAL — ATTORNEY WORK PRODUCT — PREPARED AT THE DIRECTION OF COUNSEL
(internal analysis — the outbound letter below carries no such header)

⚠️ Reviewer note
• Sources: no research connector connected — CCPA timing and exemptions are from training knowledge [verify before relying].
• Classified: two rights — access and deletion. They're handled on one clock but are separate obligations.
• Clock: running from receipt (June 24, 2026), not from identity verification — generally 45 days under CCPA, one 45-day extension available with notice [verify the deadline and section cites].
• Identity [review]: the sender (r.calderon.work@gmail.com) does not match the account email on file (rcalderon@tellermark-health.com) — verify identity before disclosing anything.
• Whose data? [review]: the app is used at a Tellermark fulfillment site — this may be data Sablefield processes for Tellermark as controller. If so, the DPA likely says forward the request to Tellermark. Confirm our role before responding.
• Exemptions [review]: the “internal notes about my performance” may include other people's PII (redact) and possibly HR-investigation or privileged material — flagged for your call, not withheld on the skill's own say-so.
• Before relying: confirm our role (controller/processor) and the systems to search; verify the CCPA deadline and cites.

Two letters, not one. A prompt acknowledgment goes out now; the substantive response (the data, or a reasoned refusal) by the deadline. Draft of the acknowledgment:

Outgoing — acknowledgment letter (no work-product header; this one is external)

Dear Ms. Calderón,

Thank you for your message of June 24, 2026. We are treating it as a request to (1) access the personal information Sablefield holds about you and (2) delete it, under the California Consumer Privacy Act. We have logged it as received on June 24, 2026.

To protect your information, we first need to verify your identity, because your message came from an email address that doesn't match the one on your account. We'll follow up shortly with how to do that. Verifying does not pause the legal clock — your request is already on it.

We'll respond substantively within the time the law allows (generally 45 days, with one possible extension we would tell you about).

One note: some data you use the app with may be controlled by your employer rather than by Sablefield. If that's the case for any part of your request, we'll tell you and point you to the right contact. — Sablefield Privacy Team

Condensed for the page; the steps are the skill's own — classify → verify → locate → exemptions → draft, two letters: dsar-response. Your run's judgments will differ — that's what the [review] flags are for. The skill drafts; it does not send.

5. Notice the three moves a checklist alone wouldn't make: the clock started on receipt, not verification; the identity mismatch stops the disclosure, not the clock; and the “whose data is this?” question may hand the whole request to Tellermark. The acknowledgment goes out today; the hard work — locating the data and ruling on exemptions — happens against the deadline.

Stretch — the same paper from both sides, then a feature that trips the policy

Stretch · controller vs. processor, and triage → PIA

Each push reuses the plugin you set up and exercises a different skill. Run any one on its own to see what it does.

Stretch 1 — review a DPA where you're the processor. Tellermark Health (your customer) sends its data-processing terms for you to sign — here, Sablefield handles data on Tellermark's behalf. Grab it and review against your processor positions:

⬇ Tellermark → Sablefield DPA (Word) or .md

/privacy-legal:dpa-review

Then: “Review this DPA — we're Sablefield, the processor here.” Watch it detect your side, then flag the 24-hour breach-notice window (tighter than you can meet), the per-subprocessor veto, the uncapped data-breach liability — and the one a hurried read misses: PHI is in play at a health customer, but there's no BAA / HIPAA flow-down, which the skill treats as a defect, not a nicety.

Stretch 2 — the same skill, the other side of the table. Now you're the controller: Wickline Perception, your AI-vision vendor, processes your robot-camera frames. Review its addendum and watch the findings invert:

⬇ Wickline → Sablefield DPA (Word) or .md

/privacy-legal:dpa-review

Then: “Now we're the controller — Wickline is our vendor processing our camera frames. Review their addendum.” The marquee move: strike “Processor may use Customer Data to train its models.” Plus a 🔴 for no international-transfer mechanism (Wickline stores wherever it likes, no SCCs), “industry-standard security” with no annex, and no subprocessor list. Same plugin, opposite playbook.

Stretch 3 — triage a new feature, then write its PIA. Product wants to ship “FloorSight” — always-on video and location, streamed to the app, shared with Wickline to train its model, kept forever. Is that a problem? Triage it first:

⬇ FloorSight product brief (Word) or .md

/privacy-legal:use-case-triage

Then: “Triage this FloorSight feature — we're Sablefield.” Watch the four-way verdict (PROCEED / PIA REQUIRED / DPIA MANDATORY / STOP) and the STOP on policy conflict — continuous video and precise location aren't in your published policy. Then take its offer to roll straight into the assessment:

/privacy-legal:pia-generation

Notice three things: the triage's risk rating carries into the PIA as a floor (it can't quietly become low); the PIA surfaces the bystanders — warehouse staff and visitors who never installed the app; and it ends on the rule that one of the policy or the feature has to change before launch.

Free play

Free play · break it on purpose
  • Watch the drift appear. Grab Sablefield's published privacy policy (.md), then run /privacy-legal:policy-monitor and ask “does our published policy cover FloorSight?” See the REQUIRED gaps it surfaces: the missing video/location category, “we do not sell or share” against the Wickline training-share, the stale App Store privacy label, and the retention mismatch.
  • Point it at a moving law. Run /privacy-legal:reg-gap-analysis against a new state privacy law (or the 2025 COPPA amendments) — watch it scope first (“does it even apply to us?”), diff against your policy, and flag the highest-fabrication-risk cites (effective dates, section pinpoints) loudly, precisely because no research connector is wired in.
  • Try to make it misbehave. Run /privacy-legal:customize and attempt to set a DSAR deadline below the legal minimum, or to delete a whole section — and watch it refuse and explain why.
  • Off the menu, on purpose. /privacy-legal:matter-workspace does nothing for Sablefield — matter workspaces are for multi-client firms and are off for in-house. (Cumberland & Ross, the outside firm, is who'd use it.)

Check your understanding

Lab notebook

Governance note — the clock, and the call, are yours

Three privacy-specific things to carry from this module. First, external letters go out without the privileged header, and the plugin drafts but never sends — the DSAR acknowledgment and the substantive response are addressed to a data subject, so a licensed human verifies identity, confirms the legal call, and hits send. Second, that PRIVILEGED & CONFIDENTIAL — ATTORNEY WORK PRODUCT header on the internal analysis is a US doctrine — it does not exist in most of the world, and it will not shield a DPIA or privacy analysis from an EU regulator. For a company like Sablefield with an EU footprint, the marking means confidentiality, not immunity. Third, because the plugin bundles no research connector, every statutory deadline and section cite defaults to [model knowledge — verify] — the Sources line tells you so, and verifying the clock against the actual statute is the reviewer's job, not the tool's.

And the rule that never goes away: the analysis, the acknowledgment, the deletion decision — every one is a draft for attorney review.
Source: privacy-legal/CLAUDE.md (Outputs / work-product header) · dsar-response skill

Going deeper: the privacy-legal fact sheet has the full nine-skill inventory, the connector list, and the state it keeps on your machine.