Skip to main content

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

Tobias Jonas Tobias Jonas 12 min read
§ 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.

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.

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 in the Partner Center documentation for the CSP program. Important: only Direct-Bill Partners and Indirect Providers can download the document directly. As a customer, you obtain it through your CSP partner.

Here is what the process looks like at our end:

  1. Formal quote: You commission that your Azure costs are procured through innFactory. innFactory is happy to prepare a quote for an Azure subscription with no markup on the regular list prices. There is no onboarding or management fee either.
  2. Confirm the partner link: You link your tenant with innFactory as your partner.
  3. Create the subscription: innFactory provisions the subscription through the indirect CSP model with TD SYNNEX as distributor.
  4. Accept the § 203 StGB addendum: The addendum for professional-secrecy holders is concluded in text form as part of the CSP relationship.
  5. Apply for Modified Abuse Monitoring: For Azure OpenAI, i.e. the “Foundry Models sold by Azure”, we jointly submit the Modified Abuse Monitoring form and register our Microsoft contacts as the point of contact.
  6. 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).

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. As a CSP partner, we monitor these deadlines for our clients, because in the CSP context this is a classic blind spot.

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 single signed acceptance record. The evidence is indirect, but legally sound, and rests on three building blocks:

  1. Evidence of MCA acceptance: an export or screenshot from the Microsoft Admin Center, Azure Portal or Partner Center with the date, tenant ID and accepting organization. No addendum without MCA acceptance.
  2. Valid version of the addendum: the PDF version valid at the time of acceptance, with its version date, filed as evidence of content. The document is not signed; it documents what was part of the 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. We set up this documentation as standard during onboarding, together with our clients.

Modified Abuse Monitoring: the overlooked AI building block

Step 5 of the process deserves a closer look. For abuse monitoring, Azure by default logs flagged prompts and completions and stores them 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). The application is per subscription, not per tenant. Important – and a point that has recently tightened: Modified Abuse Monitoring is now only available to customers and partners managed by a Microsoft account team or running under an eligible program. Anyone who starts via self-service without that access may not even qualify. This is exactly where a CSP partner with direct Microsoft contacts pays off: we know the route via the account team, accompany the application through to activation, and in our experience plan for a few business days. Incidentally, Microsoft does not state a binding processing time – anyone who gives you a firm promise does not know the process.

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 five 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.

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

Microsoft AzureAWSGoogle Cloud
Contract basisAddendum for professional-secrecy holders via CSPIndividual addendum via partner channel (TD SYNNEX/AWS)Addendum for professional-secrecy requirements, requested under NDA
Degree of formalizationHigh, documented processMedium, established channelCase-by-case, best effort
Term specificsAddendum expires 36 months after acceptance at the latest, active renewal requiredPer agreementPer agreement
AI specificsApply for Modified Abuse Monitoring per subscription (managed customers only)Bedrock models automatic, use-case form for individual modelsClarify the § 203 commitment individually before using Vertex
Time horizonPredictablePredictable with bufferNot committable

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.
  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 and model releases are their own workstreams alongside the framework agreement – Modified Abuse Monitoring 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. A CSP and cloud partner with direct contacts shortens the path 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. On this basis you can operate a dedicated AI hub like CompanyGPT in your own Azure tenant, where the data never leaves the controlled environment in the first place. 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 describes the processes to the best of our knowledge at the time of publication. Contract offers, forms, terms and programs of the hyperscalers change regularly. In particular, always check the current version of the addenda and the availability and conditions of Modified Abuse Monitoring at Azure at the time in question. The statutory text of § 203 StGB is publicly available. This article is not a substitute for legal advice – the assessment under professional law belongs in the hands of your legal counsel.


Are you planning cloud or AI workloads with data covered by professional secrecy? innFactory is happy to prepare a quote for an Azure subscription with no markup on the regular list prices and no onboarding or management fee. Get in touch with us, no strings attached.

Tobias Jonas
Written by Tobias Jonas CEO

M.Sc. Informatik, Schwerpunkt KI & Cloud. Vertritt die innFactory nach außen und entwickelt die Strategie. Begleitet als technischer Lead viele Projekte operativ.

LinkedIn