Use when a privacy or security incident is suspected or confirmed — unauthorized access, ransomware, a lost device, a misdirected disclosure, an exposed database, or a vendor-reported incident — and counsel needs the incident organized: an incident-facts intake, a reportability question set, a notification-obligation inventory, contractual notice mapping, a working chronology, and an evidence-preservation checklist.
When to use
A security, IT, or engineering team reports suspected or confirmed unauthorized access to systems or data.
A ransomware, extortion, or data-theft event has occurred or is suspected.
A device has been lost or stolen, an email or file has been misdirected, or a database, bucket, or endpoint has been found exposed.
A vendor, processor, or sub-processor has notified the organization of an incident affecting data processed on its behalf.
Counsel has asked for the incident organized: a facts intake, a chronology, a notification-obligation inventory, and a preservation checklist.
The organization needs contractual incident-notice obligations pulled from its DPAs, vendor contracts, and customer contracts after an incident.
An incident-response tabletop or post-incident review needs the same structured working file built from a hypothetical or historical fact pattern (use fictional or anonymized facts only).
Required inputs
The incident description as currently understood — what happened, how it was discovered, the suspected vector, and containment status. Incident facts evolve; record them as user-supplied facts as of a stated date and time, and mark the record as provisional.
The discovery date and any other candidate trigger dates (occurrence date if known, vendor-notice date, confirmation date), each as a user-supplied fact. If any date is ambiguous, flag it [CONFIRM: trigger date] — do not infer it.
The data elements, populations, and systems believed affected — categories of personal data, data subject groups and geographies, and systems involved, with counts labeled as estimates where they are estimates.
The privilege posture — whether the investigation is being conducted at the direction of counsel, and who is directing it. If unknown, flag [ATTORNEY TO CONFIRM: privilege structure for this investigation] and route to counsel before the working file is circulated.
Optional: DPAs, vendor contracts, and customer contracts containing incident- or breach-notice obligations — required for the contractual notice map; without them that section is a gap, not a guess.
Optional: the cyber-insurance policy or a summary of its notice provisions.
Optional: the incident response plan and any forensic or investigation reports produced so far.
Optional: the practice group's practice-profiles/privacy.md if it has been populated and is loaded alongside this skill. If present, use its Standard Positions and Escalation Thresholds to benchmark the workflow; if absent, proceed without profile benchmarking.
If the incident description or the discovery date is missing, stop and request them. A suspected incident is time-critical: state prominently that the matter should be routed for immediate attorney attention (see core/jurisdiction-and-deadline-gates.md), and do not let intake work delay that routing.
Use when reviewing a product or service that may attract minors to organize audience-analysis facts, age-gating and parental-consent mechanics, data-minimization and profiling facts, and cross-jurisdiction age-threshold divergence for attorney review.
When to use
A product, app, game, or online service is being reviewed for whether children's-privacy obligations may apply.
A product team is designing or has implemented an age gate, age-assurance mechanism, or parental-consent flow and wants the mechanics organized for legal review.
A launch review, feature review, or marketing-claims review has surfaced signals that minors may be part of the actual or likely audience.
The organization operates or is evaluating a school-facing or edtech product and needs the school/education context flagged for specialized review.
A vendor, partner, or internal team raises a concern that underage users may be present despite the stated age gate or terms of service.
The organization needs a periodic children's-privacy fact review as part of a broader privacy or product-legal audit.
Required inputs
A description of the product or service — its functionality, how it is accessed (web, app, in-person, school-issued device), and its stated intended audience.
Audience-analysis facts — content, subject matter, visual design, marketing channels, user testimonials or reviews, app-store category, influencer or ambassador programs, and any usage or analytics data bearing on the actual or apparent audience. Provide these as facts; do not ask the skill to infer an audience from a bare product name.
The age-gating mechanics as implemented or designed — whether there is an age screen, self-declaration, neutral age screen, or a technical age-verification or age-estimation method, and how it behaves (e.g., what happens on a "too young" answer).
The parental-consent flow, if any — how it is triggered, what is collected from the parent, how consent is verified, and what happens if consent is withheld or not obtained.
Data practices — what personal data is collected from users, what the default settings are (visibility, sharing, notifications, geolocation), and whether profiling, personalization, recommendation systems, or targeted/behavioral advertising are used and whether minors are excluded from them.
School/edtech context — whether the product is offered directly to consumers, through a school or district, under an operator/school agreement, or as an instructional tool, and who is understood to be the contracting party.
Optional: any known instance of actual knowledge of underage use inconsistent with the stated audience or age gate — for example, a support ticket, a parent complaint, or internal data suggesting users below the stated minimum age.
Optional: the practice group's practice-profiles/privacy.md if populated and loaded alongside this skill. If present, use its Standard Positions and Escalation Thresholds to benchmark the review; if absent, proceed without profile benchmarking.
If the product description and audience-analysis facts are not provided, stop and request them. Do not infer audience, age-gating behavior, or data practices from assumption or model background knowledge of similar products.
Use when reviewing a website or app's cookie and tracking consent implementation to inventory trackers against disclosure, describe consent-banner mechanics, record consent-record facts, and flag dark-pattern and cross-border divergence issues for attorney review.
When to use
A website or app's cookie banner, tracker inventory, or consent flow needs a first-pass legal/compliance read.
A privacy or marketing team has run a tracker scan and needs the results compared against the cookie notice or privacy policy.
The organization is evaluating or has just deployed a consent management platform (CMP) and wants its configuration facts organized for review.
A regulator inquiry, complaint, or internal audit has raised a question about whether disclosed and actual tracking match, or whether the consent flow gives users a genuine choice.
The organization operates across multiple markets and needs the site's consent mechanics checked for jurisdiction-specific divergence (for example, prior-consent vs. opt-out models, or reject-parity requirements).
A redesign of the cookie banner or consent flow is proposed and the current-state facts need to be captured before changes are made.
Required inputs
The tracker inventory or scan output — a list of cookies, pixels, SDKs, and other tracking technologies actually present on the site or app, ideally from a scan tool or manual audit, including the technology name, vendor, and stated category (essential, functional, analytics, advertising, etc.), if categorized. Do not proceed on a description of "we use some cookies" alone.
The cookie/tracking disclosure text — the cookie notice, cookie policy, or the tracking section of the privacy policy, in full.
A description or screenshots of the consent banner — its timing (does tracking occur before a choice is made), the choices actually offered (accept all, reject all, customize, close/dismiss), the visual layout and prominence of each choice, and any pre-checked boxes or pre-selected categories.
Consent-record-keeping facts — what the organization logs when a user makes a choice (timestamp, choice made, banner version, user/device identifier), where the record is stored, and the stated retention period for consent records.
Optional: whether a CMP or IAB TCF-style framework is in use, and which one.
Optional: the geographies/markets where the site or app operates, so cross-border divergence can be flagged against the actual footprint rather than assumed.
Optional: the practice group's practice-profiles/privacy.md if populated and loaded alongside this skill. If present, use its Standard Positions and Escalation Thresholds to benchmark the review; if absent, proceed without profile benchmarking.
If the tracker inventory and the disclosure text are not both provided, stop and request them. Do not infer the tracker inventory from the disclosure text, or vice versa — comparing the two is the point of the review.
Use when reviewing a proposed or existing cross-border transfer of personal data — a new vendor hosted abroad, an intercompany data flow, an offshore support model, or a transfer-clause exhibit — to inventory the data flows, map the claimed transfer mechanisms, organize a transfer-impact-assessment fact pattern, flag onward transfers and sub-processor chains, and produce a gap list for attorney review.
When to use
A new vendor, hosting arrangement, or support model would move personal data to another country, and counsel needs the flows and claimed mechanisms organized before assessing them.
An intercompany or intragroup data flow (shared HR systems, centralized CRM, global analytics) crosses borders and needs a structured review.
A DPA's transfer exhibit, standard-contractual-clauses-style annexes, or an equivalent transfer addendum has been provided and the team needs the flows, roles, and annex completeness inventoried.
Counsel has asked for the fact pattern for a transfer impact assessment — data categories, destination, importer commitments, supplementary measures — organized for attorney completion.
An existing transfer is being re-reviewed after a change: a new destination, a new sub-processor, a changed mechanism, or an updated annex.
Diligence on a vendor or transaction surfaced cross-border flows that need mapping before contract or closing.
Required inputs
The documents describing the transfer — DPAs, transfer-clause exhibits and their annexes, intercompany agreements, vendor contracts, security summaries, or data-flow diagrams. Work only from what is provided; if the transfer is described orally, record the description as user-supplied fact and list the missing documents as gaps.
The parties to each flow — the exporter and importer entities and their claimed roles (controller, processor, sub-processor). If roles are unstated or unclear, flag [CONFIRM: party roles].
The origin and destination countries for each flow, as stated in the documents or by the user. Do not infer a destination from a vendor's brand or headquarters; if a destination is not stated, flag [CONFIRM: destination country].
The business purpose of the transfer and the client's posture — whether the client is the exporter, the importer, or sits on both sides of an intragroup flow.
Optional: any existing transfer impact assessment or supplementary-measures analysis — recorded as a provided document whose claims are attributed, not adopted.
Optional: sub-processor lists and onward-transfer disclosures — needed for the chain map; without them the chain is a flagged gap.
Optional: the practice group's practice-profiles/privacy.md if it has been populated and is loaded alongside this skill. If present, use its Standard Positions and Escalation Thresholds (for example, standing posture on mechanism types or destination escalations) to benchmark the review; if absent, proceed without profile benchmarking.
If no transfer-describing documents and no user-supplied flow description are provided, stop and request them. Never reconstruct a transfer arrangement, an annex, or a mechanism from memory or from what such documents "usually" say.
Use when reviewing a draft or existing data retention schedule to inventory data categories against stated purposes, collect retention-period facts, flag legal-hold interactions, and surface orphaned-data and vendor-coverage gaps for attorney review.
When to use
The organization has a draft retention schedule and wants it checked for internal consistency and completeness before adoption.
An existing retention schedule needs a periodic review against the current data inventory.
A privacy, records-management, or legal-ops team wants retention periods, legal bases, and deletion mechanics organized for attorney sign-off.
A DSAR, audit, or regulatory inquiry has surfaced a question about how long a data category is actually kept versus what the schedule says.
Counsel needs to understand how a proposed litigation hold or preservation notice would interact with the standing retention schedule.
Required inputs
The retention schedule itself — the draft or existing document, spreadsheet, or policy text, provided in full. Do not review from a description alone.
The data inventory or record of processing activities, if one exists, so categories in the schedule can be checked against what the organization actually processes. If none is available, note the gap — this review cannot independently verify that the schedule is complete against actual data holdings.
The stated purpose for each retention period — business need, legal/regulatory requirement, or contractual obligation, as the organization or the schedule states it. Do not supply a purpose the skill infers from category name alone.
Optional: known legal holds or preservation obligations currently in effect, so hold-override interactions can be flagged.
Optional: vendor and backup system inventory — third-party processors, backup and archive systems, and disaster-recovery copies that may hold the same data categories outside the primary system.
Optional: the practice group's practice-profiles/privacy.md if populated and loaded alongside this skill. If present, use its Standard Positions and Escalation Thresholds to benchmark the review; if absent, proceed without profile benchmarking.
If the retention schedule text is not provided, stop and request it. Do not reconstruct or assume schedule content, category names, or retention periods.
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.
Use when running pre-contract or renewal privacy diligence on a vendor, processor, or sub-processor — a security questionnaire has come back, a new tool is proposed, or procurement asks for a privacy read — to inventory the vendor's claimed privacy posture, map data categories and purposes against the client's requirements, build a risk and gap table, and package follow-up questions and contract-term asks for attorney review.
When to use
Procurement or a business team proposes a new vendor or tool that will process personal data, and counsel wants a privacy read before contracting.
A vendor's completed security or privacy questionnaire has come back and needs to be organized against the client's requirements.
A vendor is being re-reviewed at renewal, after an incident, after an acquisition, or because its role or the data scope has expanded.
A processor proposes a new sub-processor and the client's approval workflow requires a diligence pass.
Counsel wants a follow-up question list and contract-term asks assembled before DPA negotiation begins.
Diligence on a transaction surfaced a target's key vendors and the privacy posture of each needs a first-pass organization.
Required inputs
The vendor diligence materials — completed questionnaires, certification summaries or attestation reports, privacy notices, sub-processor lists, security summaries, data-flow descriptions, or the vendor's trust-center exports. Work only from what is provided; a vendor described from memory or reputation is not diligence.
What the vendor will process — the data categories, data subject groups, and processing purposes, as stated by the user or the documents. If the data scope is unstated, flag [CONFIRM: data scope] and treat scope-dependent findings as provisional.
The client's requirements baseline — internal vendor-privacy standards, a diligence checklist, or requirements stated inline by the user. If no baseline is provided, say so, organize the review around the gaps the materials themselves reveal, and flag every "requirement" framing as [CONFIRM: client requirement] — do not invent a standard the client never adopted.
The engagement context — what the vendor is hired to do and the client's own role for this processing (controller, processor, or both). The same vendor answer can be fine for one role and a gap for the other.
Optional: the draft contract or DPA, if one exists — reviewed here only to note where diligence findings should become negotiated terms; the document review itself belongs to dpa-review.
Optional: the prior diligence file for renewals — so the output can record what changed.
Optional: the practice group's practice-profiles/privacy.md if it has been populated and is loaded alongside this skill. If present, use its Standard Positions and Escalation Thresholds to benchmark vendor answers; if absent, proceed without profile benchmarking.
If no vendor materials are provided at all, stop and request them. Do not assemble a diligence read from general knowledge about the vendor or its industry.