A startup privacy policy checklist you can finish

A startup privacy policy checklist you can finish is a short operating list: inventory personal data, write plain disclosures, set retention and deletion, lock access, and rehearse incident steps. You walk the list once with the people who touch customer or employee data, write what is true today, and put a review date on the calendar. The point is a usable first policy, not a polished brochure.

Many early teams ship a privacy page copied from a peer and never map it to their own systems. That gap shows up when a customer asks where their data lives, a contractor keeps a spreadsheet of emails, or a laptop with export files goes missing. The Federal Trade Commission (FTC) Protecting Personal Information guide for business, as of November 2026, still frames the work as five habits: take stock, scale down, lock it, pitch what you no longer need, and plan ahead for incidents.

This post is not legal advice. Privacy and breach rules vary by state, country, and product category. Check with counsel before you publish, promise, or notify. Use the checklist even if you never open a product for policies. Where Nautis appears, it is one place to keep the working notes, signed acknowledgements, shared files, and secrets that the policy depends on.

What a finished startup privacy policy checklist covers

A finished checklist answers five questions in writing:

1. What personal data do we collect, and from whom?
2. Why do we collect each field, and where does it sit?
3. Who inside and outside the company can see it?
4. How long do we keep it, and how do we delete it?
5. Who leads if something goes wrong, and whom do we notify?

If any of those five is blank, you have a vibe page. Fill the blanks before you link the policy in a signup form. Pair the policy work with cybersecurity basics founders should fund first so the words match the controls you actually pay for.

Founder scenario (example): Lena's three-person B2B tool collected work emails, calendar metadata for scheduling, and support chat transcripts. Her public policy still claimed "we never share data with third parties" while a marketing tool ingested every signup. She rewrote the disclosure line to name the tool and the purpose, cut an unused phone field from the form, and booked counsel for a one-hour review. That is a finished checklist pass even before the lawyer redlines tone.

Inventory every place personal data lands

Start with a data map, not with marketing copy. The FTC take-stock step asks you to know what personal information you hold and who can reach it. Walk sales, support, product, hiring, and vendors. List systems, exports, and people, not slogans.

Capture at least:

• Collection points: website forms, checkout, support chat, waitlists, demo booking, hiring applications, invoices
• Stored fields: name, email, phone, company, billing identifiers, device or log data, resumes, investor contact notes
• Locations: production database, analytics, email provider, customer relationship management (CRM), shared drives, founder laptops, contractor tools
• People with access: founders, engineers, contractors, advisors with inbox access, vendors with admin seats

Write one row per data type. Mark whether you still need it. The FTC scale-down rule is blunt: if you lack a legitimate business need for sensitive personally identifying information, do not keep it, and do not collect it. Social Security numbers belong only to required lawful uses such as tax reporting, not as casual customer identifiers.

Example inventory rows (illustrative only):

When a row says "no," schedule deletion the same week. Do not leave "maybe later" piles that become breach fuel.

Disclosure table for what you tell users

Your policy must match the inventory. Build a disclosure table before you write paragraphs. Each row states the data, the purpose, the legal or practical basis you rely on in plain words, the processors involved, and whether the field is optional.

These rows are examples. Replace processor names with your real vendors. If a vendor appears in the table, it must appear in the policy. If a field is optional, the form must not force it. If you later add a feature that collects new personal data, add a row the same day and bump the policy version.

Keep disclosures short and specific. "We may share information with trusted partners to improve our services" fails a buyer who asks which partners. Name categories and, when practical, the vendor. When you use signed processor terms, store the executed Portable Document Format (PDF) file where operators can find it. DocSign for startup contracts is the pattern for getting those acknowledgements off email threads and into a tracked status.

Retention windows you can defend

Retention is a calendar, not a hope. The FTC asks companies that must keep information for business or legal reasons to write what must be kept, how it is secured, how long it stays, and how it is disposed of when the need ends. Pitch what you no longer need: shred or securely erase paper and media; do not leave identifiers in trash or retired drives.

Write retention as rules with owners:

• Account profile data: keep while the account is active, then delete or anonymize within a stated window after closure (example: 30 days for product data, longer only where law or dispute requires it)
• Support transcripts: keep for a stated window after ticket close (example: 12 months), then delete
• Marketing leads who never bought: delete or suppress after a stated quiet period unless they re-consent
• Hiring resumes for people you did not hire: delete after a stated window (example: 90 days) unless a claim requires longer hold
• Backups: note that deleted records may persist until backup rotation finishes, and state that window honestly

Label every example figure as an illustration. Your counsel and your regulators care about the rule you publish, not a peer's blog number. Pair retention with a deletion runbook: who clicks delete, which systems must be touched, and how you confirm the row is gone.

Access, secrets, and contractor boundaries

A policy that promises limited access fails when every contractor has production admin and passwords live in a shared note. Follow least privilege: each person gets only what their job needs. Prefer unique secrets you can revoke. Prefer multi-factor authentication (MFA) on accounts that hold customer data, which matches both common security practice and the FTC lock-it guidance on stronger electronic controls.

Practical access checklist:

1. List admin seats on every system that holds personal data
2. Remove alumni and unused vendor seats the same week someone leaves
3. Store production secrets in a vault, not in chat or a wiki page
4. Separate investor contact lists from product customer exports
5. Train anyone with access on phishing and export rules in one short session

In Nautis, keep shared passwords, API keys, and certificates in the Credentials vault so values are encrypted at rest and visible only to people granted access. Put the living policy draft and the inventory table in Notes with a clear owner. Keep vendor and counsel contacts in Contacts so the incident call tree is not trapped in one founder's phone. When you share diligence files that include policy versions or signed processor agreements, use Data rooms with their own sharing rules and activity log rather than a public link dump.

Incident steps written before a scare

Plan ahead before you need the plan. The FTC incident guidance is concrete: designate a senior owner, disconnect a compromised machine from the network, investigate quickly, close the hole, and consider whom to notify inside and outside the company. Many states and federal regimes have breach notice rules. That is why counsel belongs on the call tree from day one.

Write a one-page incident card:

• Owner (example: chief technology officer (CTO)) and backup (example: chief executive officer (CEO))
• First hour actions: preserve logs, revoke keys, isolate devices, pause risky automations
• Evidence to capture: time detected, systems touched, data types at risk, whether encryption applied
• Notify list: counsel, co-founders, affected customers when required, insurers if you have a policy, law enforcement when advised
• Public voice: who may speak, and a rule that no one improvises on social channels

Rehearse once with a tabletop story (example: contractor laptop with a comma-separated values (CSV) file of emails is stolen from a car). Time how long it takes to revoke access and find the last export. Fix the slow step while the scare is still fake.

Publish, version, and keep the policy alive

Ship the policy on a dated page. Link it from signup, checkout, and the site footer. Record the version and the date in the same note as the inventory. When product or vendors change, update the disclosure table first, then the prose, then the published page.

Before publish day:

• Diff the policy against the current inventory and disclosure table
• Confirm every named vendor still has a live contract or terms uniform resource locator (URL)
• Confirm deletion and retention owners are still at the company
• Send the draft to counsel with a short list of open questions
• Store the approved PDF and the redline pack where the team can find them

Company formation and early governance already force you to keep evidence buyers and banks can open; see the legal checklist for forming a United States (US) startup. Privacy artifacts belong in that same evidence habit. For plan limits and workspace features while you centralize notes and vaults, see pricing.

A startup privacy policy checklist is finished when the inventory, disclosures, retention rules, access list, and incident card all match what the company does this month. Write the truth, check with counsel, version the page, and schedule the next review. Hope is not a privacy program.