7.5 Secondary Use, Function Creep, and Purpose Limitation Controls

7.5 Secondary Use, Function Creep, and Purpose Limitation Controls

The principle of purpose limitation is a cornerstone of international data protection frameworks, including GDPR Article 5(1)(b), the OECD Privacy Guidelines, and modern US state privacy statutes. It establishes that personal data must be collected for specified, explicit, and legitimate purposes and not further processed in a manner incompatible with those initial purposes. In engineering practice, however, data stored in central repositories tends to attract secondary uses. Without technical purpose binding, systems inevitably suffer from function creep, expanding processing activities beyond user expectations and legal authorizations.

---

Function Creep: Mechanisms and Real-World Failure Modes

Function creep describes the gradual expansion of a system's data processing activities beyond the original, stated purposes for which the data was collected, typically without the knowledge, choice, or consent of the data subjects.

The Mechanics of Function Creep

Function creep rarely occurs through malicious intent; instead, it is driven by organizational incentives, convenience, and architectural shortcuts:

1. Shared Monolithic Storage: Storing disparate data attributes in a single centralized database table where all internal services possess broad read access.
2. Ambiguous Metadata: Failing to document the explicit legal basis and permitted processing purposes alongside column definitions in data catalogs.
3. Internal Metric Pressures: Product and marketing teams discovering existing customer records (e.g., telephone numbers, IP logs, billing zip codes) and querying them to boost conversion metrics or ad engagement.

Landmark Industry Case Studies

• Two-Factor Authentication (2FA) Phone Numbers Repurposed for Ad Targeting: Facebook's 2019 FTC order (with a $5 billion penalty) addressed, among other things, phone numbers collected for two-factor authentication that were also used for advertising. In May 2022, Twitter agreed to pay $150 million because it had used phone numbers and email addresses collected for account security to target ads, violating a 2011 FTC order. Both orders require companies to stop using security-collected data for advertising and to run privacy programs that review new uses before launch.
• Automated License Plate Readers (ALPR): Systems originally procured and installed by municipalities to detect stolen vehicles or locate missing persons were subsequently integrated into regional surveillance networks, queried for immigration enforcement, or mined by insurance companies to assess driver risk profiles.
• Office Badge Telemetry for Productivity Tracking: Electronic building access badges implemented for physical facility security being aggregated by human resources to monitor desk attendance, calculate break durations, and automate employee disciplinary scoring.

---

Technical Controls for Purpose Binding

Policy documents and employee training cannot guarantee purpose limitation. Technologists enforce purpose binding through technical, architectural controls that gate data access based on runtime intent.

1. Attribute-Based Access Control (ABAC)

Traditional Role-Based Access Control (RBAC) grants permissions based solely on user identity or group membership (e.g., "User is a Data Scientist"). RBAC cannot enforce purpose limitation because a data scientist may have legitimate permission to query a database for fraud detection but is strictly prohibited from querying that same table for ad retargeting.

Attribute-Based Access Control (ABAC) solves this by evaluating a multi-dimensional attribute tuple for every request:

• Subject Attributes: Identity, team, role, authentication assurance level.
• Action Attributes: Read, export, execute, aggregate, delete.
• Resource Attributes: Data classification (e.g., confidential), sensitivity level, and Permitted Purposes metadata tags (e.g., ["fraud_prevention", "account_security"]).
• Environmental/Contextual Attributes: Current timestamp, network origin, and crucially, the Declared Request Purpose (e.g., purpose = "fraud_prevention").

2. Open Policy Agent (OPA) and Purpose Enforcement

Modern cloud-native systems deploy Policy Decision Points (PDP) using Open Policy Agent (OPA), expressing access rules as declarative code in Rego:

package privacy.purpose_limitation

# Rego v1 syntax (OPA 1.0+): rules use `if` and `contains`
default allow := false

# Allow access only if the client's declared purpose matches the dataset's permitted purposes
allow if {
    # Verify client is authenticated and provides a declared purpose claim
    input.subject.authenticated == true
    declared_purpose := input.context.declared_purpose
  
    # Retrieve permitted purposes metadata for the target resource
    permitted_purposes := data.resources[input.resource.id].permitted_purposes
  
    # Validate that declared purpose is explicitly authorized for this dataset
    permitted_purposes[_] == declared_purpose
  
    # Ensure sensitive data classes are not queried under general analytics purposes
    not violates_sensitive_constraint(declared_purpose, data.resources[input.resource.id].classification)
}

violates_sensitive_constraint(purpose, classification) if {
    classification == "HIGHLY_RESTRICTED_SECURITY"
    purpose == "MARKETING_ANALYTICS"
}

3. Purpose-Bound Identity Tokens

In microservice architectures, service-to-service communication relies on OAuth 2.0 access tokens and JSON Web Tokens (JWT). Systems extend token payloads to carry cryptographically signed purpose claims:

{
  "iss": "https://auth.enterprise.internal",
  "sub": "svc-fraud-detector-01",
  "aud": "https://data-lake.enterprise.internal",
  "exp": 1791244800,
  "purpose": "FRAUD_INVESTIGATION",
  "ticketId": "SEC-TICK-90812",
  "allowedScopes": ["read:transactions", "read:device_fingerprints"],
  "prohibitedScopes": ["write:all", "read:marketing_profiles"]
}

When svc-fraud-detector-01 calls the customer data store, the service mesh (e.g., Istio Envoy proxy) verifies the token signature, checks that purpose == FRAUD_INVESTIGATION, and grants access strictly to transaction tables while blocking queries to marketing profile tables.

4. Data Virtualization and Dynamic Schema Projections

Rather than connecting microservices directly to underlying relational tables, organizations deploy data virtualization layers (e.g., Trino, Starburst, Denodo). The virtualization engine dynamically projects columns and applies masking rules at query execution time based on the caller's session purpose:

• If session purpose is FINANCIAL_AUDITING: The engine returns transaction amounts and invoice IDs, but masks email addresses and phone numbers.
• If session purpose is SECURITY_INCIDENT_RESPONSE: The engine unmasks IP addresses and authentication timestamps, but suppresses financial payment amounts.
• If session purpose is MARKETING: The engine completely excludes any record flagged with opt_out = true or collected under a security-only legal basis.

---

Enterprise Data Lakehouse Governance

In modern data lakehouses (e.g., Databricks, Apache Iceberg, Snowflake), massive volumes of raw operational events are streamed into object storage. Enforcing purpose limitation requires physical and logical architectural separation across storage tiers:

1. Isolating the Raw Landing Zone

The raw landing zone (e.g., bronze storage tier) receives unprocessed, raw payloads from API gateways and event queues. To prevent function creep:

• The landing zone is configured with write-only service credentials.
• Human analysts, data scientists, and standard application service accounts are denied all read permissions (s3:GetObject denied).
• Only automated, auditable ETL/ELT pipelines (e.g., Apache Spark jobs running under dedicated service identities) have access to read from raw buckets.

2. Purpose-Specific Data Marts

The ETL pipeline processes raw records into isolated, purpose-specific data marts (gold storage tier):

• Fraud Detection Mart: Retains pseudonymous device IDs, IP subnet ranges, and transaction velocity counters. Contact details (phone, email) are tokenized or omitted.
• Marketing Analytics Mart: Contains customer purchase histories and product preferences, but strictly filters out all records where the customer has not provided affirmative opt-in consent for commercial marketing.
• Financial Reporting Mart: Contains aggregated revenue, tax data, and ledger summaries with zero customer-level identifiers.

3. Segregating Machine Learning Training Datasets

The rapid adoption of Artificial Intelligence and Large Language Models (LLMs) has amplified the risk of function creep. When users interact with customer service chatbots, search boxes, or mobile apps, their prompts and session data are frequently co-opted to fine-tune AI foundation models.

Privacy engineering mandates strict training dataset segregation:

• Customer operational data must not automatically flow into model training feature stores.
• A dedicated ML Purpose Clearinghouse validates whether training datasets contain explicit consent or a lawful basis for algorithmic modeling.
• Data pipelines enforce automated sanitization (PII scrubbing, synthetic data generation, or differential privacy noise injection) before model training clusters (e.g., PyTorch, Ray) can read training partitions.