Every production deployment carries the risk of introducing a regression. Without a documented rollback mechanism, a bad deploy becomes a multi-hour incident requiring manual intervention with no defined process. NIST CSF 2.0 RC.RP (Recovery Plan Execution) and ISO 27001:2022 A.5.29 both treat recovery procedures as mandatory controls. The operational reality: Vercel instant rollback takes 30 seconds and requires no technical expertise; discovering you have no rollback path during a production incident adds panic on top of an already stressful situation.
Medium because lacking a rollback plan converts routine deployment regressions into open-ended manual incidents with no defined recovery path per NIST CSF RC.RP.
Confirm the hosting platform supports instant rollback (Vercel, Netlify, Fly.io all do) and document the procedure. Tag the pre-launch commit for a clear recovery reference point.
# Vercel — instant rollback via CLI
vercel rollback
# Or from the Vercel dashboard: Deployments > previous deploy > Promote to Production
# Tag the pre-launch state in git
git tag v1.0.0 && git push origin v1.0.0
For projects with database migrations, rollback is more complex: a code revert does not revert schema changes. Verify your migration tool supports migrate down (Prisma does with some caveats), and test the rollback path on staging before launch. Add a 5-line rollback note to your README — even "go to Vercel dashboard > previous deploy > Promote" is enough to prevent a panic.
ID: pre-launch.final-verification.rollback-plan
Severity: medium
What to look for: Count all deployment-related configurations and scripts. Enumerate whether a rollback mechanism exists (Vercel instant rollback, git revert workflow, blue-green deployment). Check for deployment history or rollback capability evidence. Check if the project uses platform deployments that support instant rollback (Vercel deployments list, Netlify deploy history). Check for git tags or release branches indicating versioned releases. Check README or documentation for rollback procedures. Check for database migration strategy that supports rollback (Prisma migration with down migrations, or documentation of rollback approach).
Pass criteria: The project is deployed on a platform with instant rollback capability (Vercel, Netlify, Fly.io all support this), OR rollback procedures are documented, OR git tagging strategy enables easy rollback identification. For projects with a database, also verify whether database migrations support rollback (down migrations exist, or migration tool supports migrate down). A Vercel deployment rollback does not roll back database schema changes — a bad migration can cause data loss even after code revert. If the project has database migrations but no down migration or rollback procedure, note this in the detail field as a partial pass. At least 1 rollback mechanism must be documented or configured.
Fail criteria: No evidence of rollback capability — a bad deploy would require manual intervention with no clear recovery path.
Skip (N/A) when: Never — even simple projects benefit from knowing how to undo a bad deploy.
Cross-reference: For database backups that support rollback, see db-backup.
Detail on fail: "No rollback plan or capability found — a bad production deploy would require manual recovery with no defined process"
Remediation: Something will go wrong after launch. Having a rollback plan means the difference between a 5-minute outage and a 2-hour panic:
# Vercel — instant rollback to previous deployment
vercel rollback
prisma migrate rollback before launch. For Supabase, test that reverting a migration doesn't destroy data.git tag v1.0.0 so you have a clear point to revert to.