Does the server have to be located in Germany?

A location in Germany is not legally required. Within the EU and the EEA the General Data Protection Regulation applies uniformly, so a data centre in another member state is equivalent in data protection terms. In practice, however, a location in Germany or the EU makes many things easier: shorter routes for information requests, contract documents in the local language, short round trips to a regional audience and no documentation duties for third country transfers. More important than the pure location is the possibility of access anyway: if support, remote maintenance or backup storage sit outside the EU, the location of the hard drive changes little in the assessment.

Is the provider's backup enough, or do I need my own as well?

For many small websites a solid provider backup is sufficient, provided it runs daily, retains several weeks, sits on separate infrastructure and can be restored without a long wait. An additional backup of your own makes sense if orders or bookings run through the site, if content is created regularly that would be hard to reconstruct, or if you want to stay independent of the provider account - for instance in the event of an account suspension or a change of provider. In both cases what counts is less the number of copies than the evidence that a restore has actually worked.

What does a 99.9 percent availability promise mean day to day?

Arithmetically it means around 8.76 hours of downtime per year or just under 44 minutes per month, based on 8,760 hours in a year. Whether that is noticeable depends less on the total than on the distribution: a single eight-hour disruption on a weekday morning weighs more heavily than many two-minute outages at night. The small print is also worth reading, because planned maintenance windows and disruptions at upstream suppliers are frequently excluded, and the legal consequence is usually a proportionate credit note rather than compensation for lost orders.

How can I tell whether my website runs on an outdated PHP version?

In most hosting control panels the configured PHP version can be viewed directly, often per domain or per directory. Alternatively, the administration area of many content systems shows the version in its system report. For comparison, the official overview of supported versions is enough: it states the end of security support for each branch. If your package sits on a branch whose date has passed, plan the change and check on a test environment beforehand whether extensions and templates come along. A jump across several branches needs more preparation than a single step.

How long does a hosting migration take, and is the website offline during it?

For a manageable website the effort usually amounts to a few hours spread over one or two weeks, because waiting periods sit between test migration, DNS lead time and the switchover. The website itself normally does not have to go offline: it already runs completely on the new server before the address is switched. The change tends to be noticeable with email instead, because messages can briefly arrive in two places during the transition. With a lowered DNS validity period and a quiet time window, that phase can usually be kept to a few hours.

Is managed hosting worthwhile for a small business?

That depends on how much time the business has for technical work and how much rides on the website. Pure storage hosting is cheaper but shifts updates, backup checks, certificate upkeep and troubleshooting to you. Managed hosting bundles these tasks and costs more per month, yet saves detours and waiting time when something breaks. As a rough guide: as soon as enquiries, appointments or orders arrive through the website regularly and a day of downtime would be felt, the benefit of a supervised environment usually outweighs the cost. For a pure business-card website with few visits, a simple package can be sufficient, provided backups and the PHP level are in order.

Web Hosting 2026: What Local Businesses Must Check

Hosting is the part of a website that rarely gets discussed. It sits as a line item on an invoice, often unchanged for years, and works quietly in the background - until the site is unreachable on a Monday morning, the contact form stops delivering messages, or a failed update reveals that the most recent usable backup is three weeks old. Only then does a technical topic become a business question. That is avoidable, because the criteria for dependable hosting are manageable and can be checked without technical vocabulary. This article sorts six of them: server location and data protection, backups, availability, the software level of the server, speed, and support and contract. It closes with eight questions for your current provider - the answers say more about the quality of an offer than any feature table. Deliberately left out are a provider comparison, domain law in detail and the editorial upkeep of the website.

Key takeaways

A host processes form submissions, server logs and mailboxes on the business's behalf. Article 28(3) GDPR requires a contract covering eight points (EUR-Lex); what matters is who can access the systems, not only where the hard drive sits.
A backup that has never been restored is an assumption: Article 32 GDPR demands rapid restoration plus regular testing of that ability. Solid means daily backups, a separate storage location, several weeks of depth and a documented test restore.
A pledge of 99.9 percent availability still allows 8.76 hours (calculated on 8,760 hours per year) of downtime annually. Planned maintenance windows are usually excluded, and the remedy is normally a pro-rata credit, not compensation for lost orders.
Security support for PHP 8.2 ends on 31 December 2026 (PHP.net), and PHP 8.1 has received no security updates since 31 December 2025 (PHP.net). TLS 1.0 and TLS 1.1 have been formally deprecated since March 2021 (IETF, RFC 8996).
Server response time caps every later optimisation: Google cites 0.8 seconds (Google Search Central) to first byte as the benchmark and treats it as the basis for Core Web Vitals. Image formats and scripts cannot compensate for a slow server.
Switching providers follows a fixed order: inventory, test migration under a temporary address, mailboxes first, lower the DNS record lifetime one or two days ahead, an agreed switchover window, and keep the old contract running for a few more weeks.

Why hosting only becomes a topic after the first outage

Most hosting contracts in small businesses have grown rather than been chosen. They date back to the first web presence, were carried along through a relaunch and have quietly continued ever since. As long as nothing happens, there is little to object to. European statistics show how regularly something does happen: around 18 percent (Eurostat) of enterprises in the EU reported unavailability of their ICT services due to hardware or software failures for 2023, and around 22 percent (Eurostat) experienced consequences from IT security incidents at all. These are not exceptional cases, but the normal range of experience for a business over a few years.

Behind the word hosting there is more than storage space. It covers the server environment with its PHP version and database, TLS encryption, backups, mailboxes, round-the-clock reachability and the person who answers the phone when something jams. Looking at these components individually makes one thing clear quickly: the price difference between a very cheap and a solid package rarely comes from storage, but from the backup concept, software upkeep and support. For a website that is meant to produce enquiries, this is not a side issue but the foundation of website maintenance.

Hosting, domain and upkeep are three separate contracts

Hosting is the space the website runs on. The domain is the address it can be reached at. Upkeep is the ongoing work on content, updates and security. These three things may sit with one provider, but they do not have to - what matters is that you know for each part who is responsible and who has access. How to organise that is described in the article on who owns your website: securing domain and access.

Server location and data protection in practice

A website almost inevitably processes personal data: names and messages from the contact form, email addresses, server log files with IP addresses and, where appointments are booked, additional time and service details. The host processes this data on your behalf and is therefore a processor. Under Article 28(3) (EUR-Lex) of the General Data Protection Regulation this requires a contract setting out the subject matter and duration of the processing, its nature and purpose, the type of personal data, the categories of data subjects and the obligations and rights of the controller. Beyond that, the provision prescribes eight points (EUR-Lex) that the contract must expressly cover.

Documented instructions: the processor processes the data only on documented instructions from the controller, including for transfers to third countries (Art. 28(3)(a) GDPR).
Confidentiality: the persons involved are committed to confidentiality or are under an appropriate statutory obligation (point b).
Technical and organisational measures: the processor takes all security measures required under Article 32 (point c).
Sub-processors: further service providers may only be engaged under the conditions of paragraphs 2 and 4 - in practice that means a named list, notice of changes and the option to object (point d).
Support with data subject rights: the provider helps to answer requests for access, erasure and rectification (point e).
Support with security and notification duties: this covers Articles 32 to 36, including notification of personal data breaches within 72 hours (EUR-Lex) under Article 33(1) (point f).
Deletion or return: after the end of the contract the data is deleted or returned at the controller's choice (point g).
Evidence and audits: the provider makes available the necessary information and allows for audits, including inspections (point h).

These points are not paperwork for large corporations. They are the reason why a host without an accessible data processing agreement is a poor starting point for a business with a contact form. Breaches of Articles 28 and 32 fall within the fine range of up to 10 million euros or 2 percent (EUR-Lex) of worldwide annual turnover under Article 83(4). More realistic for small businesses is a query from a supervisory authority, which becomes uncomfortable without a contract and without the record of processing activities required by Article 30. If the website is being reworked anyway, these points are best settled during the website relaunch.

Ask for proof of location

Ask about the specific data centre location, not the provider's business address. The two frequently differ. Carefully run providers name the country and region of their data centres in the contract or the service description.

Check the agreement before booking

The data processing agreement should be available for inspection before the contract is signed, not drawn up only on request. If it is missing from the customer area, that is a reliable indicator of how mature the remaining processes are.

Know the sub-processors

Delivery networks, mail dispatch and backup storage often sit with further service providers. That chain belongs in a named list so you know where data actually resides and who can touch it.

Location alone is only half the answer

A server in Germany helps little if remote maintenance, support or backup storage can reach the systems from a third country. What counts is the possibility of access, not merely the location of the hard drive. A usable framework is the C5 (BSI) criteria catalogue published by the German Federal Office for Information Security: it describes minimum requirements for secure cloud computing, demands transparency about the division of responsibilities between provider and customer, and is currently being revised. A C5 attestation is not a must for small businesses, but the topics it raises make a good basis for the conversation.

Third country transfers: what to document since Schrems II

On 16 July 2020 (CJEU, Case C-311/18) the Court of Justice of the European Union declared adequacy Decision 2016/1250 invalid while confirming that standard contractual clauses under Decision 2010/87 remain valid. The reasoning is what matters: anyone transferring data to a third country must assess case by case whether an essentially equivalent level of protection exists there, adopt supplementary measures where necessary and suspend the transfer if that does not succeed (CJEU, Case C-311/18). Since 10 July 2023 (European Commission), Implementing Decision (EU) 2023/1795 has restored an adequacy decision for the United States - but only for organisations certified under the EU-US Data Privacy Framework.

For the daily reality of a local business this means: if web space, backup storage and mail servers sit in Germany or the EU, this assessment largely falls away. If part of the chain moves to a third country, for instance through a delivery network or a dispatch service for emails, the transfer has to be documented. Impermissible third country transfers fall within the stricter fine range of up to 20 million euros or 4 percent (EUR-Lex) of worldwide annual turnover under Article 83(5). The practical effort is considerably smaller than the sentence suggests, provided it is done properly once and then kept up to date as part of maintenance. Which services additionally require consent in the front end is covered in the article on the GDPR cookie banner.

These five entries belong in your records

First: which providers are involved in the website, including hosting, backup, mail dispatch and delivery network. Second: in which country each of these providers processes the data. Third: on what basis any third country transfer takes place - adequacy decision, standard contractual clauses or a derogation under Article 49 GDPR. Fourth: which supplementary measures have been agreed, such as encryption or restrictions on remote access. Fifth: when this was last reviewed. Five lines per service provider are enough - what counts is that the list exists and is kept current.

Backups that deserve the name

Almost every hosting package advertises backups. The difference lies in the detail, and the General Data Protection Regulation names it with surprising precision. Article 32(1)(c) (EUR-Lex) requires the ability to restore the availability of and access to personal data in a timely manner in the event of a physical or technical incident. Point d adds a process for regularly testing and evaluating the effectiveness of those measures (EUR-Lex). Both lead to the sentence by which backup concepts can be judged: a backup that has not yet been restored is an assumption. The BSI's IT baseline protection also treats the data backup concept as a module of its own and calls for scope, frequency and retention to be documented rather than practised tacitly (BSI).

Feature	Frequently found	Dependable
Frequency	weekly, timing unknown	daily, with a documented time window
Scope	files	files, database and configuration
Retention	the last seven days	several weeks plus monthly snapshots
Storage location	same machine, same account	separate storage with its own access path
Restore	on request, duration open	can be triggered in the customer area, timeframe stated
Evidence	none	at least an annual test restore, logged
Cost	often charged separately in an incident	included in the package price

Two figures help in the conversation with a provider, even without jargon. The first is the maximum acceptable data loss: if the backup runs daily at three in the morning, a whole working day of form messages, orders and content changes may be missing in the worst case. The second is the time to restore: whether that takes an hour or three working days decides whether an incident is annoying or expensive. Both values belong in the contract or the service description, not in the head of a single employee.

The test is the proof

A restore into a test environment shows within an hour what months of backup logs cannot demonstrate: that the data comes back complete, readable and in the right version. Without that evidence a backup remains a promise.

Stored separately

Backups on the same machine help with software errors but little with hardware failure, an encryption attack or an accidentally deleted account. Separate storage with its own access path is the difference between a copy and a backup.

Depth, not just recency

Manipulation and creeping errors are rarely noticed on the same day. Anyone keeping only seven days has no clean state left once the problem surfaces late. Monthly snapshots across several months cost little storage and solve exactly that problem.

One enterprise in five does not back up separately

79 percent (Eurostat) of enterprises in the EU backed up data to a separate location or the cloud in 2024. That is a good figure - and at the same time it means that roughly one in five would have to fall back on backups stored in the same place as the original. For comparison: around 4 percent (Eurostat) of enterprises reported destroyed or corrupted data for 2023 from hardware or software failures alone, that is, independently of attacks.

Reading availability realistically

Percentages in hosting offers feel reassuring because they sit close to one hundred. Translated into hours, the picture becomes more tangible. A year has 8,760 hours (calculation based on 365 days), and every tenth of a percent equals roughly nine hours. It also matters what a promise actually covers: planned maintenance windows are excluded in many service descriptions, as are disruptions at upstream suppliers. And the legal consequence is usually a proportionate credit note, not compensation for lost orders.

Promise	Downtime per year	Downtime per month	Assessment
99.0 percent	87.6 hours	7.3 hours	more than three days a year, tight for business websites
99.5 percent	43.8 hours	3.7 hours	noticeable, yet common in entry-level packages
99.9 percent	8.76 hours	43.8 minutes	the usual expectation for sites with an enquiry function
99.95 percent	4.38 hours	21.9 minutes	sensible for shop and booking operations
99.99 percent	52.6 minutes	4.4 minutes	demanding, rarely required for local businesses

A worked example makes the scale tangible: assume your website produces 40 enquiries a month, spread across business hours. An eight-hour outage on a working day then corresponds arithmetically to roughly two or three lost contacts - assuming no second attempt follows. The actual damage often sits next to it: in the email that was not delivered during the disruption, in the call that goes elsewhere instead, and in the time the business spends on follow-up questions. How to get more out of the visitors you already have is described in the article on more enquiries through the website.

Without measurement, availability remains a claim

An availability promise only takes effect once someone notices outages and can evidence them. That requires an automatic reachability check at short intervals, a notification to a person who can react, and a record of disruptions with timestamps. Without records it is hard to claim a credit note or to judge whether changing provider is justified. In our website maintenance this check is part of the standard scope.

Software level: the quiet risk in legacy contracts

The most common quiet defect in long-standing hosting contracts is a PHP version without security updates. The schedule is predictable and publicly documented: every PHP branch receives two years (PHP.net) of active support followed by two more years (PHP.net) of security-only support. After that, even critical vulnerabilities receive no official fixes. Because websites sometimes need adjustments after a branch change, they tend to stay on the old level in practice - unnoticed, because the site is still being served.

PHP 8.1 has been without security support since 31 December 2025 (PHP.net), older branches for even longer. If you are here, plan the change.
PHP 8.2 receives security updates until 31 December 2026 (PHP.net) - which leaves this year for the switch.
PHP 8.3 is covered until 31 December 2027 (PHP.net); active support ended at the turn of the year 2025/2026.
PHP 8.4 is in active support until the end of 2026 (PHP.net) and receives security updates until 31 December 2028 (PHP.net).
PHP 8.5 was released on 20 November 2025 (PHP.net) and is covered until 31 December 2029 (PHP.net).

Besides PHP, three further points delivered by the provider deserve a look, none of which is visible on the website itself. Encryption should rest on current protocol versions: TLS 1.0 and TLS 1.1 (IETF, RFC 8996) have been formally deprecated since March 2021 and must no longer be negotiated. Certificate lifetimes are being shortened step by step - to 200 days (CA/Browser Forum) from 15 March 2026, to 100 days (CA/Browser Forum) from 15 March 2027 and to 47 days (CA/Browser Forum) from 15 March 2029. Without automatic renewal that quickly turns into a source of errors with a browser warning attached.

Renew certificates automatically

Given the shrinking lifetimes, manual renewal is no longer a workable option. Ask whether renewal runs automatically, who is notified if it fails, and whether this also applies to subdomains and mail servers.

HTTP/2 and HTTP/3

Both protocol versions transfer many small files considerably more efficiently than their predecessor. Whether the server offers them is purely a matter of configuration - and a good indication of how current the platform is kept overall.

Who updates what, exactly

Operating system, web server and PHP sit with the provider; the content system and its extensions sit with you or your agency. That boundary should be recorded in writing so no gap appears - the article on website maintenance and security goes deeper into the second half.

Speed starts at the server

Loading time is usually associated with images and scripts. The first measurable step, however, comes before that: time to first byte describes how long the server takes to answer. Google names 0.8 seconds (Google Search Central) as a good guide value and explicitly frames it as the basis for the metrics that follow. The Core Web Vitals themselves sit at 2.5 seconds (Google Search Central) for the largest visible content, 200 milliseconds (Google Search Central) for the response to interactions and 0.1 (Google Search Central) for layout stability, each measured at the 75th percentile (Google Search Central) of page loads. If the server response is slow, everything after it shifts back, no matter how well the page is built.

A current PHP version with the bytecode cache switched on instead of an expired branch.
An adequately sized database on fast storage rather than on an oversubscribed shared server.
Server-side caching for recurring page views, matched to the content system.
Compression of the delivery plus sensible expiry times for static files.
HTTP/2 or HTTP/3 enabled so that many small files transfer in parallel.
A data centre geographically close to the target audience, which saves round trips in the millisecond range.

Everything that comes afterwards - image formats, fonts, scripts, layout stability - is described in the guide to improving website loading speed and is not repeated here. Only the order matters: optimising the front end achieves little as long as the server answers half a second too late.

A fast server does not make a slow website fast. A slow server makes every fast website slow.

Working principle from our hosting and performance projects

Support, contract and the migration

Reachability and response time

What counts is less the phone number than the agreed response time and the question of who is reachable outside office hours. An incident on a Friday evening shows the difference between a ticket system and a named contact more clearly than any feature list.

Term and notice period

Twelve-month terms with automatic renewal are common. Note the cancellation date in the calendar as soon as the contract is in place - otherwise the notice period decides when a change is possible, rather than the actual need.

Mailboxes and access

Email is attached to the hosting package almost everywhere and is easily overlooked during a migration. Clarify the number of mailboxes, storage sizes and access to administration - details in the article on professional email with your own domain.

Changing provider sounds risky but is plannable when it runs in the right order. The critical part is rarely the website, it is email: mailboxes have to be transferred in full, and during the switchover messages can arrive in two places. For the schedule, therefore, a simple rule applies: put the switchover on a quiet weekday and end the old contract only a few weeks later.

Inventory: which domains, mailboxes, databases, forwardings and certificates exist, and who holds the access credentials.
Test migration: the website is set up and checked on the new server under a temporary address before anything is switched.
Think of email first: mailboxes are created and existing messages transferred so that nothing is lost during the switchover.
DNS lead time: the validity period of the DNS records is lowered one or two days before the date so the change takes effect quickly later on.
Switchover window: the records are changed at an agreed time, after which form, mail dispatch, forwardings and certificate are checked.
Run-out phase: the old contract stays active for a few weeks until it is certain that no messages or visits arrive there any more.

Why the DNS lead time decides the outage window

DNS records are cached by providers and network operators for the duration of their stated validity. If that value is set to several hours, some visitors will keep seeing the old server for an extended period after the switch. Lowering it to a few minutes one or two days in advance shortens the switchover window considerably. Afterwards the original value is restored. This single step is what separates an unremarkable migration from one that customers notice.

Eight questions for your current provider

The following questions fit into a single email and can be evaluated in a few minutes. What is telling is not only the content of the answers, but also how long they take to arrive.

In which country and in which data centre do web space, database, mailboxes and backups reside?
Where do I find the data processing agreement under Article 28 GDPR, and which sub-processors does it name?
How often are backups taken, how long are they retained, and do they sit on separate infrastructure?
When was a full restore last tested, and how long did it take?
What availability is contractually promised, what counts as downtime, and how is it determined?
Which PHP version runs on my package, until when does it receive security updates, and how does a change work?
What is the typical server response time for my home page, and are HTTP/2 or HTTP/3 delivered?
Which response times apply in an incident, how long does my contract run, and by when can I cancel?

Anyone who fails to get a solid answer to more than two of these questions does not have a price problem but an information problem - and that weighs more heavily when something goes wrong. Conversely: a provider who states location, backup rhythm, test restore and PHP roadmap without hesitation has, in our experience, also organised these topics internally.

What this means for your website

Hosting is rarely the reason a website succeeds - but frequently the reason it does not work on a given day. The effort to sort it out once comes to a few hours: inventory, contract review, a test restore and, where necessary, a migration. After that, hosting is once again a line item that is allowed to stay unremarkable.

Inventory

We look at where your website actually resides, which PHP and TLS versions are active, how backups are handled and what the contract promises. The result is a short assessment naming the points that need attention first.

Migration with a plan

Test migration, mailbox transfer, DNS lead time and an agreed switchover window - including a checklist after the change. What is involved is shown on the page about web hosting from Hildesheim.

Ongoing operation

Backups with test restores, updates for server and content system, availability checks and a named contact. The scope is set out in the overview of our services.

Legal and technical obligations attached to a website rarely arrive on their own. If you are reviewing the site anyway, take along the topics that are due in these weeks: the new electronic withdrawal function for businesses that conclude contracts online, and the question of how to use photos on the website in a legally safe way. Both rest on the same foundation as hosting: traceable processes instead of tacit assumptions. For follow-up questions you can reach us through the contact form.

Sources and studies

This article is based on data from: EUR-Lex with Regulation (EU) 2016/679 (General Data Protection Regulation), in particular Article 28(3) on the eight mandatory contents of a data processing agreement, Article 30 on the record of processing activities, Article 32(1)(b) to (d) on availability, timely restoration and regular testing, Article 33(1) on the 72-hour notification deadline, Articles 44 to 49 on third country transfers and Article 83(4) and (5) on the fine ranges of 10 million euros or 2 percent and 20 million euros or 4 percent of worldwide annual turnover respectively; Court of Justice of the European Union, judgment of 16 July 2020 in Case C-311/18 (Schrems II) invalidating Decision 2016/1250, confirming the continued validity of the standard contractual clauses under Decision 2010/87 and setting out the assessment and suspension duties of the data exporter; European Commission with Implementing Decision (EU) 2023/1795 of 10 July 2023 on the adequate level of protection for organisations certified under the EU-US Data Privacy Framework; the German Federal Office for Information Security (BSI) with the C5 criteria catalogue for secure cloud computing (version C5:2020, revision in preparation) and the IT-Grundschutz Compendium (2023 edition) including its data backup concept; PHP.net (Supported Versions) with the life cycle of two years of active support and two years of security support as well as the end dates of 31 December 2025 for PHP 8.1, 31 December 2026 for PHP 8.2, 31 December 2027 for PHP 8.3, 31 December 2028 for PHP 8.4 and 31 December 2029 for PHP 8.5, released on 20 November 2025; Google Search Central with the Core Web Vitals thresholds (2.5 seconds for the largest visible content, 200 milliseconds for the response to interactions, 0.1 for layout stability, measured at the 75th percentile) and the guide value of 0.8 seconds for time to first byte; Eurostat with its survey on ICT security in enterprises (79.2 percent backing up data to a separate location or the cloud in 2024, around 22 percent of enterprises with consequences from IT security incidents, 18.0 percent with unavailability of ICT services due to hardware or software failures and 3.9 percent with destroyed or corrupted data for the same reason, reference year 2023); IETF with RFC 8996 of March 2021 deprecating TLS 1.0 and TLS 1.1; CA/Browser Forum with the Baseline Requirements and the schedule of shrinking certificate lifetimes to 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. Downtime figures in hours are our own calculations based on 8,760 hours per year.