Certified CSA STAR Auditor key terms

A CSA program that lets cloud providers publish security documentation and, at higher levels, independent audit results, so customers can compare providers against a common baseline instead of bespoke questionnaires.

The self-assessment tier of STAR. The provider completes the CAIQ and publishes the resulting responses, together with supporting documents, to the public STAR registry without an independent auditor validating the answers.

The third-party assessed tier of STAR. An independent auditor evaluates the provider's controls against CCM and issues a report, giving customers higher assurance than a self-declared Level 1 submission.

CSA's public listing of providers that have submitted STAR assessments. Entries show the assurance level, the documents published, and the scope, letting buyers verify a claim rather than rely on marketing statements.

A published STAR submission at Level 2, produced by a licensed auditor and covering a defined scope and period. It is the evidence artifact customers request during vendor due diligence.

The documented boundary of a STAR assessment: which services, systems, locations and time period are covered. Anything outside it is not assured, so readers must check scope before relying on a report.

A short provider statement covering the gap between the end of an audited period and the current date, confirming whether controls changed materially. It is not an audit opinion and carries no independent assurance.

CSA's control framework organised into domains, each control stating a security objective for cloud providers and mapping to other standards. Auditors use it as the criteria against which STAR Level 2 is assessed.

A single requirement in the Cloud Controls Matrix, identified by a domain code and number, with a stated objective and often a specification of the evidence expected. It is the unit an auditor tests.

A thematic grouping of related controls in the matrix, such as identity, data security or supply chain. Domains give structure to scoping and reporting and let auditors plan coverage area by area.

A cross-reference showing how a CCM control aligns with requirements in other frameworks such as ISO/IEC 27001 or NIST publications. Mappings support reuse of evidence but do not prove equivalence.

The assignment of each CCM control to the party responsible for operating it, either the cloud provider or the customer, or shared between them. Clear ownership prevents controls falling between the two.

The split of security duties between a cloud provider and its customer, varying by service model. STAR reports describe the provider side, so customers must identify what remains theirs.

The technical and organisational edge separating what the provider operates from what the customer controls. Defining it precisely is a prerequisite for a defensible STAR scope.

A standardised set of yes/no questions with room for explanations, derived from CCM. Providers answer it for STAR Level 1, and auditors use the same structure to organise Level 2 evidence requests.

A provider's answer to one CAIQ question, comprising the yes/no selection plus a written explanation and often a reference to supporting evidence. Auditors test whether the explanation matches reality.

A CSA initiative addressing how AI systems are assessed and assured, extending the STAR approach to AI-specific risks such as model behaviour, training data and output reliability, alongside conventional cloud controls.

The extension of the STAR program to AI services, allowing providers to publish AI-focused assessments. It layers AI-specific controls and questionnaires on top of the existing cloud assurance structure.

CSA's control framework for AI systems, covering areas such as data governance, model lifecycle, transparency and human oversight. It plays the same role for AI that CCM plays for cloud infrastructure.

The questionnaire counterpart to the AI Controls Matrix, giving providers a standard set of questions to answer about their AI systems so results can be compared and published under STAR for AI.

One of the accepted paths to STAR Level 2, where the provider holds a certified information security management system and the auditor maps that certification and its supporting evidence to CCM controls.

A path to STAR Level 2 in which the auditor uses an existing SOC 2 report, typically covering security, availability or confidentiality, and maps its tested controls to the corresponding CCM requirements.

A CSA assessment aimed at cloud services in specific jurisdictions or sectors, providing a structured evaluation against CCM that can sit alongside or precede a full STAR Level 2 attestation.

A preliminary review comparing a provider's current controls with CCM requirements to identify missing or weak areas before a formal audit. Findings are advisory and do not constitute assurance.

A documented set of actions, owners and dates addressing control deficiencies found in assessment. Auditors check that plans exist for exceptions and that progress is tracked rather than asserted.

A control that does not fully meet its CCM objective, disclosed with justification and any compensating measure. Undisclosed exceptions undermine the credibility of the whole attestation.

A tangible record an auditor inspects to test a control, such as a configuration export, ticket, log sample or signed policy. Evidence must be relevant to the period and scope under review.

Selecting a subset of items, such as servers, changes or access reviews, to test a control when the population is large. The auditor documents selection method so conclusions can be defended.

The requirement that the assessing party has no stake in the outcome and is not managed by those it assesses. Independence is what distinguishes a Level 2 attestation from a self-assessment.

An individual authorised by CSA to perform STAR Level 2 assessments, having met training and competence requirements. Only such auditors can produce attestations accepted into the registry.

Ongoing collection of control evidence between formal audits, used to detect drift and support faster renewal. It complements, but does not replace, periodic independent assessment.

The stages an AI model passes through, from data collection and training to deployment, monitoring and retirement. AICM controls attach governance and evidence requirements to each stage.

Controls over the origin, quality, licensing and handling of data used to build AI models, including provenance records and restrictions on sensitive content. Auditors look for documented decisions, not assurances.

The arrangement by which people can review, intervene in or override an AI system's outputs. In AI assessments, auditors check that oversight is defined, resourced and actually exercised.

Published information describing what an AI system does, its intended use, known limitations and how it was evaluated. It supports customer risk decisions and is a common AICM expectation.