Information checked: 23 October 2026. Website security responsibilities depend on the actual hosting and maintenance agreements. This guide helps a business clarify ownership after PHP2Shell; it does not change those agreements or certify a particular website.
One of the most difficult questions during a website security alert is often organisational: who is supposed to do something? The business pays an agency, the agency uses a host, a previous developer built a custom feature, and a separate supplier handles bookings. Each may reasonably assume that another person owns a particular check.
PHP2Shell is a useful reason to remove that uncertainty. Our incident overview explains the original vulnerabilities. This article focuses on the division of work between hosting providers, developers and business owners, and on the handover records that prevent essential tasks from falling between them.
Start with services, not job titles
“The web person handles it” is too broad to be a dependable arrangement. List the services the website relies on: domain registration, DNS, hosting, server runtime, WordPress, plugins, custom code, email delivery, payments, bookings and backups. Then identify who performs work on each and who owns the commercial relationship.
A developer may maintain WordPress while the business contracts directly with a hosting provider. An agency may resell managed hosting but rely on another supplier for server patching. A booking platform may sit outside the main website altogether. Map those relationships before assigning responsibility based on who originally built the homepage.
Keep the map understandable to a non-technical colleague. For each service, record its purpose, supplier, primary contact, backup contact and the location of the relevant agreement. Use private records for account identifiers and secure systems for credentials. The map should help authorised people find the right owner without exposing secrets.
Distinguish the runtime from the application
PHP is part of the environment that runs many websites. WordPress, its plugins and the site’s custom features are a different layer. The official WordPress notice makes clear that the original PHP2Shell issues concern PHP, with no WordPress update planned specifically for those vulnerabilities.
That distinction should appear in the responsibility record. Ask who checks server-runtime advisories, who applies the applicable package and who confirms that it is active. Separately, identify who maintains the application and who tests its important journeys after a hosting change. A generic “website updates” line can conceal all of those separate tasks.
Also distinguish identifying a need from performing the work. A developer may notice an advisory and raise a ticket, while only the host can change the managed runtime. The business needs to know who follows the ticket through to completion. Sending a request is a step in the process, not evidence that the remediation happened.
Clarify what the hosting provider covers
Ask the provider which parts of the service are managed. Does it maintain the operating system and PHP packages? Does it require the account owner to choose a supported runtime? Are legacy installations included? Does its general security announcement apply to the specific product and account you use?
Request evidence appropriate to the service. For a managed platform, a service-specific confirmation may be the available output. For a server managed by your own team, the record may include a package reference and deployment evidence. Avoid demanding an irrelevant format while still requiring a clear answer about scope and completion.
Confirm how urgent notices reach the account owner. A provider can send a useful warning to an abandoned mailbox and still leave the business unaware. Check the ownership of operational contact details through the normal account-management process. Do not assume that the person receiving invoices also receives technical alerts.
Clarify what the developer or maintainer covers
Read the maintenance scope rather than infer it from a monthly payment. Content edits, plugin updates, uptime checks, backups, malware monitoring, emergency response and forensic investigation are different services. Some may be included, some available separately and some outside the supplier’s expertise.
Ask what happens when an urgent hosting advisory arrives. Will the maintainer check applicability, contact the host, coordinate a maintenance window, test the application and send a completion record? Which of those actions require additional approval or an agreed fee? Clarifying the process in advance reduces delay when pressure is high.
For custom code, identify who can assess compatibility and maintain the relevant integration. A hosting provider may correctly apply a PHP update without being responsible for repairing a bespoke application. Conversely, a developer cannot confirm a vendor package was deployed merely because the site’s pages still load.
Keep business ownership explicit
The business owner does not need to become the server administrator. The business does need to decide who may authorise work, how urgent decisions are escalated and what level of service interruption it can tolerate. Those decisions should be informed by technical advice and the consequences for customers.
Name a backup decision maker. An urgent issue should not remain unresolved because the only approver is on holiday or asleep. Agree an escalation arrangement proportionate to the service, including the boundaries of any standing authority. Avoid vague permission that leaves suppliers unsure whether they may act.
The business also owns knowledge of its critical journeys. A developer may not know that a little-used form sends high-value trade enquiries or that a particular booking export is essential every Monday. Give the maintainer a concise list of those dependencies so technical testing reflects actual operations.
Use a responsibility table with concrete outputs
Create a table with the task, person doing the work, person accountable for completion, people to consult and evidence expected. Keep the wording operational. “Patch PHP” is less useful than “confirm the fixed runtime package is active for the listed services and retain the supplier reference”.
Separate related tasks into different rows. Advisory assessment, installation, functional testing, compromise review and customer communication may involve different owners. A single row labelled “security” makes it difficult to tell which part is complete. The table should reveal gaps rather than hide them behind a reassuring category.
For each outstanding item, include a target date and escalation route. If a supplier cannot provide the evidence, record that limitation and identify who will decide the next action. A responsibility table is only useful when someone maintains it as services, people and contracts change.
Define urgent work separately from routine maintenance
A monthly update schedule may be appropriate for ordinary improvements, but a critical advisory needs a triage process. Agree who assesses urgency, which sources they use and how they contact the relevant technical owner. The process should account for internet-facing exposure and the business role of the service.
The NCSC’s PHP guidance prioritises identifying relevant systems and applying vendor remedies, with further action where timely remediation is not feasible. Translate that into an ownership process for your estate rather than treating it as a universal instruction to shut every website down.
Keep a distinction between acknowledgement and resolution. A supplier replying quickly is helpful, but the business still needs the result of the assessment and the completion evidence. Set a follow-up owner so an acknowledged ticket does not sit indefinitely without a clear next step.
Account for later advisories and changing information
Security work can develop after the first announcement. PHP’s additional notice on 23 October is a reminder that an earlier completion statement has a date and scope. Ask who reviews subsequent notices and who determines whether they require further assessment for the application.
Do not turn this into uncontrolled configuration changes. The host and developer should assess current vendor advice together where application behaviour matters. The business record should show who reviewed the notice, what conclusion they reached and any outstanding action. This makes later decisions traceable without asking non-specialists to interpret every technical detail.
When reporting progress, use dated language. “The original fixes were confirmed on this date; the later notice is being assessed by this owner” is clearer than “everything is secure”. It allows completed work to be recognised while keeping a genuinely new question visible.
Include dormant sites and forgotten environments
Old campaign pages, staging copies and former brands can outlive the person who created them. They may still run software, hold data or provide a route into shared infrastructure. Ask the technical owner to identify these services and decide whether each still has a business purpose.
Assign an owner before assuming something can be removed. An apparently unused subdomain might support an integration or a contractual obligation. Equally, an installation with no remaining purpose should not persist indefinitely simply because nobody knows who may approve its retirement. Establish a controlled decision and record the outcome.
When a project ends, include service retirement in the handover. Identify what will remain live, who will maintain it and where necessary records are kept. A finished marketing campaign does not automatically terminate its hosting account or remove its maintenance needs.
Make access and recovery part of the handover
The business should know which accounts it owns and how authorised staff can recover access. Domain registration and hosting control should not depend entirely on a former employee’s personal inbox. Review the arrangement through the appropriate account owner and provider process, without sharing passwords through ordinary documents.
List recovery dependencies. Who can restore a backup? Who can update DNS if the current host is unavailable? Who can contact the payment or booking supplier? The answers should be available before an incident makes them urgent. Keep access proportionate to each person’s role and obtain appropriate authorisation for changes.
A handover should also explain custom code, scheduled jobs, integrations and unusual configuration. The next maintainer needs enough context to assess changes safely. A folder containing only design files does not describe the operational website that customers rely on.
Agree who investigates and who communicates
Possible compromise introduces responsibilities beyond routine patching. Establish who coordinates evidence preservation, who assesses suspicious activity and when a specialist is required. A host’s infrastructure review and a developer’s application review may cover different areas. Ask them to state their scope rather than assume they overlap completely.
Business communications should be coordinated with the findings. Staff need a clear route for reporting symptoms and answering customer questions, while public statements should reflect verified facts. Avoid announcing either a breach or an all-clear solely because a headline, a scan result or a working homepage seems persuasive.
If legal, regulatory or contractual questions arise, involve the appropriate advisers for the circumstances. This responsibility map does not determine those obligations. Its purpose is to ensure that someone recognises the question and routes it to the right expertise without losing time.
Use evidence in routine service reviews
After the immediate incident, review whether the arrangement worked. Were the right people contacted? Was the inventory accurate? Did the host provide a useful confirmation? Were important customer journeys tested? Focus on specific gaps and improvements rather than assigning blame without understanding the sequence.
Ask for a proportionate service record: completed work, unresolved issues, support limitations and upcoming decisions. Avoid relying solely on a dashboard score or a count of updates. Those measures can be useful, but they do not show whether responsibilities were understood or whether the business’s essential functions were checked.
Where the website’s needs have changed, revisit the support scope. A brochure site that now accepts payments or stores member information may need different arrangements. Our web design services offer a starting point for discussing the site and its ongoing needs, with the actual scope agreed rather than assumed.
A practical handover exercise
Ask a colleague who was not involved in the website build to locate the host, support contact, backup owner and critical-journey list using the existing records. Do this as a documentation exercise, without changing access or testing live recovery. Note where the instructions are missing, outdated or dependent on one person’s memory.
Then ask the technical owner to review the gaps. Resolve unclear account ownership through authorised processes and update the service map. Record when the review took place and who will maintain it. This modest exercise can reveal practical weaknesses before an urgent incident exposes them under pressure.
The result should be a usable operating record, not a lengthy document nobody reads. A concise map with current contacts, clear responsibilities and evidence locations can be more effective than a broad promise that a supplier “handles everything”.
Frequently asked questions
Is the hosting company responsible for every website issue?
No. Responsibility depends on the service and agreement. Hosting-runtime maintenance, application compatibility, content and external integrations may have different owners. Ask each supplier to confirm its scope and the evidence it provides.
Does paying for maintenance mean incident response is included?
Not necessarily. Routine updates, monitoring and specialist investigation are distinct activities. Check the agreed scope and establish an escalation route for work that falls outside it.
What should a business owner personally decide?
The business should define authorisation, escalation, critical services and acceptable operational impact with technical advice. It should know who is accountable for completion without needing to perform server administration itself.
Why include old staging sites?
They may still run software or hold information even when no longer used for development. Assign an owner, confirm their purpose and arrange maintenance or controlled retirement through the appropriate process.
Who should review a later PHP advisory?
Name a technical owner, with application input where configuration or code affects applicability. Record the assessment date and conclusion. An earlier patch confirmation should not silently stand in for a later review.
What is a good final responsibility record?
One that identifies the service, work owner, accountable person, evidence, outstanding actions and escalation route. It should be understandable to the business and usable by the next maintainer without exposing credentials.
