Website stewardship guide 04
Website security starts with knowing who can change your site, which software it depends on, and where customer information goes. Protect those connections, give alerts an owner, and agree what your team will do if something looks wrong.
← All website stewardship guidanceKnow the accounts
Limit access
Remove unused features
Watch useful alerts
Plan for a problem
Why this matters
A site with no customer login still depends on domain, hosting, deployment, and administrator accounts. It may also connect to forms, analytics, maps, and booking services. HTTPS protects the connection to the website, but it does not prevent someone with a stolen administrator login from changing the site.
The right controls depend on what your site does. A basic informational site and a system accepting customer files have different exposure. Your provider should explain the important risks in plain language, reduce unnecessary features, and make sure there is someone to contact when a warning needs investigation.
Responsible practices
Remove unused plugins, abandoned test sites, obsolete integrations, and former staff accounts. This reduces the attack surface: the places someone could try to gain access or misuse the system. Ask the provider to check that backups, private files, and administrative tools are not accidentally public.
Use individual logins and multifactor authentication, especially for the registrar, email, hosting, and website administration. Least privilege means giving each person only the permissions their work needs. Prefer phishing-resistant sign-in methods where supported, and keep a recovery route that the business controls. At the registrar, turn on registrar lock and automatic renewal so the domain cannot be moved or lapse without notice.
The security baseline is the set of protections your provider expects to remain in place: supported software, appropriate permissions, HTTPS, protected secrets, backups, and suitable monitoring. Have the provider recheck it after changes. Tools that publish the site need protection too; a locked-down website can still be altered through a poorly protected deployment account.
Ask what a form collects, where the information is stored, who can read it, and when it is removed. Collect only what the request needs. Your technical provider should validate incoming data and limit abuse without making the form unusable. Sensitive submissions should not spill into analytics, public URLs, or unnecessary logs.
Choose alerts someone can act on, such as unexpected administrator changes, failed delivery, and relevant software advisories. Keep an incident runbook: a short set of contacts, authority, and response steps for a suspected problem. It should address evidence preservation, containment, recovery, and any customer-data questions that need qualified help.
Worked example
Illustrative response exercise. The right action depends on the service and the suspected incident; use your agreed incident plan and the provider's verified support channels.
The useful preparation is knowing whom to call and who can authorize action. An owner should not have to improvise technical incident response.
Security baseline
Confirm who can change the domain, website, and hosting account.
Enable suitable multifactor authentication and review former staff or provider access.
Turn on registrar lock and automatic renewal for your domain.
Ask whether SPF, DKIM, and DMARC email records protect your domain from impersonation.
Identify an emergency contact route that does not depend entirely on the website or its email.
Ask the provider to explain the response plan for an unexpected login or altered page.
Review exposed services, permissions, software support, secret handling, and the production security baseline.
Test forms, monitoring, and recovery arrangements using safe sample data.
Investigate incidents, preserve useful evidence, and coordinate containment and clean recovery with the business.
Avoid these failures
Good website care lowers risk, but no provider can guarantee uninterrupted service.
Questions business owners ask
HTTPS protects the connection to the configured website. Administrator accounts, application code, stored data, forms, and outside services still need their own protections.
Yes. Its domain, hosting, repository, deployment, forms, and other service accounts still matter. The scope can be simpler than for a custom application, but those connections need appropriate access and recovery controls.
A named person who can assess them or reach the responsible technical provider. Agree a backup contact, expected response process, and how alerts are handled outside normal support availability.
No website can be made perfectly secure. Ask which controls the provider operates, what it monitors, how incidents are handled, and what recovery help is included.
Primary guidance
Plan the next step