Who patches your website: you, your web agency or your host?

Part of the guide Customer security questionnaires: what they ask and how to answer

Who is responsible for website security updates?

Responsibility for website security updates is usually shared, and your contract decides who does each task. Your firm, your web agency and your host can each hold part of the job.

The UK National Cyber Security Centre (NCSC) says a supplier with privileged access joins in the job of keeping a service secure.

The NCSC says to know what systems and software you have, and who is responsible for what. For systems that do not update themselves, the plan should name who does and checks the updates.

You can hand the work to a supplier. The decision to leave something unpatched stays with you. The NCSC calls a decision not to update a senior-level risk decision that the organisation must own.

Who patches each part of a website?

Who patches each part of a website depends on how the site is hosted. The NCSC says each party's share depends on the type of service and how the provider runs it. On your own servers, you are entirely responsible for security.

With a hosting or cloud service, the provider will almost always look after its servers and their physical protection. Responsibility for the software on those servers depends on the type of service.

Your firm did not write PHP, the language many websites run on. The NCSC advises making your provider responsible for updates to all software your organisation did not write.

Some jobs always stay with you. You check the service meets your security needs, set it up securely and decide what data goes into it.

What did the NCSC say about the PHP security issue?

On 21 October 2026 the NCSC published an alert about a critical security issue affecting PHP. It encouraged UK organisations to take immediate action.

PHP published a security update for an issue that may let attackers run commands on any web server running PHP. The NCSC said organisations using any version of PHP are affected and should update to the latest fixed version.

If an update is not possible straight away, the NCSC describes temporary mitigations. If those cannot be applied, or would take too long, it says to consider taking the system offline until it is fixed. A system that could not be updated quickly should also be checked for signs of compromise and for backdoors.

PHP can also sit inside other products. The NCSC says to watch for updates from third-party vendors, including products and services that may bundle PHP. If you are not confident checking for compromise yourself, the NCSC says an NCSC-assured Cyber Incident Response provider can help.

How fast should a website security fix be applied?

A website security fix for a critical or high-risk weakness should be applied within 14 days of the update's release, on NCSC guidance.

That figure comes from the NCSC guide for small firms choosing a managed service provider. We apply it here to web agencies and hosts, because they also run systems for you.

Faster is better when attackers are already using a weakness. The NCSC says to speed up updates when a critical weakness is under active exploitation, especially on an internet-facing system. Attackers often try to exploit weaknesses as soon as they are disclosed.

A security fix should not sit in a queue. The NCSC says an update strategy should aim to minimise the time before updates are applied.

If you cannot update everything, the NCSC says to update the parts facing the internet first. A public website is one of those parts. A flaw that lets attackers run code may be more serious there than on an internal system.

Some software is no longer supported and cannot receive updates. The NCSC says patching alone will not always be enough, so plan to move off older products before support ends.

What should a website maintenance contract say about security updates?

A website maintenance contract should set out who applies security updates and who does everything else. The NCSC calls a matrix of responsibilities good practice.

The NCSC also says to agree how incidents are reported, including whether the supplier will tell you about one it suffers. Agree who is accountable for vulnerabilities, damages and incident impacts.

Ask who tracks end-of-life dates for your software, and who acts before support ends. Cover any third parties your supplier uses to deliver the service. Agree that your supplier and its own suppliers will work with your incident response team.

Ask about backups. The NCSC says to check what backup arrangements a supplier has, how often they are tested and whether they suit you.

Give a supplier only the access it needs. The NCSC recommends least privilege and an extra sign-in step, so accounts are harder to hack. It also says to check how a supplier protects its login credentials.

You should be able to see which privileges a supplier holds.

Some security work may cost extra, so read the contract carefully.

Does data protection law leave website security with you?

Data protection law can leave website security with you. Your site may collect personal data, for example through a contact form. A supplier that handles it for you may then be your processor under UK data protection law.

The ICO says a controller must only use a processor that can provide sufficient guarantees to protect personal data.

The responsibility does not move with the contract. The ICO says a controller is primarily responsible for its own compliance and its processors' compliance. Whatever the contract says, the controller may face the corrective measures and sanctions in the UK GDPR.

The ICO says controllers should check a processor's compliance on an ongoing basis. It notes this guidance is under review because of changes made by the UK's Data (Use and Access) Act.

What to do

1. Ask your web agency and your host which parts of the website each one updates. Write the answer into a matrix of responsibilities.
2. Ask each supplier for its policy for applying updates. Compare it with the NCSC's 14 days for critical or high-risk fixes.
3. Ask whether your site runs PHP. If it does, ask whether the update after the NCSC alert of 21 October 2026 has been applied.
4. Ask how your backups are kept and tested, and which access your supplier holds.
5. Sign up for NCSC Early Warning, a free service for organisations based in the UK.
6. Record any decision not to update as a senior-level risk decision.

Common questions

Is my web agency responsible if my website is hacked?

It depends on your contract. The NCSC says to agree who is accountable for vulnerabilities, damages and incident impacts. If the site handles personal data, the ICO says the controller may still face sanctions in the UK GDPR whatever the contract says.

Does my host update PHP on shared hosting?

It depends on the type of service. The NCSC says responsibility for the software on the servers depends on the type of service used. Ask your host who updates PHP for your site.

What if a security update breaks my website?

Plan for it before it happens. The NCSC says to limit the impact of problematic updates by staggering them and having a rollback strategy available. Agree in the contract who pays for that work, because some security work may cost extra.

Who keeps the logins if we change web supplier?

Your firm should. The NCSC says to apply least privilege to a supplier's accounts and to see which privileges have been granted to them. That list is what you remove or hand over when the supplier changes.

Where next

• After a ransomware or security incident
• What is supplier assurance, and what do buyers check?
• How much is Cyber Essentials, and what does it ask?
• Incident response plan: what to write down
• Who is a data controller, and who is a processor?
• Data processing agreement: what must an Article 28 contract say?

This is an independent editorial guide, not legal advice.