Last updated: 2026-11-01
A type 2 report assesses the controls over a period. Anything that went differently from plan during that period therefore belongs in the system description. This page covers only this part; the other minimum content is explained on the C5 system description page, and the difference between the report types on the type 1 or type 2 page.
What does the catalogue additionally require for type 2?
Three items that come on top of the eight items of minimum content (section 3.4.5.1). The “Catalogue” column quotes extracts from the English version 1.0.1; the right-hand column is our recommendation.
| Content | Catalogue (EN 1.0.1, 3.4.5.1) | What goes in, in practice |
|---|---|---|
| Significant changes | “Details on significant changes to the cloud service provider’s System of internal control applicable to the C5 criteria, that have been implemented during the specified period” | per change: what changed, from when, which criteria are affected, what the control looked like before and after |
| Significant events | Events and conditions that are exceptions to normal operation and that, during the period, resulted in contractual agreements on availability not being fulfilled, “unauthorised third parties having gained access to cloud service customer data”, or the integrity of customer data being compromised or protective measures not being effective | per event: type, time frame, impact on customers, cause at control level |
| Measures initiated | “the measures initiated by the cloud service provider to prevent such events and conditions in the future” | per event: measure, status, responsible unit |
The general rule for the system description applies to all three: it must not omit or distort any information relevant to meeting the applicable criteria (section 3.4.5.1, item 2). A period without significant changes or events is possible; in that case we recommend saying so explicitly in the description.
When is a change significant?
The catalogue does not define “significant” for changes in general. It sets only one case: adjustments of the system of internal control to C5:2026 count as significant changes and belong in the system description (section 3.5). For everything else we recommend a simple test question: does anything change in what the system description says about a control or the system?
| Typically significant (our assessment) | Typically not significant |
|---|---|
| a control runs differently: new frequency, new owner, new tool, for example a switch of identity directory | a release that went through the described change process; that is the control in operation |
| a control is added or dropped | corrections to the wording of policies with no effect on how they are carried out |
| system components in scope are added or dropped, for example a new region or a new module | scaling within the described limits, for example additional instances of the same type |
| a subservice organisation is replaced, or the carve-out or inclusive method changes | replacing a supplier that is not a subservice organisation within the meaning of section 3.4.6 |
| responsibilities in the organisation change, for example a new owner for information security | a change of person within a role whose tasks stay the same |
Record the decision for each change, with the date from which the new version applies. A type 2 report covers the whole period; auditors and customers need to see which version of a control ran in which part of the period.
When is an event significant?
For events the catalogue gives a yardstick: events and conditions are “typically significant when they affect multiple cloud service customers, and the cloud service provider informs the affected parties or the public” (section 3.4.5.1). Events with one of the three consequences from the table above have to be disclosed. “Typically” is a pointer, not an exhaustive rule. Our recommendation for the decision:
- Keep a flag in incident management showing whether an incident had one of the three consequences: contractual availability missed, unauthorised third-party access to customer data, integrity compromised or a protective measure not effective.
- For each flagged incident, apply the catalogue’s yardstick: were several customers affected, and were the affected parties or the public informed?
- Decide borderline cases deliberately, for example unauthorised access that affects only one customer, and record the reasoning. Agree borderline cases with the auditor early.
The list of reviewed incidents with the decision is also good evidence for minimum content item 6, dealing with significant events.
How do you disclose without revealing points of attack?
The catalogue asks for both at once. The information “should be as transparent as possible, without revealing vulnerabilities or potential points of attack”; the details must not jeopardise the information security of individual customers and should therefore not contain a detailed description of individual events (section 3.4.5.1). We recommend describing each event in five fields and drawing a line for each field:
| Field | Include | Leave out |
|---|---|---|
| Type | category under the catalogue, for example “contractual availability not fulfilled” | names of attacker groups, speculation |
| Time frame | month or calendar week, duration of the impact | minute-by-minute sequences from which detection times can be read |
| Impact | which functions, whether several customers, whether data was affected | names of affected customers, record counts for individual customers |
| Cause | at control level, for example “configuration change without the intended second review” | product versions, addresses, names of internal systems, vulnerabilities that are still open |
| Measures initiated | measure and status, for example “technical block on changes without approval, implemented in June” | details of detection rules or security tools |
A check before release: read every paragraph once through an attacker’s eyes. If it teaches them something about a target that is still open today, cut it back to control level.
Example: type 2 section of a billing platform
Fictitious example, not a client. A provider runs a billing platform for care services as SaaS. The type 2 period runs from 1 January 2027 to 31 December 2027. It begins before 1 June 2027 and should therefore comprise only the C5:2020 criteria (section 3.5); because it ends after 28 February 2027, the description needs information on planned changes. Extract in our wording:
| Entry | Wording in the system description (fictitious) |
|---|---|
| Significant change | “Since 15 May 2027, the provider’s staff have signed in through a new central identity directory. Since then, the controls for granting and reviewing access rights have run through this directory; owners and frequency are unchanged. Until 14 May 2027, the previous control applied as described in chapter 6.” |
| Significant change (adjustment to C5:2026) | “To adjust to C5:2026, the provider has, since September 2027, generated a software bill of materials (SBOM) with every build and stored it with the release. Since November 2027, a separate policy has governed patch management, with deadlines per severity; until then it was part of the operations policy. Until each changeover, the controls applied as described in chapter 6.” |
| Significant event | “In March 2027, the platform was unavailable for around six hours after a faulty configuration change to the database layer. All customers were affected, and the contractually agreed availability was not met for that month. No customer data was lost. The provider informed customers on the same day.” |
| Measures initiated | “Since June 2027, changes to the database layer have only been technically possible after approval by a second person. The contingency exercise in October 2027 included the recovery of this layer.” |
| Reviewed, not significant | “During the period there were no further events with one of the consequences listed in section 3.4.5.1 that affected several customers.” |
The wording gives category, time frame, impact and measure, but no product, no version and no sequence from which an attack path could be read.
Planned changes when moving to C5:2026
If an audit period ends on or after 28 February 2027, the provider additionally has to include information on planned changes to controls in the system description (section 3.5). The catalogue gives the reason as transparency for customers about the provider’s ability to comply with the new criteria going forward. Which revision applies to your period is shown by the deadline module on C5:2026.
The catalogue sets no end date for this obligation. The BSI FAQ adds a limit: the information is needed if the period ends on or after 28 February 2027 “but still before 1 June 2027” (our translation); the FAQ also applies the rule to type 1 specified dates, while the catalogue refers to the end of a period. This is a discrepancy between the FAQ and the catalogue. The catalogue is authoritative; check with your auditor how they treat the FAQ reading.
For each planned change the description should, as applicable, contain four items: the revised criterion, the nature of the change, the implementation status and the implementation date. Continuation of the example, criterion titles as in the English version 1.0.1 of C5:2026:
| Criterion (C5:2026) | Nature of the change (fictitious) | Status | Implementation date |
|---|---|---|---|
| DEV-13 Transparency about Software Components | a software bill of materials (SBOM) is generated with every build and stored with the release | implemented | September 2027 |
| AM-04 Software Asset Inventory | the software inventory is compiled from the SBOMs of all production components | not implemented | planned for March 2028 |
| OPS-27 Managing Vulnerabilities - Patch Management Policies and Procedures | separate policy with deadlines per severity, previously part of the operations policy | implemented | November 2027 |
| SSO-07 Ensuring Transparency within Service Organisations | contractual amendment with the platform provider and the data centre operator | not implemented | planned for February 2028 |
Keep two things apart. What you have already switched during the period is an adjustment to C5:2026 and therefore also a significant change that belongs in the type 2 section, in the example DEV-13 and OPS-27; the catalogue points out that evaluations may then cover the status before and after the adjustment. What is only planned appears only in the information on planned changes. For this information the auditor checks whether it is fairly presented; whether the planned controls are suitably designed or operating effectively is not yet assessed (section 3.5).
Who supplies the information, and who approves it?
The information comes from three processes: changes from change management and information security management, events from incident and business continuity management, planned changes from the C5:2026 migration plan. Our recommendation: collect continuously during the period, not only at the end, and have the information security officer review the wording before it goes into the description. In the management statement, management confirms that the description fairly presents the system; this part is included.
Typical gaps in changes and events
| Possible gap | Cause | Effect | Remedy |
|---|---|---|---|
| Event missing | incident closed in the ticket system but never checked against the three consequences in section 3.4.5.1 | the description omits relevant information and is then not fairly presented; the audit opinion may be qualified (section 3.4.12) | keep the flag in incident management and the list of reviewed incidents |
| Too much detail | post-incident report copied into the description | points of attack and internal system names become visible to every reader of the report | use the five fields with their limits, describe the cause at control level |
| Change without a date | tool switch described, but not from when the new control applies | auditors and customers cannot see which control ran in which part of the period | for each change, state the date and the control before and after |
| Planned changes missing | period audited against C5:2020, obligation from section 3.5 overlooked | required information is missing from the description | check the deadline module on C5:2026 for every period, use the migration plan as the source |
Frequently asked questions
Do type 1 reports also need information on significant changes and events?+
Do we have to list every security incident?+
What do we write if nothing significant happened?+
Does the auditor audit the planned changes for C5:2026?+
Until when is information on planned changes needed?+
Read more
- C5 system description: minimum content, structure and example
- C5:2026: what is new, moving from C5:2020 and the transition period
- C5 type 2 or type 1 report: differences, period, choice
- C5 management statement: what management confirms
- BSI C5 audit process: steps, audit standards and timeline
- C5 readiness assessment: gap analysis, action plan and timeline
Sources
- BSI: Kriterienkatalog Cloud Computing C5:2026, version 1.1.0 (PDF, German), sections 3.4.5.1 and 3.5, licensed under CC BY-ND 4.0 (retrieved 2026-11-01)
- BSI: Cloud Computing Compliance Criteria Catalogue C5:2026, version 1.0.1 (PDF), sections 3.4.5.1 and 3.5, licensed under CC BY-ND 4.0 (retrieved 2026-11-01)
- BSI: C5 FAQ, question on when C5:2026 applies and which transition periods apply (German) (retrieved 2026-11-01)
- BSI: C5:2026 change history (Excel), sheet “Change History” (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).