How to Secure a Business Website

Inventory the website and its owners

Website security is an ongoing responsibility, not a one-time scan. List the domain registrar, hosting provider, application, content management system, plugins, payment provider, analytics, and the people or companies that administer them. Record a current support contact and who can approve an emergency change.

Identify what the site handles: public content, contact enquiries, customer accounts, files, payments, or integrations. Different information needs different controls. A simple brochure site still needs protection from unauthorized changes, while an online store must also consider customer and payment data.

Example: a compromised administrator account

An attacker obtains a reused password for the content management system and changes a payment link. Individual accounts, multifactor authentication, limited privileges, and alerts for important changes can reduce the likelihood or impact. A tested backup and a response plan help the team restore trusted content and investigate what happened.

Protect accounts and access

Use unique accounts and strong passwords managed with a reputable password manager. Enable multifactor authentication for hosting, domain, email, and administration wherever supported. Grant only the access needed for a role and remove access promptly when a person or supplier no longer needs it.

Keep a secure inventory of privileged accounts and recovery methods. Avoid sharing an administrator login among staff; shared accounts make it difficult to establish who made a change. Check that service accounts and API credentials have limited scope and rotate them when exposed or no longer needed.

Patch and configure the application

Keep the operating system, application framework, CMS, themes, plugins, and dependencies supported and updated. Prioritize security fixes using the supplier's guidance and the exposure of the affected component. Test updates in a staging environment when possible, and maintain a rollback plan. Remove unused plugins and accounts rather than assuming an inactive component is harmless.

Use HTTPS throughout the site, redirect ordinary HTTP traffic to the secure canonical address, and monitor certificate expiry. HTTPS protects data in transit but does not make an application immune to account compromise, insecure code, or a malicious administrator. Review security headers and application settings with a qualified developer.

Protect data and forms

Collect only the information needed for the service, validate inputs on the server, and ensure users can access only their own authorized records. Protect administrative functions and uploads, and store secrets outside source code. Review integrations and log access without recording passwords, payment details, or unnecessary personal data.

Use a payment provider's supported integration rather than collecting card numbers in ordinary form fields. Your responsibilities depend on the payment arrangement; review the PCI DSS resources and consult the provider.

Prepare for incidents

Maintain backups separated from ordinary administrator access and test restoration regularly. Agree who can take the site offline, contact the host, preserve evidence, reset credentials, and communicate with affected people. Legal notification duties depend on the incident and jurisdiction, so involve appropriate advisers.

Monitor availability, suspicious login activity, and critical changes, and ensure alerts reach an owner. Rehearse a realistic scenario rather than assuming a backup file is recoverable. The backup and restore guide explains how to test the recovery process.

Review third-party services and recovery

List scripts and services that can execute on the website or receive visitor information. For each, identify its purpose, owner, required permissions, and support contact. Remove integrations that are no longer used and review the effect of a supplier outage. A third-party component can create risk even when the application itself has not changed.

Test a restore into a separate environment and verify both content and functionality. Can staff log in, do forms send to the intended destination, and are uploads present? Record the time taken and the data that would be lost between the last usable backup and the incident. Decide whether those results meet the business's recovery needs, and adjust the backup schedule or procedure if they do not.

Establish a routine

Assign owners to review available updates, administrator access, backup results, certificate expiry, and unusual activity on an agreed schedule. Maintain a change log for production releases and keep the contact details of the host and development supplier accessible during an outage. Confirm that someone else can act if the usual administrator is unavailable.

An automated scan can help identify known issues, but it does not prove a site is secure. Review findings, confirm their applicability, and track remediation. For higher-risk applications, consider a qualified independent assessment with an agreed scope and authorization. Avoid scanning systems you do not own or have permission to test.

When an incident occurs, contain the problem, preserve relevant evidence, and involve the people responsible for legal, technical, and customer communications. Restore only after identifying and addressing the entry point where possible; otherwise the same compromise may recur. Review the response afterward and update the plan based on what the team learned.

Further reading

The NIST Cybersecurity Framework provides a voluntary structure for identifying, protecting against, detecting, responding to, and recovering from cybersecurity risks.