# Pre-Release Security Checklist

> **Intro:** Use this checklist right before launch, rollout, or a risky production change. The goal is not perfect security; the goal is to avoid shipping known, high-leverage problems.

## Best time to use this checklist

Use it for major releases, high-risk features, public API changes, admin workflows, payment flows, auth changes, or any change that expands authority or exposure.

## Stop-the-line conditions

* no meaningful rollback or kill switch for a risky feature;
* unresolved broken authorization, authentication, secret exposure, or public storage issue;
* no logging or owner for a feature that handles sensitive actions;
* a major trust-boundary change that nobody actually reviewed.

## Text-first review prompts

* What changed in authority, exposure, or data flow?
* Which findings are still open, and which of them are truly release-blocking?
* What is the rollback plan, and who can execute it?
* What feature flag, sync window, or deployment control limits the blast radius?
* What logs, alerts, or dashboards will confirm normal behavior after release?
* Who is on the hook if this breaks in production?

## Evidence table

| Control area     | What to verify                                                                                                | Typical evidence                            |
| ---------------- | ------------------------------------------------------------------------------------------------------------- | ------------------------------------------- |
| Release blockers | Critical authz/authn, public secret, or exploitable tenant-boundary issues are closed or consciously accepted | ticket list, review notes, exception record |
| Rollback         | The rollback path is tested, understood, and owned                                                            | runbook, deployment record                  |
| Observability    | High-value events are logged and visible                                                                      | dashboard, alert, log sample                |
| Approval         | Required approvers and release controls are in place                                                          | pipeline approvals, change ticket           |
| Blast radius     | Rollout strategy limits impact if behavior is wrong                                                           | feature flag, canary, staged rollout plan   |

## Common misses

* treating “no open critical findings” as the same thing as “safe to release”;
* shipping a new admin action without clear logs;
* assuming rollback works without checking data-migration or config side effects;
* forgetting that a third-party integration change can widen exposure even without code changes.

## Related pages

* [Production Readiness Security Checklist](/learning-labs-interview-and-templates/index-3/production-readiness-security-checklist.md)
* [Cloud Change Review Checklist](/learning-labs-interview-and-templates/index-3/cloud-change-review-checklist.md)
* [Product Security Incident Response Playbooks](/attack-paths-testing-detection-and-hardening/index/product-security-incident-response-playbooks.md)

\---*Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.*


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/learning-labs-interview-and-templates/index-3/pre-release-security-checklist.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.