BSI A5: structure, community draft status and the bridge to C5

In July 2026 the BSI published A5, a draft framework for auditing AI systems. This page covers the current status, the structure, the audit methodology and the link to C5, which for AI providers in the cloud defines the shortest route to a future A5 audit.

What is BSI A5?

A5 stands for AI Audit and Assurance Assessment Architecture. It has two parts: auditable criteria for the trustworthiness of AI systems, AI applications or their components, and an audit methodology under which independent public auditors (Wirtschaftsprüfer) test those criteria based on ISAE 3000 (Revised). A5 addresses everyone along the AI value chain, “such as those involved in development, operation, oversight, and procurement” (BSI A5 page). The criteria follow the conventions of the BSI State-of-the-Art Library and are also published in the machine-readable OSCAL format. A5 was developed in the BSI project AICRID.

What is the current status of A5?

As of 1 November 2026, A5 is a community draft. The BSI published it for comment in July 2026; comments could be submitted until 31 August 2026. No revised or final version is listed on the BSI site yet, and the BSI says it will keep updating, extending and testing A5.

A5 is therefore a draft. Criteria and methodology may change before a final version; base your preparation on the structure rather than treating individual wording as fixed.

How A5 is structured

Criteria are organised in profiles and profile modules defined by the BSI. A profile is a predefined set of applicable criteria; a profile module is a subset, for example for a technology, an operating model or a regulatory requirement. The draft contains two modules:

• Horizontal Trustworthiness Core Module: the technology- and application-agnostic foundation, with criteria grouped into six practices along the AI life cycle: Governance, Compliance and Scope; Design, Engineering and Integration; Verification and Validation; Deployment; Operations; Retirement.
• Cloud Infrastructure Operations Module: a vertical module for requirements that arise when an AI system runs on cloud services.

Trustworthiness dimensions described in the core module include data quality and governance, transparency and explainability, human oversight, robustness including confidentiality, integrity and availability, performance, record-keeping, monitoring, bias and accountability, with AI governance as an overarching layer.

How is A5 audited?

The A5 methodology is modelled on C5:

The methodology recommends coordinating A5 with audits under ISAE 3402, SOC 2, C5, ISO/IEC 42001 or conformity assessments under the EU AI Act (Regulation (EU) 2024/1689). A mere reference to similar criteria in other standards is not enough, though: the auditor needs their own conclusion based on their own procedures, and results of an ISO certification are to be assessed differently from those of an ISAE 3000 engagement (methodology, section 3.3).

The bridge to C5: criterion GCS.2.5

The cloud infrastructure module contains one criterion in the draft, GCS.2.5. It says the responsible party should document the trustworthiness of the underlying infrastructure and cloud components “by providing recognised evidence of compliance (C5 certificate)”. There is no such thing as a C5 certificate; the German text says “C5-Testat”, an attestation. In short, that evidence has to cover the infrastructure relevant to the AI system and the assessment period, come from independent personnel and show that no critical security-related issues were found. The full wording with all elements is in the module itself (BSI, A5 Cloud Infrastructure Operations Module, section 2.1.1, © BSI 2026).

A period the C5 report does not cover can be bridged with a bridge letter. The module does not define the term; usually it is a statement by the provider for the time between the end of the report period and the cut-off date.

Our view: an AI system on someone else’s cloud infrastructure needs that platform’s C5 report, and its scope and period have to match the AI system’s assessment period. Because the evidence is meant to show that no critical issues were found, the section listing deviations in the platform’s C5 report has to be reviewed too; an unqualified opinion alone does not tell you that. A provider that has its own service attested to C5 also covers its own operations layer. How platform attestations and your own audit scope fit together is explained on C5 scope. C5:2026 applies to Type 1 dates and Type 2 periods from 1 June 2027; earlier adoption is permitted.

What A5 is not

• Not a legal obligation: A5 is an audit framework. The BSI places it in the context of the EU AI Act and the Cyber Resilience Act; it does not create duties of its own.
• Not an AI Act conformity assessment: the methodology mentions overlaps and recommends coordination. AI Act deadlines are not covered here; check them against the current official text.
• Not a certificate: under the methodology, the outcome is a public auditor’s Type 1 or Type 2 report.
• Not AIC4: the older BSI catalogue AIC4 for AI cloud services was designed as an extension of C5 and, according to the BSI, is currently not being updated directly; A5 is a separate, modular framework.

Example: AI-based receipt recognition on a hyperscaler platform

Fictitious example, not a real client. A provider runs a billing platform with AI-based receipt recognition on a large cloud platform. A financial services customer asks whether an A5 audit is planned.

1. Assessment object: the receipt recognition including the integrated model, not the whole company.
2. Infrastructure evidence (GCS.2.5): the provider obtains the platform’s C5 report, checks regions, services and period, reviews the reported deviations and plans a bridge letter for the gap up to its own cut-off date.
3. Own operations layer: as the customer already requires a C5 attestation for the service, the provider prepares that first. System description, controls and evidence can be reused for A5 later.
4. AI-specific gaps: a gap analysis covering the six practices shows missing evidence on data provenance, validation, human oversight and drift monitoring.

What you can prepare now

1. Clarify your C5 basis: which C5 attestations cover your infrastructure, and does your own service need one? This addresses GCS.2.5 and builds experience with ISAE 3000 audits.
2. Define the assessment object: which AI system, model or component will be audited, and who is the responsible party.
3. Build evidence early: data provenance, validation results, approvals and operational monitoring accumulate over time. A Type 2 report needs them for the whole period.

How we prepare AI providers for A5 and C5

We prepare cloud and AI providers for the C5 attestation that A5 expects for the infrastructure and, if useful, include the A5 practices in the same gap analysis. Blackfort Technology does not issue attestations. A C5 attestation is issued by an independent auditor; the A5 methodology provides for a public auditor (Wirtschaftsprüfer). Book an initial call to discuss your starting point.