Last updated: 2026-11-01
The catalogue calls the general conditions “Information on the General Conditions of the Cloud Service”, “also called ‘General Conditions’ or ‘GC’ for short”, hence the IDs GC-01 to GC-06 (section 4). They are not among the 168 criteria in section 5, but they belong in every system description. The BSI FAQ (German) still calls them “BC-01 to BC-06”; they are the same thing.
What are the general conditions for?
The information tells customers about the level of information security the service offers. According to section 4, it should enable customers to assess the suitability of the service for their use case and make reports from different providers comparable. It is written for subject matter experts of the customers: people who define or implement information security requirements, validate their effectiveness or assess the suitability of the service from a legal and regulatory perspective, for example in IT, compliance and internal audit.
This sets the standard for the wording: the reader does not know your contract and has little time. They have to find each piece of information quickly and understand it without asking back. Where the general conditions sit in the catalogue as a whole is shown on C5 criteria catalogue.
The six general conditions at a glance
Titles as in the English version 1.0.1. The column “What customers read from it” is our assessment.
| ID | Title (catalogue) | Where the information goes | What customers read from it |
|---|---|---|---|
| GC-01 | Information on applicable law, jurisdiction, countries, partitions, regions, zones and locations | system description and contractual agreements | which legal systems affect the provider and where their data is |
| GC-02 | Information on availability and incident handling during regular operation | binding in the contractual agreements; the system description indicates where | what availability and response times are committed to and what follows if they are missed |
| GC-03 | Information on recovery parameters in emergency operation | on request for subject matter experts of the customers; the system description indicates where | values for their own business impact analysis |
| GC-04 | Information on the approach to ensuring service availability | information for customers; the system description indicates where | how resilience is built into infrastructure and service |
| GC-05 | Information on how investigation requests from government agencies are handled | system description | risk of authorities accessing their data |
| GC-06 | Information on certifications or attestations | system description | which other evidence from independent third parties exists |
How do the general conditions relate to the system description?
The information is minimum content item 3 of the system description: “Information on the general conditions of the cloud service in accordance with the criteria in section 4 of this criteria catalogue […]” (section 3.4.5.1). Under section 3.4.7, the provider’s description is only fairly presented if it includes this information and the information on subservice organisations. If it is missing, more than one chapter is missing. The other minimum content items and the structure of the description are explained on system description.
Two special points apply:
- References instead of values for GC-02 to GC-04. The values themselves are in the contract, in the operational documentation or in documents on request. The system description says where to find them, specifically for each aspect. If you also include the values in the report, for example in a section “Other information provided by the Cloud Service Provider”, then according to the notes on GC-02 to GC-04 they are not subject to the auditor’s procedures there, and the auditor does not issue an opinion on them.
- Direct engagement. In a direct engagement there is no system description from the provider. The auditor then documents the information on the general conditions based on the information the provider gives (section 4).
What goes into each general condition?
The following overview summarises the requirements briefly and in our own words and names what to watch for when writing; the right-hand column is our recommendation. It does not replace the catalogue: the wording of section 4 governs, with all individual points and notes. Read it before you write the system description.
| GC | Core of the requirement (abridged) | What to watch for |
|---|---|---|
| GC-01 | applicable law and jurisdiction, registered seat of the companies, places of data processing | name the places for all data types and distinguish processing, storage and backup; identify regions or locations that are not audited. The terms partition, region, zone and location are defined in section 1.2. The agreed region is secured technically by PSS-12, see PSS; for a foreign parent company see international providers. |
| GC-02 | binding commitments on availability and incident handling during regular operation, with consequences | values belong in the contract or SLA; mark average values without a commitment separately. |
| GC-03 | recovery parameters for emergency operation, on request for subject matter experts of the customers | customers need the values for their business impact analysis; they have to match your own analysis and your tests, see BCM. |
| GC-04 | approach to service availability: metrics and architecture design principles for physical and logical resilience | describe it so specialists understand it, with reference to your actual architecture and without marketing claims. |
| GC-05 | handling of requests from government agencies: procedures, involvement of customers, ability to decrypt, numbers | state the actual technical situation, even if you can decrypt; numbers with a reference period. Which legal systems are relevant depends on registered seat and locations and needs a legal assessment in each case. The procedure is shown on INQ. |
| GC-06 | existing and valid certifications or attestations by independent third parties | for each item date, issuer, scope and validity; you do not need evidence for every aspect, but you have to list the existing ones in full. |
If locations, subservice organisations or commitments change during the audit period of a type 2 report, check whether this is a significant change that the system description has to disclose, see significant changes and events.
How do you word the information so it holds up?
The following rules are our recommendation; they follow from the wording of section 4 and from what customers do with the information.
- One source per value. Availability, response times and consequences are in the contract or SLA. The system description refers to the document and section for each aspect and does not repeat the values in its own words. That way, report and contract cannot diverge.
- Mark binding values and averages. Where a value is only an average without a commitment, say so explicitly, as GC-02 requires.
- All data types and all places. GC-01 names cloud service customer data, cloud service derived data and account data and distinguishes processing, storage and backup. Also name the location of the backups and of the subservice organisations; the information has to match minimum content item 8 and the subservice organisation inventory.
- Name exclusions. If you operate regions or locations that are not audited, name them with an indication of their exclusion (GC-01 no. 6).
- Numbers with a reference period, including zero. For GC-05, state the period to which the number of requests and disclosures refers. If there were none, write “none” instead of leaving the point out.
- Only valid evidence, with four details. For GC-06, only certificates and reports that are valid in the period under review, each with date, issuer, scope and validity. A C5 attestation is an audit report, not a certificate; never write “C5 certified”.
- Write for specialists, not for sales. No marketing claims such as “maximum availability”; every statement has to be traceable to contract, architecture or evidence.
Sample wording as a working aid
Fictitious example, not a client. A provider runs a scheduling and billing platform for physiotherapy practices as SaaS on the infrastructure of a large cloud service provider in Germany. The wording consists of our own suggestions, not catalogue text; replace values in square brackets with your own. Agree the exact wording with your auditor and, where contract and law are affected, with your legal advisers.
| GC | Sample wording in the system description |
|---|---|
| GC-01 | “The contracts for the service are governed by the law of the Federal Republic of Germany; place of jurisdiction is [place]. This system description was prepared by [company] GmbH, registered in Germany. The ultimate parent company is [holding], registered in [country]. Cloud service customer data, cloud service derived data and account data are processed and stored in the region [region] of the subservice organisation [platform] with the zones [A] and [B] in [city], Germany; backups are kept in zone [C] of the same region. The region [region 2], in which the service is operated at the request of individual customers, is not in scope of this audit.” |
| GC-02 | “The binding information on availability is set out in the service level agreement (appendix 2 to the framework agreement, version [date]): availability in section 2.1, categories and priorities of incidents in 2.2, response times per category in 2.3, recovery times in 2.4, consequences of non-compliance in 2.5. The monthly figures published on the status portal are actual values and not a commitment.” |
| GC-03 | “Information on MTPD, RTO, RPO, recovery time to start emergency operation, minimum business continuity objective and restore time until normal operation is provided to subject matter experts of our customers on request in the document ‘Recovery parameters [service]’, sections 1 to 5. Please send requests to [address].” |
| GC-04 | “Our approach to availability is described in the document ‘Architecture and resilience [service]’ in the customer portal: availability metrics in section 1, distribution across [number] zones and data centre redundancy in section 2, logical resilience of the application (load balancing, database replication, recovery) in section 3, historical availability over the last twelve months in section 4.” |
| GC-05 | “We handle requests from government agencies for access to or disclosure of customer data according to the procedure described in chapter [x]: documented legal review of the legal basis, prompt notification of the affected customer where legally permitted, information on their ability to object. We store customer data encrypted; we manage the keys, decryption is technically possible for us and only takes place under the procedure described. In the period [from] to [to] we received [number] requests from [countries]; in [number] cases data was disclosed. The technical procedures are described in the document under INQ-04 in the customer portal.” |
| GC-06 | “ISO/IEC 27001:2022, certificate no. [number], issued on [date] by [certification body], scope: development and operation of the service [service] at the location [place], valid until [date]. No other certifications or attestations exist at present for the aspects under GC-06.” |
The GC-05 wording deliberately shows a provider that can decrypt. The information has to reflect the actual situation; a more favourable presentation would be a distortion that the system description must not contain under section 3.4.5.1.
Possible mistakes and how to avoid them
| Possible mistake | Effect | Remedy |
|---|---|---|
| SLA values in the system description differ from the contract | Customers read conflicting commitments; the presentation cannot be followed. | only refer, for each aspect with document and section |
| Location of the backups missing | GC-01 no. 5 also requires the places of backup; the information is incomplete. | name processing, storage and backup separately |
| Country of the parent company missing | GC-01 no. 4 is not met; customers lack information for their risk assessment. | clarify the group structure up to the ultimate parent company |
| GC-05 without numbers | Nos. 6 and 7 are missing; customers cannot judge how often requests occur. | keep a register under INQ-01, state numbers with the period |
| GC-06 lists expired certificates or says “C5 certified” | GC-06 requires valid evidence; a C5 attestation is not a certificate. | check validity before every version, use the terms correctly |
Frequently asked questions
Who writes the information on the general conditions?+
Does the auditor check my SLA values?+
Do I have to publish my recovery times?+
Do I need specific certificates for GC-06?+
What changes if I offer only one region?+
Read more
- C5 system description: minimum content, structure and example
- C5 criteria catalogue: structure, basic and additional criteria
- C5 INQ: investigation requests from government agencies
- C5 BCM: business continuity and restore tests under C5:2026
- C5 PSS: product security of the cloud service under C5:2026
- C5 Germany: BSI C5 for international healthcare SaaS providers
- C5 subservice inventory: example and report review
- C5 significant events and changes in a type 2 report
- C5 readiness assessment: gap analysis, action plan and timeline
Sources
- BSI: Kriterienkatalog Cloud Computing C5:2026, version 1.1.0 (PDF, German), section 4 GC-01 to GC-06, sections 1.2, 3.4.5.1 and 3.4.7, PSS-12, licensed under CC BY-ND 4.0 (retrieved 2026-11-01)
- BSI: Cloud Computing Compliance Criteria Catalogue C5:2026, version 1.0.1 (PDF), section 4 General Conditions, sections 1.2, 3.4.5.1 and 3.4.7, PSS-12, licensed under CC BY-ND 4.0 (retrieved 2026-11-01)
- BSI: C5 FAQ (German; designation “BC-01 to BC-06”) (retrieved 2026-11-01)
- BSI: C5:2026 overview page with downloads (retrieved 2026-11-01)
This content provides general technical and organisational information and does not constitute legal advice (no legal services within the meaning of the German RDG).