Security Checklist

Begin With One Customer Action

The dangerous threshold is not a large launch. It is the first time a user trusts the product with something they cannot easily take back: a private document, a payment action, an access token, a client record, or authority over another system.

A security review should follow that trust through the product. Pick one action such as uploading a file, inviting a teammate, connecting an account, or exporting customer data. Trace what receives it, where it travels, what stores it, who can retrieve it, what gets logged, and how the system recovers when something fails. A generic inventory of controls can look complete while leaving the most important path undefended.

This checklist establishes a minimum defensible boundary for a small product. It is not a penetration test, compliance assessment, or promise that the product is secure. Products involving health, finance, children, critical operations, regulated data, or unusually severe harm need qualified review and a higher bar.

Name the Harm Before the Control

Write the three most credible ways the chosen action could hurt a customer. Use consequences, not attack vocabulary:

• one customer can read or change another customer’s records;
• a stolen founder account gives an attacker unrestricted production access;
• a leaked integration token exposes a customer’s external system;
• corrupted or deleted records cannot be restored;
• an intrusion remains invisible until a customer reports it.

Severity and exposure determine the work. A launch blocker is a plausible failure with serious harm and no effective barrier or recovery path. A lower-risk weakness may enter the hardening queue with an owner and trigger. “Later” is not a decision until it says who will revisit the risk and what evidence will make it urgent.

Copyable Security Review

Complete the review for one customer action. Record evidence you inspected—a test, configuration, log query, restore result, or access review—rather than writing “implemented.”

# Security review: [customer action]

Review date:
Owner:
Release or change being reviewed:

## Scope
Customer action:
Sensitive data or authority involved:
Entry point and trust boundaries:
Systems and vendors touched:
People and service identities with access:
Three credible customer harms:

## Identity and sessions
[ ] Every human and service is identifiable; shared accounts are removed.
[ ] Login, account recovery, and session invalidation have been exercised.
[ ] Privileged accounts use stronger protection, including MFA where supported.
[ ] Authentication failures and abuse are limited or surfaced without locking
    legitimate users out indefinitely.
Evidence:

## Authorization
[ ] The server checks permission for every protected action and object.
[ ] Access is denied when a role, tenant, ownership, or policy fact is missing.
[ ] Tests attempt cross-account reads, writes, exports, and guessed identifiers.
[ ] Founder and support access is narrow, attributable, and revocable.
Evidence:

## Inputs, outputs, and files
[ ] Untrusted input is constrained by expected type, length, format, and size.
[ ] Database and command operations do not concatenate untrusted input.
[ ] User-controlled output is encoded for the context where it is rendered.
[ ] Uploads have explicit type, size, storage, serving, and deletion rules.
[ ] Errors reveal enough to help the user without exposing secrets or internals.
Evidence:

## Secrets, dependencies, and infrastructure
[ ] Production secrets are absent from source, images, logs, and client code.
[ ] Each secret and service identity has only the access it needs.
[ ] Important credentials can be rotated and revoked without guesswork.
[ ] Dependencies and public services have an owner and an update or alert path.
[ ] Production data and administrative surfaces are not public by convenience.
Evidence:

## Data and recovery
[ ] Data is protected in transit and in the product's stores and backups.
[ ] Collection and retention are limited to what the product currently needs.
[ ] Backups are access-controlled, and a restore has been tested.
[ ] Destructive operations require the intended authority and leave evidence.
Evidence:

## Detection and response
[ ] Logs capture relevant authentication, authorization, admin, and data events.
[ ] Logs exclude passwords, tokens, private content, and unnecessary user data.
[ ] A useful signal reaches a person who can act; it is not merely stored.
[ ] The founder can revoke access, contain the system, preserve evidence,
    restore service, and contact affected customers without inventing the plan
    during the incident.
Evidence:

## Decisions
Release blockers:
Accepted risks and reasons:
Hardening work, owner, and trigger:
Next review event:
External review needed because:
Decision: release | release after blockers | do not release

The checklist separates authentication from authorization deliberately. Knowing who made a request does not prove that the person may act on this tenant, record, export, or administrative function. Exercise the permission boundary from the server side, including failure paths; hiding a button is not an access control.

Worked Review: A Client Report Upload

Suppose a solo founder runs a reporting product for small agencies. An agency user uploads a client spreadsheet, the product produces a report, and a teammate can download it. The trace crosses the browser, upload endpoint, object store, background worker, database, report store, and email notification.

The founder identifies three immediate harms: a guessed report identifier crosses agency boundaries, an object-store link remains public after logout, or compromise of the founder’s admin account exposes every agency. The review therefore blocks release until server-side tenant checks cover upload, status, and download; stored objects are private and delivered through bounded access; cross-tenant tests fail; and the founder account uses a unique identity with MFA and a tested recovery path.

Other findings do not disappear, but they receive proportion. Dependency alerts can become owned hardening work before the next release. A restore test remains a blocker if these reports are the only copy of paid customer work. A log that records report IDs and permission failures is useful; a log that copies spreadsheet contents or access tokens creates another exposure.

The result is not “security complete.” It is an inspectable release decision tied to this product path, this damage, and this evidence.

Make the Decision

Release only when every credible high-harm failure has either an effective control and recovery path or a reasoned boundary that removes the exposure. Record lesser risks with an owner and an event that forces review: a new data class, integration, administrative role, customer promise, incident, or material increase in usage.

Run the checklist again for each materially different trust path. Then use the Privacy Checklist to question whether the product should collect and retain the data at all. Security protects a justified data path; it cannot justify creating one.