GENERAL INFORMATION · NOT LEGAL ADVICE · JULY 2026
How to use this
Open three things side by side: your Privacy Policy, your Terms of Use, and the build you are actually shipping. Work down the list. For each point you are answering one question: does the document match the product?
Write down every place the answer is “no” or “I’m not sure.” That list is the useful output.
Part one — Does the Privacy Policy describe this app?
- Every route in. Account and profile, payments, support messages, user-created content, device identifiers, diagnostics, analytics, advertising, attribution, and every permission the app requests. Is each one described?
- Every third party out. Every SDK, cloud service, AI provider, analytics tool, and embedded web view that receives user data. Does the policy account for each, in a way a user could follow?
- Purpose, stated concretely. For each category collected, is the real product or business reason given, rather than one generic phrase standing in for five different purposes?
- Sharing, sale, and tracking. Does the policy say plainly who else receives data and why, and does what it says about tracking match what the app does?
- Retention and deletion. How long is data kept, what does deletion actually do, and how does a person ask? Does the described route exist in the product?
- Choices that exist. Every choice offered — opt-out, access, correction, deletion, withdrawal of consent — can a user genuinely do it today?
Part two — Does the Terms of Use describe this product?
- What you actually promise. Does the document describe the service the app really provides, including anything that changed in recent releases?
- Money. Purchases, subscriptions, trials, renewals, refunds, and who bills the user — described the way they actually work, including the app store’s role?
- User content and conduct. If users create, upload, or share anything: the licence you need, what is prohibited, how reports are handled, and what happens to content when an account ends.
- Ending the relationship. Suspension, termination, deletion, and what a user can take with them — described, and matching the product?
Part three — Do your public statements agree with each other?
- The store disclosures. Put your App Store privacy answers and, if you ship on Android, your Play Data safety answers beside the policy. Do the three tell the same story about collection, purposes, sharing, retention, and deletion?
- Everything else you have said. Website, marketing copy, onboarding screens, consent prompts, and support articles are public statements too. Do any contradict the documents?
What to do with your list
If the list came back empty, that is a good sign, and it cost you an hour. If it came back with “not sure” entries, those are usually factual questions your own team can answer — what does this SDK actually send? Answer those first.
What is left, where you know the documents and the product disagree and are not sure which should change, is the kind of thing worth a second set of eyes.
A caution worth stating plainly
This list is general information, not legal advice, and it is not exhaustive. It does not cover every requirement that might apply to your app, your users, or your jurisdictions. Working through it does not make your documents compliant, correct, or approved, and no one can tell you otherwise from a web page. It is a way to find questions, not a way to close them.
If you would like the list read
The Focused Review is a written review of your app’s existing, final-form Privacy Policy and Terms of Use — $275 flat, one app, both documents, under Tennessee law. You receive written issue spots and considerations. It is not drafting, not revisions, not a compliance certification, and not a call.
Have both final documents? Begin the private Focused Review →
Send names only — who you are and how to reach you. Please do not send app details, documents, confidential information, or payment in a first message.