Building Purpose Limitation Enforcement

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:

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

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:

Enforcement Metrics

Prism Data Systems AG tracks the following purpose limitation enforcement metrics:

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