Use this skill when implementing GDPR or CCPA compliance, designing consent management, conducting DPIAs, or managing data processing agreements. Triggers on GDPR, CCPA, data privacy, consent management, DPIA, data subject rights, privacy policy, cookie consent, and any task requiring privacy regulation compliance or data protection design.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
name
privacy-compliance
version
0.1.0
description
Use this skill when implementing GDPR or CCPA compliance, designing consent management, conducting DPIAs, or managing data processing agreements. Triggers on GDPR, CCPA, data privacy, consent management, DPIA, data subject rights, privacy policy, cookie consent, and any task requiring privacy regulation compliance or data protection design.
Privacy by design - Build privacy controls into the architecture from day
one. Data minimization, access controls, and audit logs are structural decisions,
not features added after launch. Retrofitting is expensive and incomplete.
Data minimization - Collect only what you need, retain it only as long as
necessary, and delete it on schedule. Every field in your database is a liability
if you cannot justify its purpose and retention period.
Lawful basis for processing - Every processing activity must have a documented
lawful basis (GDPR) or a disclosure obligation (CCPA). "We might need it someday"
is not a lawful basis. Document the basis before you collect the data.
Transparency - Users must understand what data you collect, why, how long you
keep it, and who you share it with. Privacy policies must be readable, not a legal
wall. Consent must be informed to be valid.
Accountability - Maintain records of processing activities (RoPA), run DPIAs
for high-risk processing, appoint a DPO when required, and respond to data subject
requests within statutory deadlines. Compliance is a continuous process, not a
one-time audit.
Core concepts
GDPR vs CCPA at a glance
Dimension
GDPR (EU/EEA)
CCPA / CPRA (California)
Scope
Any org processing EU/EEA residents' data
Businesses meeting revenue/data thresholds serving CA residents
Opt-out for sale/sharing; opt-in for sensitive data (CPRA)
Data subject rights
Access, rectification, erasure, portability, restriction, objection, no automated decision
Know, delete, correct, opt-out of sale/sharing, limit sensitive data use, non-discrimination
Response deadline
30 days (extendable to 90 days)
45 days (extendable to 90 days)
Breach notification
72 hours to supervisory authority; notify individuals if high risk
Reasonable time; private right of action for breaches
Penalties
Up to 4% global annual turnover or €20M
Up to $7,500 per intentional violation
DPO required
For large-scale systematic processing or sensitive data
No equivalent role required
Cross-border transfers
SCCs, adequacy decisions, BCRs required
No equivalent mechanism required
Lawful bases for processing (GDPR Art. 6)
Basis
When to use
Gotcha
Consent
Marketing, non-essential cookies, optional features
Must be withdrawable; withdrawal must be as easy as giving it
Contract
Processing necessary to fulfill a contract with the user
Can only cover what is genuinely necessary for the contract
Legal obligation
Tax records, fraud reporting mandated by law
Must be a specific law, not a vague compliance claim
Vital interests
Emergency medical situations
Rarely applicable outside health contexts
Public task
Government and public authority processing
Not applicable to most private organizations
Legitimate interests (LI)
Analytics, fraud prevention, direct marketing (with caveats)
Must pass LI Assessment (LIA) - user interests must not override yours
Data subject rights
Right
GDPR
CCPA/CPRA
Implementation note
Right to know / access
Art. 15
Yes
Export all personal data in a portable format
Right to rectification / correction
Art. 16
CPRA only
Update incorrect data across all systems
Right to erasure ("right to be forgotten")
Art. 17
Yes
Cascade deletes across primary store, replicas, backups, third-party processors
Right to portability
Art. 20
Yes (categories + specific pieces)
Machine-readable format (JSON, CSV)
Right to restriction of processing
Art. 18
No
Freeze processing while dispute is resolved
Right to object
Art. 21
Opt-out of sale/sharing
Especially for direct marketing and LI-based processing
No automated decision-making
Art. 22
No
Human review option for decisions with legal/significant effects
Cross-border transfer mechanisms
Mechanism
Use when
Adequacy decision
Transferring to a country the EU Commission has approved (e.g., UK post-IDTA, Japan, Canada)
Standard Contractual Clauses (SCCs)
Most common for transfers to non-adequate countries (e.g., US). Use 2021 SCCs.
Binding Corporate Rules (BCRs)
Intra-group transfers within a large multinational; requires DPA approval, lengthy process
Derogations (Art. 49)
Narrow exceptions: explicit consent, performance of contract, vital interests. Not for systematic transfers.
Common tasks
1. Implement a GDPR compliance checklist
Use this as a product/engineering launch gate:
Data inventory
Record of Processing Activities (RoPA) created and up to date
Lawful basis documented for each processing activity
Retention periods defined for each data category
Third-party processors identified; DPAs signed with each
Technical controls
Personal data encrypted at rest and in transit
Access to personal data is role-based and audited
Pseudonymization applied where full identification is not needed
Automated deletion jobs scheduled per retention policy
User-facing obligations
Privacy policy published, accessible, and up to date
Cookie consent mechanism in place (see task 2)
Data subject request workflow implemented (see task 4)
Age verification where required (special categories, children's data)
Organizational
DPO appointed (if required) and contact details published
Data breach response procedure documented and tested
DPIA completed for high-risk processing activities (see task 3)
Staff privacy training completed
2. Design consent management (cookie banners and preference center)
The consent bar is higher than most implementations meet. For GDPR, pre-ticked
boxes, bundled consent, and making "reject" harder than "accept" are all invalid.
Cookie categories to surface to users:
Category
Examples
Requires consent?
Strictly necessary
Session auth, load balancing, CSRF tokens
No - but must disclose
Functional / preferences
Language, theme, remembered settings
Yes (GDPR), disclose (CCPA)
Analytics / performance
Google Analytics, Heap, session recording
Yes (GDPR), opt-out (CCPA)
Marketing / advertising
Ad pixels, retargeting, cross-site tracking
Yes (GDPR), opt-out of sale (CCPA)
Implementation requirements:
Banner must:
- Appear before any non-essential cookies are set
- Present accept and reject options with equal prominence
- Link to full privacy policy and cookie policy
- Allow granular category-level choice (not just accept all / reject all)
- Record consent with timestamp, version, and signal (for audit)
Preference center must:
- Be accessible from footer at any time
- Allow withdrawing consent as easily as giving it
- Persist preferences across sessions (store in first-party cookie or server-side)
- Respect GPC (Global Privacy Control) signal for CCPA opt-out
3. Conduct a DPIA (Data Protection Impact Assessment)
A DPIA is mandatory under GDPR Art. 35 when processing is likely to result in a
high risk to individuals. Always required for: systematic profiling, large-scale
sensitive data processing, systematic monitoring of public areas.
DPIA template:
1. DESCRIPTION OF PROCESSING
- Purpose(s) of the processing
- Nature of the processing (collection, storage, sharing, deletion)
- Scope: data categories, volume, frequency, retention
- Context: who are the data subjects? Are they vulnerable?
- Recipients: internal teams, third-party processors, public
2. NECESSITY AND PROPORTIONALITY
- Is each data element strictly necessary for the stated purpose?
- Could a less privacy-invasive approach achieve the same outcome?
- What is the legal basis? Is it proportionate to the risk?
- What retention period is justified?
3. RISK IDENTIFICATION
For each risk, assess: likelihood (Low/Medium/High) x severity (Low/Medium/High)
- Unauthorized access or data breach
- Inadvertent disclosure to wrong recipients
- Excessive collection beyond stated purpose
- Inability to fulfill data subject rights
- Re-identification of pseudonymized data
- Discrimination or unfair automated decisions
4. RISK MITIGATION MEASURES
- Technical: encryption, access controls, pseudonymization, audit logs
- Organizational: training, DPAs with processors, incident response plan
- Process: retention schedules, DSR workflow, breach notification procedure
5. RESIDUAL RISK AND SIGN-OFF
- Residual risk level after mitigations: Low / Medium / High
- If residual risk remains High: consult supervisory authority before proceeding
- Sign-off: DPO (if applicable), Legal, Engineering, Product owner
- Review date: (recommend annually or on significant change)
4. Handle data subject requests (SAR, deletion, portability)
Response deadlines: 30 days (GDPR), 45 days (CCPA), both extendable once by
an additional 30-45 days with notice to the requestor.
Identity verification: Verify identity before fulfilling any request. For
authenticated users, session confirmation is sufficient. For unauthenticated
requests, ask for information already held (e.g., email + last 4 of payment card).
Do not ask for more data than needed to verify.
Request types and implementation:
Subject Access Request (SAR / Right to Know):
- Export all personal data held across: primary DB, data warehouse,
analytics tools, marketing platforms, support tickets, backups*
- Include: categories of data, purposes, retention periods,
recipients/third parties, source of data if not collected directly
- Format: machine-readable (JSON/CSV) + human-readable summary
- *Note: you must describe backup data; you are not required to restore
a backup solely to fulfill a SAR
Erasure / Right to Deletion:
- Delete from primary store, read replicas, analytics, marketing platforms
- Notify all processors and sub-processors
- Exceptions: data held for legal obligation (tax, fraud) may be retained
with processing restricted; document the exception
- Backups: document policy (e.g., "purged within 90 days as backups rotate")
- Send confirmation to requestor with scope of deletion
Portability (GDPR Art. 20 / CCPA):
- Applies to data the user provided (not inferred data under GDPR)
- Format: structured, commonly used, machine-readable (JSON preferred)
- Must include all user-provided + observed behavioral data
Request tracking minimum fields:
- Request ID, type, date received, requestor identity verified (boolean)
- Date fulfilled / extended / denied, reason if denied, response sent (boolean)
5. Write a privacy policy
A compliant privacy policy must be concise, transparent, and written in plain
language. Structure it as follows:
Section
Required content
Who we are
Controller identity, DPO contact (if applicable), lead supervisory authority
What data we collect
Categories of personal data, sources (direct, third-party, inferred)
Why we process it
Purpose for each category, lawful basis (GDPR) or business purpose (CCPA)
How long we keep it
Retention period or criteria for each category
Who we share it with
Categories of recipients, processors, any sale/sharing for advertising (CCPA)
Your rights
List all applicable rights and how to exercise them
Cross-border transfers
Mechanisms used if data leaves the jurisdiction
Cookies
Summary + link to full cookie policy
How to contact us
Email/form for privacy requests, complaint/supervisory authority info
Changes
How you notify users of material updates; effective date
6. Implement data retention policies
Every data category needs a documented retention schedule enforced by code, not
just policy documents.
Retention decision framework:
For each table / data category:
1. What is the purpose of this data?
2. Is there a legal minimum retention? (e.g., financial records: 7 years)
3. Is there a legal maximum? (e.g., GDPR's storage limitation principle)
4. When does the retention clock start?
- Date of collection, last interaction, end of contract, or legal obligation end
5. What deletion action is taken?
- Hard delete: remove the row entirely
- Anonymization: replace PII fields with null/hash - retain for analytics
- Archival: move to cold storage, restricted access, then delete at archive TTL
Enforcement pattern:
// Scheduled job (daily or weekly)
function runRetentionPolicy():
for each retention_rule in retention_schedule:
records = db.query(
"SELECT id FROM " + rule.table +
" WHERE " + rule.clock_column + " < NOW() - INTERVAL '" + rule.period + "'" +
" AND NOT has_legal_hold"
)
for each record in records:
if rule.action == "delete":
db.hardDelete(rule.table, record.id)
auditLog("retention_delete", rule.table, record.id)
else if rule.action == "anonymize":
db.anonymize(rule.table, record.id, rule.pii_columns)
auditLog("retention_anonymize", rule.table, record.id)
7. Manage cross-border data transfers
Decision tree:
Is the destination country on the EU adequacy list?
YES -> Transfer permitted. No additional mechanism required.
(Maintain documentation confirming adequacy status.)
NO -> Is it an intra-group transfer?
YES -> Consider Binding Corporate Rules (BCRs)
- Long approval process; only viable for large multinationals
NO -> Use Standard Contractual Clauses (2021 SCCs)
- Use Module 1 (controller to controller)
- Use Module 2 (controller to processor) - most common
- Conduct Transfer Impact Assessment (TIA) for high-risk destinations
- Implement supplementary measures if TIA shows elevated risk
(e.g., encryption where processor cannot access keys)
Transfer Impact Assessment (TIA) - key questions:
Does the destination country have laws enabling government access to data?
What is the legal remedy available to EU individuals?
What supplementary technical measures would reduce the risk (e.g., end-to-end
encryption, pseudonymization, data minimization before transfer)?
Anti-patterns
Anti-pattern
Why it's wrong
What to do instead
Dark patterns in consent (pre-ticked boxes, hidden reject button)
Invalid consent under GDPR; FTC/CCPA enforcement risk
Equal prominence for accept/reject; no pre-ticked boxes; granular controls
Collecting data "just in case we need it later"
Violates data minimization; every field is liability; no lawful basis
Define purpose before collection; if no purpose, do not collect
Treating privacy policy as a legal shield, not a user document
Users don't read walls of legalese; regulators notice
Write in plain language; use headers, tables, and short sentences
Forgetting processors in deletion flows
Erasure obligation extends to all processors; incomplete deletion is non-compliant
Maintain processor inventory; trigger deletion notifications via API or DPA process
Every data category needs a retention period; automate deletion
Skipping DPIA for "obviously low-risk" processing
Regulators and courts do not accept this; DPIA is mandatory for defined categories
Run DPIA for any processing involving profiling, sensitive data, or systematic monitoring
Gotchas
Consent banners that fire after analytics scripts have already loaded are non-compliant - A common implementation mistake is loading Google Analytics, Meta Pixel, or Heap in the <head> before the consent banner renders. By the time the user sees the banner, non-essential cookies have already been set. Load analytics scripts conditionally: fire them only after consent is granted, not before the banner resolves.
Deletion requests must cascade to all processors and data warehouses, not just the primary DB - Deleting a user from your application database while leaving their data in Segment, BigQuery, Amplitude, Intercom, and your email platform is not compliant with GDPR Art. 17. Maintain a processor inventory and build a deletion workflow that triggers deletion across every system in the chain.
Legitimate Interests as a catch-all basis for analytics is high-risk - Many companies use "Legitimate Interests" for all analytics because it avoids requiring consent. But LI requires a genuine balancing test (Legitimate Interests Assessment) where user interests do not override yours. Regulators have repeatedly ruled that behavioral analytics for marketing cannot rely on LI and require explicit consent. Default to consent for analytics; use LI only for fraud prevention and security logging.
Breach notification to supervisory authority must happen within 72 hours of becoming aware - The GDPR 72-hour clock starts when your organization has reasonable certainty that a breach occurred - not when the forensic investigation is complete. You can submit an initial notification with incomplete information and supplement it later. Many organizations fail this deadline by waiting for full confirmation.
Standard Contractual Clauses must be the 2021 version, not the 2010 version - The EU Commission invalidated the 2010 SCCs in 2021. Any Data Processing Agreement or data transfer mechanism signed before June 2021 that uses the old SCCs must have been updated by December 2022. Using legacy SCCs is a compliance gap that regulators flag in audits. Always use the 2021 SCCs with the correct module (controller-to-processor = Module 2).
References
For detailed side-by-side regulatory comparison, load the relevant reference file:
references/gdpr-ccpa-comparison.md - Full GDPR vs CCPA requirements table with
article citations, thresholds, and implementation notes
Only load the reference file if the current task requires deep regulatory detail -
it is long and will consume context.
Companion check
On first activation of this skill in a conversation: check which companion skills are installed by running ls ~/.claude/skills/ ~/.agent/skills/ ~/.agents/skills/ .claude/skills/ .agent/skills/ .agents/skills/ 2>/dev/null. Compare the results against the recommended_skills field in this file's frontmatter. For any that are missing, mention them once and offer to install:
