What is Section 203 hosting?
Timo Wevelsiep•Updated: 27.08.2026Editorial note: Versions, commands and prices may change. Please verify critical steps independently before production use. This guide does not replace individual consulting.
Want to run open-source software, Supabase or a custom application in an operating model designed for professional secrets? Explore the Section 203 Managed Cloud.
Section 203 hosting is not a single technical product and not a generally recognised certification. In practice, the term describes a cloud and operating model that takes account of the special requirements professional secrecy holders face when processing protected information. It covers not only the server, but also the application, administrative access, participating service providers, support paths, backups and recovery.
The legal basis is Section 203 of the German Criminal Code. It covers professions including doctors, psychotherapists, lawyers, notaries, tax advisers and auditors. Paragraph 3 addresses the involvement of other participating persons, while paragraph 4 also addresses their handling of third-party secrets and the obligation of further participants. The responsible organisation must obtain legal assessment for its specific arrangement. This guide explains the technical context and is not legal advice.
Why ordinary hosting is too narrow a description
A conventional hosting package usually answers four questions: how much CPU, memory, storage and traffic are available? That view is insufficient for production processing of professional secrets.
At least the following layers are also relevant:
| Layer | Typical assessment question |
|---|---|
| Application | Which data does the software process and which user journeys exist? |
| Infrastructure | Where do compute, database, storage, logs and backups run? |
| Administration | Who can technically access systems, data or keys? |
| Service providers | Which parties participate in hosting, support and operations? |
| Operations | How are updates, monitoring, incidents and restores handled? |
| Lifecycle | How are data exported, deleted and handed over during a change? |
A German location can be part of the target architecture. It does not by itself answer which people participate in support, where backups are replicated or which external services the application calls.
The application belongs inside the trust boundary
Managed hosting is often discussed only at infrastructure level. Modern applications distribute data across several components:
- web application and API
- database and connection pool
- authentication and identity provider
- file or object storage
- email and notification services
- logs, error tracking and monitoring
- backups and off-site copies
- AI models, embeddings or external APIs
The trust boundary therefore needs to start with the real application. A server may be tightly controlled while an SDK in the frontend sends usage data to another provider. Conversely, a cloud environment can be designed around the intended requirements when data flows, access and participating service providers are deliberately constrained.
Section 203 and the GDPR are separate layers
Professional secrets and personal data often overlap, but they are not identical. The GDPR governs the processing of personal data. Section 203 protects third-party secrets entrusted to or otherwise learned by specified professions.
For a project, this means:
- Assess the data-protection role and processing.
- Separately determine whether professional secrets are involved.
- Align agreements and obligations with the real service-provider chain.
- Apply technical and organisational measures to the intended operations.
A data processing agreement under Article 28 GDPR may be required. It is not a blanket substitute for assessing professional secrecy.
What a managed-cloud scope should cover technically
The exact scope depends on the application and its criticality. A dependable operating model can include:
- separate production and administrative access
- MFA, role-based permissions and controlled maintenance paths
- segmentation between application, database and management layers
- encrypted transport and an agreed key-management model
- monitoring for availability, capacity and security-relevant events
- controlled updates through a documented change path
- backup, off-site copies, retention and tested recovery
- traceable incident, export and deletion processes
Not every workload needs the same architecture. A small internal business application, a public client portal and an AI platform processing documents differ significantly in attack surface, availability and data flows.
Which applications are relevant?
Common starting points include:
- AI-generated software for professional secrecy holders moving from prototype to controlled production operations
- Supabase involving professional secrets, where database, auth, storage, functions and RLS need to be assessed together
- Managed Open Source for professional secrecy holders for collaboration, automation, documents or identity
- custom business applications, portals and APIs
- existing environments whose hosting and operational ownership need to be taken over
What is enough for an initial assessment?
Production credentials are not needed for the first conversation. Useful information includes:
- application name and purpose
- broad data types and user groups
- current stage: idea, prototype, production or migration
- platforms and external services in use
- desired operating location and known integrations
- availability, recovery and response-time requirements
This is enough to determine whether the next step should be a technical assessment, a migration or the direct construction of a target environment. The subsequent proposal remains tailored to the actual scope.
Related WZ-IT entry points
- The Section 203 Managed Cloud is the dedicated operating model for professional secrets.
- The AI Code & Production Readiness Audit assesses existing and AI-generated applications before go-live or takeover.
- Supabase migration, Managed Supabase and Managed Open Source are independent services that can be combined with the Section 203 Managed Cloud where required.
- Prototype to Production and software development cover technical remediation, further development and co-development.
Sources
Enquiry
Assess the application and operating model
Describe the application, data types, and current situation. We will assess which technical starting point fits the intended operations without obligation.
Frequently Asked Questions
Answers to the most important questions
No. There is no general Section 203 hosting certificate. The concrete processing arrangement, parties, agreements, access paths and technical safeguards are what matter.
No. Location is one attribute. The service-provider chain, administrative access, data flows, backups, support and deletion also need to be assessed.
No. Data protection and criminally protected professional secrecy are separate assessments. A DPA may be required, but does not answer Section 203 on its own.
In principle, yes. The software licence and suitability of the operating model are separate questions. Installation, access, updates, backups and integrations belong in the scope.
Yes. Architecture, data flows, access, versions, backups and operational state are assessed before takeover. This becomes the basis for an individual migration or takeover plan.
