BSI C5 Attestation, Explained for SaaS Companies Selling in Germany

Key Points:

• BSI C5 is a catalogue, not a certificate. BSI C5 (Cloud Computing Compliance Criteria Catalogue) is published by Germany's Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik, BSI). There is no BSI C5 certification. An independent public auditor (Wirtschaftsprüfer) issues an attestation report called a C5-Testat under ISAE 3000 (Revised), reported in Germany as IDW PS 951.
• It is legally mandatory only for German federal cloud procurement. For private-sector SaaS, a C5-Testat is commercial pressure: German enterprises, BaFin-regulated banks and insurers, healthcare buyers and public tenders (Vergabe) ask for one during vendor security review. A missing C5 stalls deals, it does not break a law.
• Type 1 is design, Type 2 is operation. C5 Type 1 attests controls are suitably designed at one point in time. C5 Type 2 attests they also operated effectively across an observation period, usually six to twelve months. German enterprise buyers increasingly want Type 2 and a report covering the current period.
• BSI C5 does not require German hosting; it requires disclosure of where data is processed and stored. The distinctive C5 requirement is a mandatory system description plus environment parameters: jurisdiction, data locations, subprocessors, certifications held and government access requests. Neither ISO 27001 nor SOC 2 forces that transparency.
• The real bottleneck is your deployment pipeline, not the law. Provable least privilege, reviewed production changes, centralized logs with enforced retention, and infrastructure as code. Teams where every production change already flows through one reviewed pipeline turn C5 Type 2 evidence collection into an export.

A deal just stalled because a German buyer's procurement team asked for a "C5-Testat", and nobody on your side knew what that was. I have watched this happen to good SaaS companies with ISO 27001 and SOC 2 already in hand. So here is the reference I wish those founders had read first: what BSI C5 actually is, who really needs it, and which parts land on your engineers rather than your lawyers.

I will be blunt about one thing up front. A C5-Testat is an auditor's attestation report, not a certification. Say that sentence back to procurement and you are already ahead of most vendors.

What is BSI C5 and who issues a C5 attestation?

BSI C5 is the Cloud Computing Compliance Criteria Catalogue published by Germany's Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik, BSI). Compliance is proven when an independent German public auditor (Wirtschaftsprüfer) issues an attestation report, a C5-Testat, under ISAE 3000 (Revised), reported in Germany via IDW PS 951. There is no BSI C5 certificate, no badge, and no public seal you can put in your footer.

The terms matter, because buyers use them precisely:

• BSI - Bundesamt für Sicherheit in der Informationstechnik, Germany's federal cybersecurity authority. It writes the catalogue; it does not audit you.
• C5 - the Cloud Computing Compliance Criteria Catalogue. First published in 2016, revised as C5:2020.
• C5-Testat - the attestation report an auditor issues. This is the artifact buyers ask for.
• Wirtschaftsprüfer - a German certified public auditor. Only they can sign a C5-Testat.
• Basiskriterien - the basic criteria, the mandatory baseline every provider in scope must meet.
• Zusatzanforderungen - additional requirements, optional scope you agree with your auditor and your buyer. They are not an automatic part of the engagement.

C5:2020 groups its criteria into 17 subject areas (control domains): organisation of information security, security policies and work instructions, personnel, asset management, physical security, operations, identity and access management, cryptography and key management, communication security, portability and interoperability, procurement and supplier management, incident management, business continuity, compliance, dealing with investigation requests from government agencies, and product safety and security. You can read the full list in the official C5:2020 catalogue.

Here is the part almost no competing article explains. Alongside the controls, C5 forces a mandatory system description plus environment parameters: your jurisdiction, where data is processed and stored, which certifications you hold, and your disclosure obligations to public authorities. That transparency is baked into the standard, as Microsoft's own C5 documentation spells out.

One more practical point. The C5-Testat circulates like a SOC 2 report: shared with buyers under NDA. There is no public registry to look a vendor up in, so a C5 claim on a website means nothing until you read the report.

Is BSI C5 mandatory to sell SaaS in Germany?

No. BSI C5 is not a law that binds private-sector SaaS vendors. It is effectively mandatory for German federal government cloud procurement and has become a de facto buying requirement for German enterprises, BaFin-regulated banks and insurers, healthcare buyers and public tenders, which means a missing C5-Testat stalls deals rather than operations.

Demand comes from three places:

• Regulated finance. BaFin's BAIT and VAIT circulars and the EBA Guidelines on outsourcing arrangements (EBA/GL/2019/02) push institutions toward independent third-party attestations of their cloud providers, with real audit and evidence rights. On top of that, DORA (Regulation (EU) 2022/2554) has applied across the EU since 17 January 2025 and raises the bar on ICT third-party risk. C5 reports are commonly submitted inside that evidence pack.
• Enterprise commercial pressure. DAX and Mittelstand vendor security questionnaires, insurance and healthcare buyers, and any Vergabe (public tender) that names a C5-Testat in its requirements. The sovereignty mood is real: in Bitkom's Cloud Report, the overwhelming majority of German companies now treat a cloud provider's country of origin as a decisive selection factor.
• Public sector. German federal administration cloud procurement uses C5 as a baseline expectation.

Be honest about when to skip it. If you sell to SMBs, outside German-speaking markets, or to buyers who accept ISO/IEC 27001 plus SOC 2 Type II, chasing a C5-Testat before anyone asks usually burns a quarter of engineering time for nothing.

The trigger signals that it is now worth it are specific: procurement explicitly naming a C5-Testat, a deal parked in vendor security review over it, a German public tender you cannot bid on without one, or a BaFin-regulated prospect asking for audit and evidence rights.

As for the future, C5 is widely treated as the national ancestor of the EU Cloud Services Scheme (EUCS). I would not plan around EUCS yet: per ENISA, it remains a candidate scheme that has not been adopted.

What is the difference between BSI C5 Type 1 and Type 2?

BSI C5 Type 1 attests that your controls are suitably designed at a single point in time. BSI C5 Type 2 attests that those same controls also operated effectively across an observation period, usually six to twelve months, a window confirmed in BSI's own C5 guidance. Type 1 unblocks a first deal, Type 2 is what most German enterprise buyers now insist on seeing.

The evidence each demands is very different. Type 1 looks at policies, architecture and configuration: is the control designed correctly today. Type 2 looks at tickets, pipeline run logs, approval trails and access reviews sampled across the whole window: did the control actually run, every time, for months.

The usual sequence I recommend:

1. Readiness assessment with the Wirtschaftsprüfer.
2. Type 1 to unblock the first deal.
3. Open a Type 2 observation window at the next cycle, and stop changing the control set mid-window.

Because buyers treat a C5 report like a SOC 2 Type II, they want the current period. Plan continuous annual coverage with no gap between observation windows. On cost and timeline I will not invent numbers: it is a multi-month engagement whose length depends almost entirely on how much evidence your platform already produces automatically.

Two things to watch. First, a qualified opinion or a listed exception in the report is the thing a prospect's security team will zoom straight to, so pre-empt it by fixing the weak control before the window opens, not after. Second, because C5 reports are shared under NDA, you cannot verify a vendor's C5 claim from its website. Ask for the report and check the scope, the period, and the exceptions list.

German enterprise buyers increasingly accept only the Type 2 rows.

How does BSI C5 compare to ISO 27001, SOC 2, and TISAX?

BSI C5 overlaps heavily with ISO/IEC 27001 and SOC 2 on the underlying controls but differs in three concrete ways: the catalogue is defined by a government body rather than a private standards body, it mandates disclosure of jurisdiction, data location and government access requests, and it is delivered as an audit report under NDA rather than a certificate you can display publicly.

On overlap, do not trust round percentages anyone quotes you. C5:2020 itself publishes mapping tables linking its criteria to ISO/IEC 27001, ISO/IEC 27017, the CSA Cloud Controls Matrix, BSI IT-Grundschutz and the AICPA Trust Services Criteria. If you already hold ISO 27001, most of your policy, risk, supplier and asset groundwork is reusable.

Where BSI C5 is stricter than ISO/IEC 27001 and SOC 2: the mandatory system description, the environment parameters, the data location disclosure, and the dedicated domain on handling investigation requests from government agencies. That government-access domain is the part most non-German teams have never had to document before.

Where ISO/IEC 27001 is broader: it certifies a management system (ISMS), is recognised globally, and carries a publicly verifiable certificate. The current version is ISO/IEC 27001:2022, with 93 Annex A controls grouped into four themes. For most SaaS companies it is still the first framework to hold.

Where SOC 2 differs: it runs on the AICPA Trust Services Criteria, a CPA firm signs it, and US buyers know it cold. German buyers often accept it, but rarely prefer it over a C5-Testat.

TISAX matters only if you sell into German automotive OEMs and their supply chain. It is administered by the ENX Association, results are exchanged on the ENX portal rather than published, and a TISAX label is valid for three years.

A word on compliance automation. Vanta, Drata and Secureframe genuinely help with evidence collection, policy management and continuous control monitoring. They cannot issue a Testat, and they cannot change where your workloads run. Keep that boundary clear.

Which BSI C5 controls hit SaaS engineering teams hardest?

The BSI C5 criteria that actually slow SaaS engineering teams down are operational, not documentary: identity and access management, change management with documented approvals, centralized logging with an enforced retention period, data location, encryption key ownership, portability, and vulnerability and patch management of the runtime. Each one is answered with an artifact the auditor samples, not a policy PDF.

Write every control down evidence-first. The auditor does not want your intention, they want the export:

• Identity and access management. Least privilege, separation of duties between development and production, no standing admin access, MFA everywhere, periodic access reviews. Evidence: role definitions, group membership exports, review records with dates and named approvers. This is not academic. In the 2025 Verizon Data Breach Investigations Report, stolen credentials were the initial action in roughly a fifth of breaches, and third parties were involved in about 30 percent.
• Change management. Every production change traceable to a reviewed commit and a named approval, with no manual kubectl or cloud console changes in production. Evidence: pipeline run logs and pull request history mapped one to one to deployments.
• Logging and monitoring. Centralized, tamper-resistant logs, a retention period you actually meet, and records of who accessed what. Evidence: log pipeline configuration and retention settings, not a screenshot.
• Data location and residency. Which region hosts customer data, where backups and logs land, and the complete subprocessor list. Evidence: a data flow map that matches the system description word for word. This also maps directly to GDPR Articles 28 and 32 on subprocessors and security of processing.
• Cryptography and key management. Encryption in transit and at rest, who holds the keys, rotation schedule. Evidence: KMS configuration and key policies.
• Portability and interoperability. A C5-specific domain most SaaS teams overlook. Can a customer export their data and leave, is the export format documented, and has the export been tested.
• Vulnerability and patch management of the runtime. Kubernetes control plane and node upgrades, base image patching, CVE response SLAs, and proof the SLA was met. Kubernetes only supports the three most recent minor releases, roughly 14 months each per the version skew policy, so an unpatched cluster becomes an exception fast.
• Incident management and business continuity. Detection, classification, customer notification timelines, post-incident records and tested restore procedures an auditor can sample.

What does the BSI C5 shared responsibility model cover, and what stays yours?

If your cloud provider holds its own BSI C5 attestation, you inherit the infrastructure controls (data centre physical security, hardware lifecycle, hypervisor isolation, network backbone) and C5 hands you everything above it as complementary customer controls. Complementary customer controls are the controls the provider's own C5 report explicitly assumes you operate, and your auditor will test exactly that list. If you never read the provider's complementary customer controls section, you will fail on it.

The big three each publish C5 attestations. Verify the current scope yourself before you rely on it:

• AWS completed its 2025 C5 Type 2 attestation covering 183 services across nine regions including Frankfurt (eu-central-1), and distributes the report through AWS Artifact.
• Microsoft Azure maintains a combined C5, SOC 2 Type 2 and CSA STAR report available via the Service Trust Portal.
• Google Cloud holds a C5:2020 Type 2 attestation, with the report available through its Compliance Reports Manager.

Inheritance has a catch worth repeating: it only covers the services and regions actually in scope in the provider's C5 report. A service you use that is out of scope is back on you.

Region choice is about disclosure, not geography. BSI C5 does not require German hosting; it requires disclosure of where data is processed and stored. Many buyers still want an EU or German region such as AWS eu-central-1 (Frankfurt), Azure Germany West Central, or Google Cloud europe-west3 (Frankfurt), but that is a commercial preference, not a C5 rule.

This is why BYOC (running workloads inside your own cloud account) simplifies the audit: one jurisdiction, one inherited attestation, no fourth-party control plane holding customer data, and the cloud contract plus any committed-use discounts stay in your name. The trap is the opposite model. When a vendor-hosted PaaS owns the cloud account, your data boundary moves to that vendor, and you have to evidence the vendor's controls instead of inheriting the hyperscaler's attestation directly.

Watch subprocessor scope creep too. Observability SaaS, CI providers, error trackers, transactional email, AI APIs: each becomes a disclosed subprocessor and widens both your audit scope and your system description.

How do you get BSI C5 ready without freezing engineering for six months?

Make the platform emit audit evidence as a side effect of normal work: infrastructure as code, git-based deployments with mandatory review, per-environment RBAC, centralized logs with enforced retention, and exactly one documented path to production. When every production change already flows through one reviewed pipeline, most of a C5 Type 2 audit becomes an export rather than a project.

Here is the order I would run it:

1. Scope the service and write the system description first. It drives the entire audit, including what you disclose about jurisdiction, data location, certifications held and government access requests.
2. Pick the region and freeze the data map. Customer data, backups, logs, and every subprocessor.
3. Remove manual production access. Deploy through the pipeline only, with break-glass access that is time-bound, logged and reviewed.
4. Codify environments so development, staging and production parity is provable from the repository rather than from memory.
5. Centralize logs and set retention to match the policy you wrote, not the platform default.
6. Readiness assessment, then Type 1, then open the Type 2 window and freeze the control set for its duration.

This is where Qovery fits, and I will keep it factual. Qovery deploys and operates your applications inside your own AWS, GCP, Azure or Scaleway account, or your existing Kubernetes cluster, so the cloud contract, the region and the customer data stay in your name. Git-push deployments give a traceable change path, per-environment RBAC supports least privilege and dev/prod separation, managed cluster upgrades help with patch management, and preview environments plus environment auto-stop keep non-production workloads out of the production boundary.

The limit, stated plainly: Qovery is not a C5 attestation and does not make anyone compliant. It reduces the engineering work behind the operational controls and the evidence those controls require. Nothing more.

To be fair to the alternatives: Heroku, Vercel and Render host workloads in their own accounts, which moves the data boundary to the vendor. Porter offers a BYOC model like Qovery. Terraform plus an in-house Kubernetes platform gives you full control at the cost of building and documenting the pipeline yourself. Vanta, Drata and Secureframe automate evidence collection but do not change where your workloads run.

Frequently asked questions

Is BSI C5 a certification or an attestation?

A C5-Testat is an attestation, not a certification. An independent German public auditor (Wirtschaftsprüfer) issues it as a report under ISAE 3000 (Revised), reported in Germany via IDW PS 951. There is no BSI C5 certificate, badge or logo you can display publicly.

Is BSI C5 mandatory to sell SaaS in Germany?

BSI C5 is legally mandatory only for German federal government cloud procurement. For private-sector SaaS it is commercial pressure: German enterprises, BaFin-regulated financial institutions, healthcare buyers and public tenders ask for a C5-Testat during vendor security review, so a missing one stalls deals rather than breaking a law.

Do I need BSI C5 if I already have ISO 27001 and SOC 2 Type II?

If your German buyers accept ISO/IEC 27001 plus SOC 2 Type II, you may not need BSI C5 yet. But C5 adds disclosures those frameworks do not force (jurisdiction, data location, and government access requests), so once a German enterprise or BaFin-regulated prospect explicitly asks for a C5-Testat, your existing certifications will not substitute for it.

What is the difference between BSI C5 Type 1 and Type 2?

BSI C5 Type 1 attests that your controls are suitably designed at a single point in time. BSI C5 Type 2 attests that those controls also operated effectively across an observation period, usually six to twelve months. Most German enterprise buyers now want a Type 2 report covering the current period.

Can I inherit BSI C5 controls from AWS, Google Cloud, or Azure?

Yes, if the provider holds its own C5 attestation you inherit the infrastructure controls, and C5 hands you the rest as complementary customer controls that your auditor tests. AWS, Microsoft Azure and Google Cloud each publish C5 attestations, but inheritance only covers the services and regions actually in scope in that provider's report.

Does my SaaS data have to be hosted in Germany to pass BSI C5?

No. BSI C5 does not require German hosting; it requires disclosure of where data is processed and stored. Many German buyers still prefer an EU or German region as a commercial choice, but the C5 requirement itself is transparency about data location, not a German location.

How long does a BSI C5 attestation take, and what does it cost?

A BSI C5 attestation is a multi-month engagement, and I will not quote euro or week figures because they depend entirely on your starting point. The single biggest variable is how much evidence your platform already produces automatically; teams with one reviewed deployment pipeline and infrastructure as code move far faster than teams collecting evidence by hand.

What is the difference between BSI C5 and the EU Cloud Services Scheme (EUCS)?

BSI C5 is Germany's national cloud security catalogue, proven by a C5-Testat today. The EU Cloud Services Scheme (EUCS) is a proposed EU-wide scheme under the EU Cybersecurity Act that, per ENISA, remains a candidate and has not been adopted. C5 is widely seen as its national ancestor, but you cannot obtain an EUCS certificate yet.

The hard part of BSI C5 was never the German law. It is whether every production change already flows through one reviewed pipeline that can hand your auditor the evidence on demand.