Start with a one-page release packet

Before testing individual controls, write down what is being launched. A reviewer should not need to reverse-engineer the application to understand its risk.

The packet should name:

  • the business owner and a technical contact;
  • the intended users and the actions each role may perform;
  • the data the application reads, creates, changes, exports, and deletes;
  • every external service, model, API, database, and scheduled job it depends on;
  • the production environment, repository, deployment method, and support path;
  • the critical workflows that must work for the application to be useful; and
  • the expected impact if the application is unavailable or behaves incorrectly.

Keep links to diagrams, tests, dashboards, runbooks, and approvals in the packet. The packet is the index of the release evidence, not a claim that the evidence exists.

Gate 1: Ownership and scope are explicit

  • A business owner decides who should use the application and what outcomes it supports.
  • A technical owner can deploy, diagnose, disable, and recover it.
  • The owners have agreed on a support channel and response expectation.
  • The application has an inventory of data and external dependencies.
  • Someone other than the original builder can find the repository, production environment, configuration, and runbook.

Stop the launch if nobody accepts operational ownership. A prototype that only one person understands is not ready to become a company dependency.

Gate 2: Identity and authorization match the job

  • Every user has an attributable identity; shared administrator accounts are removed.
  • Roles grant only the actions needed for the job.
  • Authorization is enforced by the server or trusted backend, not only by hidden buttons in the browser.
  • A disabled or departed user loses access.
  • A test user cannot read or change another role's restricted records.
  • Administrative and destructive actions require deliberate confirmation and are recorded.

Choose verification requirements that fit the application's risk. The OWASP Application Security Verification Standard is a current menu of web-application security requirements, not a badge that a team earns by checking a few boxes.

Gate 3: Secrets are managed outside the code

  • API keys, database credentials, signing keys, and tokens are absent from source files, browser bundles, screenshots, logs, and sample data.
  • Development, preview, and production use separate credentials.
  • Each application or job receives the minimum permissions it needs.
  • The owner knows how to rotate and revoke every production secret.
  • Repository history and build output have been checked for accidental exposure.
  • Secret access and administrative changes are attributable.

The OWASP secrets-management guidance covers storage, least-privilege access, rotation, revocation, auditing, and backup considerations. Follow the current instructions for the specific secret manager as well.

Stop the launch if a production secret is embedded in code or sent to the browser when the browser does not need it. Removing the visible string is not enough after exposure; revoke or rotate it and inspect its use.

Gate 4: Production data has a defined lifecycle

  • Test and preview environments cannot silently write to production data.
  • Inputs are validated at the trusted boundary before they reach storage or privileged operations.
  • Schema changes have a migration plan and have been tested against a production-shaped copy that contains no unnecessary sensitive data.
  • Retention, export, correction, and deletion behavior match company policy.
  • Backups cover the state the application cannot recreate.
  • A restore has been performed in a safe environment and its duration and result were recorded.

A backup job reporting success is not restore evidence. The Google Cloud reliability framework explicitly includes testing recovery from failures and data loss. The principle applies regardless of cloud provider.

Gate 5: The build and change path are inspectable

  • The deployed revision can be traced to reviewed source code.
  • Dependency versions are locked or otherwise reproducible.
  • Generated code receives the same review and tests as hand-written code.
  • Automated checks cover formatting or compilation, unit behavior, and the critical integration path.
  • Known high-impact vulnerabilities and unsupported dependencies are triaged before release.
  • The release packet records accepted exceptions, their owners, and their deadlines.

The NIST Secure Software Development Framework provides a common set of secure-development practices that can be integrated into an existing lifecycle. Use it to improve the process, not to imply that one tool or scan makes the application secure.

Gate 6: Critical workflows fail safely

Test the small set of workflows whose failure would cause the most harm or confusion. For each workflow, record the setup, action, expected result, actual result, and evidence.

  • The normal path works with a least-privileged user.
  • Invalid, missing, duplicated, and oversized input is handled deliberately.
  • A dependency timeout or error does not create a false success.
  • Retrying an interrupted action does not create unintended duplicates.
  • Partial failure leaves data in an explainable state.
  • Destructive operations can be cancelled or recovered where the business requires it.

If the application calls a model at runtime, also test empty, malformed, hostile, and unexpectedly long model output. If it does not call a model at runtime, do not add AI-specific tests merely because an agent helped write the code.

Gate 7: Operators can see and explain failure

  • Health, error rate, latency, and critical workflow outcomes are visible.
  • Alerts identify an owner and point to a useful first response.
  • Application events identify the actor, action, target, time, and outcome where those fields are appropriate.
  • Logs exclude credentials, session tokens, and unnecessary sensitive data.
  • Clock, retention, access, and tamper-resistance expectations are defined.
  • The team has simulated a logging or monitoring failure.

Infrastructure logs alone may not explain which user changed a business record. The OWASP logging guidance distinguishes operational, security, audit, and transaction uses and recommends testing the logging mechanisms themselves.

Gate 8: Release, rollback, and data recovery are separate

  • Preview and production are distinct, and only an approved revision can become live.
  • The deploy process records who released which revision and when.
  • A previous application revision can be redeployed without rebuilding it from changing inputs.
  • Database migrations are backward-compatible with the rollback window, or the release has an explicit forward-recovery plan.
  • Rollback has been rehearsed with a harmless change.
  • Data recovery has been rehearsed independently of code rollback.

Redeploying old code does not restore deleted or corrupted records. Conversely, restoring data may make the current code incompatible with that data. Record both procedures and the decision-maker for each. NIST's contingency-planning guidance is designed for federal systems, but its emphasis on coordinated recovery responsibilities, procedures, and technical measures is broadly useful.

Gate 9: There is a plan for the day after launch

  • The team knows how to disable the application or its riskiest capability.
  • The runbook covers common failure, escalation, credential rotation, rollback, and restore.
  • Dependency and platform updates have an owner and review cadence.
  • Usage, errors, access, and accepted exceptions will be reviewed after launch.
  • Ownership transfer or application retirement includes code, data, credentials, documentation, and user communication.

Schedule the first operational review before launch. A concrete date is more reliable than an intention to revisit the application later.

The HowToX stop/go scorecard

Copy this table into the release packet. Replace “evidence” with a durable link, not a sentence saying the item was checked.

Gate Result Evidence Owner
Ownership and scope Pass / Fail / N/A Link Name
Identity and authorization Pass / Fail / N/A Link Name
Secrets Pass / Fail / N/A Link Name
Data lifecycle and restore Pass / Fail / N/A Link Name
Build and change path Pass / Fail / N/A Link Name
Critical workflow tests Pass / Fail / N/A Link Name
Observability and audit Pass / Fail / N/A Link Name
Release and code rollback Pass / Fail / N/A Link Name
Data recovery Pass / Fail / N/A Link Name
Post-launch operation Pass / Fail / N/A Link Name

Do not average the rows into a readiness percentage. Stop when a failed item would allow inappropriate access, expose a production secret, lose important data, make a critical workflow unsafe, or leave the team unable to disable or recover the application. A noncritical exception needs a named owner, written rationale, compensating measure, and deadline.

Run one final recovery-oriented dry run

Before the launch decision, ask someone other than the original builder to use the packet:

  1. Grant a new least-privileged user access and verify the role.
  2. Confirm a disabled test user is rejected.
  3. Rotate a noncritical test credential without editing source code.
  4. Trigger one controlled dependency failure and find the resulting alert.
  5. Find who performed a test administrative change in the event history.
  6. Restore a disposable record or dataset into a safe environment.
  7. Redeploy the previous application revision.
  8. Locate the person authorized to stop the launch.

Record actual results. Failed steps become release work or explicit exceptions; they do not disappear because the rest of the checklist passed.

Frequently asked questions

Does passing this checklist mean the app is secure?

No. It shows that a team collected evidence for a practical release decision. The depth of security review, testing, privacy review, and compliance work must match the data, users, capabilities, and consequences of failure.

Must every item pass before any coworker can use the app?

Not every item has the same risk in every application. Mark an item not applicable only with a written reason. Do not waive a critical failure by assigning it a low numeric score; either fix it, reduce the application's scope, add a reviewed compensating measure, or delay the launch.