Security audit checklist before you go live

A security audit checklist before you go live is for the week you stop pretending staging is enough, when real users and real data are about to hit the system. This is not a PDF policy pack. It is a short list of things that break launches when nobody checked them.

When this checklist applies

Use it before first paying customers, before a relaunch after an agency handoff, or before you move off a spreadsheet into a portal that holds personal data. Skip the enterprise pen-test theatre. You want go-live hygiene: restore, access, secrets, auth, and someone woken when things fail. I’ve seen launches delayed a week because a backup had never been restored onto a clean copy.

The checklist

Identity and access. Root and break-glass accounts have MFA. No shared “admin” logins. Leavers lose access the same day. Cloud IAM is least privilege for humans and for the app role, not AdministratorAccess because it was faster.

Secrets. Nothing in the repo, not even “temporarily.” CI secrets are scoped. Env files are not on laptops forever. Rotate anything that was in a Slack paste.

Data and backups. You know where production data lives (UK/EU if that is the promise). Backups exist and you have restored one onto a copy. Encryption at rest is on for the database and object store you actually use.

Network and edge. Admin panels are not on the open internet without a gate. TLS is real (full chain, right names). Security groups and firewalls are intentional, not a decade of “open 22 from anywhere.”

App auth and sessions. Password reset and session expiry behave. Cookies are secure where they should be. Unauthenticated visitors cannot reach customer data or admin APIs. Forms reject rubbish instead of trusting the browser.

Dependencies. Known critical CVEs in what you ship are patched or consciously accepted with a date. Lockfiles are committed. Supply-chain surprises are not a mystery.

Logging and alerting. Auth failures, deploy failures, and disk/backup failures make noise somewhere a person looks. You know who gets the 2am page, and they have tested the alert path once.

Incident basics. Named owner for “site down” and “data leak.” A one-page note on how to revoke keys and take the app offline. Support email is monitored.

Good enough to launch vs stop and fix

Good enough: MFA on privileged accounts, secrets out of git, a restore you have done once, TLS and auth not obviously broken, and alerting on the failures that cost money. Launch and schedule the deeper pass.

Stop and fix: secrets in the repo, no restore ever tried, admin open to the world, shared root passwords, or customer data reachable without a login. Those are not “phase two.” Fix them before the marketing site flips the DNS and the first support ticket arrives.

Where DIY ends

A checklist catches the dumb misses. An independent security audit catches the ones you cannot see because you built it: cloud account surprises, network holes, app and API paths, data and continuity. Eight Mile’s audits are run by security-cleared engineers in London. You get a plain-English report, fixes ranked by what to do first, and a retest so you finish with evidence. Soft path when go-live sits on accounts you own: SaaS and infrastructure and cloud.

That is the security audit checklist before you go live in practice: a torch for dumb misses, then an audit as a second pair of eyes that still shows up for the retest.

If you want that report, ranked remediation, and retest before customers arrive, contact Eight Mile and say what is going live.