Security Audits in Waves: Triaging Findings by Severity Pre-Launch

Security work that happens as a single pre-launch checklist pass reliably misses things, because a checklist assumes you already know what to look for. Real hardening in production systems tends to happen in distinct, numbered waves, each one driven by an actual audit, with findings graded by severity and fixes re-audited afterward. A real sequence looked like this: a wave adding an admin API with audit logging and plan gating. A separate wave covering GDPR compliance, disaster recovery, and database row-level security enforcement together, account deletion and data export flows, automated backups, and RLS enforcement across tenant-scoped tables. A dedicated wave closing out pre-launch audit findings, explicitly graded and tracked by severity tier (critical, medium, low, using labels like C1, C2, M1, L1, L2). And a hardening pass specifically on the install script, removing a JWT-in-URL fallback that had been sitting there as an overlooked credential leak. The severity-grading discipline is the part worth adopting even outside security specifically. When an audit (yours or a third party's) produces a findings list, don't work it in discovery order, grade every finding by real exploitability and impact first, fix critical and high findings before medium and low ones, and re-audit after the fix wave to confirm closure and catch anything the fixes themselves might have introduced. This is a repeatable cadence, not a one-time gate, especially valuable to re-run after any major architecture change like adding multi-tenancy or a new external-facing surface.