Penetration Testing in the BSI C5 Attestation: What Cloud Providers Must Prove

Anyone preparing a C5 attestation for their cloud service sooner or later runs into the question of whether a penetration test is actually required or just a good idea. Under the BSI Cloud Computing Compliance Criteria Catalogue (C5), the answer is unambiguous: the pentest is an explicit mandatory criterion with clear rules on frequency and tester qualification. It is therefore not an optional add-on but part of the evidence the attesting auditor expects to see. This article shows what C5 specifically requires and what cloud providers need to watch out for when implementing it.

The Pentest Is a Criterion of Its Own in C5

C5 leaves little room for interpretation here. In the Operations (OPS) domain it mandates penetration testing as a fixed control objective. In the C5:2020 edition this is criterion OPS-19; in the C5:2026 revision, published in April 2026, it is carried as OPS-22. The cloud provider must demonstrate that its service is regularly tested for exploitable vulnerabilities through penetration tests, and this evidence feeds directly into the C5 attestation.

The nature of the attestation itself matters here. C5 is not granted as a certificate but attested through the audit opinion of an independent auditor, in Germany under the IDW PS 860 standard, internationally under ISAE 3000 (Revised). A distinction is made between a Type 1 attestation, which assesses the suitability of controls at a point in time, and a Type 2 attestation, which additionally examines the operating effectiveness of the controls over a period. For the Type 2 attestation in particular, it is not enough for a pentest process to exist on paper. The auditor wants to see that testing actually took place during the audit period. Just how binding the Type 2 attestation has become is evident in the healthcare sector: for cloud services processing patient data, it has been mandatory since July 2025.

Frequency: At Least Annually, Semi-Annually at High Protection Level

The criterion requires a penetration test at least annually, plus additional testing whenever the cloud service undergoes significant changes. A major architectural change, a newly exposed service, or a substantial infrastructure rebuild therefore triggers a test, regardless of when the last one took place. The annual cadence is the floor, not the rule for every situation.

For cloud services with high protection requirements the bar rises considerably. Testing must then happen at least semi-annually, and it must be carried out by independent external testers. Cloud providers should therefore assess the protection level of their service realistically and early, because it directly determines both testing frequency and tester setup. Anyone who only realizes shortly before the attestation that their service qualifies as high protection faces a cadence they can no longer reconstruct retroactively within the current year.

Who May Test: Independence and Tester Qualification

C5 sets requirements not only on the whether and how often, but also on the tester. As examples of acceptable evidence for the required qualification, the catalogue names the BSI-certified IS penetration tester or a CREST certification. This ensures the test is methodologically sound and not merely a superficial scan.

The second decisive point is independence. Internal specialists may contribute in a supporting role, but they do not satisfy the external independence required at the high protection level. This is the point at which many providers hit a limit with their internal operations. A test by the in-house security team may cover the baseline case, but once the service is classified as high protection, there is no way around an independent external pentest. In practice the external test is advisable anyway, because it demonstrates independence to the auditor without any discussion.

What the Auditor Wants to See: The Report

A penetration test does not satisfy the C5 criterion simply by having taken place. What matters is that its results are documented in an audit-proof way. A report that merely lists vulnerabilities is of little help to the auditor. What is needed is a traceable methodology, an assessment of the identified vulnerabilities by exploitability, and above all a documented handling of the findings.

The auditor looks not only at the test but at the closed loop behind it. Were the identified vulnerabilities remediated, and can that be demonstrated? Where remediation did not happen, is there a justified and approved risk acceptance? A retest or a documented tracking of remediation is therefore often just as important as the test itself. It is precisely this loop of testing, assessment, remediation, and proof that distinguishes an attestation-grade penetration test from a mere vulnerability scan.

What Cloud Providers Should Do Now

The pentest should not be understood as an ad hoc obligation squeezed in just before the attestation, but as a planned, recurring process. Anyone pursuing a C5 attestation should align frequency, scope, and tester independence with the attesting auditor early, so that the extent of testing matches the intended protection level and the type of attestation. This alignment before the audit period spares you the unpleasant realization that a test already performed turns out to be insufficient in hindsight.

Equally important is a cleanly defined scope that covers the actual attested system boundary of the cloud service. External services, management interfaces, and the underlying infrastructure usually belong in it. And finally, the entire cycle of testing, remediation, and retesting should be documented so that it is fully traceable throughout the audit period. For Type 2 attestations, this continuity over time is the real touchstone.

Conclusion

Under BSI C5, the penetration test is not a may but a must. The criterion prescribes it explicitly, requires at least annual testing, semi-annual at the high protection level, by qualified and independent testers, and makes it part of the attestation. Anyone who sets it up as a recurring, well-documented process with proven remediation, rather than a one-off snapshot, satisfies the criterion not only formally but genuinely improves the security of their cloud service. If you are planning a cloud pentest for a C5 attestation, aligning scope, frequency, and tester qualification early pays off.