Information checked: 21 July 2026.
Securing a website is best treated as a sequence: establish ownership, reduce exposure, protect access, monitor changes and prepare recovery. Make one controlled change at a time and verify that business functions still work.
In brief: Secure the accounts and operating process before adding optional defensive products.
Step 1: secure the control plane
- Confirm business control of the domain, DNS, hosting, CMS, email and payment accounts.
- Replace shared logins with named accounts.
- Enable MFA and store recovery codes securely.
- Remove former staff, expired suppliers and unknown API keys.
Step 2: reduce the attack surface
- Upgrade unsupported runtimes and applications.
- Remove unused software, demo pages, test accounts and public administration tools.
- Restrict file uploads and administrator access where the platform supports it.
- Use secure development practices for custom code and input handling.
Step 3: protect and observe
Operational protections
- TLS and secure cookies
- Purpose: Protect data in transit and sessions; Verification: External test and browser inspection
- Security headers
- Purpose: Tell browsers to apply additional restrictions; Verification: Header scan plus functional test
- WAF or managed protection
- Purpose: Filter selected hostile requests; Verification: Review logs and false positives
- File and account monitoring
- Purpose: Detect unexpected change; Verification: Test alert delivery
- Independent backups
- Purpose: Enable recovery after compromise; Verification: Restore into an isolated environment
Step 4: rehearse the response
Write who can isolate the site, reset credentials, preserve evidence, notify the business and restore service. Test the contact route before relying on it.
Acceptance check
Repeat a full customer journey after security changes and record the configuration, tests, exceptions and rollback instructions.
Make changes in a safe sequence
Security work can break legitimate scripts, forms or payment callbacks. Change one layer at a time, record the previous configuration and test the affected business journey before proceeding. High-risk custom code should be reviewed by a competent specialist rather than “secured” through generic settings.
Records to keep
- Pre-change configuration and backup.
- Security change ticket and approval.
- Functional test evidence.
- Exceptions and temporary controls.
Owner test: After each control is enabled, complete the same enquiry or purchase journey a real customer uses.
Sources and date checked
This practical guidance was checked against the following primary sources. Date checked: 21 July 2026.
Keep the decision under your control
Retain the relevant accounts, source material, supplier terms and recovery information. Recheck changing prices, interfaces and rules before acting.