Guide · Security
Security checklist before launching a website or app
Launch week is busy, and security checks are easy to postpone "until after launch" — when real customer data is already flowing and attackers' scanners have already found the new site. This checklist covers the essentials to confirm before going live. It complements the functional website launch checklist.
[ 01 ]
In short
In short
- 01
Accounts and access are company-owned, individual and protected by two-factor authentication.
- 02
HTTPS is enforced; security headers are set; admin areas are protected.
- 03
The application validates input on the server and enforces permissions on every request.
- 04
Personal and payment data is minimised, protected and handled according to law.
- 05
Backups, monitoring and an incident plan are in place before launch, not after the first incident.
[ 02 ]
Guide
Access
- Domain, hosting, admin, analytics and ad accounts owned by the company. See access management for teams.
- Individual accounts with minimal privileges; test and default accounts removed.
- Two-factor authentication on all critical accounts.
- Secrets and API keys stored in secure configuration, not in the code repository.
HTTPS and headers
- HTTPS on all pages and subdomains, with redirects from HTTP and a valid certificate that renews automatically. See HTTPS and SSL certificates.
- Security headers configured where appropriate: Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, frame protection, Referrer-Policy.
- Cookies with Secure, HttpOnly and SameSite attributes where relevant.
Server and infrastructure
- Software on supported versions with current security updates.
- Only necessary ports open; databases not exposed to the internet.
- Admin panels and staging protected — by authentication and, where possible, network restrictions.
- Directory listing disabled; error messages do not reveal internals.
- DDoS and web application firewall protection for public sites. See DDoS protection.
Application
- Server-side validation of all inputs.
- Protection against injection and cross-site scripting through framework defaults and review.
- Authorisation checks on every request — users cannot access others' data by changing IDs.
- Rate limits on login, registration, password reset, contact forms and APIs.
- Secure password storage and reset flows.
- File uploads restricted by type and size, stored safely.
- Dependencies checked for known vulnerabilities.
Data protection
- Only necessary personal data collected; privacy policy published. See privacy policy.
- Consent captured where required.
- Access to personal data limited by role and logged.
- Card data handled only by the payment provider. See PCI DSS for online stores.
- Staging does not contain unprotected real personal data.
Backups and recovery
- Automated backups off the server, with at least one immutable or separate-account copy.
- A successful test restore before launch. See backup strategy.
Monitoring and logging
- Uptime, certificate and domain expiry monitoring.
- Error and security event logging with alerts.
- Alerts for failed backups and integrations. See 24/7 monitoring.
- SPF, DKIM and DMARC configured for all sending services. See email domain security.
Incident readiness
- A short incident plan: who to call, what to do first, how to communicate.
- Contacts for hosting, CDN, payment provider and developers.
[ 03 ]
FAQ
Frequently asked questions
Is a penetration test needed before launch?
For systems handling sensitive data or payments at scale, it is worth doing. For typical business websites, this checklist and a security review cover the main risks.
Who is responsible for these checks?
The development team implements them; the business owner should confirm that they were done. A written checklist with sign-off makes it clear.
What if we launch before everything is done?
Prioritise: access, HTTPS, updates, backups and monitoring first. Record remaining items with deadlines.