Use when reviewing a data processing agreement (DPA) or data processing addendum to produce a structured risk summary and prioritized issues for attorney review.
When to use
A user asks to "review this DPA," "redline the data processing addendum," or "flag the risks in this data processing agreement."
The organization is being asked to sign a vendor DPA or is preparing its own DPA for a customer.
A DPA has been updated by the other party and the user needs to identify what changed and whether new risks arise.
A DPA is being negotiated and the user wants a structured issue list before the next round.
An internal team (legal ops, procurement, privacy) needs a first-pass risk summary before attorney review.
Due diligence on a transaction requires assessment of the target's data processing arrangements.
Required inputs
The full DPA text (uploaded, pasted, or linked). If the document is not provided, stop and request it. Do not draft a hypothetical review.
The client's role: controller, processor, or sub-processor. If unclear from the document, flag as [CONFIRM: client role] and note that the risk assessment will differ materially depending on the answer.
The main commercial agreement (or a description of it), if available — needed to assess the liability and indemnity interplay. If not provided, note the gap and flag it as an attorney-verification item.
Optional: the applicable privacy framework(s) or regulation(s) the parties have identified (e.g., the DPA references GDPR, CCPA/CPRA, or another framework). Note these as stated in the document; do not independently assert which law applies.
Optional: any prior version of the DPA or a markup showing changes, if this is a revision review.
Optional: the practice group's practice-profiles/privacy.md if it has been populated and is loaded alongside this skill. If present, the skill uses its Standard Positions and Escalation Thresholds tables to benchmark the output and to gate escalation. If absent, the skill proceeds without practice-profile benchmarking and asks the user to supply standing positions inline if needed.
If the DPA text is missing, stop and request it. Never fabricate document terms or infer what a DPA "probably says."
Use when an organization receives a data subject access request (or any data subject rights request) and needs a structured triage, handling record, and response plan for attorney review.
When to use
An individual has submitted a request to access their personal data ("please send me all data you hold about me").
An individual has requested deletion, erasure, or "right to be forgotten" of their personal data.
An individual has requested correction or rectification of inaccurate personal data.
An individual has requested portability of their personal data in a structured, machine-readable format.
An individual has submitted a request to restrict or object to processing of their personal data.
An individual has submitted an opt-out of sale, sharing, or targeted advertising request.
An internal team (legal ops, privacy, compliance) needs a structured intake and handling record for any of the above.
The organization is building or auditing its DSAR intake and response process and needs a template workflow.
A regulator has inquired about the organization's handling of a specific data subject request.
Required inputs
The request itself — the full text or a faithful summary of what the individual submitted, and the channel through which it was received (email, web form, postal mail, in-product form, verbal, etc.).
Date the request was received — required for deadline tracking. If the date is ambiguous, flag as [CONFIRM: date received].
Organization's name and role — whether the organization is a controller, processor, or acting in another capacity with respect to the data in question. If unclear, flag as [CONFIRM: client role].
Optional: the identity information already provided by the requester (name, email, account number, etc.), needed for the identity verification step.
Optional: any prior correspondence with the requester about this or related requests.
Optional: the applicable privacy framework(s) the organization operates under, as confirmed by counsel (e.g., GDPR, CCPA/CPRA, state law). Do not independently assert which law applies.
Adverse context information — any known information about the requester's relationship to the organization beyond ordinary customer or employee status: whether the requester is an adverse party in actual or anticipated litigation, a known regulator or regulatory contact, a journalist, or a representative of a third party with an adversarial interest. Also note whether the organization is aware of any active litigation hold, regulatory inquiry, or anticipated dispute that could intersect with the personal data in scope. If no such context is known, state that explicitly; do not assume it is absent.
Optional: the practice group's practice-profiles/privacy.md if it has been populated and is loaded alongside this skill. If present, the skill uses its Standard Positions, Escalation Thresholds, and Preferred Output Style tables to benchmark the workflow against the group's standing DSAR process. If absent, the skill proceeds without practice-profile benchmarking and asks the user to supply standing positions inline if needed.
If the request text and date received are not provided, stop and request them. Do not fabricate request details.
Use when drafting an internal privacy impact assessment for a new or changed processing activity to document the data involved, design-linked risks, policy consistency, and mitigations for privacy-counsel review.
When to use
A product, engineering, or business team is launching a new feature, vendor integration, or processing activity that involves personal data, and an internal PIA is needed before sign-off.
An existing processing activity is being materially changed — expanded data categories, new access paths, new subprocessors, changed retention, or changed purpose — and the PIA must be updated.
Privacy counsel or a data-protection officer has asked for a PIA draft as an input to their review.
A procurement or legal-ops team needs a structured first-pass assessment before routing to privacy counsel.
Internal policy requires a PIA for new processing activities, and a structured draft is needed to initiate that workflow.
Required inputs
Description of the processing activity: what the feature, system, vendor use, or change does in functional terms. If not provided, stop and request it.
Data categories: the specific fields or data elements involved — not generic labels like "user data" or "personal information." If only generic labels are provided, request specifics before proceeding.
Data subjects: who the personal data relates to (e.g., customers, employees, job applicants, minors, website visitors). If unknown, flag as [CONFIRM: data subjects].
Purpose of processing: the stated business or functional purpose for which the data is collected or reused.
New collection or reuse: whether this activity involves collecting data for the first time or reusing previously collected data for a new purpose.
Access: who within the organization, and which systems, can access the data; whether access is role-restricted.
Storage: where the data is stored (jurisdiction, cloud region, on-premises) and who controls the infrastructure.
Retention period: how long the data is kept and what triggers deletion or archival. If unknown, flag as [CONFIRM: retention period — [deadline verification required]].
Vendors and subprocessors: any third parties that receive, process, or store the data, or that provide infrastructure used to process it.
Failure modes: known or foreseeable failure scenarios — breach, unauthorized access, data loss, misuse, re-identification.
Optional but recommended:
The organization's current privacy policy or privacy notice (used to perform the policy-consistency check in Step 5).
Any prior triage memo, preliminary PIA, or risk log for this activity.
The organization's PIA house style or template preferences (if the output should conform to an internal format).
The practice group's practice-profiles/privacy.md if it has been populated and is loaded alongside this skill. If present, the skill uses its Standard Positions and Preferred Output Style tables to benchmark the PIA against the group's standing template, risk-rating rubric, and approval routing. If absent, the skill proceeds without practice-profile benchmarking and asks the user to supply standing positions inline if needed.
If the description of the processing activity or the data categories are not provided, stop and request them. Never fabricate processing details, invent data fields, or assume purpose from context.
Use when reviewing a published privacy policy or privacy notice to identify gaps, internal inconsistencies, and discrepancies between what the policy says and the organization's described actual data practices.
When to use
A user asks to "review our privacy policy," "find gaps in this privacy notice," or "does our policy match what we actually do."
An organization is updating its privacy policy and wants a first-pass review before attorney review and redrafting.
A privacy audit or assessment requires a document review of the current privacy notice.
An organization has changed its data practices (new vendor, new product feature, new data collection) and needs to identify whether the policy needs to be updated.
Due diligence on a transaction requires review of the target's public-facing privacy representations.
A regulator or counterparty has raised concerns about the organization's privacy policy and the legal team needs a structured analysis.
The organization operates in multiple jurisdictions and wants to identify disclosure topics that may need to be addressed for different audiences [CONFIRM: applicable requirements with counsel].
Required inputs
The privacy policy or privacy notice text — uploaded, pasted, or linked. If not provided, stop and request it. Do not fabricate or assume policy terms.
A description of the organization's actual data practices — what personal data is collected, from whom, for what purposes, who it is shared with, how it is processed, and how long it is retained. This description must come from the user; do not invent practices. If this description is not provided, the practice-versus-policy comparison step cannot be completed — note the gap and proceed with a structural review only, flagging the comparison as an open item.
Optional: the organization's industry or sector (e.g., healthcare, financial services, children's services, e-commerce) — relevant for identifying sector-specific disclosure topics to flag, though applicable law is always [CONFIRM].
Optional: the audience or jurisdictions the policy is intended to serve (e.g., EU residents, California residents, global) — used to identify disclosure topics commonly associated with those audiences, not to assert applicable law.
Optional: a prior version of the policy, if this is a revision review.
Optional: the practice group's practice-profiles/privacy.md if it has been populated and is loaded alongside this skill. If present, the skill uses its Standard Positions and Source-of-Truth Documents tables to benchmark the policy against the group's baseline policy template. If absent, the skill proceeds without practice-profile benchmarking and asks the user to supply standing positions inline if needed.
If the policy text is missing, stop and request it. If the description of actual practices is missing, proceed with structural review only and flag the practice comparison as incomplete.