C5 attestation: prepare cloud assurance evidence

A cloud customer wants to know which protections the provider operates and which remain its own responsibility. The German Federal Office for Information Security (BSI) publishes the Cloud Computing Compliance Criteria Catalogue, C5, as a structured basis for examining that assurance. For a CTO, preparation means making the service boundary, control implementation, and operational records inspectable—not merely assembling policies.

C5 is a criteria catalogue used for independent attestation, not an ISO-style certification. The BSI’s C5 documentation is the primary reference. Start by agreeing the applicable edition, assurance objective, and examination scope with the independent auditor.

Define exactly which service the report will cover

Describe the cloud service, operating locations, organizational boundaries, and dependencies. A report covering one service does not automatically cover every product under the same brand. Identify production components, management interfaces, support operations, and external services that can affect the assurance claims.

The system description should let an outsider understand how customer data enters, moves through, and leaves the service. Include administration paths, deployment processes, security monitoring, backups, and the division of responsibilities between teams. Explain relevant service characteristics and operating conditions rather than substituting architecture diagrams for narrative.

Resolve these scope questions before collecting evidence:

• Which products, regions, and environments are included?
• Which teams administer production or can access customer information?
• Which underlying providers support the service, and how are their controls treated?
• Which configurations and security tasks remain with customers?
• Which material changes occurred, or are planned, during the examination period?

Give exclusions an explicit rationale. If a legacy deployment is excluded, ensure customer-facing statements do not imply that it is covered. The deliverable is a versioned system description supported by architecture, dependency, and responsibility records.

Choose the report type before setting the evidence calendar

C5 assurance is generally expressed through an auditor’s attestation report. Type 1 addresses control design and implementation at a point in time. Type 2 additionally examines operating effectiveness over a specified period.

Type 1 can be a useful milestone when establishing a control environment, but it does not answer the same question as Type 2. Confirm what customers actually require before choosing an interim report.

Agree the period and evidence expectations with the auditor. Do not assume a universal observation length. A procedure written near the end of a period cannot establish that the control operated earlier. Likewise, a successful current test does not erase a historical failure.

Build evidence around responsibility and execution

As a practical preparation method, build an evidence register connecting each applicable criterion to the implemented control, owner, service boundary, evidence source, review frequency, and unresolved gaps. Record applicability decisions and their rationale; avoid marking a criterion irrelevant simply because implementation would be difficult.

Separate three questions: what should happen, what is implemented, and what actually happened. A policy addresses the first. Configuration records can support the second. Tickets, logs, approvals, and test results support the third.

These are practical examples, not a complete C5 checklist. Use the agreed catalogue and scope to determine the required coverage, including organizational, personnel, physical, and technical controls.

Make evidence reproducible

For each export or screenshot, retain the source system, collection date, relevant period, filters, and collector. Explain whether it represents the full population or a selected item. Auditors need to understand the population from which they select samples; a folder containing only successful examples is not sufficient.

Prefer records that retain actor, timestamp, action, and outcome. Protect evidence against unauthorized alteration and avoid unnecessary customer-data exposure. Where redaction is needed, preserve enough context for the reviewer to understand what the record proves.

Separate inherited controls from retained duties

An infrastructure provider’s assurance may support physical security or underlying platform controls. It does not establish that your application’s tenant authorization works. Document the dependency, relevant report scope, period, exceptions, and responsibilities your team must still fulfil.

Complementary customer controls also need practical wording. “Customer responsible for security” is too broad. Specify tasks such as administering tenant users, configuring identity federation, or reviewing customer-controlled access policies. Keep these responsibilities consistent across the system description, service documentation, and contractual arrangements.

Run preparation as an engineering programme

Start with a gap assessment against the agreed criteria. Distinguish missing implementation from missing evidence: those require different remedies. An undocumented review may require better records; an access review that never occurred requires an operational control.

Assign each gap an owner, remediation action, dependency, and target date. Prioritize issues affecting tenant separation, privileged access, production changes, incident response, and recoverability according to the service’s risks—not merely the easiest documentation tasks.

Before the Type 2 period, check that recurring controls have workable schedules and durable records. Confirm who performs them during absence or staff turnover. For event-driven controls, such as account termination, make sure the triggering population can be identified.

Conduct a readiness walkthrough with representative evidence. Trace one change from request through deployment, one departing administrator through revocation, and one recovery exercise through corrective action. This exposes broken handoffs that a policy review can miss.

During examination, maintain a request register with owners and response status. Keep original records available, explain discrepancies openly, and track remediation separately from historical evidence. Do not rewrite old records to make them look compliant. The auditor determines how findings affect testing and the opinion.

Worked example: a managed application on external infrastructure

Assume, illustratively, that a provider operates a multi-tenant application in one region, uses an external infrastructure provider, and seeks Type 2 assurance. Its team controls application releases, tenant permissions, production administration, and recovery procedures.

The scope description identifies the application, database, management plane, support tooling, and infrastructure dependency. It explains which underlying controls are inherited and which remain with the application provider.

For tenant isolation, the team records its authorization design, automated negative tests, security-test findings, and release approvals. It also retains change records showing when authorization logic changed. The infrastructure report is supporting dependency evidence, not proof of application isolation.

For privileged access, the team retains the administrator population, grant approvals, review decisions, and removal records. Suppose a review discovers an unused support account. The team records the discovery, revocation, exposure assessment, and preventive action. That is more credible than submitting only the cleaned-up account list.

For recovery, it retains a restore-test result showing what was recovered, elapsed time, data integrity checks, and unresolved limitations. A configured backup job alone does not demonstrate recoverability. Each evidence set has an owner and a defined period, so the auditor can connect the records to the control being examined.

Reuse assurance work without claiming equivalence

ISO/IEC 27001 concerns a scoped information security management system. SOC 2 is an attestation report using its own criteria and reporting context. C5 focuses on cloud-service assurance under the BSI catalogue.

Existing risk assessments, access controls, incident procedures, and operational records can support more than one programme. Reuse them through version- and scope-specific mappings, then check for requirements or reporting differences. A shared control is not automatic equivalence between frameworks.

Choose the assurance portfolio from actual customer requirements and service risks. C5 is not universally mandatory for every cloud provider; tender, contractual, or applicable sector requirements need separate review. Neither a C5 report nor another assurance document independently establishes GDPR or NIS2 compliance.

Prepare the report for customer decisions

Customers need the system description, date or period, actual opinion, exceptions, and responsibility boundaries—not just the report label. When sharing reports, respect contractual confidentiality and provide context for the customer’s assessment.

Explain remediation status without suggesting that subsequent fixes change the historical opinion. If the report period predates a major architectural change, identify that limitation. Agree recurring examinations around customer expectations and operating changes rather than treating attestation as a timeless credential.

Secani helps teams connect control implementation and evidence to reviewed requirements. Model the service and dependencies, assign owners and reviewers, attach supporting records, and turn evidence gaps into tasks. Keep human approval explicit for mappings and conclusions. The audit-readiness model helps preserve the scope and responsibility behind each claim.

Questions to resolve before the first examination

Does the BSI issue the report?

The BSI publishes the catalogue. An independent auditor performs the examination and issues the attestation report; confirm the applicable assurance framework and engagement terms with that auditor.

What if no real incident occurred?

Do not invent an incident record. Retain evidence that the process was implemented and, where appropriate, exercised. Agree how the absence of events affects testing with the auditor.

What should the team do next?

Take one representative production service and prepare its scope description, responsibility matrix, and evidence register. Review those three deliverables with the prospective auditor before assembling a large evidence package.