Website security depends on decisions throughout planning, development and operation. Define the information, access and recovery requirements before treating a plugin or platform label as the solution.
Limit what the website needs to collect
Map each form and connected service to a business purpose. Request only the information needed for the task and explain how it will be handled. Keep confidential files and account credentials out of general public enquiry routes.
Identify who controls the information and how access is approved or removed. A public content editor, an application administrator and a customer account need different permissions. Do not assume one broad role is convenient enough to justify unrestricted access.
Choose supported components and clear ownership
Use maintained software and assess dependencies for the actual requirements. Both established platforms and custom code need updates, access controls and operational support. A small component list does not by itself prove a smaller practical risk.
For WordPress, the official hardening handbook provides platform guidance. Apply recommendations with an understanding of the hosting and application rather than copying configuration changes into production without testing.
Test access and failure behaviour
Acceptance checks should include denied access, invalid input, duplicate requests and recovery routes where relevant. Use safe test data and controlled environments. A form displaying a success page does not establish that the message reached the intended mailbox.
Record findings with enough context to reproduce and verify the correction through an authorised process. Do not expose internal errors or sensitive diagnostic data in public responses.
Plan updates and a recoverable release
Keep source, deployment and hosting responsibilities explicit. Take suitable backups and test restoration. A rollback plan should identify the files, data and configuration required, not just a screenshot of the previous design.
Security headers and transport settings can help, but they need to match the application. A header checklist or an HTTPS padlock is not a complete security assessment.
Maintain the arrangement after launch
Review accounts, dependencies, logs and important journeys according to the site’s needs. Establish who investigates alerts and handles an incident. Revisit the plan when new functionality or third-party processing changes the information handled.
See website maintenance for ongoing responsibilities and security review scope for assessment questions. This guide describes principles; live-system decisions need appropriate technical judgement and authorisation.
