SOC 2 vs C5: shared standards, differences and reuse

German customers are asking for a C5 attestation and you already have a SOC 2 report: a common situation for US providers. BSI C5 is the German Federal Office for Information Security’s criteria catalogue for cloud services. This page sets out what the two reports share, what you can carry over from SOC 2 into C5, and where C5 goes further. If you start from an ISO 27001 certificate instead, see C5 vs ISO 27001.

What do SOC 2 and C5 have in common?

Both are examinations of a service organisation’s internal control system by an independent auditor, reporting on control design and, for Type 2, operating effectiveness. The underlying standards are related, but not the same:

• A SOC 2 examination is performed under the AICPA attestation standards, AT-C section 105 and AT-C section 205 (SSAE 18), against the Trust Services Criteria (TSP section 100). Microsoft, for example, describes its own SOC 2 report this way.
• Every C5 engagement follows ISAE 3000 (Revised) or a national equivalent such as IDW PS 860 (sections 3.2 and 3.4.1). ISAE 3402 and IDW PS 951 n.F. are also taken into account (section 3.2), and reporting is “based on the requirements of ISAE 3402.53” (section 3.4.13).
• The bridge between the two: the BSI’s additional requirements considered AT-C section 105 and AT-C section 205 (section 3.4), and the criteria considered, among others, the AICPA Trust Services Criteria (section 2.3).
• Both distinguish Type 1 (design) and Type 2 (design plus operating effectiveness over a period).

The BSI C5 FAQ (in German) simplifies this: it says both reports are based on the same international standards, ISAE 3000 and ISAE 3402, and calls SOC 2 a US counterpart of ISAE 3000. Read that as shorthand. AT-C 205 and ISAE 3000 govern comparable engagements but are separate standards, and the catalogue itself pairs ISAE 3402 with SOC 1 (section 3.3).

How do SOC 2 and C5 differ?

C5 is built for cloud services and is more granular. The BSI FAQ puts it this way: SOC 2 reports are prepared for IT services in general and rest on the AICPA Trust Services Criteria (the FAQ still uses the older term Trust Service Principles), while the C5 criteria are more detailed and cover additional areas such as transparency requirements, handling of investigation requests and cloud-specific topics.

On the audit team: the FAQ notes that ISAE 3000 reports normally only name the signing auditor, whereas a C5-compliant report also gives information on the audit team and its qualifications. Where C5 asks for more than the general standards, the C5 rules prevail.

What you can reuse from your SOC 2 report

The existing system description is the biggest asset. The catalogue allows reuse: “an existing Description that was prepared to meet the requirements of another standard shall be adapted to the description criteria [...] of this catalogue, as necessary” (section 3.4.4, Attestation Engagement; the description criteria themselves are in section 3.4.5.1). In practice:

• check the eight minimum content items of section 3.4.5.1, from name, type and scope of the service to the services of subservice organisations,
• add the information for general conditions GC-01 to GC-06,
• list the applicable C5 criteria and justify every exclusion,
• relate the complementary user entity controls (CUEC) you assume to the C5 criteria,
• state company name, location of processing and storage (country level is sufficient) and an assessment of dependency for each subservice organisation (section 3.4.6).

Controls and test results can be reused, too. The BSI FAQ describes how an ISAE 3000 engagement can be extended into a C5 engagement: map the controls already tested to the C5 criteria; where your controls cover the same or more, no extra testing is needed for the C5 report, and where C5 asks for more, the difference is tested additionally. This presupposes that the existing engagement was Type 2. The FAQ speaks of ISAE 3000 engagements; the same route works for a SOC 2 report by analogy, as the catalogue considered the AICPA standards.

Our view: the more precisely the gap between your SOC 2 controls and the C5 subcriteria is defined, the less additional testing the auditor needs. Defining that gap is the key step before you engage an auditor.

Where SOC 2 does not replace C5

If a customer contract, a tender or a regulation explicitly requires a C5 attestation, a SOC 2 report is not enough. In German healthcare, Section 393 SGB V (Book V of the German Social Code) refers to a current C5 attestation covering the basic criteria (see Section 393 SGB V), and the C5 Equivalence Ordinance (C5GleichwV) lists ISO/IEC 27001, ISO 27001 based on IT-Grundschutz and the Cloud Controls Matrix 4.0 as alternatives, each with a remediation plan. SOC 2 is not on that list. Whether a rule applies to your service needs a legal assessment in the individual case.

Aligning SOC 2 and C5 periods

Shared periods save effort. The catalogue recommends aligning ISAE 3402/SOC 1 or SOC 2 audits with the C5 engagement (section 3.3). A C5 Type 2 period should cover three to twelve months and may, in exceptional cases, be longer, “for example to better align with other audits” (section 3.4.4, Attestation Engagement).

The catalogue revision matters for the shared period, too: C5:2026 applies to Type 2 periods beginning on or after 1 June 2027, and a period that begins earlier should be audited against C5:2020 only (section 3.5). Further transition rules are in section 3.5 of C5:2026.

Does a C5 report have to look like a SOC 2 report?

The BSI FAQ says the audit report has to be written in the form of a SOC 2 report. The C5:2026 catalogue contains no such requirement; it bases the reporting on ISAE 3402.53 and lists the report components in section 3.4.13 (auditor’s report, management statement, system description, controls with test procedures and results). If you know SOC 2 reports, you will find your way around a C5 report quickly; the catalogue defines what has to be in it.

Example: a US SaaS provider with SOC 2 Type 2 entering Germany

Illustrative example, not a real client. A US SaaS provider holds a SOC 2 Type 2 report covering twelve months. A German hospital group requires a C5 attestation before purchasing.

1. Scope: the attestation should cover the service in the EU region the customer uses; see C5 scope.
2. System description: the SOC 2 description is extended with GC-01 to GC-06, the applicable C5 criteria, CUEC and the infrastructure provider as a subservice organisation (C5 system description).
3. Gap: SOC 2 controls are mapped to the C5 subcriteria. Gaps appear, for example, for investigation requests (INQ), the region of data processing (PSS-12) and the new container management criteria. If the customer also asks about sovereignty, look at the BSI’s C3A criteria.
4. Period: the next SOC 2 period and the first C5 period are aligned. As the provider already collects evidence of operating effectiveness, the first C5 engagement can be Type 2 straight away; a Type 1 report is not a prerequisite (section 3.4.11).

More questions from international providers, such as local entity and processing location, are covered on BSI C5 for international providers.

How we support the move from SOC 2 to C5

In a C5 gap analysis we compare your SOC 2 report and system description with C5:2026 and define the difference the auditor has to test additionally. Blackfort Technology does not issue attestations; an independent auditor does. We support you until you are ready for the audit. To discuss your starting point, book an initial call.