§ 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 August 2026: Since the original publication we have received many follow-up questions about the Azure path, above all on costs, on the roles of innFactory and TD SYNNEX, on GDAP permissions, on the scope of the addendum and on Modified Abuse Monitoring. We have worked the answers into this article, bundled in the new section “The most common questions about the Azure path”.

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 2017 – the law came into force on 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 will walk through all three, exactly as we implement them at innFactory with our clients.

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, available to customers of every size, 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. Here is what the process looks like at our end:

1. Quote and clarification of roles: You commission that your Azure costs are procured through innFactory. 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.
2. Confirm the partner, grant GDAP, set up the mandate: You confirm innFactory as your partner in the Microsoft 365 Admin Center and grant the minimal GDAP permission (more on that below). If you use Conditional Access policies, they are adjusted so that billing works. Add to that a B2B SEPA direct debit mandate, which we verify with a EUR 1 test debit that is credited against the first invoice. If no Entra tenant exists yet, we briefly coordinate the setup.
3. Verify MCA acceptance: In Partner Center we check your customer account for a valid acceptance of the Microsoft Customer Agreement and document the result during onboarding. With an existing tenant the MCA is usually already in place. Only with a new tenant do you accept it as part of the CSP setup, directly in the Microsoft 365 Admin Center. Without confirmed acceptance no CSP subscription can be created.
4. Create the subscription: innFactory provisions the subscription through the indirect CSP model with TD SYNNEX as distributor.
5. Accept the § 203 StGB addendum: innFactory downloads the official document from Partner Center and provides it to you. You accept it and attach it to your MCA. The addendum takes effect through your acceptance; Microsoft does not countersign it. Our recommendation: create productive resources in the subscription only after documented acceptance.
6. 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. innFactory coordinates the application free of charge and, through its own Microsoft contacts, makes sure it can be processed even without your own Microsoft account team.
7. Optional: roll out a Sovereign Landing Zone – policy-as-code guardrails for data residency, encryption and confidential computing, based on Microsoft’s Sovereign Public Cloud (Bicep or Terraform).

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 6 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. This is exactly where we come in: innFactory coordinates the application free of charge and, through its own Microsoft contacts, has an account created at Microsoft 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, steps one to six are 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: August 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. 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.

There is no minimum and no maximum customer size, neither in the number of users nor in revenue. The only prerequisite is that we may invoice the Microsoft amounts and collect them by direct debit. For newly founded companies without an established credit history we reserve the right to a check.

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 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; we do this for our clients with every enquiry and back the result with the source.

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.

Will we get individual commitments from Microsoft?

Realistically, no. Whatever Microsoft does not offer as standard, such as individual confirmation letters, contract amendments or commitments regarding further provisions like § 43e BRAO, is practically unobtainable below roughly one million euros of Azure spend per year. We can raise special requests with Microsoft, but we set expectations clearly. 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. 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. We set up contract and platform with you.

AWS: an addendum through the partner channel

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 that we initiate via our 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

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. We have contacts at Google and accompany the process, but we 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, procurement through an indirect CSP partner like innFactory costs nothing extra, and a partner with direct contacts at Microsoft shortens the path for Modified Abuse Monitoring considerably.

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 (August 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.

Are you planning cloud or AI workloads with data covered by professional secrecy? innFactory accompanies you as an indirect Microsoft CSP partner: Azure subscription at Microsoft list prices with no markup, no setup fee, no ongoing fees and no minimum spend, including the addendum for professional-secrecy holders and coordination of Modified Abuse Monitoring. Get in touch with us, no strings attached.