Cloud practice software: the C5 attestation from the vendor’s perspective

This page is for vendors of practice management systems and other practice software who offer their software as a cloud service. For practices choosing a provider, and for the legal basis, see the page on Section 393 SGB V (Book V of the German Social Code): it explains who the provision applies to, which deadlines apply and why, in our assessment, the hosting provider’s attestation alone is not enough. This page does not repeat that and is not legal advice.

The example: a practice management system in the cloud

Fictitious example, not a customer. A vendor offers a practice management system for medical practices as a cloud service. The architecture:

• Application in the browser, run on a cloud platform in a region in Germany, with backups in a second region in Germany; one tenant per practice.
• Local component on a PC in the practice that connects the card reader, printer and individual devices and communicates with the application over an encrypted connection. The vendor develops it and distributes updates; hardware and operating system belong to the practice.
• Support by the vendor’s own team, which connects to a practice’s tenant at the practice’s request to track down faults.
• Data migration from a practice’s legacy system when it switches, and export of all data when a practice terminates its contract.
• An older version of the same software is still sold for local installation.

Who is responsible for what: vendor, platform, practice

The right-hand column belongs in the system description as complementary customer controls (CUEC) that the vendor assumes in the design of its controls (section 3.4.5.1 no. 7). Each of these obligations needs wording that the practice can implement and evidence, and a link to the complementary customer criteria in the catalogue.

Decision 1: Does the local component belong in scope?

In our assessment, partly. Its development, signing and the distribution of updates lie with the vendor and affect the service directly; they belong in the subject matter of the audit, with the same controls for changes, tests and approvals as the application. Operating the practice PC is the practice’s responsibility. Criteria that would relate to it can only be excluded if the justification rests on the nature and design of the service or on the vendor’s principles, procedures and measures (section 3.4.3); the fact that the vendor has no control because it never set one up is not enough. The practice’s obligations then appear as complementary customer controls in the system description, and the guidance on secure operation goes into the guidelines for customers (PSS-01).

Decision 2: How support accesses practice data

Access by the vendor to customer data is governed by IAM-07 “Access to Cloud Service Customer Data”. Three subcriteria matter for support:

• IAM-07.06B: Through contractual agreements and before offering the service, the vendor discloses all instances in which it may access customer data in unencrypted form.
• IAM-07.03B to .05B: If staff access a practice’s data without its prior consent, the practice is informed for each event, where the data was accessed in unencrypted form or the contract does not explicitly exclude informing it. Unless contractually agreed otherwise, the information states the cause, time, duration, geographic location, type and scope of the access and the retention time of data generated during the access, such as logs or copies; it is provided no later than 72 hours from the initiation of the access.
• IAM-07.03AS (additional criterion): Access requires the prior consent of an authorised department of the customer, provided the data is accessible in unencrypted form or the contract does not explicitly exclude such consent.

Our assessment for practice software: in the example, the process in which the practice requests and enables support already exists. If you enforce and log it technically, you can add the additional criterion IAM-07.03AS with little extra effort, and practices see in the report that nobody looks at their data without approval. Emergencies need a contractual rule. For how privileged access as a whole becomes auditable, see IAM domain. Whether maintenance and support access counts as processing under Section 393 SGB V and what the GeDIG draft bill would change is covered on the page Section 393 SGB V and maintenance access.

Decision 3: Data migration and return when a practice switches

PI-02 requires contractual rules for providing customer data after the contract ends: type, scope and format of the data, methods of delivery, time frames, the point in time from which the vendor makes the data inaccessible and deletes it, the customer’s obligations to cooperate, and that the data remains the customer’s property (PI-02.01B). In our assessment, for practice software this means: export format and time frame belong in the contract before the first practice terminates, and the export has to be tested; a description alone is not enough. The practice’s retention obligations under professional and data protection law are its own; the contract should be designed so that the practice can meet them itself after the export. Whether and for how long the vendor retains data for the practice is a contractual question and needs a separate legal assessment.

Migration from a legacy system is the counterpart: it processes customer data outside normal operations, often with tools and temporary storage created only for this purpose. Our recommendation: bring the import into scope as a separate, documented process, including deletion of intermediate data.

Decision 4: Involving practices in releases

DEV-10.02B requires customers to be involved in the release of changes according to the contractual agreements. If the contract promises practices that changes are announced in advance or only rolled out in maintenance windows, that promise becomes an auditable control. Only put in the contract what you can evidence for every change in the audit period.

Cloud version and on-premises version from the same vendor

According to the BSI FAQ, a C5 attestation covers the audited cloud services in specified regions, never the vendor as a whole. The locally installed version is not a cloud service and does not belong in the report. In our assessment it still pays to set up development and release the same way for both product lines: the auditor sees your development process, and two processes mean twice the work. Marketing and offers should make clear which version is attested.

Evidence vendors should prepare

Possible gaps for vendors of practice software

• Remote maintenance without a log. Cause: support uses a remote maintenance tool on the practice PC and reaches the application from there. Effect: access to customer data can neither be evidenced nor reported, and the tool is missing as a service organisation from the directory under SSO-04. Remedy: support access only through a dedicated, logged route in the application.
• Export never tested. Cause: no practice has terminated so far. Effect: the export promised in the contract is not evidenced. Remedy: run the export once a year with a test tenant and record it.
• Customer controls too general. Cause: “The practice ensures secure end devices.” Effect: the practice can neither implement nor evidence the obligation. Remedy: specific requirements for the practice PC, with supported versions and check instructions, in the guidelines for customers.