Cloud checklist for professional secrecy holders

Already have an application or prototype? Use the Section 203 Managed Cloud to request a non-binding technical scope assessment.

A cloud assessment for professional secrecy holders should not start with a list of providers. It should start with the real processing: which information enters which component through which user journey, who can access it, and how does it leave the system? Once these questions are answered, infrastructure and operating model can be selected meaningfully.

This checklist supports technical and organisational decisions. It is not legal advice.

1. Define purpose, data and users

Describe the business use in a few sentences:

• Which task does the application solve?
• Which professions and staff use it?
• Which data are entered, uploaded, generated or imported?
• Are client, patient, health, tax or procedural data involved?
• Are some data within the same system outside the professional-secret scope?
• Which results are exported, sent or written to other systems?

The answers shape the architecture. A scheduling system without professional content, a document portal and AI-assisted file analysis can require very different safeguards within the same organisation.

2. Draw the complete system boundary

A modern application rarely consists of only a web server and database. Include at least:

Mark whether each connection transmits content, metadata, credentials or only technical state. Logs can also contain names, email addresses, document titles or complete requests.

3. Identify participating providers and people

The technical architecture and provider chain must describe the same reality. Relevant parties include not only invoice issuers but everyone who participates in the intended operations or may receive technical access.

Assessment questions:

• Who provides infrastructure, platform and application?
• Who handles administration, support and on-call response?
• Which subcontractors are involved?
• Which people or roles can access production, backups and keys?
• How are additional participants introduced and changes communicated?
• How is access removed after a role or contract ends?

Section 203 paragraphs 3 and 4 are central when participating persons are involved. The agreements required in a specific case should be assessed legally.

4. Constrain administrative access

An administrator does not automatically require permanent access to all data. A suitable model separates roles and access paths:

• named rather than shared administrative accounts
• MFA for management, cloud and repository access
• separate roles for infrastructure, application and database
• time-bound or incident-approved maintenance access
• private management paths instead of public interfaces
• logging of security-relevant changes
• controlled break-glass access

Whether and how sessions may be recorded needs separate assessment. Auditability should not create new risks through unnecessary content logging.

5. Review the application and software supply chain

The server may be configured well while the application still contains unclear dependencies. A pre-production review should cover:

• repository, ownership and reproducible build
• packages, containers and images
• known vulnerabilities and update path
• secrets in source code, build logs or frontend bundles
• telemetry, analytics and error tracking
• external scripts, fonts, CDNs and APIs
• application roles and permissions
• tenant separation and access tests

This is especially important for AI-generated software. A working prototype says little about security, data design or maintainability. See operating AI-generated software for a focused checklist.

6. Treat backup and recovery as separate data flows

Backups are not merely a technical detail. They duplicate the data set and extend its lifecycle. Record:

• which components are protected
• where primary and additional copies are stored
• how data are protected from unauthorised modification or deletion
• who controls keys and recovery credentials
• which retention and deletion periods apply
• how often restore tests are performed
• how full recovery is documented

A successful backup job is not evidence of a successful restore. Database, files, secrets and application version need to be recoverable together.

7. Define operations and changes

Production does not remain static. Agree in advance:

• Who evaluates and installs security updates?
• How are changes tested and approved?
• Which events trigger an alert?
• Who responds within which time?
• How are incidents documented and communicated?
• Which dependencies are reviewed regularly?
• What is the exit path when changing provider or platform?

Measures should match criticality. An internal tool with planned maintenance windows requires a different service level from a continuously available client portal.

8. Record the outcome as a decision sheet

The result should not be a vague label such as “German cloud”. It should be a traceable target model:

1. application and permitted data types
2. system and data-flow diagram
3. participating providers and roles
4. operating locations and external connections
5. administrative access paths
6. backup, restore and deletion concept
7. update, monitoring and incident process
8. open legal and technical decisions

This sheet can support internal approval, external legal review and a concrete technical proposal.

Related WZ-IT services

• The Section 203 Managed Cloud combines isolated infrastructure, German providers, the agreed Section 203 contractual chain and managed or co-managed operations.
• The AI Code & Production Readiness Audit assesses an existing or AI-generated application before go-live, migration or operational takeover.
• Managed Open Source covers selection, installation, integration and ongoing operations for open-source applications independently of Section 203 as well.

Sources

• German Criminal Code, Section 203
• GDPR Article 28 - Processor
• GDPR Article 32 - Security of processing
• BSI IT-Grundschutz Compendium