You are close to signing a hospital group, a public authority or a large German company. The security questionnaire arrives, and one line asks for your C5 attestation. You have ISO 27001, maybe SOC 2. Neither is what they asked for.
What C5 is
C5 stands for Cloud Computing Compliance Criteria Catalogue. The BSI (Bundesamt für Sicherheit in der Informationstechnik) is Germany's federal cyber security authority, and C5 is their list of what a cloud service has to do to count as secure: how you control access, how you encrypt data, where the data sits, and what you do if a government authority demands a customer's data.
C5 is not a certificate. There is no badge and no logo. An external auditor checks your controls against the list and writes a report with their findings. That report is the attestation. In German it is called a Testat, and buyers will ask for "euer C5-Testat".
The auditor has to be a Wirtschaftsprüfer, a licensed public auditor, the same kind of auditor who signs off a company's annual accounts. They work to a fixed auditing standard, so one C5 report is put together much like the next and a buyer knows what they are looking at. This is why C5 feels much more like SOC 2 than like ISO 27001.
The requirements come in two groups.
Basic criteria are the minimum, and every C5 audit covers all of them.
Additional criteria go further. Some tighten a basic criterion, for example keeping log data for longer or testing your recovery plan more often. Others add a requirement that is not there at all in the basic set. They exist for services holding data where a leak would do real damage: patient records, payment data, HR files.
You decide with your auditor whether additional criteria are part of your audit, and that happens before the audit starts. A buyer cannot add them to a finished report. So if your market is healthcare or financial services, ask a few of your main buyers what they expect before you fix the scope. The BSI's C5 FAQ lists which criteria sit in which group.
Type 1 and Type 2
A Type 1 report looks at a single date and says whether your controls are designed sensibly. It is a snapshot. For example: you have a documented process for removing access when someone leaves.
A Type 2 report covers a period, usually three to twelve months, and tests whether those controls actually worked. Same example, but now: there were 14 leavers in that period, and here is when each one lost access.
Buyers want the Type 2. A Type 1 can still carry you through a deal if you show it and commit to a Type 2 with a date, the same way buyers accept a SOC 2 Type I while the Type II period runs. Healthcare is the exception, because there the law says what is accepted and by when.
A C5 report is not valid for a year the way a certificate is. It describes a period that has already finished. Buyers usually want one whose period ended within the last twelve months, which is why providers repeat the audit every year.
Who asks for it
Healthcare: required by law. § 393 SGB V (book five of the German social code, the law covering statutory health insurance) says health and social data may only go into a cloud service under set conditions. One is a current C5 attestation covering the basic criteria. The other is that the customer does the things the report lists on their side, such as managing their own user accounts and switching on multi-factor authentication. It applies to doctors, hospitals, pharmacies, health and long-term care insurers, and the companies that process data for them.
The deadlines below are healthcare only. No other sector has a legal date.
A Type 1 was enough until 30 June 2025. Since 1 July 2025 a Type 2 is expected. For providers who are not there yet, the C5-Gleichwertigkeitsverordnung, in force since 1 July 2024, allows ISO 27001, BSI IT-Grundschutz or the Cloud Controls Matrix during a transition, as long as the gaps are written down and a timetable is committed to: the extra measures within 12 months, a Type 1 within 18 months, a Type 2 within 24 months.
So if you sell to practices, hospitals, health insurers or DiGA providers (the digital health apps a doctor can prescribe), this is not a preference. Without C5 or a credible plan to get there, your customer is not allowed to use you.
Public sector: usually in the tender. C5 comes from the BSI, the same authority that sets security rules for the federal administration, so public buyers already know and trust it. Cloud tenders often ask for a C5 attestation, sometimes naming specific additional criteria. Read the tender documents early, because this is the kind of requirement that decides whether you make the first cut.
Enterprise: it shortens the security review. For German companies there is usually no legal duty. What happens without a C5 report is that the buyer's security team does its own review of you: a long questionnaire, follow-up calls, sometimes an audit of their own, and the contract waits while that runs. A C5 report answers most of those questions in one document, written by an auditor they can look up. That is the reason providers get one even when nobody forces them. Here you also have room to negotiate: ISO 27001 plus SOC 2 can be enough to start if you can name a date for your C5. The more sensitive the data, the less room you have.
What a buyer reads first
Almost nobody reads the whole report. They go to four places.
Where the data is and who can reach it. C5 asks you to describe where data is processed and stored, which country's law applies, and what you do when an authority demands customer data. German buyers often read this first. If you run on US infrastructure, expect questions here.
What was actually audited. The report contains a description of the audited service. Buyers check that the product they are buying is fully covered. Being audited for your EU platform while they are buying your new mobile product is a problem.
Exceptions. If the auditor found something that did not work as described, it is written in the report. One exception rarely kills a deal. The buyer will ask what happened and what you changed.
What they have to do themselves. Every C5 report lists points the customer is responsible for, called complementary customer criteria. For example: the customer manages their own user accounts and switches on multi-factor authentication. Security teams read these closely, because they show where your responsibility stops and theirs starts.
How C5 sits next to ISO 27001 and SOC 2
ISO 27001 certifies your management system, meaning the way you find risks and deal with them. It is a good foundation and much of C5 builds on it, but it says little about cloud specifics like data location or government requests.
SOC 2 is the closest relative, also an auditor's report covering a period. It comes from the US and uses different criteria, and a German buyer will rarely accept it instead of C5.
If you already run either one, you are not starting from zero. The gap is usually in the cloud-specific and transparency criteria.
What changes with C5:2026
The BSI published C5:2026 on 7 April 2026. It replaces C5:2020 and grows from 121 criteria to 168, in the same 17 subject areas. What is new:
- A clearer structure. Criteria are split into sub-criteria, which makes mapping them to your own controls easier.
- Container management. Containers are a standard way of packaging software, usually run on a platform like Kubernetes. C5 now sets requirements for running those platforms.
- Supply chain. More on checking and monitoring your own providers.
- Post-quantum cryptography. An inventory of the cryptography you use, and a plan to move to methods that future quantum computers cannot break.
- Confidential computing. Requirements for services that process data inside protected areas of the hardware.
C5:2020 is still in use. Audits with a date or period starting on or after 1 June 2027 have to use C5:2026, and you may use it before then. If your audit period ends between 28 February 2027 and 1 June 2027, you have to describe the changes you are planning in your system description.
If you are starting your first C5 now, build against C5:2026 from the beginning. Otherwise you set your controls up for C5:2020 and then rework them to match the new requirements a year later.
Where to start
- Ask your main buyers what they actually need: which report type, which period, and whether their data would push you towards additional criteria. In healthcare the law decides. In the public sector it is in the tender. In the enterprise it is a conversation.
- Compare what you already do against C5:2026 and write down what is missing, cloud-specific criteria first. That list is your plan.
- Pick your auditor early. Auditors with C5 experience are a small group and their calendars fill up.
- Plan a Type 1 first, then a Type 2 over six to twelve months.
What's next?
If German buyers are asking you for C5, there is a fair chance NIS-2 applies to you as well. Check in 20 minutes whether it does.
If you also sell outside Germany, buyers there will usually ask for SOC 2 instead. SOC 2 Type I or Type II: What Your First Enterprise Deal Actually Requires explains which report your deal needs and why timing decides it.