Enforces GDPR Article 5(1)(b) purpose limitation with purpose-tagged data stores, per-purpose access controls, Article 6(4) compatibility assessments, and purpose creep prevention.
npx claudepluginhub mukul975/privacy-data-protection-skills --plugin privacy-skills-completeThis skill uses the workspace's default tool permissions.
Article 5(1)(b) of the GDPR requires that personal data be "collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes." This is the purpose limitation principle, one of the foundational data protection principles.
Conducts multi-round deep research on GitHub repos via API and web searches, generating markdown reports with executive summaries, timelines, metrics, and Mermaid diagrams.
Dynamically discovers and combines enabled skills into cohesive, unexpected delightful experiences like interactive HTML or themed artifacts. Activates on 'surprise me', inspiration, or boredom cues.
Generates images from structured JSON prompts via Python script execution. Supports reference images and aspect ratios for characters, scenes, products, visuals.
Article 5(1)(b) of the GDPR requires that personal data be "collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes." This is the purpose limitation principle, one of the foundational data protection principles.
The controller must specify the purpose at or before the time of collection (Article 13(1)(c) for direct collection, Article 14(1)(c) for indirect collection). Any subsequent processing for a different purpose requires either a new lawful basis or must pass the compatibility assessment under Article 6(4).
The Article 29 Working Party Opinion 03/2013 on purpose limitation (WP203) provides detailed guidance on assessing compatibility, identifying five key factors codified in Article 6(4).
When a controller wishes to process personal data for a purpose other than that for which it was collected, Article 6(4) requires an assessment of compatibility considering:
| Factor | Article 6(4) Reference | Assessment Question |
|---|---|---|
| Link between purposes | Article 6(4)(a) | Is there a connection between the original and new purpose? |
| Context of collection | Article 6(4)(b) | What is the relationship between controller and data subject? What are the reasonable expectations? |
| Nature of data | Article 6(4)(c) | Does the data include special categories (Article 9) or criminal convictions (Article 10)? |
| Consequences | Article 6(4)(d) | What are the possible consequences of the further processing for data subjects? |
| Safeguards | Article 6(4)(e) | Are appropriate safeguards in place, including encryption or pseudonymisation? |
Compatibility is not required when:
┌────────────────────────────────────────────────────────────┐
│ Data Collection Points │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Web Form │ │ API Call │ │ IoT Feed │ │ Partner │ │
│ │ P:ONBRD │ │ P:ANALYT │ │ P:MAINT │ │ P:MARKET │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ └──────────────┼──────────────┼──────────────┘ │
└──────────────────────┼──────────────┼──────────────────────┘
│ │
┌──────────────────────▼──────────────▼──────────────────────┐
│ Purpose Tagging Gateway │
│ ┌─────────────────┐ ┌─────────────────────────────────┐ │
│ │ Purpose Registry │ │ Tag Injection Middleware │ │
│ │ (canonical IDs) │ │ (attaches purpose + timestamp) │ │
│ └─────────────────┘ └─────────────────────────────────┘ │
└──────────────────────────────┬─────────────────────────────┘
│
┌──────────────────────────────▼─────────────────────────────┐
│ Purpose-Partitioned Data Store │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ ONBRD │ │ ANALYT │ │ MAINT │ │ MARKET │ │
│ │ Partition│ │ Partition│ │ Partition│ │ Partition│ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
└──────────────────────────────┬─────────────────────────────┘
│
┌──────────────────────────────▼─────────────────────────────┐
│ Purpose Enforcement Layer │
│ ┌─────────────────┐ ┌────────────────┐ ┌────────────┐ │
│ │ Policy Engine │ │ Compatibility │ │ Audit │ │
│ │ (OPA / Cedar) │ │ Assessor │ │ Logger │ │
│ └─────────────────┘ └────────────────┘ └────────────┘ │
└────────────────────────────────────────────────────────────┘
Each processing purpose is registered with canonical metadata:
{
"purpose_id": "PRP-ONBRD-001",
"purpose_name": "Customer Account Onboarding",
"description": "Collection and processing of personal data necessary to create and activate a customer account, verify identity, and establish the contractual relationship.",
"lawful_basis": "Article 6(1)(b)",
"data_categories": ["email", "display_name", "country_code", "identity_verification_result"],
"controller": "Prism Data Systems AG",
"retention_period_days": 2555,
"retention_trigger": "account_closure",
"compatible_purposes": ["PRP-SUPRT-001", "PRP-SECUR-001"],
"incompatible_purposes": ["PRP-MARKET-001", "PRP-RESRCH-001"],
"special_categories": false,
"created_date": "2025-06-01",
"last_reviewed": "2026-01-15",
"review_cadence_days": 180,
"owner": "product_team",
"dpo_approved": true
}
Purpose-based access control is implemented using OPA policies that evaluate access requests against the purpose registry:
# Prism Data Systems AG — Purpose-Based Access Policy
# Rule: Access is granted only if the requesting service's declared purpose
# matches a purpose tag on the requested data record.
allow {
input.action == "read"
input.resource.purpose_tags[_] == input.requester.declared_purpose
purpose_is_active(input.requester.declared_purpose)
role_authorized_for_purpose(input.requester.role, input.requester.declared_purpose)
}
# Rule: Cross-purpose access requires a completed compatibility assessment
allow {
input.action == "read"
not input.resource.purpose_tags[_] == input.requester.declared_purpose
compatibility_assessment_approved(input.resource.purpose_tags, input.requester.declared_purpose)
purpose_is_active(input.requester.declared_purpose)
}
# Rule: Write operations must include a valid purpose tag
allow {
input.action == "write"
valid_purpose(input.resource.purpose_tag)
input.requester.declared_purpose == input.resource.purpose_tag
}
| Role | ONBRD | ANALYT | SUPRT | MARKET | SECUR | BILLING |
|---|---|---|---|---|---|---|
| Onboarding Service | Read/Write | — | — | — | — | — |
| Analytics Pipeline | — | Read | — | — | — | — |
| Support Agent | Read | — | Read/Write | — | — | Read |
| Marketing Automation | — | — | — | Read | — | — |
| Security Operations | Read | Read | Read | Read | Read/Write | Read |
| Billing Service | Read | — | — | — | — | Read/Write |
Request submission — Service owner submits a request to process data collected under purpose A for new purpose B, documenting the business justification.
Factor analysis — The Data Protection Office evaluates the five Article 6(4) factors:
Scoring — Total score calculated (range 5-25):
Decision recording — Assessment result recorded in the purpose registry with the assessor identity, date, score breakdown, conditions, and review date.
Policy update — If approved, OPA policies are updated to allow cross-purpose access under documented conditions.
Prism Data Systems AG maintains 14 registered purposes in their purpose registry:
| Purpose ID | Name | Lawful Basis | Data Categories |
|---|---|---|---|
| PRP-ONBRD-001 | Customer onboarding | Art. 6(1)(b) | email, display_name, country_code |
| PRP-AUTH-001 | Authentication | Art. 6(1)(b) | email, password_hash, mfa_token |
| PRP-BILLING-001 | Billing and invoicing | Art. 6(1)(b) | billing_address, payment_method, vat_id |
| PRP-SUPRT-001 | Customer support | Art. 6(1)(b) | email, display_name, support_ticket_history |
| PRP-ANALYT-001 | Product analytics | Art. 6(1)(f) | pseudonymized_user_id, feature_events, session_duration |
| PRP-MARKET-001 | Direct marketing | Art. 6(1)(a) | email, display_name, marketing_preferences |
| PRP-SECUR-001 | Security monitoring | Art. 6(1)(f) | ip_address, user_agent, login_events |
| PRP-LEGAL-001 | Legal compliance | Art. 6(1)(c) | transaction_records, consent_records |
Prism Data Systems AG tracks the following purpose limitation enforcement metrics:
| Metric | Target | Measurement |
|---|---|---|
| Purpose tag coverage | 100% of records | Percentage of data records with valid purpose tags |
| Cross-purpose access attempts blocked | > 95% without assessment | Policy engine denial count vs. total cross-purpose requests |
| Compatibility assessments completed | 100% within 5 business days | Time from request to DPO decision |
| Purpose registry review currency | 100% reviewed within cadence | Percentage of purposes reviewed within their review cadence |