Privacy Checklist

Begin Before Collection

Privacy work starts with a refusal: do not collect data simply because a form, analytics tool, model provider, or imported spreadsheet makes it available. Begin with one product capability and ask what it cannot do without. Every retained data item should have a present purpose, not a possible future use.

This review follows personal or sensitive data through one feature from collection to disposal or justified retention. That includes obvious identifiers, customer-uploaded records, device and location data, support attachments, behavioral events, derived scores, and combinations that can be linked back to a person. It also includes copies that disappear from the main database but remain in logs, analytics, object storage, exports, vendors, or backups.

The checklist helps a founder expose product and engineering decisions. It is not a legal conclusion. Duties vary with the people, data, purpose, and jurisdictions involved. Products involving children, health, finance, biometrics, precise location, employment, regulated records, surveillance, or severe consequences need qualified privacy and legal review before real people depend on them.

Write the Data Promise

Choose one feature: account creation, file import, product analytics, AI assistance, team invitation, support diagnosis, or customer export. Complete this sentence in language a user could understand:

To provide [specific outcome], we use [specific data] for [specific purpose], allow access by [people and services], keep it until [event or period], and remove it by [deletion path].

If that sentence requires “and anything else we may find useful,” the feature has no defensible boundary yet. If the product works with less data, collect less. If it works with aggregate, redacted, synthetic, local, or short-lived data, prefer the form that creates less exposure.

Copyable Privacy Review

Complete one review per materially different data path. Use exact stores, vendors, roles, and events. “Industry standard,” “encrypted,” and “deleted on request” are not evidence by themselves.

# Privacy review: [feature or customer action]

Review date:
Owner:
Release or change being reviewed:
People whose data is involved:
Applicable market or jurisdiction assumptions:
Qualified review needed because:

## Purpose and necessity
Product outcome:
Data item or category:
Whose data it is:
Why this item is necessary now:
What fails if it is absent:
Less identifying or shorter-lived alternative considered:
Decision: collect | narrow | derive without retaining | do not collect

## Source, expectation, and permission
Source: supplied directly | imported by a customer | observed | inferred
What the person is likely to expect:
Notice shown before collection or use:
Choice, permission, or other required basis:
How a changed purpose would be reviewed before reuse:

## Data path
Collection point:
Application and database stores:
Files and object storage:
Logs, analytics, monitoring, and support tools:
AI or automation providers:
Other vendors or subprocessors:
Exports, webhooks, emails, and other disclosures:
Backups and replicas:
Countries or regions involved when relevant:

## Access and customer control
Customer roles with access:
Founder, support, or administrator access:
Service identities with access:
How access is granted, recorded, reviewed, and revoked:
How a person can correct or update inaccurate data:
How an authorized customer can obtain an export:
How identity and authority are verified for a request:

## Retention and deletion
Retention reason:
Deletion trigger and deadline:
Main-record deletion path:
Logs, analytics, search indexes, caches, and file copies:
Vendor deletion path:
Backup expiry or deletion behavior:
Required exceptions, owner, and end condition:
Evidence from the most recent deletion test:

## Risk and decision
Credible harm from collection, inference, misuse, disclosure, or persistence:
People who bear that harm:
Product or technical change that reduces it:
Mismatch between actual practice and customer-facing notice:
Release blockers:
Owned follow-up and review trigger:
Decision: release | release after blockers | narrow feature | do not release

For multiple data items, repeat the purpose-and-necessity block rather than giving a broad purpose to the entire database. An email address used for sign-in, billing contact, product announcements, and behavioral profiling represents several uses. Each use needs its own justification and boundary.

Trace the Copies People Forget

Start at the collection point and follow the data through actual execution. A browser may send an uploaded file to object storage while its filename enters a database, its contents enter an AI provider, a failed row enters an error tracker, and the entire request enters a debug log. Deleting the database row reaches only one of those copies.

Inspect configuration and a real test record. Ask each vendor what it receives, whether it uses the data for its own purposes, how long it retains the data, which region processes it when that matters, and how deletion propagates. Record uncertainty as a blocker when the answer could change a user’s decision to trust the feature.

Access deserves the same specificity. “Only the founder” is broad access, not a control. Name which interface or credential grants access, when it is needed, what evidence it leaves, and how it can be revoked. Support convenience is not a standing reason to expose every customer’s content.

Make Retention an Executable Rule

“Keep while needed” cannot drive a deletion job. Tie retention to an event or a defined period: an abandoned import, the end of a trial, account closure, completion of a support case, or expiry of a recovery window. Then decide what happens to derived data, exports, backups, legal or contractual holds, and vendor copies.

A deletion promise is ready only after a test record has traveled through the real path and the founder has checked every expected destination. Some backups expire on a schedule rather than supporting selective removal; say so accurately, restrict their use, and ensure deleted data does not quietly return during restoration. Where a copy must remain, record the reason, access boundary, owner, and event that ends the exception.

Export and deletion are authority-sensitive actions. Verify that the requester may act for the person, account, or workspace before releasing or destroying data. A fast privacy workflow that exports one customer’s records to another customer is a security failure.

Worked Review: An Agency Report Import

Consider the reporting product from the Security Checklist. An agency uploads a spreadsheet to produce a client report. The spreadsheet contains client names, email addresses, campaign metrics, free-text notes, and several unused columns copied from the agency’s CRM.

The naive choice is to keep the original file indefinitely because it may help support or future analysis. The privacy review changes the feature. The report needs campaign metrics and a stable client reference, but it does not need email addresses or unrelated CRM columns. The import rejects or discards those fields, replaces the client name with an account-scoped reference where the name is unnecessary, and prevents free-text notes from entering analytics and error reports.

The agency still needs time to identify a bad import, so the founder chooses a short, stated recovery window for the source file rather than permanent retention. The product shows that window before upload, restricts the file to the agency workspace and narrowly controlled founder support, and deletes it automatically when the window ends. Generated reports follow the workspace’s separate retention rule. The founder tests account deletion against the database, object store, search index, analytics events, support attachments, vendor path, and backup-expiry behavior.

Those choices are illustrative, not a universal policy. Another product may need different fields or retention because its promise and obligations differ. The review succeeds because each choice can be connected to a product need, inspected in the system, explained to the customer, and revisited when the feature changes.

Decide Before Deployment

Do not approve a feature while its actual data path contradicts its notice, its necessary data cannot be distinguished from convenient data, or deletion depends on remembering a manual tour of hidden copies. Narrowing the feature, removing a vendor, shortening retention, or declining a customer segment may be the responsible product decision.

Privacy is not complete when the checklist is full. It is credible when the product collects only what its current promise needs, behaves as described, gives authorized people meaningful control, and can prove that unwanted data stops traveling and is removed on the stated schedule or held only under a bounded exception. Carry the resulting code, configuration, migration, and deletion-job changes into the Deployment Checklist before release.