Website security Website security starts with access, updates, backups and tested ways to recover.
Most of website security is routine, unglamorous and continuous. It is a set of ordinary controls that remain owned when staff change, software updates and a supplier is unavailable. Small businesses benefit most from making those controls visible and repeatable.
Begin with an inventory, not a scanner. Record the domain registrar, DNS, hosting, content system, forms, payment provider, analytics and every account that can publish code or change settings.
Give each person their own account
Shared administrator logins remove accountability and make offboarding difficult. Create individual access with the lowest permissions needed. Remove old users promptly and review privileged accounts on a fixed schedule.
Enable multi-factor authentication on hosting, registrar, code repository, email and administrative access wherever supported. Protect the recovery email and codes as carefully as the main password. A password manager can generate unique credentials without staff inventing predictable variations.
Keep supported software current
List the operating system, framework, packages, plugins and third-party scripts the site relies on. Assign an owner to monitor security notices and test updates. Unsupported components need replacement or an explicitly approved containment plan.
Do not leave updates indefinitely because one change once caused a problem. Use a staging copy, versioned deployment and rollback plan so patches can be applied with controlled risk.
Back up what recovery actually needs
A database backup without uploaded files, configuration or encryption keys may not restore the service. Define the systems, frequency, retention and separate location. Limit access to backup stores and monitor failed jobs.
Schedule a restore test into an isolated environment. Record the time taken, missing dependencies and the point to which data returned. A successful backup notification is not evidence that recovery works.
Reduce exposure at forms and administration
Collect only fields the business uses and validate them on the server. Apply request limits, spam controls and file-type restrictions appropriate to the form. Store uploads outside executable paths and scan them when the workflow requires it.
Administrative routes should use secure transport, strong sessions and protection against forged requests. Avoid exposing debug output, secret keys or customer records in browser code and public logs.
Protect customer and business data
The ICO’s data security guidance describes measures as a risk-based decision rather than a single product. Document what personal information the website holds, why it is there, who can reach it and when it is removed.
Encrypt appropriate traffic and storage, but do not treat encryption as the whole control. Permissions, retention, staff practice and supplier arrangements determine whether protected information is still used safely.
Monitor events somebody can act on
- Repeated failed administrator logins or unexpected account changes.
- New privileged users, deployment keys or DNS changes.
- Malware warnings, altered files and unusual outbound traffic.
- Form delivery failures and sudden spikes in requests.
- Expired certificates, failed backups and overdue patches.
- Payment or integration errors that expose repeated retries.
Send alerts to an owned route with a response expectation. An alert nobody reads adds storage, not security. Keep logs long enough for the assessed need while avoiding unnecessary personal data.
Include suppliers in the control map
Record what the host, developer, platform and business each manage. Ask how urgent vulnerabilities are handled and how access is withdrawn. The contract should not leave both sides assuming the other applies updates or watches incidents.
Write an incident card before an incident
Keep a short, accessible list covering who can suspend the site, reset credentials, preserve evidence and communicate with customers. Include current supplier contacts and decision authority. Do not improvise deletion before logs and affected systems are understood.
Review legal and regulatory notification duties with appropriate advisers for the actual event. After recovery, record the cause, control changes and owner rather than closing the incident when the homepage reappears.
An incident card, used once
A small architecture practice wrote a single-page incident card and put it in the shared drive and on the office wall. Six months later a director clicked a convincing invoice link and entered their email password.
The card said: change the password from a different device, revoke active sessions, check mailbox rules and forwarding, tell the bookkeeper before authorising any payment. phone the accountant on a number from a previous invoice rather than one in an email.
Step three was the one that mattered. The attacker had already added a rule quietly forwarding anything containing the word "invoice" and deleting it from the inbox. Without that step it would have been found weeks later, after a payment had gone to a substituted bank account. The whole response took under an hour, mostly because nobody had to work out the order.
Sources and further reading
- NCSC Small Business Guide — UK National Cyber Security Centre guidance on accounts, backups, devices, malware and incident preparation.
- ICO guide to data security — the primary UK data-protection reference for risk-based organisational and technical measures.
Our website maintenance service can turn this baseline into an owned schedule, evidence log and recovery process for a specific site.
Quick website security action plan
- Use a unique account per person. Write down the result. Name one owner.
- Turn on strong sign-in checks. Test this step. Keep proof of the test.
- Remove old user access. Use real data. Check each fact.
- Apply supported updates soon. Ask one user. Note what feels hard.
- Keep safe off-site backups. Fix each fault. Run the check again.
- Test a full restore. Set a due date. Review the result.
- Protect forms from abuse. Write down the result. Name one owner.
- Write down the incident route. Test this step. Keep proof of the test.
- Choose one clear goal. Use real data. Check each fact.
- Name the owner for each task. Ask one user. Note what feels hard.
- Test the full path before launch. Fix each fault. Run the check again.
- Set the next review date. Set a due date. Review the result.
- Keep the plan where staff can find it. Write down the result. Name one owner.
- Use plain words in each note. Test this step. Keep proof of the test.
- Save proof for each key check. Use real data. Check each fact.
- Fix one issue at a time. Ask one user. Note what feels hard.
- Check the result with a real user. Fix each fault. Run the check again.
- Remove work that does not help the goal. Set a due date. Review the result.
- Share each major change with the team. Write down the result. Name one owner.
- Run the same checks after each update. Test this step. Keep proof of the test.
- Check the source of every key fact. Use real data. Check each fact.
- Keep private data out of public notes. Ask one user. Note what feels hard.
- Plan what to do when a check fails. Fix each fault. Run the check again.
- Give each choice a clear reason. Set a due date. Review the result.
- Keep old files until new work is proven. Write down the result. Name one owner.
- Ask for help when the risk is high. Test this step. Keep proof of the test.
- Check phone and desktop views. Use real data. Check each fact.
- Make the next step easy to find. Ask one user. Note what feels hard.
- Track the result that matters most. Fix each fault. Run the check again.
- Close each task when proof is saved. Set a due date. Review the result.
Use this website security plan as a live check. Keep the notes short. Review the work after each major change.
