Privacy policy for apps: a data audit and disclosure checklist
Map app and SDK data, review store disclosures, test privacy controls, and keep your app privacy policy aligned with each release.
An app privacy policy should describe the data practices your app actually implements. Start with a verified inventory of the app, its backend and its SDKs, then use that inventory to prepare the policy, store disclosures and user controls together.
This guide is an engineering worksheet for that process, not a ready-to-publish legal policy or a guarantee of compliance. Have a qualified privacy professional review the laws, notices and rights that apply to your business, audience and markets. Sources were checked on October 7, 2026.
Keep four deliverables in sync
A policy document cannot prove that an SDK waits for consent or that a deletion job reaches every database. Assign an owner to each of these deliverables and connect them to the same inventory.
| Deliverable | Question it answers | Evidence to retain |
|---|---|---|
| Privacy policy | What information is handled, for what purposes, by whom, for how long, and with what choices? | Reviewed wording, source inventory and version date |
| Store disclosures | How do those practices fit each store’s definitions and questions? | Submitted answers and the reasoning behind each classification |
| Permission and choice screens | What does the user see before a relevant action, and how can they change their choice? | Screen captures and acceptance/decline test results |
| Runtime and backend behavior | What actually happens before and after each choice or request? | Configuration, test traces, server records and deletion results |
Review discrepancies explicitly. If the document promises a deletion period that the backup system cannot meet, changing a checkbox in the store listing will not resolve the underlying problem.
Build a data inventory before drafting clauses
Walk through first launch, signup, onboarding, purchase, restore, support, logout and account deletion. Repeat with permissions declined and optional collection disabled. Include the backend: a device capture does not show every server-to-server transfer, support export or scheduled job.
For every field or event, record:
- Source and trigger: the screen, SDK call, server endpoint or background task that produces it.
- Data and identifiers: actual field names, example values from a test account, and whether records can be connected to a person or device.
- Purpose and necessity: the feature or operational question it supports, and whether the same task could use less information.
- Recipients and locations: services receiving the data, relevant processing/storage locations, and any onward handling still to verify.
- Controls: permission state, consent or other reviewed basis, collection configuration and withdrawal behavior.
- Retention and deletion: active storage, logs, backups, vendor copies, exceptions and the mechanism that enforces each rule.
- Evidence and owner: dependency version, settings, documentation, test date and the person responsible for unresolved questions.
A label such as “anonymous analytics” is not an inventory. Inspect identifiers, event properties and join paths. Hashing an email or assigning a random account ID does not by itself establish that the resulting records cannot identify a person.
A worked example: adding onboarding measurement
Suppose a fictional language-learning app wants to measure whether people finish their first lesson. The following is a proposed audit, not a description of Nuxie’s collection or a tested implementation.
| Proposed record | Reason to collect | Question to resolve before release |
|---|---|---|
| Lesson-completed event, lesson ID and app version | Identify where the first-lesson journey succeeds | Can the question be answered without lesson text, microphone recordings or free-form answers? |
| Account or installation identifier | Count completion once per chosen measurement unit | Which systems can connect it to an account, and what happens at logout or deletion? |
| Event timestamp | Compare completion within a defined window | Is exact time necessary, and how long is event-level history needed? |
| SDK delivery diagnostics | Investigate failed event delivery | Do diagnostics include device details, IP addresses or payload contents beyond the intended event? |
Now run a controlled test with synthetic accounts. Start before any optional choice, finish a lesson, change the choice, restart the app, and repeat offline and after reconnecting. Compare the emitted requests with records in the receiving service. Check whether queued events are sent after a user changes their preference. Record what the test covers and what it cannot observe.
Next, request deletion for the test account. Check the app database, analytics destination and other recipients in the inventory. Ask how retained backups are handled and how a restore avoids silently reintroducing deleted records. An unverified vendor promise should remain an open item rather than become a public claim.
For the measurement side of this exercise, see our iOS app analytics guide. For identity and subscription-state boundaries, see the subscription architecture guide.
Turn verified practices into a policy outline
Use the inventory to give your reviewer a concrete draft brief. Identify the app and responsible business, a working privacy contact, the information handled, where it comes from, each purpose, recipients, retention, user choices and the request process. Ask the reviewer which additional disclosures are required for your circumstances.
Describe security measures only to the extent you can support them. “Encrypted at rest” needs evidence for the relevant stores, exports and backups. Avoid “we never share data” if vendors receive it, and avoid “we delete everything immediately” if documented exceptions or retention periods apply.
A useful drafting exercise is to write one plain sentence per data flow: “We use [verified information] for [specific purpose], send it to [verified recipient or appropriate category], and retain it according to [reviewed period or criteria].” This is a briefing structure, not model legal wording. Keep unresolved fields visible to the reviewer; do not fill them with a competitor’s practices.
Check Apple and Google requirements separately
Apple’s privacy guidelines require an accessible policy link in the app and App Store Connect metadata, with information about data practices, retention, deletion and choices. Apps supporting account creation must also offer account deletion within the app. Review the full guidelines for permission and data-use requirements.
Apple’s App Privacy details have their own definitions of collection, linkage and tracking, including third-party partners. Apply those definitions to the inventory rather than copying policy headings into the form. Apple allows answers to be updated without an app update. SDK privacy manifests are relevant evidence, but do not replace reviewing the app’s complete practices.
Google Play’s User Data policy requires a policy in the designated Console field and a policy link or text in the app, even for apps that do not access personal and sensitive data. The policy URL must be active, public, non-geofenced, non-editable and not a PDF. It must identify the listed entity or app and explain relevant handling, retention and deletion.
Google’s Data safety answers must stay accurate and consistent with relevant policy disclosures. Where the prominent-disclosure requirement applies, a policy link alone is insufficient. Apps allowing in-app account creation need an account-deletion request route both inside and outside the app; legitimate retained data must be explained. Check the full policy for conditions and exceptions.
Resolve legal scope with your reviewer
The GDPR sets territorial scope in Article 3, lawful bases in Article 6, and disclosure requirements in Articles 13 and 14. Consent is one lawful basis; a generic “accept privacy policy” button does not settle which basis applies to every activity. Article 17 also includes conditions and exceptions for erasure. Ask your reviewer to map applicable obligations to each data flow.
California’s official CCPA overview describes rights and business responsibilities, including deletion exceptions and opt-outs from sale or sharing. Determine whether the business and activity fall within the law’s scope rather than assuming every app has identical obligations.
For children, the FTC’s COPPA rule summary covers child-directed services and other operators with actual knowledge of collecting personal information from children under 13. A “13+” sentence does not settle that assessment. Obtain specialist review where children may be part of the audience.
Make privacy review part of a release
For each new feature or dependency update, ask what changed in the inventory. A new event property, support integration, AI service, retention setting or server-side export can matter even when the app’s visible screens barely change.
- Compare the old and new data flows. Include SDK versions, defaults and production configuration.
- Resolve the obligations. Have the reviewer determine necessary policy, notice, consent and store-disclosure changes before the affected processing begins.
- Test the controls. Exercise acceptance, decline, withdrawal, logout and deletion in the relevant configurations.
- Publish the matching information. Check policy links in the released app and store listing without a privileged account.
- Retain the evidence. Link the release, inventory version, reviewed copy, store answers and test results. Assign any unresolved issue an owner.
Review periodically as well as at release time: vendors, laws and backend settings can change independently. The output should be a policy grounded in documented behavior, with a repeatable process for keeping it accurate.