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.
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.
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.
ID: app-store-privacy-data.data-handling.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.
Review the configuration in src/ or app/ directory for implementation patterns.