Website maintenance: a practical plan for security and care

Know what you own and who maintains it

Begin with an inventory that a business owner can understand. Include the domain registrar, DNS provider, hosting, content management system, code repository, form service, email delivery, analytics and any booking or payment connection. For each, record the business owner, technical maintainer, renewal contact and how authorized access is recovered. Keep credentials in a suitable password manager, not in the inventory document.

This exercise often reveals more than a generic security score. A website may be technically current while its domain renewal goes to a former employee. An agency may maintain the code but assume the business manages an embedded booking service. These gaps are operational risks that neither party can resolve by quietly assuming the other is responsible.

Ask for a plain-language maintenance agreement describing what is included, what requires a separate change and how urgent issues are handled. A static marketing site, a frequently updated CMS and a customer account portal have different needs. The scope should follow the system's actual dependencies and the consequences of failure, rather than the number of pages in the navigation.

Give people the access their work requires

Use individual accounts where the service supports them, and assign permissions according to responsibilities. An editor who updates articles should not automatically be able to change billing, install extensions or add administrators. Review access when someone changes roles or leaves, including agency staff, contractors and connected applications.

Enable multi-factor authentication for important administrative accounts and protect the recovery process as carefully as the login. OWASP's multi-factor authentication guidance discusses both stronger authentication methods and the risk of weak recovery paths. Prefer phishing-resistant options such as passkeys or security keys where supported and appropriate, with a documented way for the business to recover authorized access.

Consider a marketing manager losing a phone just before a campaign launch. The answer should not be a shared administrator password in an old message thread. Agree in advance where recovery codes are held and who can use the recovery process. Review the email accounts that can reset other services too. Access management works best when it supports ordinary staff changes calmly, rather than being rediscovered during an emergency.

Maintain software through a repeatable change process

Ask the maintainer to identify which software is their responsibility: CMS core, themes, plugins, application libraries, runtime versions and deployment tools. A managed provider may maintain some layers while leaving others to the website team. Keep that division explicit, including what happens when a component reaches the end of support.

Subscribe to relevant vendor advisories and use appropriate dependency monitoring. A reported vulnerability needs assessment and a response, not merely an alert forwarded indefinitely. OWASP's dependency management guidance describes different remediation situations and the need to verify changes. The business-level question is whether somebody can explain what is affected, what action is planned and when it will be checked.

Routine updates can follow a scheduled process with a recoverable version and checks of important journeys. Urgent issues may require faster action based on exposure and vendor guidance. After changes, verify forms, publishing and connected services, not just the homepage. Automatic updates can be useful for suitable components, but they still need monitoring and a recovery plan. An update that silently breaks enquiry delivery has created another problem to resolve.

Treat a backup as a recovery capability

A successful backup notification does not prove that the website can be restored. Identify what needs protecting: code, content, uploaded assets, configuration and any stored submissions. Some of these may live with different providers. A copy of the public pages may be insufficient to rebuild the editing system or recover recent enquiries.

Agree on how much recent change the business could tolerate losing and how long it could tolerate an outage. Those decisions help determine backup frequency, retention and the recovery approach. Keep recovery copies appropriately protected and separated from the failure they are meant to address. Limit access to backups because they can contain sensitive information even when the public website does not.

Schedule a restore exercise in a safe environment. Record what was restored, the date of the source copy, how long the exercise took and which steps required missing access or undocumented knowledge. For example, restoring articles while omitting their images is a partial recovery. The useful deliverable is a tested procedure and a named operator, with any limits explained clearly to the business owner.

Review the services the page brings with it

Every widget or marketing tag adds another relationship to manage. Maintain a register of what runs, why it is needed, what information it can access and who approved it. Remove abandoned campaign tools and duplicate integrations through a controlled change. OWASP's third-party JavaScript guidance explains risks including external code changes and disclosure of information.

Have the technical team maintain HTTPS and review relevant browser protections. MDN explains that TLS protects communication in transit; it does not establish that the application, accounts or stored data are secure. A working certificate is one necessary part of the system.

A Content Security Policy can provide additional restrictions on what the browser loads and executes. It needs to fit the site and be tested against legitimate integrations. OWASP describes a report-only mode that observes violations without enforcing the policy. Ask for deliberate implementation, rather than copying a strict header that unexpectedly blocks forms or booking tools. Keep configuration changes connected to the same verification and recovery process as software updates.

Write an agreement you can use on a difficult day

“Maintenance included” is too broad to be a dependable operating arrangement. Ask the proposal to name the systems covered, the routine checks, the contact route for a problem and the hours during which someone will respond. Distinguish a promised response from a promised resolution: investigating an issue is different from knowing how long its repair will take.

Clarify what happens when a third-party service fails or a requested change falls outside the agreed scope. Identify who can authorize additional work and where the owner can find account access and recovery information. Keep credentials in an appropriate secure system, not in the maintenance document itself.

Have the supplier explain how recovery is rehearsed and how the result is recorded. A backup schedule is useful, but the business also needs to know what would be restored and who can do it. Review the arrangement when new forms, payment services, publishing tools or integrations are added. Compare these responsibilities in the website budget and document the initial setup in the launch record.

Keep the routine visible and proportionate

Use a recurring maintenance review to check evidence rather than collect reassuring statements. The interval should reflect how often the website changes and how consequential a failure would be. Important alerts need prompt routing even when the next scheduled review is weeks away.

• Access: Are current users and recovery contacts correct?
• Software: Are updates, advisories and unsupported components addressed?
• Recovery: Are backups succeeding, and when was restoration tested?
• Operations: Are uptime, form delivery and service failures monitored?
• Dependencies: Are renewals and third-party tools still appropriate?
• Response: Does the business know whom to contact and who can act?

Define an incident contact path and preserve relevant records when something looks wrong. Let the responsible technical team investigate and coordinate containment; avoid improvised changes that erase evidence or widen the problem. No routine can promise that an incident will never occur. Its value is a maintained system, fewer unmanaged gaps and a clearer, more practiced response when attention is needed.