Writing the BSI C5 system description

A C5 system description is the document in which a cloud service provider presents its service and the related system of internal control, so that customers can judge its information security. If you are heading for a BSI C5 attestation, you will almost certainly write one. What the attestation as a whole tells customers is covered on the page C5 attestation.

What the system description is in C5

The catalogue calls it the “Description”: the description of the provider’s system of internal control relevant to the development and operation of the cloud service. In an attestation engagement it is the subject matter of the audit, and the audit also rests on a written management statement (sections 3.4.4 and 3.4.5.2).

In a direct engagement the provider does not supply a description. The auditor identifies the system during the engagement and presents it in the report (sections 3.4.4 and 3.4.13). The catalogue sees this variant as particularly suitable for providers whose system of internal control is not yet sufficiently documented. The C5 audit process page compares both engagement types.

In the final report the description is the third component, after the auditor’s report and the management statement, and before the controls with test procedures and results (section 3.4.13).

The eight minimum content items of section 3.4.5.1

The catalogue requires a fair presentation of the system with eight minimum content items, “in order to provide customers with sufficient transparency about the information security of the cloud services in scope”. The catalogue column quotes the official English version verbatim, with omissions marked […]; the other two columns are our practical notes.

Two rules apply across all eight items. The description shall not omit or distort information relevant to meeting the applicable criteria (section 3.4.5.1, no. 2). And a presentation only counts as fair if it includes the general conditions and the specific information on subservice organisations (section 3.4.7). Thin coverage of items 3 or 8 therefore puts the whole description at risk.

Additional content for Type 2 reports

For a Type 2 report the description also covers significant changes to the system of internal control during the period, significant events that led to missed availability commitments, unauthorised access to customer data or compromised integrity and ineffective safeguards, and the measures taken to prevent recurrence (section 3.4.5.1). Events are typically significant when they affect multiple customers and the provider informs the affected parties or the public. The catalogue asks for transparency “without revealing vulnerabilities or potential points of attack”.

When moving to C5:2026, control adjustments count as significant changes, and for periods ending on or after 28 February 2027 the description needs information on planned changes (section 3.5). The catalogue sets no end date for this; only the BSI FAQ limits it to periods ending before 1 June 2027. When wording significant changes and events, our advice is that customers should be able to see cause, impact and remedy without the text exposing a point of attack. The report types are compared on Type 1 or Type 2.

A sample outline

The catalogue defines content, not chapters. The outline below is our recommendation and follows the eight minimum content items so auditors and customers can find each item quickly.

1. Introduction and scope: purpose, report type, date or period, catalogue revision, services and regions covered (item 1).
2. Company and service: organisation, service model, features, customer groups, excluded modules (item 1).
3. System components: architecture, infrastructure, software, data and data flows, network, operations and development tooling, people and roles (item 2).
4. General conditions: one subsection per GC-01 to GC-06, consistent with contract and SLA so the general conditions match the contract (item 3).
5. System of internal control: control environment, risk assessment, information and communication, monitoring (item 5).
6. Applicable criteria and controls: applicability table, justified exclusions, additional criteria selected, then the controls per criterion (items 4 and 5).
7. Significant events: incident and contingency process, customer communication (item 6).
8. Complementary user entity controls (CUEC): numbered list of the controls your service relies on customers to perform, linked to criteria (item 7). A good starting point is the complementary customer criteria the catalogue gives for selected criteria. They are general and not exhaustive; the CUEC are written for your service.
9. Subservice organisations: method, table with the required details, expected controls, monitoring (item 8).
10. Type 2 only: significant changes, significant events, measures; planned changes during the transition under section 3.5.

The management statement is a separate report component and does not belong in the description’s outline; in it, management confirms in writing that the description fairly presents the system (section 3.4.5.2). The outline is available as an editable file on templates.

How specific control descriptions need to be

Specific enough for an auditor to derive a test procedure. When assessing design, the auditor considers, among other things, the frequency or timing of a control, the authority and competence of the person performing it and the tasks within the control (section 3.4.9). Controls are mapped to subcriteria, and the subcriteria of a criterion are read together (section 2.1); a criterion is not met if one of its subcriteria is not met (section 3.4.12).

We suggest the same fields for every control. A made-up example, not catalogue text:

Whether such a control covers all mapped subcriteria is the auditor’s call. If an element is not covered, the auditor reports the gap; if the provider can evidence a further control, it is added to the description (section 3.4.8).

Applicability, exclusions and additional criteria

Basic criteria define the minimum scope of every audit. Exclusions must be justified by the nature and design of the service or by the provider’s policies, procedures and measures, for example IaaS-only criteria for a SaaS service. The auditor assesses whether the justification is fairly presented. Criteria shall not be excluded because controls are missing or ineffective, or because the provider is unwilling or unable to demonstrate conformity (section 3.4.3). Where a risk-based criterion led to the conclusion that there is no risk to mitigate, that justification belongs in the applicability section as well.

Providers choose additional criteria freely, down to individual subcriteria, and state the rationale. A sharpening additional subcriterion replaces the basic subcriterion in the description; a complementing one is presented together with the basic subcriteria (section 3.4.3).

Subservice organisations and customer controls

For each subservice organisation the description states the method, carve-out or inclusive (section 3.4.6). Under carve-out, that organisation’s controls stay outside the description and the audit, but the description still names the complementary subservice organisation controls (CSOC) you rely on and your monitoring under SSO-05. How to choose and what a platform report covers is explained on C5 scope. A separate register of the required details per subservice organisation, a subservice inventory, helps; a template is on templates.

The auditor does not test CUEC at the customer. The procedures are limited to the fair presentation of your assumptions about these controls (section 3.4.4), and the report states that the criteria can only be met if the customer controls are effective (section 3.4.13). For healthcare customers in Germany this links to Section 393 SGB V (Book V of the German Social Code), which requires that the complementary customer criteria contained in the audit report are implemented. The act uses the German name of that catalogue part, not the term CUEC; which content of the report is meant needs a legal assessment, see Section 393 SGB V.

Who writes it

The cloud service provider. The auditor’s report states that the provider is responsible for preparing the description and the management statement, including completeness, accuracy and method of presentation (section 3.4.13, no. 1.2). Management then confirms in writing that the description fairly presents the system (section 3.4.5.2).

In practice we recommend one owner in the information security function who collects input: operations and platform for components and controls, engineering for change processes, legal or procurement for general conditions and suppliers, management for the control environment and sign-off. Consultants can structure, draft and review. The auditor is not the right author, because the auditor has to confirm independence before accepting the engagement (section 3.4.2). Blackfort Technology supports the drafting; the attestation is issued by an independent auditor.

What the auditor checks

The auditor concludes whether the description fairly presents the system as of the date or throughout the period (section 3.4.4). Section 3.4.7 requires the auditor to:

• obtain and read the description and evaluate whether the aspects in scope are fairly presented, with special attention to the minimum content;
• determine through inquiry combined with observation and inspection of records whether the system has been implemented as described;
• check that the general conditions and the subservice organisation details are included, because without them the presentation is not fair.

If the description does not fairly present the system in all material respects, the auditor has to modify the opinion (section 3.4.12). A polished description that differs from day-to-day operations is riskier than a short one that is accurate.

Reusing SOC 2 or ISO 27001 material

A description prepared for another audit, such as SOC 2, may be reused but has to be adapted to the C5 requirements for the description (section 3.4.4); general conditions, CUEC and subservice organisations (items 3, 7 and 8) are written specifically for C5. What else carries over is covered on C5 and SOC 2 and C5 and ISO 27001.

Example: a description for an AI reporting assistant

Fictitious example, not a client. A provider runs an AI assistant that pre-structures radiology reports, offered as SaaS to hospitals. It runs on an IaaS platform in a German region, with inference on its own GPU instances. The plan is an initial Type 2 engagement with a six-month period.

Three common gaps and how to close them