SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsbuilding-purpose-limitation-enforcement

building-purpose-limitation-enforcement

Data & analytics

View repository

Updated 10-16 06:50

About this skill

Building Purpose Limitation Enforcement

Overview

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).

Article 6(4) Compatibility Assessment Factors

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:

  • Processing is based on consent (Article 6(1)(a)) — new consent can be obtained for the new purpose
  • Processing is based on Union or Member State law that constitutes a necessary and proportionate measure (Article 6(4) final paragraph)
  • Processing is for archiving in the public interest, scientific/historical research, or statistics per Article 89(1)

Purpose-Tagged Data Architecture

Design Principles

  1. Purpose binding at ingestion — Every data record is tagged with its collection purpose at the point of entry into the system
  2. Purpose-based access control — Access policies are defined per purpose, not per data field alone
  3. Purpose audit trail — Every access is logged with the purpose under which it was authorized
  4. Purpose expiry — When a purpose is fulfilled, the associated data enters a retention countdown

Architecture Diagram

┌────────────────────────────────────────────────────────────┐
│                   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     │  │
│  └─────────────────┘  └────────────────┘  └────────────┘  │
└────────────────────────────────────────────────────────────┘

Purpose Registry Schema

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
}

Access Control Per Purpose

Policy-as-Code with Open Policy Agent (OPA)

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-Purpose Authorization Matrix

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

Purpose Compatibility Assessment Workflow

  1. Request submission — Service owner submits a request to process data collected under purpose A for new purpose B, documenting the business justification.

  2. Factor analysis — The Data Protection Office evaluates the five Article 6(4) factors:

    • Link between purposes (scored 1-5: 1 = no link, 5 = closely linked)
    • Context and expectations (scored 1-5: 1 = unexpected, 5 = fully expected)
    • Nature of data (scored 1-5: 1 = special category, 5 = non-sensitive)
    • Consequences (scored 1-5: 1 = severe, 5 = minimal impact)
    • Safeguards (scored 1-5: 1 = no safeguards, 5 = comprehensive safeguards)

  3. Scoring — Total score calculated (range 5-25):

    • 20-25: Compatible. Approve with standard documentation.
    • 15-19: Potentially compatible. Approve with additional safeguards (pseudonymization, access restriction).
    • 10-14: Likely incompatible. Requires DPO escalation and DPIA consideration.
    • 5-9: Incompatible. Denied. New lawful basis or separate consent required.

  4. Decision recording — Assessment result recorded in the purpose registry with the assessor identity, date, score breakdown, conditions, and review date.

  5. Policy update — If approved, OPA policies are updated to allow cross-purpose access under documented conditions.

Prism Data Systems AG Implementation

Purpose Registry

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

Enforcement Metrics

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

Key Regulatory References

  • GDPR Article 5(1)(b) — Purpose limitation principle
  • GDPR Article 6(4) — Compatibility assessment factors
  • GDPR Article 13(1)(c) — Information about purpose at collection
  • GDPR Article 14(1)(c) — Information about purpose for indirect collection
  • GDPR Article 89(1) — Exception for archiving, research, statistics
  • GDPR Recital 50 — Further processing compatibility
  • Article 29 Working Party Opinion 03/2013 on purpose limitation (WP203)
  • EDPB Guidelines 4/2019 on Article 25 Data Protection by Design and by Default