policystamp.com
Home / Examples

See what you get
before you pay.

Full anonymized policies for six common business archetypes. Open any one to read the complete document, or click "Start with this profile" to drop the wizard into the same shape.

All examples passed our audit pipeline · 34 issues addressed across the set
Industry
Document
Example 01 · B2B SaaS startup

Northwind Labs

Privacy Policy · 1280 words

Cross-border SaaS handling team account data, processing payments, using common analytics + helpdesk integrations.

Audit passed Free preview · $2
Jurisdictions
USEUUKCA
Excerpt · first three sections anonymized

Privacy Policy

Effective date: January 1, 2026

Northwind Labs ("Northwind", "we", "us") provides a collaborative workspace product at northwindlabs.example. This policy explains what personal data we collect, why we collect it, how we share it, and the rights you have over it.

1. Who this policy covers

This policy applies to everyone who visits northwindlabs.example, creates a Northwind account, or otherwise interacts with our services. It does not cover personal data we process on behalf of a customer (for example, content uploaded into a customer's workspace) — for that, the customer is the data controller and their own privacy policy governs.

2. Information we collect

Information you provide directly

When you create an account, we collect your name, email address, and a password (which we store as a salted hash, never in plaintext). If you join a team, we record which teams you belong to and your role within each. When you communicate with our support team, we keep a copy of your messages and any context you provide.

Information collected automatically

When you use Northwind, we collect:

  • Account activity — when you log in, which workspaces you visit, which features you use.
  • Device and connection information — browser type, operating system, IP address, approximate location derived from IP (city-level).
  • Error reports — when something breaks, we collect the stack trace and the URL you were on so we can fix it.

Information from third parties

When you pay for Northwind through Stripe, we receive your name, email address, billing country, and the last four digits of your payment card. We do not receive or store full card numbers.

3. How we use information

We use the information above to:

  • Operate the service: authenticate you, route your requests, send transactional emails (sign-up confirmation, password resets, billing receipts).
  • Provide support: respond to your messages, troubleshoot bugs.
  • Improve the product: understand which features are used and which aren't, prioritize what to build next.
  • Detect and prevent abuse, fraud, and security incidents.
  • Send service announcements and (with separate consent) product news.

We rely on the following GDPR legal bases:

  • Contract — for everything required to deliver the service you signed up for.
  • Legitimate interests — for security, fraud prevention, and product analytics conducted in privacy-preserving ways.
  • Consent — for marketing communications and any non-essential cookies.
  • Legal obligation — for tax and accounting records.
Example 02 · Shopify / e-commerce

Atlas Goods

Privacy Policy · 1180 words

DTC e-commerce on Shopify, shipping internationally, retargeting via Facebook + Google.

Audit passed Free preview · $2
Jurisdictions
USEUUKCAAU
Documents in this archetype
Excerpt · first three sections anonymized

Privacy Policy

Effective date: January 1, 2026

Atlas Goods ("Atlas", "we", "us") sells apparel direct to consumers at atlasgoods.example. This policy describes the personal information we collect when you shop with us, how we use it, who we share it with, and your rights.

1. Information we collect

When you buy something

When you place an order, we collect your name, billing address, shipping address, email, phone number (optional), the items you ordered, and payment information. Payment cards are processed by our payment provider (Shopify Payments / Stripe) — we do not store full card numbers; we keep only the last four digits and a tokenized reference for refunds.

When you browse the store

When you visit atlasgoods.example, we automatically collect device and browsing information: browser type, operating system, IP address (used to derive approximate city-level location), the pages and products you view, what you add to your cart, and how you arrived at the site (referring page or campaign).

When you sign up for marketing

When you subscribe to marketing emails, we collect your email address and any preferences you select (frequency, product categories). New subscribers receive a confirmation email and are not added to the list until they click the confirmation link.

When you contact us

When you contact customer support, we keep your messages and any context you provide (order number, photographs of damaged goods, etc.) so we can resolve the issue and improve our service.

2. How we use the information

We use the information above to:

  • Process and ship your orders, send order confirmations and shipping updates.
  • Provide customer support, process returns and refunds.
  • Send marketing emails (only to subscribers who have double-opted-in) about new products, sales, and brand updates. Every email contains a one-click unsubscribe link.
  • Show you Atlas products on other websites you visit (retargeting), only if you have consented to advertising cookies.
  • Measure the effectiveness of marketing campaigns in aggregate.
  • Prevent fraud and verify the legitimacy of orders.
  • Comply with tax, customs, and other legal obligations.

GDPR legal bases: contract (order processing), legal obligation (tax records), legitimate interests (fraud prevention, post-purchase service emails), consent (marketing emails, advertising cookies, retargeting).

3. Who we share information with

We share personal information only with the following categories of recipients, each under a written agreement that limits how they may use it:

  • Payment processors (Shopify Payments, Stripe) — to process your payment.
  • Shipping carriers (USPS, UPS, FedEx, DHL, and applicable regional carriers) — to deliver your order, including international customs declarations where required.
  • Email service provider (Klaviyo) — to send transactional and marketing emails.
  • Customer support platform (Gorgias) — to manage support tickets.
  • Advertising and analytics partners (Meta, Google) — for the limited purposes described in our Cookie Policy.

We do not sell personal information for money. Under California law (CCPA / CPRA), our use of advertising cookies for retargeting may be considered "sharing" personal information for cross-context behavioral advertising. You can opt out at any time using the "Do Not Sell or Share My Personal Information" link in the footer, or by toggling Advertising cookies off in the Cookie preferences dialog.

Example 03 · Mobile app (iOS + Android)

Tidepool

Privacy Policy · 1240 words

Consumer mobile app with push notifications, location data, in-app purchases, optional camera access.

Audit passed Free preview · $2
Jurisdictions
USEUUKAU
Documents in this archetype
Excerpt · first three sections anonymized

Privacy Policy

Effective date: January 1, 2026

Tidepool ("Tidepool", "we", "us") publishes a mobile app for tide and surf conditions on iOS and Android. This policy explains what data we collect, why, and your rights over it.

1. Information we collect

Account information

When you create an optional Tidepool account (you can use most of the app without one), we collect your email address and any display name you choose. If you sign in with Apple or Google, we receive the same information from those providers; we do not receive your password.

App usage

When you use the app, we collect:

  • Features used — which screens you visit, which tide stations you check, whether you've added a station to favorites.
  • Crash and performance data — when the app crashes or runs slowly, we collect a crash report (stack trace, device model, OS version) so we can fix the underlying issue.
  • Diagnostic IDs — a pseudonymous identifier scoped to your installation so we can correlate events without identifying you personally.

Location data (only if you grant permission)

If you grant location permission, we use your location to show tide and weather data for the spot you are at. We process location data on your device where possible. Coarse-location (city-level) is sufficient for most features; precise location is only used when you tap "Use my current spot" and is not retained after that request completes.

Device permissions

Tidepool requests the following permissions only when needed for a specific feature, and you can revoke any of them at any time from your phone's Settings:

  • Notifications — optional; lets us alert you when a saved spot has notable conditions.
  • Location (when in use) — optional; lets us show data for where you are.
  • Camera — optional; only triggered when you tap the photo-attach button in the journal.
  • Photo library (selected only) — only the photo you pick is read; we cannot enumerate your library.

In-app purchases

When you subscribe to Tidepool Premium, we receive a receipt and a subscription identifier from Apple or Google. We never see or store your payment card. Subscription management is done in your platform's settings (App Store / Google Play).

2. How we use the information

We use the information above to:

  • Operate the app: load tide data, save your favorites, send push notifications you've enabled.
  • Improve the app: understand which features people use and which need work.
  • Detect and fix crashes and performance problems.
  • Provide customer support when you contact us.
  • Process subscription billing through Apple or Google.

GDPR legal bases: contract (delivering the app you signed up for), legitimate interests (analytics and crash reporting, conducted in privacy-preserving ways), consent (location, notifications, advertising-style measurement).

3. Who we share information with

We use the following sub-processors:

  • Google Firebase — authentication, crash reporting, push delivery (US, EU regions).
  • RevenueCat — subscription receipt validation (US).
  • OneSignal — push-notification delivery (US).
  • Sentry — error tracking (US, EU regions).

We do not sell your information. We do not share your information with advertising networks. We do not place tracking SDKs that build a profile across other apps.

Example 04 · Agency / consultancy

Steady State Group

Master Services Agreement · 1340 words

Service business: client onboarding forms, time-tracking, invoicing. Limited integrations, B2B only.

Audit passed Free preview · $2
Jurisdictions
USEUUK
Documents in this archetype
Excerpt · first three sections anonymized

Master Services Agreement

Effective date: January 1, 2026

This Master Services Agreement ("MSA") governs all services provided by Steady State Group ("Steady State", "we", "us") to its clients ("Client", "you"). Each engagement is described in a Statement of Work ("SOW") executed by both parties and incorporated into this MSA.

1. Order of precedence

In the event of a conflict between this MSA and an SOW, the SOW controls for that engagement only. In the event of a conflict between this MSA and a separately negotiated agreement signed by both parties, the negotiated agreement controls.

2. Statements of Work

Each engagement begins with an SOW that describes:

  • Scope of services and specific deliverables.
  • Timeline and milestones.
  • Fees and payment schedule.
  • Any Client materials Steady State will receive or use.
  • Any acceptance criteria the Client requires for deliverables.

No services are performed without an executed SOW. Email confirmation of an SOW with the Client's authorized signatory is acceptable; we will follow up with a formal countersignature for the record.

3. Change requests

Changes to scope, timeline, or fees are made through a written Change Request that we both sign. Verbal agreements to changes are not binding until reduced to a Change Request. We will not perform out-of-scope work without a Change Request, and we will not invoice for it.

Example 05 · Healthcare SaaS

Cedar Health

Privacy Policy · 1320 words

B2B healthcare SaaS handling protected health information (PHI) on behalf of US covered entities. HIPAA + state-law overlay.

Audit passed Free preview · $2
Jurisdictions
USCA
Documents in this archetype
Excerpt · first three sections anonymized

Privacy Policy

Effective date: January 1, 2026

Cedar Health, Inc. ("Cedar", "we", "us") provides a clinical-workflow product to medical practices and other healthcare providers. This policy describes the personal information we collect from visitors to cedarhealth.example, from users of the product (clinicians, administrators, billing staff), and from prospects who contact us — and your rights over that information.

Important scope note: when Cedar processes Protected Health Information ("PHI") on behalf of a customer that is a HIPAA covered entity, we do so as a Business Associate under a Business Associate Agreement ("BAA") signed with that customer. In that role, the customer is the controller of the PHI; their own Notice of Privacy Practices governs patient relationships; and our processing is described in the BAA. This Privacy Policy does not modify the BAA.

1. Information we collect

From website visitors

Pages viewed, referring source, browser type, and approximate location derived from IP at city level. Used in aggregate to improve our website. We use a privacy-respecting analytics provider that does not set cross-site tracking cookies.

From prospects

If you contact us, request a demo, or download a resource, we collect your name, work email, organization, role, and any context you provide. We keep this in our CRM (HubSpot) and use it to follow up.

From users of the product

When a customer creates user accounts for their staff, we receive each user's name, work email, role within the practice, and any preferences they set. We also collect:

  • Authentication and session activity (when they log in, from what device).
  • Audit log entries required by HIPAA (every access to PHI is recorded with user, time, action, and the record accessed).
  • Bug reports and support messages.

Protected Health Information

PHI flows through Cedar only as part of the product. Cedar processes PHI strictly as the customer's Business Associate, only for the purposes set out in the BAA and the customer's instructions. The categories of PHI we process are defined per customer in their BAA; commonly they include patient identifiers, appointment information, clinical notes, billing codes, and where the customer's workflow requires, lab and imaging metadata.

We do not use PHI for our own analytics, for product improvement (other than incident debugging strictly scoped to a specific issue), for marketing, or for training AI models. PHI is segregated from operational data at the storage layer.

2. How we use information

We use the information above to:

  • Operate the product (authenticate users, route requests, deliver features).
  • Provide support to customers and respond to user-reported issues.
  • Maintain the audit logs required by 45 CFR §164.312(b).
  • Bill customers (Stripe processes payments under a BAA).
  • Send transactional emails (account confirmations, security notifications).
  • Send product updates only to people who have explicitly subscribed.
  • Comply with our legal obligations (tax records, BAA notification requirements, etc.).

We do not use PHI for any purpose not authorized by the applicable BAA.

3. Subprocessors

We share data with subprocessors only as needed to operate the product. Each subprocessor that may have access to PHI has signed a HIPAA-compliant Business Associate Agreement with us:

Subprocessor Purpose PHI access BAA
Amazon Web Services (HIPAA-eligible services) Hosting, database, storage Yes Yes
Stripe Payments No (PHI not transmitted) Yes
Twilio SMS appointment reminders (where customer enables) Yes Yes
Sentry Error tracking Yes (incidental, scrubbed before retention) Yes
Resend Transactional email Yes (incidental) Yes

A current subprocessor list is maintained at cedarhealth.example/legal/subprocessors. We notify customers at least 60 days before adding a new subprocessor that will process PHI; customers may object as described in their BAA.

Example 06 · EdTech (K-8 learning)

Schoolyard Studio

Privacy Policy · 1380 words

K-8 learning app distributed direct-to-parent and to schools. COPPA + FERPA + EU age-of-consent rules thread through everything.

Audit passed Free preview · $2
Jurisdictions
USEUUK
Documents in this archetype
Excerpt · first three sections anonymized

Privacy Policy

Effective date: January 1, 2026

Schoolyard Studio ("Schoolyard", "we", "us") publishes the Schoolyard learning app for children aged 6–12. We have built the app, and this policy, to comply with children's-privacy laws including the U.S. Children's Online Privacy Protection Act ("COPPA"), the U.S. Family Educational Rights and Privacy Act ("FERPA") when the app is licensed to schools, the EU General Data Protection Regulation (including Art. 8 on the age of digital consent), and the UK Information Commissioner's Office Age Appropriate Design Code.

1. Two paths, two consent models

The app is offered through two distinct distribution paths:

  1. Direct-to-parent (consumer): parents subscribe through Apple App Store or Google Play and create an account for their child. We collect the child's first name and age (no last name, no email). Before any account is created, we obtain Verifiable Parental Consent ("VPC") under COPPA.

  2. School-licensed (classroom): schools license the app under a district-wide agreement. Teachers create accounts for students within their class. We act as a "school official" under FERPA, processing personally identifiable information ("PII") from education records only at the direction and for the educational purposes of the school.

This Privacy Policy applies to both paths, with sections noting differences where they exist. Schools licensing the app additionally receive a Student Data Privacy Agreement (DPA) which controls over this policy for school-licensed accounts.

2. Information we collect

From a parent setting up a direct-to-parent account

  • The parent's email address (for account management and verifiable parental consent).
  • The child's first name only (no last name).
  • The child's age.
  • Subscription receipt from Apple or Google (we never see payment-card data).

From a child using the app

  • Activity within the app (lessons completed, scores, time spent on tasks).
  • Locally stored progress so the child sees their progress on next launch.

We do not collect from children: last names, photos, location data, contact lists, free-form text or audio (the app contains no chat or open-ended input fields), persistent identifiers used across services, or anything that could be combined to identify the child outside our service.

From schools (classroom-licensed accounts)

  • The school's name and administrator contact information.
  • For each student account the school creates: first name, optional last name (the school decides whether to include this), grade level, class assignment, and a student ID assigned by the school's information system.
  • Student activity within the app, as described above.

Schools may provide additional information via roster-sync providers (Clever, ClassLink). The school controls what is shared and we use it only for the purposes described in our DPA.

3. Verifiable parental consent (COPPA)

For direct-to-parent accounts, we obtain VPC before collecting any information about a child. We use one of the methods approved by the FTC, currently the "credit card / debit card" method linked to the App Store subscription (the FTC has approved this method since 2019 for paid services where the parent must authenticate a payment to enable the service).

After consent is given:

  • The parent can review, modify, or delete the child's information at any time from the in-app Parent Dashboard.
  • The parent can revoke consent at any time by deleting the account.
  • We send the parent a confirmation email when consent is given and when material settings change.
The pipeline that produced these

What the audit catches.

Every example above passed three rounds of the same audit you can run for free at /audit. These are the most common gap categories the pipeline flags.

Blocker

Missing required disclosures

CCPA right-to-delete section absent; GDPR legal-basis statement missing for analytics processing.

Blocker

Wrong legal basis claimed

Policy lists "consent" as the basis for processing payment data, where "contract" is the correct GDPR Art. 6 basis.

Gap

Incomplete sub-processor list

Sub-processor table omits the email provider or error-tracking service — common when copy-pasting templates.

Gap

Retention periods unstated

Policy says "we keep data as long as necessary" without specifying durations per category — a frequent regulator finding.

Polish

Conflicting effective dates

Header shows an old effective date while the body references current statutory requirements that postdate that date.

Polish

Pronoun and party-name drift

Policy uses "we", "us", and "the Company" interchangeably without a defined-terms section, weakening enforceability.

Your business is yours, but the structure repeats.

Pick the archetype closest to yours, or start fresh. Free preview, no card required.