In short and in plain language
Many people think the hosting provider takes care of all updates. That is often only partly true.
The hosting provider usually looks after the server. It usually does not look after the shop itself, its add-ons or its design. It usually does not check if the checkout still works after an update.
The article shows who is in charge of what. It lists questions you can ask your hosting provider.
You can keep your hosting provider. We take over the parts that are missing there.
“The hosting provider takes care of that.” The sentence comes up in many first conversations about a shop, and it is rarely entirely wrong. The hosting provider installs security fixes for the operating system, replaces failed disks, keeps the network reachable and offers a choice of PHP versions. What it usually does not do: raise the shop core, update extensions, adapt the theme to a new version or check whether the checkout still calculates after an update. These layers are not part of typical hosting contracts at all, and that is where the larger share of reported vulnerabilities arises. In a large-scale pentest of hosting companies, only 26% (Patchstack) of attacks on vulnerabilities were blocked. This article draws the line layer by layer: what sits with the hosting provider, what with maintenance, what stays with the operator, and where the handover between the three has to be settled.
Key takeaways
- The hosting provider is usually responsible for network, hardware, operating system and providing PHP and the database. Shop core, extensions, theme and custom code are not in the scope of typical hosting contracts.
- Server-level protection only partly catches application vulnerabilities: in a pentest of hosting companies, 26% (Patchstack) of attacks were blocked, and against known exploited vulnerabilities only 12% (Patchstack).
- Of 11,334 (Patchstack) newly reported vulnerabilities in the WordPress ecosystem in 2025, only 6 (Patchstack) affected the core. There is no comparable analysis for Shopware; the finding serves as an analogy.
- A central handover point is PHP: security support for PHP 8.2 ends on 31 December 2026 (The PHP Group). Who switches the version and who tests the shop afterwards belongs in writing.
- The duty to take appropriate technical and organisational measures under Art. 32 GDPR lies with the controller, meaning the operator. Tasks can be delegated, control cannot.
Where the hosting provider’s responsibility ends
Hosting is an umbrella term for very different services. With simple shared hosting, the shop shares a server with other customers; the hosting provider looks after everything up to the PHP version, the operator everything above. With an unmanaged virtual or dedicated server, the service often ends at hardware and network, and the operating system is the customer’s job. With a managed server, the hosting provider takes over operating system, web server, database and PHP runtime, usually with a fixed catalogue of versions. In all three cases, maintenance stops where the application begins: at the files the shop brings with it.
The reason is understandable. A hosting provider runs a very large number of installations and cannot know which extension overrides a pricing rule in which shop or which theme replaces a core template. An update of the shop core is not a platform routine but an intervention in a customer’s business: it can change the checkout, the payment integration or the export to the ERP system. That is why many hosting contracts explicitly exclude the application or do not mention it at all, which amounts to the same thing.
Managed hosting is not a managed shop
The responsibility matrix: layer by layer
The following table assigns every layer of running a shop to the three roles. It describes the typical split for a managed server with a separate maintenance contract. Individual contracts differ, especially for the database and backups. The matrix therefore does not replace a service description; it is a grid to hold the description against: every row for which nobody can be found in the contract is a gap.
| Layer | Hosting provider | Maintenance | Operator |
|---|---|---|---|
| Network and hardware | Operation, replacement, connectivity, defence against overload attacks | Monitor reachability from outside | Choose plan and location |
| Operating system | Security fixes, reboots, tracking end of support | Check the impact on the shop | Approve maintenance windows |
| PHP and database | Provide versions, maintain the runtime | Check compatibility, adapt the shop, test after the switch | Approve the date |
| Web server and firewall | Configuration, certificates, network filters | Align rules with the shop, review blocks | Approve exceptions |
| Shop core | not included | Install updates, test, keep a way back ready | Approve larger version jumps |
| Extensions | not included | Updates, licence status, compatibility | Pay licences, assess value |
| Theme and custom code | not included | Adapt to new versions, regression tests | Commission development work |
| Content and configuration | not included | Check technical settings after updates | Products, prices, texts, shipping rules |
| Access | Server and panel accounts | Review and revoke admin and developer accounts | Decide who may do what |
| Backups | Server backup as per plan | Backup before updates, practise restores | Define retention |
The hosting provider’s column stands out: from the shop core row downwards, it is empty. That is not a shortcoming of the hosting provider but the normal split. It only becomes a problem when the operator assumes these rows are covered as well. Then nobody looks after the layers where most vulnerabilities are reported. What a maintenance contract actually delivers in these rows is covered in detail in the article on what belongs in a maintenance contract.
Why server-level protection is not enough
Many hosting providers offer a firewall, malware scanning and filters in front of the web server. These layers are useful, but they act at a different point than a vulnerability in the application. A filter in front of the server sees a request, not the logic it triggers in the shop. Whether a parameter exploits a missing permission check in an extension often cannot be seen from outside, because the request looks just like a legitimate one.
Patchstack measured how large this blind spot is for the WordPress ecosystem. In a large-scale pentest of popular hosting companies, only 26% (Patchstack) of all vulnerability attacks were blocked. A second experiment with known exploited vulnerabilities found that traditional defences only stopped 12% (Patchstack) of attacks on WordPress-specific vulnerabilities. There is no comparable analysis for the Shopware Store; the finding serves here as an analogy for a modular system built the same way, in which extensions from many vendors run on a shared core.
What follows from this
Where the vulnerabilities actually are
The distribution of vulnerabilities explains why the line between hosting provider and maintenance carries so much weight. Patchstack counted a total of 11,334 (Patchstack) new vulnerabilities in the WordPress ecosystem for 2025. Only 6 (Patchstack) of them were reported in the core itself, and these were rated low priority. The rest sit in extensions and themes, exactly the layers that stay empty for the hosting provider in the matrix above. Here too, the figures come from a different system and are used for Shopware only as an analogy.
Two more values from the same analysis show how little time there is between disclosure and attack. For 46% (Patchstack) of vulnerabilities, no vendor fix was available at the time of public disclosure. For heavily exploited vulnerabilities, the median time to mass exploitation was 5 hours (Patchstack). In its 2025 situation report, the German Federal Office for Information Security (BSI) counted an average of 119 (BSI) newly known vulnerabilities worldwide per day. At that volume, waiting for the hosting provider to update an extension means waiting for something the contract does not provide for.
Platform
Operating system, web server, PHP runtime and database. This is where the hosting provider’s updates apply, usually automatically and without the operator doing anything.
Application
Shop core, extensions, theme and custom code. This is where the larger share of reports arises, and every update here needs a test in the shop.
Operation
Configuration, access and approvals. This layer cannot be fully outsourced because it contains the company’s own decisions.
PHP handover point: who switches, who tests
Hosting provider and maintenance meet most directly at the PHP version. Each release branch is fully supported for two years and then receives only critical security fixes for two more years. The PHP Group states the consequence plainly: once the four years (The PHP Group) of support are completed, the branch reaches its end of life and is no longer supported. For PHP 8.2 that is 31 December 2026 (The PHP Group); for PHP 8.4, security support ends on 31 December 2028 (The PHP Group).
According to its developer documentation, Shopware 6 requires PHP 8.2 (Shopware) as a minimum and recommends 8.4 (Shopware), together with a memory_limit of at least 512M (Shopware). For the database, the documentation names MariaDB from 10.11.6 (Shopware) or MySQL from 8.0.22 (Shopware). Which PHP version runs on the server is therefore no longer purely a hosting matter: the version has to fit the shop core, every extension and the custom code.
The documentation also contains a note that can cause misunderstandings in day-to-day work: on many servers, the command line and the web server run with different PHP configurations. In substance it says that CLI and FPM often have different php.ini files and that you should ask your hosting provider for the correct PHP binary. Anyone who switches to a new version in the panel may have raised only one of the two runtimes, while scheduled tasks or maintenance commands keep running on the old one.
Record the current state
Maintenance establishes which PHP and database version apply to the web server and the command line and which extensions are installed.
Check compatibility
For the shop core, every extension and the custom code, maintenance checks whether the target version is supported. Where it is not, the component update comes before the PHP switch.
Switch on staging
The target version runs first on a copy of the shop. Checkout, payment methods, search and exports are run through there.
Date with the hosting provider
The hosting provider switches the version in the agreed maintenance window, for web server and command line at the same time. The operator has approved the date beforehand.
Retest and way back
Right after the switch, maintenance tests the core processes in the live shop. For the failure case, it is agreed in advance who restores the old version.
Maintenance establishes which PHP and database version apply to the web server and the command line and which extensions are installed.
For the shop core, every extension and the custom code, maintenance checks whether the target version is supported. Where it is not, the component update comes before the PHP switch.
The target version runs first on a copy of the shop. Checkout, payment methods, search and exports are run through there.
The hosting provider switches the version in the agreed maintenance window, for web server and command line at the same time. The operator has approved the date beforehand.
Right after the switch, maintenance tests the core processes in the live shop. For the failure case, it is agreed in advance who restores the old version.
The decisive point is the date with the hosting provider. If the hosting provider switches the version on its own, for instance because it drops a release branch from its catalogue, the switch hits an untested shop. That is why the hosting contract needs a lead time for such changes and the maintenance contract needs the obligation to use that lead time. How an orderly version change works in detail is described in the article on PHP EOL management for safe upgrades; the same principle applies to the end of support for the operating system and database, see end of life in the shop server stack.
#!/usr/bin/env bash
# Record the state of runtime and shop before hosting provider and maintenance discuss a change.
# The values apply to the command line; the web server (PHP-FPM) may load a different php.ini.
set -u
echo "PHP (CLI):"; php -v | head -n 1
echo "memory_limit (CLI):"; php -r 'echo ini_get("memory_limit"), PHP_EOL;'
echo "Loaded php.ini (CLI):"; php --ini | head -n 2
# Database credentials as stored in the shop configuration
echo "Database:"; mysql -N -e 'SELECT VERSION();'
cd /path/to/shop || exit 1
echo "Shop core:"; composer show shopware/core | grep -E '^versions'
echo "Extensions:"; bin/console plugin:list
The script changes nothing; it only reads. Its output belongs in the ticket history before a date is agreed with the hosting provider. If the output differs from what the web server shows in its PHP info, the second runtime has been found before it brings a nightly task run to a halt.
Questions for the hosting provider before you sign
The matrix only becomes reliable once the hosting provider confirms it for its contract. The following questions can be asked in writing and answered in writing. Any answer that reads “case by case” or “on request” is a sign that the row in the matrix ends up with the operator or with maintenance.
- Which layers does the plan explicitly maintain: operating system, web server, PHP, database, mail server?
- How far in advance is it announced that a PHP or database version will be dropped, and who receives that announcement?
- Are web server PHP and command-line PHP switched together, and can the version be set per environment?
- Is there SSH and Composer access so that shop updates can run via the command line?
- Which backups run, how long are they retained, and how is a restore of individual directories or the database requested?
- Who decides on blocks by the hosting provider’s firewall, and how is a wrongly blocked payment notification released?
- Is there a staging environment on the same platform, and may it run with a copy of the live data?
- How does maintenance reach the hosting provider in an incident, and which response times are agreed?
Whether the existing hosting provider works well with external maintenance is rarely a technical question. What matters is SSH access, a predictable version policy and a reachable contact person. The answer to the question whether you can keep your hosting provider therefore depends mainly on these three points.
What stays with the operator
Even with a hosting provider and a maintenance contract, part of the work stays with the operator, and not because the service providers are being lazy. The General Data Protection Regulation explicitly places the duty to ensure security of processing on the controller and the processor. The operator can delegate tasks, but responsibility for selecting and steering its service providers stays with the operator.
[…] the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk
Among these measures, Art. 32(1)(d) GDPR explicitly lists a process for regularly testing, assessing and evaluating their effectiveness. For the shop this means: the operator should be able to show that updates are installed, tested and documented, whether it does this itself or commissions someone. A maintenance log with date, version and test result is an obvious piece of evidence for this.
Approve access
The operator decides who gets an admin or developer account. Maintenance and hosting provider implement the decision and report orphaned accounts.
Set maintenance windows
When an update may run depends on the business: promotion days, newsletters, season. Only the operator knows these dates.
Approve larger jumps
A change of major version alters interfaces and processes. The approval is one of the decisions made within the company.
Pay licences
Many extensions only deliver updates with an active licence. Whether an extension is still worth its price is for the operator to judge.
Align contracts
Hosting and maintenance contract must describe the same matrix. Gaps between the two only show once someone puts them side by side.
Keep evidence
Update logs, test results and backup records document the measures under Art. 32 GDPR. The controller has to keep them.
Access deserves a close look, because all three roles manage accounts here: the hosting provider in the panel and on the server, maintenance in the shop and the repository, the operator in the administration. What a complete access inventory looks like and how to revoke access cleanly when a service provider changes is covered in the article on revoking shop access and keeping an access inventory.
The gap between two contracts
Some gaps are not technical in nature. They arise when two contracts each assign the same area to the other. The hosting provider assumes that maintenance updates the extensions, maintenance assumes that the hosting provider adjusts the firewall rules after a warning, and the operator assumes that both happen. As a result, a known vulnerability stays open even though two service providers are being paid.
Verizon’s Data Breach Investigations Report shows how long that can take. Exploitation of vulnerabilities is now the most common known initial access vector for breaches there and rose to 31% (Verizon) in the current dataset. For critical vulnerabilities from the US agency CISA’s catalogue of known exploited vulnerabilities, the median time to full resolution rose to 43 days (Verizon). Both values come from the report’s cross-industry dataset and describe organisations in general, not online shops specifically.
Alert without a recipient
A security warning about an extension goes to an address nobody reads any more, for example that of a developer who has left.
Switch without a test
The hosting provider raises PHP as scheduled, the shop then only partly works, and nobody passed the date on to maintenance.
Backup without a trial
The plan includes a daily backup, but nobody has ever run through a restore of the shop including its database.
The same remedy helps against all three: a shared list with one name per row of the matrix, an address for security alerts that reaches maintenance, and monitoring of shop and checkout that raises an alarm after any change by the hosting provider if the shop stops responding properly. For backups, it is not enough that the hosting provider offers them; the maintenance backup service practises restores and keeps its own copy ready before every update.
Keep your hosting provider, add maintenance on top
Closing these gaps rarely requires changing the hosting provider. Maintenance builds on the existing platform and takes over the rows missing from the hosting contract: security updates for core and extensions, tests after every update, coordination with the hosting provider when PHP or the database changes. Where a move still makes sense, for instance because the plan does not allow SSH access, it can be planned in an orderly way, see moving shop servers without losing orders.
How we split the matrix
The order matters here. An update of the shop core is first installed on a staging environment and then checked with fixed regression tests, as described in the article on update testing and regression. If an update fails anyway, the way back applies that the answer to what happens if an update fails explains.
The next step
The starting point is a sheet with the matrix from this article. For each row, the operator enters who actually maintains it today and puts the hosting and maintenance contracts next to it. Rows without a name are the open spots; rows with two names are where a handover has to be settled. In parallel, the script from the section on the PHP handover point delivers the technical state. With both, a short conversation is enough to clarify which rows maintenance can take over without the hosting provider having to change. The request goes through the contact form for an initial conversation.
Sources and studies
Related Articles
Moving Shop Servers Without Losing Orders: A Runbook
Resolvers may keep serving stale DNS answers for 1 to 3 days. How a shop moves servers without losing orders, cron jobs or payment notifications.
End of support under the shop: OS and database
Debian 11, MariaDB 10.6 and MySQL 8.0 dropped out of maintenance in 2026. How to inventory distribution, database and PHP and plan the upgrades with lead time.
When your CMS version leaves support: 2026/2027
TYPO3 v12 ends on 30 April 2026, Joomla 5.x on 13 October 2026, Drupal 10 on 9 December 2026. The end dates and the lead time a version jump needs.