Skip to content 
GDPR Hosting demands clear contracts: I define responsibilities, secure data with TOMs, and transparently specify the server location. This allows me to avoid fines, respond quickly to requests for information, and clearly define subcontractors, deletion concepts, and reporting obligations in contracts [1][2].
Key points
For a robust hosting contract, I rely on a few essential clauses with clear rights and obligations.
- AVV obligation: Accurately reflect Article 28 of the GDPR
- TOM in concrete terms: Encryption, backups, access
- Server location: EU, SCC for third countries
- subcontractor: List, approval, audit
- Liability: Clear boundaries, no exemptions
Who needs GDPR-compliant hosting contracts?
Every website with a contact form, shop, or tracking processes personal data. This means that I act as the controller and the host as the processor, which constitutes a AVV makes it mandatory [1][2]. Without clear rules on purpose, scope, and deletion, unnecessary risks arise. Even small projects are not exempt, as even IP addresses are considered personal data. I keep track of what data flows, the legal basis on which I process it, and how the host supports me in terms of data subject rights.
The data processing agreement (DPA) explains
A complete AVV clarifies Rollers Clear: As the responsible party, I give instructions and the host implements them [1]. The contract specifies the purpose, type of data, categories of data subjects, and duration of processing. It also describes the TOM Not vague, but measurable: encryption, access controls, emergency processes, logging. For subcontractors, I require transparent lists, information obligations in the event of changes, and a documented approval process [1]. At the end of the contract, I oblige the host to delete or return the data, including proof, plus support with audits, information, and reports of data protection incidents [2].
Practical technical and organizational measures (TOM)
I demand mandatory Encryption in transit (TLS) and at rest, hardening of systems, and well-maintained firewalls. Backups must run regularly, be encrypted, and be testable for restoration so that recovery times are documented [2]. Access is only granted to those who really need it; multi-factor authentication and logging help with traceability. Patch management, malware protection, and DDoS defense reduce the risk of outages or data leaks. For emergencies, I require documented incident and continuity management with defined response times [1][2][6].
Server location and third-country transfers
An EU server location reduces legal Risks noticeable, because I do not provoke any illegal third-country transfers [7]. If providers or subcontractors from third countries access data, I use EU standard contractual clauses and check additional protective measures such as encryption with exclusive key control [9][10]. Technical design is crucial here: without access to plain text data in the third country, the attack surface is significantly reduced. For detailed questions, I use in-depth guidelines on Cross-border transfers. In the contract, I oblige the host to notify me in advance of any changes to locations and data paths [1][7].
Using auditing and control rights correctly
I secure myself audit rights and request evidence: certificates, test reports, technical descriptions, and log excerpts [1]. I evaluate reports older than twelve months critically and demand that they be up to date. Remote assessments are often sufficient, but in cases of increased risk, I plan on-site inspections. I specify response and provision times for evidence in the contract so that requests do not get lost. If necessary, I obtain guidance on obligations from the information provided in the legal obligations [1].
Liability, obligations, and customer responsibility
A indemnification I do not accept the host's disclaimer of all risks, as such clauses often do not hold up in court [5]. Instead, I limit liability in a comprehensible manner, differentiate between slight and gross negligence, and specify cardinal obligations. The contract sets out my own obligations: only import data lawfully, no illegal content, secure passwords, and protection against unauthorized use [8]. Reporting obligations in the event of data protection incidents must be prompt, comprehensible, and documented. Clear responsibilities avoid disputes when seconds count [5][8].
Classify certifications appropriately
An ISO 27001 seal provides valuable circumstantial evidence, but does not replace a contract review [1]. I check the scope, affected locations, and whether the certificates are up to date. In addition, I request reports on penetration tests, vulnerability management, and restore tests. It remains crucial that the TOMs specified in the AVV actually correspond to the certified scope. Without a comparison between the certificate and the contract, I cannot be lulled into a false sense of security [1][2].
Transparency with subcontractors
For everyone subcontractor I require a publicly accessible list or a customer portal with change notifications. I reserve the right to object or at least the right to terminate the contract in the event of serious changes. The host obliges every subcontractor to adhere to identical data protection standards and provides me with relevant contracts or summaries [1]. Access chains must be documented in a traceable manner, including locations and data categories. This is the only way I can maintain control over the entire supply chain.
Overview of minimum contractual content
To facilitate decision-making, I present the most important Criteria and evaluate GDPR compliance based on hard criteria [1][2].
| Provider | Server location EU | AV contract | TLS/Backups | ISO 27001 | GDPR status |
|---|---|---|---|---|---|
| webhoster.de | Germany | Yes | Yes | Yes | high |
| Provider B | EU | Yes | Yes | Partly | good |
| Provider C | outside the EU | on request | Yes | no | restricted |
The table does not replace your own Examination, but it helps me to quickly identify minimum standards and address critical issues directly [2][7].
Practical check before signing the contract
Before signing, I request the AVV In the original text, I check TOMs for traceability and request concrete evidence such as backup test logs. I clarify how I issue instructions, how quickly support responds, and how incidents are reported. For subcontractors, I ask to see the current list and include changes in a notification process. I discuss the data lifecycle from import to storage to deletion, including backup stocks. For international transfers, I insist on SCC, additional encryption, and documented risk assessments [1][2][9][10].
Contractually define SLA, availability, and support
I check SLA-Values for availability, response time, and recovery, and compare them with my business risks [4]. Contract term, termination window, and migration assistance should be clearly stated. For backups, I have intervals, retention periods, and restore times documented so that I have reliable claims in case of an emergency. Transparent support escalation saves days when there is a crisis. I get practical tips on reading contracts in the guide to SLA and Liability [4][5].
Role differentiation and shared responsibility
I keep a written record of where my Responsibility ends and that of the host begins. The host only processes data on instruction, operates infrastructure, and secures it in accordance with the AVV; I remain responsible for content, legal bases, and the configuration of my applications [1][2]. Especially with managed services, I draw clear boundaries: Who patches the application? Who configures web server logs, who configures cookie banners? I define what an instruction is (e.g., ticket, change request) and what deadlines apply. When in doubt, I avoid a de facto Joint controllership, by clearly assigning and documenting decision-making and access rights within my area of responsibility [1].
- Appointment of designated contact persons on both sides
- Process for changes: Request, evaluation, approval
- Limits of managed services: What is included, what is not
- Obligation to document all instructions and implementations
DPIA support and risk assessment
When a Data protection impact assessment (DPIA) is necessary, I require structured input: data flows, TOM descriptions, residual risks, and any compensation [1][2]. I map technical metrics to risk: RPO/RTO, zone models, recovery exercises, physical security. The host provides me with the building blocks, I decide on risk acceptance and document the results. I re-evaluate changes that have an impact on risk (new location, new logging system, new CDN chain) and have them displayed in advance [7].
Deletion, archiving, and backups in detail
I differentiate between the data lifecyclesPrimary storage, caches, log data, metadata, and backups. I set deletion periods, triggers, and documentation requirements for each segment. In the AVV, I stipulate that the host must take deletions into account not only in the production system, but also in snapshots and backups – technically realistic with the expiry of the retention periods or through selective masking, where possible [2].
- Obligation to delete or return data with deadlines after the end of the contract
- Logged deletion confirmations, including data carrier and system reference
- Separation between legal Storage and technical Archiving
- Regular tests to ensure that restores do not bring back „forgotten“ old data
I implement data minimization for logs: IP anonymization, limited retention, clear access rights. This allows me to reduce risks for those affected while maintaining a balance with forensic requirements [1][2].
Efficiently supporting the rights of those affected
The AVV obliges the host to notify me in the event of Articles 15–22 of the GDPR-requests. I specify formats and deadlines: machine-readable data exports, log extracts according to defined filters, corrections within defined time frames. I handle identity verification and ensure that the host only provides personal information on my instructions. For complex searches (e.g., log searches across multiple systems), I negotiate transparent rates and response times so that the 30-day deadline can be realistically met [1][2].
- Standardized export profiles (e.g., JSON/CSV) and checksums
- Editorial duties: Redaction of third parties in log files
- Ticket workflows with escalation logic and timestamps
Multi-client capability, isolation, and logging
Especially in multi-tenant environments, I demand Insulation at the network, compute, and storage levels. I ask about hypervisor and container hardening, tenant separation, secret scopes, and JIT access for administrators. The host logs privileged access in an audit-proof manner; access to production data is only granted according to the dual control principle and documented approval. I keep log data purpose-bound and minimized; I base retention on security and compliance requirements, not on „nice to have“ [1][6].
Key and secret management
I determine how cryptographic key generated, stored, rotated, and destroyed. Ideally, I use customer-controlled keys (BYOK/HYOK) with a clear separation of roles. The host documents KMS/HSM use, key access processes, and emergency paths. I record rotation and versioning in the AVV; separate keys and access logs exist for backups. Where third-country risks exist, exclusive key control is an effective additional safeguard [9][10].
International chains: CDN, DNS, email, and monitoring
I look at all Data paths not just the primary server location. CDN edge caches, DNS resolvers, email relays, support tools, or cloud monitoring may touch on personal data. That's why they belong on the subcontractor list, including locations, data categories, and purpose [1][7]. I require EU options, IP anonymization at the edge, and disable non-essential services if they do not provide added value. For remote support, I regulate how screen sharing, log access, and temporary admin rights are handled in accordance with the GDPR.
Authority inquiries and transparency
I oblige the host to, official request to check, inform myself (to the extent permissible), and only disclose the minimum necessary data. A defined process with contact points, deadlines, and documentation is mandatory. The host retains court orders, rejections, and correspondence and regularly provides me with aggregated transparency information. This allows me to remain able to provide information to affected parties and supervisory authorities [7].
Exit strategy, migration, and data portability
Right from the start, I plan the ExitFormats for data export, migration windows, parallel operation, prioritization of critical systems. I establish support packages (hourly quotas), data integrity checks, and binding schedules. After successful migration, I request confirmation of complete data deletion, including offsite backups, log archives, and emergency copies. Contract clauses make it clear: no data pledges, no artificial hurdles, and AVV obligations (e.g., confidentiality) apply beyond the end of the contract [1][2].
Specify incident response and reporting requirements
I write Content and timing Incident reports: Initial report within a defined number of hours, with minimum content (scope, types of data affected, time of detection, initial measures). I expect an update within 72 hours that allows me to perform an assessment in accordance with Articles 33/34 of the GDPR. My organization receives root cause analyses, corrective measures, and lessons learned in writing and in a verifiable form. This way, I don't lose any time in an emergency [2][6].
Costs, changes, and maintenance windows
I stipulate in the contract which Costs for special services (e.g., data subject rights, special export formats, additional audits) and which services are to be provided as part of the AVG obligations at no additional cost [1]. The host communicates planned changes at an early stage; maintenance windows are outside critical business hours and are subject to binding downtime limits. After disruptions, I expect post-mortems, measures derived from them, and, if necessary, credits in accordance with the SLA [4][5].
Summary for decision-makers
With a clear AVV, I keep data protection risks in check with reliable TOMs and EU locations. I contractually secure audit rights, subcontractor transparency, and realistic liability limits. For third-country access, I use SCC and additional technology to ensure that data remains protected [7][9][10]. A clean deletion and return process prevents legacy issues after the end of the contract. This keeps my hosting setup legally resilient and technically well documented – and I can respond calmly to regulatory audits [1][2].
