14 Controls for Securing Client Websites in a UK Agency

Securing a client website means protecting the functions and information the business depends on. That includes administration, customer journeys and the accounts controlling the domain and hosting. A security plugin is one possible component, not a substitute for understanding those dependencies.

Start with a small inventory and an agreed division of work. Record the CMS, extensions, access holders, data flows and recovery arrangements. The fourteen controls below form an operational routine for a UK agency; apply them according to the actual application and service, rather than as an identical configuration for every site.

Recognise four common threat patterns

Malware can alter pages, steal information or maintain unauthorised access. Phishing can trick staff into handing over credentials through a fake sign-in page. Password attacks can exploit weak or reused credentials, while abusive bots can submit spam or consume resources.

Those patterns overlap, and none requires a website to be famous. Avoid unsupported claims about which attack is most common for every business. Identify the assets and entry points involved, then select controls that reduce the relevant exposure and support recovery if prevention fails.

1. Use strong, unique credentials

Give important accounts unique passwords stored through an appropriate password manager. Avoid reusing a client’s CMS credential for hosting, email or another customer. Unique credentials help prevent one unrelated compromise becoming access to several services.

Keep ownership and recovery details current. A good password is insufficient if a former contractor still receives reset messages or an insecure mailbox can take over the account.

2. Enable suitable multi-factor authentication

Use supported additional authentication on hosting, CMS, registrar and email accounts, especially privileged ones. Prefer a method appropriate to the service and threat rather than assuming every second step offers identical protection.

Record recovery arrangements securely and test the handover process. Stronger login controls should not make one employee’s phone the only route to recover a critical business service.

3. Maintain the website software

Track supported CMS and application releases, security advisories and update ownership. Test significant changes using an appropriate safe environment and retain a recovery route. Where an urgent vulnerability requires action, do not let an indefinite testing queue become permanent inaction.

Confirm the result after updating. A dashboard showing a newer version does not prove that forms, scheduled tasks and integrations still work.

4. Remove unnecessary components

Review plugins, themes, test applications and abandoned directories. Delete software that is not required through the correct supported procedure, after confirming dependencies and retaining a recoverable copy where needed.

Inactive does not necessarily mean unreachable or harmless. Keep the inventory small enough to understand, and replace essential but unsupported components rather than leaving them installed indefinitely because nobody remembers why they exist.

5. Configure HTTPS correctly

Use valid certificates for the intended website and administration names. Check redirects, renewal and mixed content. TLS protects communication in transit; it does not inspect every plugin or prevent a compromised administrator making harmful changes.

Test actual pages and forms after configuration. A working homepage certificate should not hide a broken secure login or an unprotected hostname used in recovery messages.

6. Establish tested backups

Agree which files, databases, configuration and email are covered. Choose schedule and retention around the acceptable loss and recovery time for the client. A brochure page and a busy order database can require different arrangements.

Protect backup access and retain suitable separation from the live site. Restore a representative copy safely so the team knows recovery works and understands what information would need reconciliation.

7. Use appropriate filtering controls

A network firewall and a web application firewall address different layers. Understand what the service supplies and how application-specific rules are reviewed. Filtering can reduce exposure without eliminating the need to patch vulnerable software.

Monitor false positives. Blocking a legitimate payment callback or customer form can harm the service. Record deliberate exceptions and avoid opening broad access simply to make one error disappear.

8. Limit user privileges

Give editors, developers and clients the access their work requires. Use individual accounts where supported and remove inactive access promptly. A person updating an article rarely needs permission to install code or create other administrators.

Review shared reseller privileges carefully because they may affect several clients. Document who can change DNS, restore backups and alter production software so an urgent request reaches the right person.

9. Protect the email accounts behind recovery

A compromised support or reset mailbox can undermine website controls. Secure the email service, review recovery details and check for unfamiliar forwarding rules or authorised applications where the platform supports those features.

Verify unusual requests through a known channel. A message appearing to come from a client should not automatically authorise a new administrator or a change to domain control.

10. Monitor meaningful activity

Review authentication events, unexpected file changes, errors and suspicious outgoing activity using tools available in the environment. Establish who receives alerts and how they are investigated.

Avoid treating every failed login as a confirmed intrusion or every clean scan as proof of safety. Preserve useful timestamps and evidence, and escalate material findings rather than repeatedly dismissing the same unexplained change.

11. Teach clients the relevant habits

Show clients how to recognise the real login route, request support and report a suspicious message. Explain why credentials should not be sent through casual channels or shared among several people.

Use examples related to their work, such as an unexpected domain-renewal notice. Training should make reporting easier, without blaming someone for asking whether a message is genuine.

12. Apply supported file permissions

Follow application and hosting guidance for ownership and permissions. Keep secrets, exports and private documents outside public delivery where appropriate. Do not make whole directories broadly writable merely to resolve an unexplained error.

Permissions depend on the environment, so avoid copying one numeric setting universally. If the application requires an exception, understand why and restrict it to the necessary scope.

13. Protect login and recovery workflows

Use supported rate limiting, authentication controls and abuse protection appropriate to the application. Test password reset and session termination as well as the login screen itself. Changing a login path may reduce noise but does not repair an underlying authentication weakness.

Keep legitimate access usable. A rule that repeatedly locks out customers or inaccessible challenges can create a different operational problem.

14. Verify the hosting responsibility boundary

Ask who maintains the server platform, investigates account-level incidents and performs restores. Check actual service evidence rather than assuming a low or high price establishes security quality.

For reseller hosting, document the relationship between upstream support and your client communication. Do not promise automatic malware cleanup, a particular backup schedule or UK server location unless the selected service supports the claim.

Turn the controls into a maintained routine

Assign owners and review triggers. Staff departures should prompt access checks; major releases should prompt testing; a new integration should prompt a review of credentials and data flows. Keep the procedure short enough for the team to follow.

If a compromise is suspected, move to an incident process that preserves evidence and coordinates containment before casual cleanup. Security is risk reduction supported by preparation, not a guarantee that a site can never be attacked. A documented routine makes that work visible and repeatable across the client portfolio.