Everything seems to be working
You open your business website. The homepage loads, the contact form sends an enquiry and Google can find it. There seems to be no reason to give it another thought. Then a security alert arrives: who receives it? Who decides what needs updating? And who checks afterwards that the form still works?
These questions are easy to put off, especially when the site has worked well for years. Until an update fails or one component stops being compatible with the others. A website does not stop ageing just because nobody touches it.
A PHP alert brought the question back into focus
On 21 October 2026, the PHP project published an advisory about two critical vulnerabilities and urged users to update affected installations. PHP is one of the components behind many websites, including those built with WordPress.
WordPress published its own announcement: the fix belonged in PHP, and resolving those two issues did not require a WordPress update. For an individual website, the next step was to check its PHP version and the available fix with the provider. Updating the content management system alone was not enough.
The practical point is simple: when an alert arrives, someone needs to know which components your site uses and whether it is affected. A general headline cannot replace that check.
Components change even when your website stands still
PHP, plugins, the theme and custom code develop at different speeds. A plugin may need a newer PHP version. An old theme may stop working after an update. And code written years ago may depend on a function that has since changed.
That is why it helps to identify dependencies, prepare changes and test what matters: forms, sign-ins and the path a customer takes through the site. You also need an agreed way to roll back if testing reveals a problem.
Three questions to ask today
Who reviews updates?
Ask who receives alerts for PHP, WordPress and installed components, and who decides when to apply the updates.
How is a change tested?
Establish whether there is a test environment, what gets checked and who signs off the result before and after release.
When was the backup last tested by restoring it?
Ask for the date, what was recovered and the outcome. Having a backup file does not, on its own, prove that the website can be restored.
Hosting and maintenance: agree who is responsible
Hosting provides the infrastructure for a website. Maintenance also needs an agreement about who reviews components, applies changes and checks the result. Do not assume those responsibilities from a plan name: agree them with your provider.
Ennigulat is SAV’s hosting and cloud service, with a team in Manacor, Mallorca. We review what the project needs and set out the scope of management in our proposal. That way, you know who looks after each part of your website before it becomes urgent.