§ 203 StGB in the Public Cloud: Azure, AWS and Google Cloud, Compliant for Professional-Secrecy Holders

The question reaches us almost weekly: “As a clinic, practice or law firm, are we even allowed to move into the public cloud?” The short answer: yes. The honest answer: yes, but not with the standard contract you accept at the self-service checkout. Anyone bound by medical confidentiality or another professional-secrecy duty under § 203 of the German Criminal Code (StGB) needs more than a data processing agreement. And that “more” looks completely different at Microsoft, AWS and Google.

Update October 2026: We now receive a very large number of enquiries on this topic, many of them from small companies and almost always with the same questions. We have therefore streamlined our offering: we provide the Azure path as a fixed standard process for companies with adequate liability, such as a GmbH or AG (German limited liability company or stock corporation), but not for a UG. We accompany AWS and Google only in exceptional cases. Due to the volume of enquiries, responses may take some time. The details are in the section “Who we offer the process to”. How to procure Microsoft 365 licenses with the same addendum is covered in our new article Microsoft 365 and § 203 StGB.

Note: This article is not legal advice. It describes the established procedure as we implement it as an indirect Microsoft CSP partner with professional-secrecy holders. The assessment of your specific case under professional law belongs to your legal counsel, who is welcome to use this article as a working basis.

Why the DPA is not enough

Since the reform of § 203 StGB, in force since 9 November 2017, professional-secrecy holders may involve external service providers. That means doctors, health professionals and those responsible in clinics, but also lawyers, notaries, tax advisors and auditors. The permission to do so sits in § 203 paragraph 3 sentence 2: secrets may be disclosed to “other contributing persons” as far as it is necessary for their work. The legislator explicitly had the operation, maintenance and external storage of IT systems in mind, in other words the cloud case.

The decisive condition follows in paragraph 4: the contributing person must be obligated to secrecy. Anyone who neglects this obligation as a professional-secrecy holder becomes criminally liable themselves. That is a distinct criminal offence, not a formality. Legally, a data center is nothing other than such an “other contributing person”.

Picture the hyperscaler as a new employee: before she sees patient records on day one, she signs a confidentiality undertaking, including a briefing on the criminal consequences. The law demands nothing different from the data center. It is just that the signature here is not collected in the HR office, but through contract addenda that the providers do not advertise loudly.

One point of classification, because it causes confusion in practice: § 203 StGB names professions, not institutions. A hospital as a legal entity is not itself a “professional-secrecy holder”. The obligation rests on the treating physicians; the remaining staff are their professional assistants. In effect, the clinic is therefore still covered, but derivatively, through the health professionals working there. For lawyers, § 43e BRAO and for tax advisors § 62a StBerG specify what has to be observed when involving service providers. Microsoft’s addendum addresses § 203 StGB; you assess the parallel provisions with your legal counsel.

Key takeaway: The DPA under Art. 28 GDPR protects the data of your patients and clients. The confidentiality undertaking under § 203 StGB protects you, namely from criminal law.

You need both. And depending on the hyperscaler, the path there is a documented process, a form, or a case-by-case negotiation. We walk through all three and state for each what we offer.

Who we offer the process to

Up front, so you can place your enquiry correctly: every § 203 engagement takes time, and at AWS and Google a lot of it. That is why we apply fixed rules.

• Microsoft Azure: standard process for companies with adequate liability, such as a GmbH or AG. A UG (haftungsbeschränkt) does not qualify. You procure Azure at Microsoft list prices with no markup and receive the addendum through our indirect CSP model.
• Microsoft 365: the same process under the same prerequisites, for licenses such as Business Standard, Business Premium or E3. Details in the article Microsoft 365 and § 203 StGB.
• Modified Abuse Monitoring: we support it, but only with a corresponding purchase volume. There is no markup here either.
• AWS and Google: only in exceptional cases. The process is time-consuming, so we offer it exclusively to clients of our software development whose volume is high enough, and only to companies such as a GmbH.
• Not offered: UG (haftungsbeschränkt), the German mini-GmbH, and similar legal forms without adequate liability, for all providers. For AWS and Google, additionally no small companies.

We do not deviate from our standard process. Our terms and conditions (German AGB) apply to the reselling. We pass on Microsoft’s addendum unchanged: no additional clauses, no side agreements, no individual confirmation letters and no contract drafts of our own for the procurement. The questions we receive most often are answered further down in this article. Due to the volume of enquiries, responses may take some time.

Microsoft Azure: the most formalized path

For Germany, Microsoft has created a dedicated addendum that explicitly obligates the company to secrecy. It appears under several names but refers to the same document: in Partner Center as the “Professional Secrecy Amendment for Germany”, in German as the “Datengeheimnis-Zusatzvereinbarung für Deutschland (November 2021)”, and in the document itself as “Microsoft Customer Agreement – Zusatzvereinbarung für Berufsgeheimnisträger”. It supplements the Microsoft Customer Agreement (MCA) and is filed as an official Microsoft partner document on the CSP documents page in Partner Center. As a customer you have no direct access to it; you obtain the document through your CSP partner. It is a Microsoft standard and requires no negotiation.

We implement this path as an indirect CSP reseller: the contract exists between Microsoft and you, innFactory handles brokerage and billing, and the distributor TD SYNNEX Germany GmbH & Co. OHG acts as Indirect Provider. The standard process has five steps:

1. Quote: you receive a quote for an Azure subscription at Microsoft list prices, with no markup, no setup fee, no ongoing CSP or management fees and no minimum spend. Our terms and conditions apply to the reselling.
2. Confirm the partner, grant GDAP, set up the mandate: you confirm innFactory as your partner in the Microsoft 365 Admin Center, grant the minimal GDAP permission (more on that below) and a B2B SEPA direct debit mandate. We verify the mandate with a EUR 1 test debit that is credited against the first invoice. If you use Conditional Access policies, adjust them so that billing works.
3. Verify the MCA, create the subscription: in Partner Center we check whether a valid acceptance of the Microsoft Customer Agreement is on file for your customer account. With an existing tenant this is usually the case; with a new tenant you accept the MCA in the Microsoft 365 Admin Center. Without confirmed acceptance no CSP subscription can be created. We then provision the subscription through the indirect CSP model.
4. Accept the addendum: we download the official document from Partner Center and send it to you unchanged. You accept it and attach it to your MCA. The addendum takes effect through your acceptance; Microsoft does not countersign it. Create productive resources only after documented acceptance.
5. Optional: apply for Modified Abuse Monitoring: for Azure OpenAI, i.e. the “Foundry Models sold by Azure”, you submit the Modified Abuse Monitoring application to Microsoft. We support the application with a corresponding purchase volume (details below).

Setup, configuration and administration of the subscription remain permanently with you. A support contract is not required for the pure CSP procurement. If you want support beyond that, for example with migrating existing AI workloads to Azure AI Foundry, that is a separate offer on a time-and-materials basis, clearly separated from the CSP procurement so that the contractual relationship between you and Microsoft remains untouched.

The deadline trap: the MCA runs indefinitely, the addendum does not

One detail from the first paragraph of the addendum is regularly overlooked in practice: the MCA as a framework agreement is open-ended. The § 203 addendum is not. In the wording of the German version, it “expires on either (i) the expiry date of the Microsoft Customer Agreement or (ii) the last day of the month, 36 full calendar months after the customer’s acceptance, whichever occurs first”. The document contains no renewal clause. Lawyers call this a mismatch of terms: the main contract and its protective shield do not run in sync.

Microsoft designs it this way on purpose. § 203 StGB is national criminal law, and the company does not want to bind itself under criminal law indefinitely, but rather to adapt the addendum to legislative changes, new technical measures and updated contract frameworks. For you as a customer, this means operationally:

1. Document the expiry date on the day of acceptance, not at some point later.
2. Check after 30 to 34 months at the latest whether a newer version exists and re-acceptance is required.
3. Have it re-confirmed if in doubt, before the addendum expires.

If the addendum expires unnoticed, Microsoft’s contractual confidentiality commitment is gone while the services simply keep running. The criminal-law risk and the audit risk vis-à-vis chambers and supervisory authorities then fall back entirely on you.

How you evidence acceptance

The second question that comes up in every audit: how do you actually prove that the addendum was accepted? There is no acceptance record countersigned by Microsoft. The evidence is indirect, but legally sound, and rests on three building blocks:

1. Evidence of MCA acceptance: the Microsoft Customer Agreement exists between Microsoft and you, so the evidence sits with you as well. It is provided by an export or screenshot from the Microsoft Admin Center or Azure Portal with the date, tenant ID and accepting organization. No addendum without MCA acceptance.
2. Valid version of the addendum: in addition to your MCA, file the PDF version of the addendum valid at the time of acceptance, with its version date, together with your documented acceptance. Microsoft does not sign the document; it documents what became part of your MCA.
3. Use and ordering: the first order of cloud services after acceptance, plus ongoing invoices, count as acceptance through conclusive conduct.

Anyone who files these three pieces of evidence together is audit-proof.

Modified Abuse Monitoring: the overlooked AI building block

Step 5 of the process deserves a closer look. For the “Foundry Models sold by Azure”, in particular Azure OpenAI, Azure by default logs flagged prompts and completions for abuse monitoring and stores them for up to 30 days in a separate data store that is segregated by customer. Review is initially automated; human review by authorized Microsoft employees only takes place when the automated assessment is inconclusive, and, for services in the European Economic Area, by staff located within the EEA. So even though not every prompt is read by a human: for client or patient data, the mere storage with possible human review is a problem that no DPA in the world solves.

Only approved Modified Abuse Monitoring switches off this storage and the human review (an automated assessment without storage may still take place). Unlike the addendum, which you simply accept, Modified Abuse Monitoring has to be applied for. The application is a form that you as the customer submit to Microsoft yourself. Microsoft decides; there is no guarantee of approval, and Microsoft does not state a binding processing time either. Anyone who gives you a firm promise does not know the process.

The application is aimed at customers managed by a Microsoft account team. Anyone who starts via self-service often lacks that access. innFactory therefore supports the application, but only with a corresponding purchase volume, meaning a corresponding Azure consumption, because the support is time-consuming. We charge no markup for it. Where the volume is in place, we have an account created at Microsoft through our own Microsoft contacts so that the application can be processed even without your own account team. A practical planning note: in our experience the application support works between September and June. During the summer months of July and August the process largely pauses on Microsoft’s side, so plan AI project starts accordingly.

You can verify yourself whether Modified Abuse Monitoring is active: after approval, the capabilities list of the affected resource shows the entry ContentLogging with the value false. You find it in the JSON view of the Azure portal or via Azure CLI with az cognitiveservices account show. That is the technical evidence for your compliance documentation, backed by the public Microsoft documentation on data and privacy for Azure OpenAI.

Not every AI service needs Modified Abuse Monitoring. The question comes up regularly for Azure AI Document Intelligence, for example when digitizing patient records or client correspondence. Classic Azure AI services such as Document Intelligence have no abuse monitoring and their own data retention model: inputs and results are held for retrieval for up to 24 hours and then deleted, and earlier deletion of the analysis results is possible via the Delete Analyze API (Microsoft documentation). A Modified Abuse Monitoring application is neither required nor provided for such services.

A note on naming, so you find the right documentation: Microsoft reorganized the Azure OpenAI services under “Microsoft Foundry” / “Models sold by Azure” in 2025, and the content filters are now called “Guardrails”. The mechanism behind it stays the same.

The optional Sovereign Public Cloud adds another layer on top: Microsoft’s sovereignty offering for the European data-center regions combines the EU Data Boundary (fully implemented since February 2025) with operational transparency via the “Data Guardian” (access by personnel based in Europe, logged in a tamper-evident way) and customer-managed keys in your own HSMs (External Key Management). The operating model is the Sovereign Landing Zone, a sovereignty-focused variant of the Azure Landing Zone, available as a Bicep and Terraform implementation. The offering was announced in June 2025 and has been rolling out across the European regions since then. For organizations with high protection requirements, this is the logical next step; for getting started, the standard process above is enough. What such a sovereign setup looks like is something we show using our sovereign AI hub on STACKIT and in our article on Azure Landing Zones.

The most common questions about the Azure path

The following points come from the enquiries that have reached us since the original publication. We answer them here the way we answer them by e-mail: directly, as a description of the established procedure and without claiming to give legal advice. Status: October 2026.

What does procurement through innFactory cost?

For Microsoft Azure products we charge no setup fee; Microsoft list prices apply with no markup. There are no ongoing CSP or management fees and no minimum spend for the Azure procurement. This applies to all Azure resources in the subscription, including network and security components such as Private Endpoints or Azure Front Door. Billing is based on actual consumption via B2B SEPA direct debit. As your volume grows, only the Microsoft consumption costs increase; our terms do not change.

The prerequisite is a company with adequate liability, such as a GmbH or AG. We do not serve a UG (haftungsbeschränkt) in this model. In addition, we need a B2B SEPA direct debit mandate through which we collect the Microsoft amounts. For newly founded companies without an established credit history we reserve the right to a check. Support with Modified Abuse Monitoring additionally requires a corresponding purchase volume.

Marketplace and partner products are explicitly excluded. Why that matters especially for AI models is explained below.

Who is the contracting party, and what role does TD SYNNEX play?

The contract exists between Microsoft and you. innFactory, as an indirect CSP reseller, handles brokerage and billing; TD SYNNEX, as distributor, is the Indirect Provider. In the pure CSP model innFactory has no access to your customer content and does not itself need a § 203 obligation. If we additionally provide services within your subscription, we agree that separately, including the confidentiality obligation then required.

We often receive legitimate questions about the distributor’s role. Technically, a Foreign Principal of TD SYNNEX is registered in your subscription. It serves exclusively to resolve billing data. TD SYNNEX has no active access to your tenant, your subscription or your content. In addition, innFactory holds a § 203 confirmation from TD SYNNEX as Indirect Provider, so the chain from the professional-secrecy holder to Microsoft is documented without gaps.

What access rights does innFactory receive in our tenant?

The minimal ones. We request a GDAP relationship (Granular Delegated Admin Privileges) with Limited Access covering exactly two Entra roles: Directory Reader and Service Support Administrator. They serve to create and assign the subscription in the CSP model and allow us to open Microsoft support requests on your behalf. Both roles act at directory level. innFactory receives no Azure RBAC roles such as Owner or Contributor on your subscription or resources and has no access to your content.

You can end the GDAP relationship at any time in the Microsoft 365 Admin Center. The reseller relationship for ordering and billing remains unaffected (Microsoft GDAP FAQ). Without GDAP, however, we cannot handle administrative tasks such as support tickets or the creation of additional subscriptions for you; if needed, we then set up the relationship again.

Which services does the addendum cover?

The addendum is not service-specific. It supplements the Microsoft Customer Agreement with the professional-secrecy clause and covers the online services procured under the MCA. Services of the Azure platform outside the Marketplace, such as Azure OpenAI, Azure AI Foundry or Azure AI Document Intelligence, fall under it. Whether that is sufficient for your specific use is something you clarify with your legal counsel; the contractual position itself is clear.

The same applies to Microsoft 365 if you procure the licenses in the CSP model under the MCA. How that works through us is described in the article Microsoft 365 and § 203 StGB.

The important exception is third-party AI models. In Azure AI Foundry Microsoft distinguishes two categories, and the difference determines your contractual position:

• Foundry Models sold by Azure: hosted and operated by Azure, billed through your Azure subscription, Azure SLAs, Microsoft support. They run under the Microsoft contracts and thus under the MCA with addendum. For individual models an additional provider EULA applies. Example, as of August 2026: Microsoft lists Cohere-rerank-v4.0-pro and Cohere-rerank-v4.0-fast as “Cohere models sold by Azure”. For these the Azure AI EULA for Cohere Models additionally applies, a contract between you and Cohere for use via Microsoft’s platform. No separately negotiated agreement with the provider is required, but the EULA belongs in your legal review.
• Models from partners and community: non-Microsoft products under the Microsoft Product Terms, procured via the Azure Marketplace, with license terms and price set by the provider. They fall neither under the Microsoft DPA nor under the addendum and cannot be procured in the CSP model.

A model’s status can change. Therefore check it in the public Microsoft catalog before use.

Isn’t the C5 attestation enough?

No. The scope of Microsoft’s BSI C5 attestation is publicly documented, and Azure AI Foundry and Azure OpenAI are part of it. C5 evidences security controls and is a sensible building block of your documentation. It does not replace a confidentiality obligation under § 203 paragraph 4 StGB, because that arises exclusively from the contractual commitment, i.e. from the accepted addendum. Anyone who derives § 203 compliance from a C5 attestation confuses technical security with a criminal-law obligation.

Are there individual commitments or additional clauses?

No. We do not deviate from our standard process. Our terms and conditions apply to the reselling, and you receive the addendum exactly as Microsoft provides it: unchanged, with no additional clauses and no side agreements. Individual confirmation letters, contract amendments or commitments regarding further provisions like § 43e BRAO are practically unobtainable from Microsoft below roughly one million euros of Azure spend per year anyway, and we do not request them. The good news: § 203 StGB itself is standard and needs no negotiation.

We are an IT service provider ourselves, with end customers in healthcare or the legal sector. Does that change anything?

Not for the procurement path; the same prerequisites apply. Contract, subscription, addendum and Modified Abuse Monitoring work for a service provider exactly as they do for the clinic or law firm itself. What differs is your own role in the chain: whether and how you yourself are obligated as a contributing person under § 203 paragraph 3 StGB and pass that obligation on to Microsoft is a matter of your contract with your end customers. We make no statement on that; it belongs to your legal counsel.

AWS: an addendum through the partner channel

Up front: we offer the § 203 process for AWS only in exceptional cases. It is time-consuming, so we provide it exclusively to clients of our software development whose volume is high enough, and only to companies such as a GmbH. We do not offer it to UGs or small companies. The process below shows how the path works in principle.

At AWS there is no publicly linked § 203 standard agreement of the kind Microsoft provides. The existing AWS addenda do not specifically address the German professional-secrecy duty. The path therefore runs through an individual agreement initiated via the distribution channel. The process:

1. Create an AWS account or use an existing one, which works just as well.
2. Set up a billing transfer to innFactory / TD SYNNEX so the account is run under the partner model.
3. Request the addendum: through our contacts at TD SYNNEX and AWS, we initiate the confidentiality addendum.
4. Conclude the agreement: you conclude the addendum directly with AWS.
5. Check Bedrock models: since October 2025, AWS has simplified access to Amazon Bedrock: the serverless models of a region are now generally available automatically, and the earlier manual enablement step is gone. For individual models, however, a hurdle remains: the Anthropic models, for example, require a one-time use-case form before first use. Check this early so that the desired model is ready at project start.

The last point is the typical pitfall: teams conclude the agreement, start the project, and then find that the use-case form is still missing for the desired model. Plan the model release as its own step, not as a given.

Google Cloud: possible, but without a timeline guarantee

Up front: the same applies to Google as to AWS, whether Google Cloud or Google Workspace. We accompany the process only in exceptional cases, for clients of our software development with a correspondingly high volume, and only for companies such as a GmbH.

Google is the path with the most unknowns. Publicly available is only the general Cloud Data Processing Addendum, which governs data-protection processing under GDPR. Beyond that, a dedicated addendum for the professional-secrecy requirements under § 203 StGB does exist, but it is not publicly available. The procedure: you request the document under a non-disclosure agreement (NDA), review it with your legal counsel, and Google then handles the request on a best-effort basis. Where we accompany the process, we use our contacts at Google, but we still cannot name a reliable timespan to a conclusion. Nor should anyone who knows the process promise one.

That is not a disqualification of Google Cloud or Vertex AI. It simply means: anyone betting on Google who falls under § 203 StGB should start the contract initiation early and not make project planning dependent on a fixed contract date.

The three paths at a glance

Conclusion: four steps to a compliant cloud

All three hyperscalers can be used while respecting § 203 StGB, but none of them “just like that” via credit card and standard contract. Our rule of thumb:

1. Contract first, then the data. No patient or client data in the cloud before the confidentiality addendum is concluded and documented.
2. Manage deadlines and evidence. Document expiry dates, file the three pieces of evidence, and initiate renewal in good time. An expired addendum is as good as none.
3. Assess AI services separately. Abuse monitoring, data retention, model status and model releases are their own workstreams alongside the framework agreement: Modified Abuse Monitoring and the distinction from Marketplace models at Azure, the use-case form for individual Bedrock models at AWS.
4. Go through the partner channel. The addenda run through partner and distribution structures at all three providers. At Azure and Microsoft 365, procurement through innFactory as an indirect CSP partner costs nothing extra, provided your company has adequate liability, such as a GmbH or AG.

Anyone who lays this foundation cleanly can then use the leading AI models in a way that is compliant with both data-protection and professional-secrecy law: GPT via Azure OpenAI, Claude via Amazon Bedrock or Google Vertex AI, Gemini via Vertex AI. The models then run inside your secured cloud environment instead of over a public endpoint.

From contract to finished solution: CompanyGPT and AI Gateway

The addendum creates the framework, but not yet a workplace where physicians, lawyers or tax advisors actually work with AI. For that we offer a complete solution with CompanyGPT: an AI assistant with a ChatGPT-like interface that runs entirely in your own Azure subscription, i.e. exactly in the environment covered by the MCA and the addendum. CompanyGPT obtains its models through Microsoft Foundry (formerly Azure AI Foundry) in the EU Data Zone, sign-in runs through Microsoft Entra ID, SharePoint documents are searched with the permissions of the respective user, and specialist systems and your own agents can be connected via the Model Context Protocol. Only the Azure consumption costs are billed through the CSP procurement, with no per-seat licenses. We describe the cloud stack behind it in the article CompanyGPT cloud stack in your own Azure tenant.

CompanyGPT is complemented by the innFactory AI Gateway: an OpenAI-compatible LLM gateway written in Rust that bundles all AI access of your applications, tools and agents behind a single API, authenticates users via Entra ID, enforces budgets and cost centers per team or agent, and logs every access. For professional-secrecy holders the routing aspect is the most interesting part: besides Azure OpenAI, the gateway also speaks Amazon Bedrock, Google Gemini, STACKIT and other providers. Third-party models such as Anthropic Claude can thus be integrated via the route for which you have concluded the appropriate contractual framework, for example Amazon Bedrock after concluding the AWS addendum, while your users continue to see only a single, controlled endpoint. Provider keys are stored in Azure Key Vault, and the data stays in your cloud or in sovereign German data centers. The gateway is a standalone product and not a prerequisite for CompanyGPT; it pays off as soon as several teams, applications or agents are to be controlled across different model providers.

And even desktop tools like Claude Cowork and Claude Code can be redirected to your own compliant model endpoints via a centrally distributed configuration profile. We show exactly how in our article Claude Cowork & Claude Code, GDPR-compliant with CompanyGPT (in German).

Important note: This article is not legal advice and does not replace it. It describes the processes and the established procedure to the best of our knowledge at the time of the last update (October 2026). There is no such thing as a “100 percent legally secure” or “automatically § 203-compliant” cloud: compliance arises on your side from contract, configuration and organization, and the assessment of your specific case under professional law belongs in the hands of your legal counsel. Contract offers, forms, terms, model catalogs and programs of the hyperscalers change regularly. In particular, always check the current version of the addenda, the status of the models you use in the Microsoft catalog, and the availability and conditions of Modified Abuse Monitoring at the time in question. The statutory text of § 203 StGB is publicly available.

Is your company a GmbH, AG or comparable company with adequate liability, planning cloud or AI workloads with data covered by professional secrecy? innFactory accompanies you as an indirect Microsoft CSP partner: Azure subscription and Microsoft 365 licenses at Microsoft list prices with no markup, no setup fee and no ongoing fees, including Microsoft’s unchanged addendum for professional-secrecy holders. Get in touch. Due to the volume of enquiries, responses may take some time.