Skip to content
AppFoyer
Start free

Guides

When your Data safety form and your privacy policy disagree

Two declarations about the same app, read side by side, and usually written months apart. What each one is, where they drift, and how to reconcile them from the dependency list.

They are two descriptions of the same app and the stores read them together, so a disagreement is itself the problem. Fix it from the app rather than from either document: list every SDK in your build, write down what each sends, then fill in the form and rewrite the policy from that one list.

Checked 19 September 2026. Store policies change, sometimes without notice. Everything below links to the official documentation, and that page — not this one — is the authority. If the two disagree, the store is right.

Your Data safety form and your privacy policy are two descriptions of the same app, and the stores read them together. When they disagree, the disagreement is the problem — not whichever one happens to be wrong. Google Play states it plainly: “When Google becomes aware of a discrepancy between your app behavior and your declaration, we may take appropriate action, including enforcement action.”

Apple has the same structure under different names: the App Privacy details on your product page, plus the required privacy policy URL.

This page is about keeping the two in step, and about the third thing they are both checked against: what your app actually does.

The two documents, briefly

The Data safety form (Play Console → App content) and App Privacy details (App Store Connect) are structured declarations: tick-boxes and categories, rendered on your store listing as a summary a user reads before installing. They are answers to a fixed questionnaire.

The privacy policy is prose at a URL you host. It says the same things in sentences, plus the things a questionnaire has no box for — your legal basis, retention, who to contact, how to ask for deletion.

Neither substitutes for the other. A policy does not fill in the form, and a completed form does not mean your policy is accurate.

Where they drift apart

They are written months apart. The policy gets written the week of launch. The form gets filled in on submission day, by someone reading a dependency list, and nobody goes back to the policy.

A new SDK arrives. You add a crash reporter in a sprint. Nothing about the policy or the form is in the pull request, so neither changes. Google Play is explicit that this counts: data collection “includes data collected and handled through any third-party libraries or SDKs used in their apps… You must reflect data collection or sharing carried out by such third-party code in the Data safety form for your app.” Apple asks the same: “You need to identify all of the data you or your third-party partners collect.”

A feature ships without its disclosure. Location for a “find nearby” feature, a referral system that shares a user id with a partner. The engineering work is visible; the declaration work is not on anyone’s board.

A template was used for one of them. A generated policy that lists advertising identifiers for an app with no ads is as much of a mismatch as an omission — and it is the easier one to spot, because it contradicts a form you filled in honestly.

Reconciling them, in the only order that works

Start from the app, not from either document. Both are supposed to describe it, so fixing one against the other just moves the error.

  1. Open your dependency files — build.gradle/libs.versions.toml, Podfile/Package.swift, pubspec.yaml, package.json. List every third-party SDK.
  2. For each, write down what it sends. A crash reporter sends device identifiers and stack traces. An analytics SDK sends events and often an advertising id. An ads SDK sends a good deal more. A push library registers a device token. The vendor’s own privacy documentation is the source here.
  3. Add your own collection — accounts, uploads, anything your backend stores.
  4. Check the permissions and usage strings you declare, which are a second, independent list of what the app can reach: ACCESS_FINE_LOCATION, NSLocationWhenInUseUsageDescription, camera, contacts, photos.
  5. Now fill in the form from that list, and rewrite the policy from the same list. They end up consistent because they came from one source, not because you compared them.

That list, not the form, is the thing to keep current. Both declarations are downstream of it.

Keeping them in step afterwards

The declarations go stale silently, so the check has to be attached to something that does not. Google Play requires it: “Your Data safety form responses must remain accurate and complete at all times.” Apple, likewise: “You’re responsible for keeping your responses accurate and up to date.”

The cheapest version that works is a line in your release checklist — did any dependency change this release? if so, re-check the policy and the form — because a dependency change is exactly the event that invalidates both.

What this page cannot tell you

Which specific regime applies to you. GDPR, the UK GDPR, CCPA/CPRA, LGPD and children’s privacy rules each expect particular things in the policy, and which of them apply depends on where your users are and what your app does. If anything about your app is unusual — health data, children, anything you would hesitate to explain in one sentence — that is worth an hour of a lawyer’s time. Templates, ours included, are a starting point, not advice.

What AppFoyer does here

We draft the privacy policy from the SDKs found in your build files — with a coding agent that reads the repository, or from a short form — so the policy and the answers you give the stores come from the same dependency list rather than from memory. The checklist keeps flagging the page until the placeholder naming your third parties is replaced, because that section is what a reviewer compares against your form.

We do not fill in the Data safety form for you, and no service can: it is a declaration you sign in your own console, and Google Play says “you alone are responsible for making complete and accurate declarations.”

The authoritative sources

Do this in a few minutes instead

AppFoyer hosts the pages this guide is about — privacy policy, terms, support, account deletion and app-ads.txt — on their own subdomain, with no domain or server of your own. One app is free, and nothing a store requires is ever behind a paywall.

Start free See a live example