# Data collection is minimized to what is necessary

- **Pattern:** `ab-000479` (`app-store-privacy-data.data-handling.data-collection-minimization`)
- **Severity:** info
- **Lifecycle:** active
- **Last modified:** 2026-04-18
- **Canonical URL:** https://auditbuffet.com/patterns/ab-000479
- **License:** CC-BY-4.0 — attribute to AuditBuffet Pattern Catalog (https://auditbuffet.com/patterns/ab-000479)

## Why it matters

GDPR Art.5(1)(c) requires data minimisation — collecting only what is strictly necessary for a specified purpose. Requesting contact list access in an app with no contact-sharing feature, or logging 40+ analytics event types for an app with a narrow feature set, is over-collection that creates unnecessary legal exposure without any product benefit. Excessive analytics events are a common attack surface for data leak scenarios: each event payload is another opportunity for inadvertent PII capture. Store reviewers also flag permission requests without a demonstrable feature need, resulting in rejection.

## Severity rationale

Info because over-collection is a risk signal rather than an active exploit — it increases legal surface area and reviewer scrutiny without constituting a breach by itself.

## Remediation

Audit each permission request and each analytics event against the feature that justifies it. Remove permissions and tracking events that cannot be tied to a user-facing feature.

Apply the progressive disclosure principle: collect additional data only when users engage with features that require it. Review the `src/analytics/` or equivalent directory and list every distinct event tracked — if the list exceeds what your product team can act on, it is over-collection. For permissions, search for `requestPermissionsAsync`, `requestCameraPermissionsAsync`, and similar calls in `src/` and verify each maps to a visible feature.

## Detection

- **ID:** `data-collection-minimization`
- **Severity:** `info`
- **What to look for:** Count all relevant instances and enumerate each. Look for data collection patterns beyond what the app's features require. This is an informational signal — flag patterns but do not fail unless clearly excessive. Search for: (a) **Contact list access** — does the app request `NSContactsUsageDescription` or `READ_CONTACTS` without a clear contacts feature (inviting friends, auto-fill, etc.)? (b) **Calendar/reminders** — calendar access without a scheduling feature? (c) **Microphone** — microphone permission without voice/audio features? (d) **Unnecessary analytics events** — search for analytics calls tracking every screen view, button tap, form field focus, keyboard input, etc., across the entire app. High-volume event tracking without a product analytics use case may be excessive. (e) **Device identifiers beyond IDFA** — collecting manufacturer, model, OS version, carrier, IP address, and sending all to first-party analytics (some of this is normal, but flagging extreme cases). (f) **Third-party SDK scope creep** — SDKs initialized that are not actively used (imported but `start()` never called, or called but no events logged). Flag as info with specific findings; do not fail this check unless collection is clearly disproportionate.
- **Pass criteria:** Data collection appears proportionate to the app's stated functionality. At least 1 implementation must be verified. No obvious cases of collecting data types unrelated to any feature.
- **Fail criteria:** Not applicable — this is an info check. Result is `pass` or `info` (recorded as `pass` with a detail note) or `skip` only. Flag notable findings in the detail field.
- **Skip (N/A) when:** App has no analytics, no advertising, and no permission requests.
- **Detail on fail:** Not applicable — info check. Use detail to note any concerning patterns: `"App requests contacts access but no contacts feature detected — consider removing this permission"` or `"Analytics SDK logs 40+ distinct event types including every keystroke in search — review data minimization policy"`
- **Remediation:** Over-collection increases legal exposure and can cause store rejection for permission requests without clear purpose.
  1. Audit each permission request and each analytics event against the feature that justifies it
  2. Remove permissions and tracking events that cannot be tied to a user-facing feature
  3. Apply the "progressive disclosure" principle: collect additional data only when users engage with features that require it

  Review the configuration in `src/` or `app/` directory for implementation patterns.

## External references

- gdpr Art.5(1)(c)
- gdpr Art.5(1)(b)
- ccpa §1798.100

Taxons: privacy-consent

HTML version: https://auditbuffet.com/patterns/ab-000479