Privacy Policy
Agent Prompt Snippet
Ensure the project has a privacy policy disclosing data collection, storage, sharing, user rights, and contact information. Required for GDPR, CCPA, and app store submission.Purpose
A privacy policy is the public disclosure that tells users what personal data your product collects, why it is collected, how it is stored and protected, who it is shared with, how long it is retained, and what rights users have over their data. It is both a legal requirement and a trust signal.
The privacy policy is legally required by GDPR (European Union), CCPA (California), PIPEDA (Canada), APPI (Japan), and many other privacy laws. App stores (Apple App Store, Google Play) require a privacy policy for any app that collects user data, and will reject or remove apps without one. Failure to have an accurate privacy policy exposes the organization to regulatory fines (GDPR maximum: 4% of global annual revenue or €20 million), class action lawsuits, and platform removal.
Privacy policies are often written by lawyers for lawyers. This is a mistake. A privacy policy serves users—it must be written in plain language that a user can actually read and understand. The GDPR requires that privacy notices be “concise, transparent, intelligible, and in an easily accessible form.” A 20-page document in 8-point legal text fails this requirement.
The privacy policy is not a security document. It does not specify how data is technically protected (that is the Security & Privacy Plan). It discloses what data exists and what rights users have.
Who needs this document
| Persona | Why they need it | How they use it |
|---|---|---|
| Sam (Indie Dev) | Required for app store submission, GDPR compliance, and basic user trust; not optional | Writes before first public launch; links from app, website footer, and app store listing |
| Claude Code (AI Agent) | Must not generate code that collects undisclosed data; policy defines the data collection boundary | Reads policy before implementing any analytics, tracking, or user data storage; verifies new features against disclosed data collection |
| Priya (Eng Lead) | Engineering decisions about data collection must align with the published policy | Reviews new features for undisclosed data collection before launch; triggers policy update before adding new data types |
What separates a good version from a bad one
Criterion 1: Data collection is enumerated, not vague
✓ Strong: “We collect: (1) Account data — email address (required for login), display name (optional). (2) Usage data — feature usage events, not linked to individual users, 90-day retention. (3) Payment data — billing address, last 4 digits of payment card. Full card numbers are processed by Stripe and never stored by us. (4) Device data — operating system, app version (for crash reporting). We do not collect: location, contacts, camera, microphone.”
✗ Weak: “We collect information necessary to provide our services, including personal information you provide and information about how you use our services.” (Maximally vague. A user reading this cannot determine whether their location data is being collected.)
Criterion 2: Third-party sharing is specific and justified
✓ Strong: “We share data with: (1) Stripe (payment processor) — billing information only, under their own Privacy Policy and our Data Processing Agreement. (2) SendGrid (email delivery) — email address only, for transactional emails you request. (3) Sentry (crash reporting) — stack traces with personally identifiable information scrubbed. We never sell user data. We never share data with advertisers.”
✗ Weak: “We may share data with trusted third-party service providers.” (Every SaaS company shares data with third-party providers. Users deserve to know which ones and for what purpose.)
Criterion 3: User rights are stated with a process to exercise them
✓ Strong: “Your rights under GDPR (if you are in the EU): Right of access — email privacy@example.com to receive a copy of your data within 30 days. Right to erasure — request account deletion at Settings > Account > Delete Account. Data is permanently deleted within 7 days. Right to data portability — download your data as JSON at Settings > Account > Export Data. Right to object to processing — contact privacy@example.com.”
✗ Weak: “You have rights under applicable law.” (Which rights? How do you exercise them? A privacy policy that states rights without a mechanism to exercise them is not GDPR compliant.)
Criterion 4: Retention periods are specified per data type
✓ Strong: “Retention: Account data is retained until account deletion plus 7 days. Payment records are retained for 7 years (tax compliance). Usage analytics are retained for 90 days then deleted. Crash reports are retained for 30 days. Backup retention: 7 days. We do not retain deleted account data beyond 7 days except as required by law.”
✗ Weak: “We retain data as long as necessary.” (The GDPR requires specific retention periods. “As long as necessary” is not specific.)
Common mistakes
Privacy policy written by engineers, not reviewed by a lawyer. Privacy law is complex and jurisdiction-specific. A policy that fails to cover CCPA rights, or mischaracterizes GDPR basis for processing, creates liability. Have a lawyer review the policy before publishing it.
Policy not updated when new data types are added. The most dangerous privacy policy is one that is outdated. If the policy says “we collect email addresses” but the app also collects location data (added in a feature update), the organization is in violation of its own policy. Require policy review in the feature launch checklist.
Separate policy from reality. A privacy policy that says “we do not sell data” while the analytics provider has a clause granting them data rights is a false statement in a legal document. Audit third-party agreements against the policy.
No effective date or version history. Users and regulators need to know when the policy changed. Include an “effective date” and provide a changelog or previous versions for transparency.
How to use this document
When to create it
Write the privacy policy before collecting any user data—which means before beta testing with real users. Have it reviewed by a lawyer familiar with GDPR and CCPA before publishing.
Who owns it
Legal and the product team co-own the privacy policy. Engineering provides technical accuracy (what data is actually collected). Any new data collection or new third-party data sharing requires a privacy policy update before launch.
How AI agents should reference it
get_standard_docs(type="mobile_app", features=[])
→ privacy_policy in documents[]
→ agent reads privacy policy before implementing analytics or data collection features
→ agent verifies new data fields are disclosed in the policy
→ agent flags if proposed feature would collect data not currently disclosed
The prompt_snippet — “Ensure the project has a privacy policy disclosing data collection, storage, sharing, user rights, and contact information” — tells the agent to verify all five dimensions are present.
How it connects to other documents
The Privacy Policy is the user-facing disclosure layer on top of the PII Classification Specification (internal data classification), the Security & Privacy Plan (internal controls), and the GDPR Compliance Checklist (regulatory compliance verification). All three inform the policy’s content.
Recommended Reading
- GDPR Privacy Notice Guide (ico.org.uk) — The UK Information Commissioner’s Office guide to writing GDPR-compliant privacy notices in plain language.
- Privacy by Design by Ann Cavoukian — Foundational framework for embedding privacy into product design; context for why the privacy policy matters.
- IAPP Privacy Law Fundamentals — The professional resource for understanding privacy regulations across jurisdictions.