Website Maintenance, Security and Backups: Who Owns What?

Distinguish support from ongoing maintenance

Post-delivery defect support normally addresses issues in the agreed delivered scope according to the contract. Maintenance is continuing operational work such as dependency review, provider changes, monitoring and recovery preparation. A new module or changed business workflow is a separate change unless the agreement says otherwise.

Ask for a responsibility matrix rather than the phrase "full maintenance". Record the system, activity, owner, expected frequency and escalation contact. This makes the service understandable without promising that every future problem or new request is included indefinitely.

Keep control of accounts and renewal dates

Identify who owns the domain, hosting, business email, deployment account and external integrations. Maintain an access inventory without storing plaintext secrets in a public document. Define how an authorised person can recover access if the usual administrator is unavailable.

Use individual staff access where supported and remove access when responsibilities change. Review who may publish a release, export records or alter billing. Renewal reminders should go to a monitored business contact rather than depend on one developer remembering an annual date.

Plan updates with a rollback path

An update can fix an issue but can also change behaviour. Decide which changes need a preview, a backup and a tested rollback. Focus testing on important journeys such as enquiries, authentication, booking and checkout rather than only whether the homepage loads.

Record the version deployed and the reason for the change. If a provider removes an API feature or alters an account requirement, assess the effect before changing the production integration. Avoid describing software as maintenance-free simply because it currently works.

Define what a useful backup must recover

List the database, uploaded files, relevant configuration and any external system that holds essential records. A copy of website source code does not necessarily contain the live customer data. Decide how much recent work the business could tolerate losing and how quickly it needs the service restored.

Those expectations inform the schedule, retention, storage separation and access controls. Consider an illustrative shop where losing a day of orders is unacceptable: a daily snapshot alone would not meet that requirement. Choose the recovery design around the business tolerance rather than a convenient default.

Test restoration instead of trusting a green status

A completed backup job is useful evidence, but recovery needs its own test. AWS Backup documents restore testing to evaluate recovery behaviour. Regardless of the provider, an authorised test should verify that the relevant data can be restored into a suitable isolated environment and used as intended.

Record what was restored, how long it took, what failed and which follow-up action is required. Protect the restored data with appropriate access controls. Do not overwrite the live system or expose real customer records simply to demonstrate that a backup exists.

Give incidents a clear owner and escalation route

Define how an outage is reported, who decides whether to roll back and who updates the business owner. Distinguish a critical operational outage from a minor visual issue. Response and resolution targets should match the actual support agreement, not an assumed round-the-clock promise.

• Monitor important service outcomes, not just server availability.
• Maintain secure access and a tested recovery procedure.
• Record provider contacts and business decision-makers.
• Review recurring incidents and approve corrective work through the agreed process.