Who applies your site's security patches, and how fast?

Two questions are enough: who applies your site's security patches, and within what delay after they are published. A management team that cannot answer either one does not have a maintained site, it has a hosted site, which is not the same service.

The confusion comes from contract wording. Hosting guarantees that the site responds. Maintenance guarantees that it is kept current. Both are often billed together under one monthly line, and nobody checks what the second one covers.

The risk is not theoretical and it does not target your business in particular. Intrusion attempts are automated and look for a known flaw across thousands of sites at once. The delay between a patch being published and applied at your end is exactly your exposure window.

For a large business, the stakes go beyond the site. A security questionnaire sent by a client, a cyber insurance policy or a tender requirement will sooner or later ask for those two answers, in writing.

What the contract has to say

Three elements, no more. The maximum delay for applying a critical patch. The rollback mechanism if an update breaks something, and therefore the backup frequency. And the name of the person responsible, at the vendor and at your end.

One nuance so you do not aim at the wrong responsibility. A vendor who applies patches without testing the site afterwards takes another risk, that of breaking a function without anyone noticing for weeks. A good contract covers both sides, not just speed.

The internal owner's name matters as much as the vendor's. Without one, the monthly report arrives in an inbox nobody opens, and the business finds out the day the site goes down.

A monthly report confirming what was applied completes the set. It is worth less for its content than for what its absence reveals: nobody can report on work they are not doing.

This point sits within the thresholds described in the design thresholds that became mandatory.