Framework

CSA STAR
cloud security assurance levels, registry, and evidence

CSA STAR (Security, Trust, Assurance, and Risk) is the Cloud Security Alliance assurance programme cloud providers publish their security posture against and that enterprise buyers read against the provider longlist during procurement. STAR sits on top of the CSA Cloud Controls Matrix (CCM) and the Consensus Assessments Initiative Questionnaire (CAIQ). It ships three levels (Level 1 self-assessment, Level 2 third-party certification or attestation, Level 3 continuous self-assessment) that map onto progressively higher assurance commitments and that buyers, regulators, and audit committees read against critical-vendor relationships. This page covers the three levels, the registry mechanics, the level-vs-level dimensions, the buyer-side and provider-side operating shape, the failure modes that erode the registry trust, the evidence pack STAR Level 2 reads against, the operating cadence from scope to a Level 2 entry, and the cross-walk to ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, SOC 2, NIST SP 800-53, FedRAMP, PCI DSS, and the regulator-aligned cloud regimes.

Get Started Free

No credit card required. Free plan available forever.

CSA STAR explained for cloud security and GRC programmes

CSA STAR (Security, Trust, Assurance, and Risk) is the Cloud Security Alliance assurance programme cloud providers publish their security posture against and that enterprise buyers read against the provider longlist during procurement. STAR sits on top of the CSA Cloud Controls Matrix (CCM) and the paired Consensus Assessments Initiative Questionnaire (CAIQ). The CCM is the control catalogue. The CAIQ is the assessment companion. STAR is the publishing and certification regime where the assessment evidence lands publicly, in three levels (self-assessment, third-party certification or attestation, and continuous self-assessment), so customers, regulators, and procurement teams have a registered, dated, scoped record they can read against the provider rather than reconstructing the assurance per deal.

For cloud security teams, GRC and compliance teams, vendor risk functions, internal audit, CISOs, security architects, and enterprise buyers, STAR is the framework that turns the cloud-provider assurance from a bespoke security questionnaire response into a public, levelled, scoped, dated registry entry. For cloud providers, STAR is the buyer-facing artefact that pairs with the operating programme already running: ISO/IEC 27001 for STAR Certification, SOC 2 for STAR Attestation, the CCM layered on at Level 2, and the published cadence at Level 3.

The STAR programme: framework, questionnaire, registry

STAR does not sit in isolation. It is one part of a four-part CSA assurance programme buyers and regulators read together: the framework (CCM), the assessment questionnaire (CAIQ), the publishing and certification regime (STAR), and the public registry that holds the assurance evidence. The four together carry the procurement, audit, and continuous-assurance shape the enterprise cloud-buying motion expects.

The assurance overlay above CSA CCM

CSA STAR (Security, Trust, Assurance, and Risk) is the Cloud Security Alliance assurance programme that operates on top of the CSA Cloud Controls Matrix (CCM). The CCM is the control catalogue. The CAIQ is the assessment questionnaire that reads against the CCM. STAR is the publishing and certification regime where the assessment evidence lands and against which cloud customers, regulators, and procurement teams read provider posture.

Three assurance levels, one registry

STAR ships three levels that map onto progressively higher assurance commitments. Level 1 is self-assessment (a completed CAIQ or CCM mapping the provider publishes itself). Level 2 is third-party assessment (STAR Certification reads against ISO/IEC 27001 with CCM; STAR Attestation reads against AICPA SOC 2 with CCM). Level 3 is continuous self-assessment (STAR Continuous), the cadence-based discipline providers operate to keep the assurance current rather than annual.

A publicly searchable registry

The STAR Registry is publicly searchable. Many enterprise procurement teams, vendor risk functions, and regulator-aligned buyers expect to find a provider in the registry before they will close a cloud purchase. The registry entry carries the level, the underlying assessment evidence (CAIQ for Level 1, audit report references for Level 2), the scope, and the date. The registry is the index the buyer-side reads against rather than a bespoke security questionnaire response.

The three STAR assurance levels in detail

STAR ships three levels that map onto progressively higher assurance commitments. Each level carries a different audience, a different underlying assurance, a different cost shape, and a different cadence. Programmes deciding which level to operate against pin the level to the buyer commitment the provider has made: Level 1 for entry-tier procurement, Level 2 for regulated and enterprise procurement, Level 3 for regulator-aligned and federal-adjacent relationships.

STAR Level 1: Self-Assessment

The provider completes a CAIQ (or publishes a CCM mapping) and lodges it in the STAR Registry. The Level 1 entry is free, the registry submission is the published artefact, and the buyer reads the answers against the provider responsibility. Level 1 is the entry assurance posture. Procurement teams that previously accepted no published artefact now treat the absence of a Level 1 entry as a procurement red flag.

STAR Level 2: Third-Party Certification or Attestation

STAR Certification is an ISO/IEC 27001 audit performed by an accredited certification body with the CCM layered on. STAR Attestation is an AICPA SOC 2 examination with the CCM layered on. Both are independent third-party assessments that read against the underlying regime (ISO 27001 or SOC 2) and the CCM control mapping at the same audit. Level 2 is the dominant enterprise assurance commitment; many enterprise RFPs name STAR Level 2 specifically.

STAR Level 3: Continuous Self-Assessment (STAR Continuous)

STAR Continuous is the continuous self-assessment programme that pairs with Level 1 or Level 2 to keep the assurance current. The provider commits to a published cadence (typically monthly or quarterly) for selected CCM control specifications, with structured evidence published per cycle. Level 3 is the most operationally demanding level and the one regulator-adjacent and federal-aligned buyers increasingly read against rather than annual audit alone.

STAR Level 1 vs Level 2 vs Level 3

The level comparison reads cleanly across five dimensions. The matrix below names what each level is built for, what the underlying assurance looks like, what the cost shape is, what the refresh cadence is, and how a buyer reads the registry entry against the responsibility split. Programmes deciding which level to operate use these dimensions to pin the level commitment to the deal and procurement cycle the assurance has to carry.

DimensionLevel 1 (Self-Assessment)Level 2 (Certification/Attestation)Level 3 (Continuous)
Audience the level is built forProcurement and vendor risk doing first-pass triage. Buyers asking for any published assurance before opening the security review. Sales engineering responding to procurement-only requirements.Enterprise procurement that requires independent assurance. Regulated buyers (financial services, healthcare, federal-adjacent) that need third-party-audited posture. Customer security questionnaire deflection.Regulator-aligned buyers that require continuous monitoring evidence. Federal-adjacent buyers that read continuous attestation as supporting evidence. Critical-vendor relationships where annual posture is insufficient.
Underlying assuranceSelf-assessment. The provider publishes a CAIQ or CCM mapping themselves. No third-party audit.Third-party audit. STAR Certification reads against ISO/IEC 27001 with CCM. STAR Attestation reads against SOC 2 Trust Services Criteria with CCM. Performed by accredited audit firms.Continuous self-assessment, typically paired with Level 1 or Level 2 underneath. The provider commits to a published cadence and submits structured evidence per cycle.
Cost shapeInternal effort to complete the CAIQ accurately and publish. No external audit cost. Repeatable cost when the CAIQ is refreshed.External audit cost (ISO 27001 certification cycle or SOC 2 Type II cycle). CCM scope addition is incremental on top of the underlying regime. Annual or biennial recurring depending on the audit cycle.Internal cadence cost. The published cadence drives the operating discipline; the cost is the continuous evidence operation rather than an external audit fee.
Refresh cadenceRefresh on a documented schedule (typically annual). Programmes increasingly refresh on major release, on material change to the security programme, or on regulator change.Tied to the underlying regime: ISO 27001 surveillance audits (annual) with a recertification audit (every three years), or SOC 2 Type II (typically annual examination period).Monthly or quarterly cadence as the provider commits to. The cadence itself is the assurance value; lapsed cadence erodes the Level 3 posture quickly.
Buyer-side readEntry signal. The buyer reads the answers against the responsibility split. Sufficient for low-tier vendors; flagged as insufficient for higher tiers.Independent assurance. The buyer reads the underlying audit report (ISO 27001 certificate, SOC 2 Type II report) and the CCM cross-walk against the trust criteria. Carries weight in regulator-adjacent reviews.Continuous assurance. The buyer reads the cadence and the per-cycle evidence. Carries weight where annual posture is insufficient (regulator-driven critical vendors, federal-adjacent buyers).

How buyers read STAR posture

Enterprise procurement, vendor risk teams, audit committees, regulator-aligned buyers, and the customer-side cloud security programme each read the STAR posture differently. The patterns below are the ones that recur across enterprise buyer-side practice.

  • Procurement reads the STAR Registry before the security questionnaire. Enterprise procurement and vendor risk teams that already filter the vendor longlist against the STAR Registry shorten the security review cycle. The registry entry covers the bulk of the questionnaire load; bespoke follow-ups are scoped to the residual.
  • Vendor risk teams pin the level to the contract tier. The vendor risk programme aligns the required STAR level to the contract tier: critical or regulated vendors need Level 2 or higher with an active registry entry; medium-tier vendors need Level 1; experimental vendors get a residual-risk-acceptance route with a documented expiry.
  • CISO and audit committee briefings cite STAR posture per critical vendor. The board-side cyber-risk briefing covers the third-party cyber posture, and STAR posture per critical vendor is the data point the briefing carries because it is independent, public, and verifiable.
  • Regulator-adjacent buyers (FFIEC, EBA, MAS TRM, APRA CPS 234, RBI, HKMA) read STAR posture as supporting evidence. STAR is not the regulator-issued assurance but is increasingly accepted as supporting evidence for the cloud-side third-party assurance the regulator expects.
  • STAR Level 3 (Continuous) reads as evidence of operating cadence rather than annual posture. Buyers that need confidence the provider has not let posture drift between audit cycles read Level 3 entries as the continuity signal.
  • STAR posture pairs with the customer-side cloud security programme rather than replacing it. The buyer-side programme runs cloud security posture management, cloud security assessment, cloud entitlement controls, and the customer-side CCM mapping against the workloads the buyer operates; STAR posture covers the provider side.

How providers operate the STAR posture

On the provider side, the STAR posture is part of the buyer-facing assurance the security and GRC functions operate against. The level commitment, the cadence, and the renewal cycle are programme decisions; the underlying record is the operating discipline already running.

  • Level 1 first. Most providers start with a CAIQ in the STAR Registry. The CAIQ is the published artefact the buyer reads; the underlying evidence pack lives in the provider workspace and feeds the answers. Programmes that publish a CAIQ without the underlying evidence land in follow-up cycles that ask for the evidence anyway.
  • Level 2 on the schedule the buyer cycle expects. Providers selling into enterprise increasingly need STAR Level 2 (Certification or Attestation) on the cadence the enterprise RFP cycle reads against. The ISO/IEC 27001 certification or the SOC 2 examination is the underlying regime; the CCM cross-walk is the layered addition that turns the audit into a STAR Level 2 assurance.
  • Level 3 (Continuous) for regulator-aligned and federal-adjacent buyers. STAR Continuous is the cadence-based discipline that demonstrates the assurance is operating rather than annual. Providers that publish the Level 3 cadence shorten the buyer-side residual-risk negotiation and reduce the bespoke security questionnaire load further.
  • The CCM scope decision drives the assessment cost. The STAR Level 2 scope reads against the CCM domains the provider operates: a single SaaS application typically reads against the full 17 domains, an infrastructure provider reads against a different cut, and a niche cloud service narrows the scope further. The scope decision is the largest cost driver for the Level 2 assessment.
  • The registry entry is a controlled artefact, not a one-off upload. Programmes that treat the registry entry as a controlled document with a named owner, a versioning trail, a review cadence, and a renewal cycle carry a durable Level 1 or Level 2 posture across leadership turnover. Programmes that treat the registry entry as a one-time procurement artefact let it expire and lose the buyer-side trust the registry was meant to carry.

Recurring failure modes the registry surfaces

STAR is forgiving on the underlying programme shape and on the specific tooling that backs the controls. It is unforgiving about a small number of patterns that make the registry entry cosmetic rather than substantive. The patterns below are the recurring ones that erode the buyer-side trust the registry was designed to carry.

  • Publishing a CAIQ without the underlying evidence pack. Programmes that complete the CAIQ at face value, without the supporting evidence (configuration baselines, audit logs, ISMS records, vulnerability scan output, incident records), end up answering the same questions in bespoke follow-ups when the buyer-side review pulls the evidence string. The CAIQ is the index; the evidence pack is the substance.
  • Treating STAR Level 1 as a substitute for Level 2 in enterprise sales. Enterprise procurement increasingly names STAR Level 2 specifically. A Level 1 entry without a path to Level 2 stalls the deal at the security review when the buyer cannot accept self-assessment for the contract tier. Programmes mapping the buyer-side level expectation to the deal stage avoid the stall.
  • Confusing STAR Certification and STAR Attestation. STAR Certification is the ISO/IEC 27001 audit with CCM. STAR Attestation is the SOC 2 examination with CCM. Programmes that name the wrong regime in buyer conversations or procurement responses lose credibility quickly because the buyer-side audit literacy is high in regulated sectors.
  • Letting the STAR Registry entry expire. The registry entry carries a validity period. Programmes that produce a STAR Level 1 or Level 2 entry once, then let it lapse, lose the buyer-side trust the registry was designed to carry. The renewal cadence is part of the assurance commitment.
  • Adopting STAR Level 3 without the operating discipline to sustain the cadence. Level 3 is the most operationally demanding level. Providers that announce a STAR Continuous cadence and then fail to publish the per-cycle evidence in the registry undermine the Level 3 posture and the broader trust the registry carries.
  • Treating STAR as a marketing artefact rather than a security operating commitment. STAR posture reads well against the buyer-side review when it pairs with an operating security programme (ISMS, vulnerability management, configuration baseline, incident response, evidence retention). STAR posture without the underlying operating record erodes quickly because the buyer-side reviewer or the third-party auditor will pull the evidence string and find the gap.

Operating cadence: from scope to a Level 2 entry

A defensible STAR programme runs as a continuous cycle rather than an annual submission. The cadence below names the steps that take a provider from cloud services without a published assurance to a STAR Level 1 entry, a Level 2 certification or attestation, and a Level 3 cadence the regulator-aligned buyer reads against. The cycle compounds: the per-cycle evidence carries from cycle to cycle, the CCM mapping refines as the cloud estate evolves, and the buyer-facing assurance reads consistently across releases.

  1. 1Scope the cloud services in scope of the STAR posture. The scope decision determines which CCM domains read against the provider responsibility and which read against the customer responsibility. Programmes that operate multiple cloud services typically maintain a STAR Registry entry per service or per service group, with the scope documented per entry.
  2. 2Complete the CAIQ accurately, with evidence references. Each CAIQ answer ties back to evidence in the underlying programme: the ISMS record (ISO 27001), the trust services criteria control (SOC 2), the configuration baseline (BAI10 in COBIT vocabulary), the scan output (vulnerability management), the incident response record, the encryption key management evidence, the access control record. The CAIQ is the index; the evidence pack is the substance.
  3. 3Publish the Level 1 entry in the STAR Registry. The registry submission goes through the CSA submission process; the published entry includes the CAIQ, the scope, and the validity period. The submission itself is a controlled document with a named owner.
  4. 4Schedule the Level 2 path on the cadence buyer demand requires. ISO/IEC 27001 certification reads against a three-year cycle with annual surveillance audits. SOC 2 Type II reads against the examination period (typically annual). The CCM cross-walk is the layered scope addition on top of the underlying audit; programmes plan the CCM scope and the CCM evidence pack so the audit firm reads consistently across the regime and the CCM.
  5. 5Operate the STAR Level 3 cadence if the buyer commitment requires it. The Level 3 cadence reads against the specific CCM control specifications the provider commits to monitor continuously. The cadence is published in the registry; the per-cycle evidence is submitted on the cadence. Programmes that adopt Level 3 typically pair it with the per-cycle internal operating record (configuration baseline checks, vulnerability scan output, access reviews, change records) so the cadence reads from the live programme rather than from a separate continuous-attestation workstream.
  6. 6Refresh the registry entries on the validity period. Every STAR Registry entry has a validity period. The renewal cadence is part of the programme commitment; programmes that miss a renewal lose the registry entry and the buyer-side trust the entry carried. The renewal cycle is tied to the underlying regime cycle (ISO 27001, SOC 2) where Level 2 is in play.

The STAR evidence pack

The STAR evidence pack reads well when it is built as a side effect of the operating work rather than reconstructed at submission time. The minimum set below maps to the artefacts the audit firm, the buyer-side reviewer, and the regulator each pull when they examine the STAR posture against the underlying programme. The same artefacts feed parallel reads under ISO/IEC 27001, SOC 2, NIST SP 800-53, FedRAMP, PCI DSS, HIPAA, and the regulator-aligned cloud regimes when the underlying record is structured.

  • The published STAR Registry entry per cloud service in scope, with the level, the validity period, the scope description, the named programme owner, the renewal cadence, and the cross-reference to the underlying assessment evidence (CAIQ for Level 1, ISO 27001 certificate or SOC 2 Type II report for Level 2).
  • The completed CAIQ v4 with the per-question evidence reference, the named CAIQ owner, the named CAIQ reviewer, the assessment date, and the version control trail. The CAIQ reads against the CCM control specifications; the evidence reference reads against the underlying programme record.
  • The CCM mapping to the customer-responsibility, provider-responsibility, shared-responsibility, and third-party-responsibility rows per CCM control specification per service. The shared-responsibility row carries the documented split between provider and customer for each shared control.
  • For STAR Level 2 Certification: the ISO/IEC 27001 certificate, the Statement of Applicability with the CCM cross-walk shown, the Annex A control evidence, the audit firm report, and the surveillance audit cycle record. The CCM cross-walk lives on the same record the ISO 27001 audit reads against.
  • For STAR Level 2 Attestation: the SOC 2 Type II report, the Trust Services Criteria control mapping with the CCM cross-walk shown, the period of audit, the audit firm opinion, and the trust criteria control evidence. The CCM cross-walk lives on the same record the SOC 2 examination reads against.
  • For STAR Level 3: the published cadence (monthly, quarterly), the per-cycle evidence package, the CCM control specifications under continuous monitoring, and the cadence renewal trail. The Level 3 evidence reads against the live operating programme rather than a separate continuous-attestation pipeline.
  • The operating programme evidence the CAIQ and the audit both read against: the ISMS records (policies, procedures, management review minutes), the vulnerability management cycle output, the configuration baseline per service, the access management records, the encryption key management evidence, the incident response records, the change management records, the training records, the third-party (sub-processor) management records, the document retention and disposal records.
  • The cross-walk pack to ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, SOC 2, NIST SP 800-53, FedRAMP, PCI DSS v4.0, HIPAA, NIST CSF 2.0, NIST SP 800-161, and the regulator-aligned cloud regimes (FFIEC, EBA, MAS TRM, APRA CPS 234, RBI, HKMA). One mapping satisfies multiple buyer-side reads.

What an auditor or buyer reads against

A STAR Level 2 assessment, a customer security questionnaire response, a vendor risk review, a regulator examination, or an audit committee briefing each read the STAR record against a small set of lenses. The lenses below are the shape the conversation takes; programmes that produce the evidence pack with these lenses in mind shorten the assurance cycle and reduce the bespoke follow-up to a manageable residual.

  • Coverage. Every cloud service in scope of the STAR posture is mapped against the relevant CCM domains, the CAIQ is complete with the per-question evidence reference, the responsibility split is documented per shared-responsibility row, and the level (1, 2, or 3) is consistent with the buyer-side commitment.
  • Continuity. The STAR Registry entries are within the validity period, the renewal cadence is documented, the Level 2 underlying audit cycle (ISO 27001 surveillance or SOC 2 examination) is current, and the Level 3 cadence (if claimed) has the per-cycle evidence published.
  • Decision durability. Risk acceptance, exceptions, and compensating controls against specific CCM control specifications are recorded with the named owner, the rationale, the expiry, and the review cadence. Decisions persist beyond the individual who made them.
  • Framework alignment. The CCM mapping cross-walks against ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, SOC 2 Trust Services Criteria, NIST SP 800-53, FedRAMP baselines, PCI DSS v4.0, HIPAA, NIST CSF 2.0, NIST SP 800-161 supply chain, and the regulator-aligned cloud regimes the provider sells into. The cross-walk is a single source of truth rather than parallel spreadsheets.
  • Defensibility under buyer-side scrutiny. The buyer-side review can pull the evidence string from a CAIQ answer to the CCM control specification to the underlying programme record (configuration baseline, scan output, incident record, access review, training record) without a multi-team excavation. The chain reads consistently across all CCM domains.

How STAR relates to adjacent assurance regimes

STAR is the cloud-specific assurance overlay; the underlying regimes carry the certifiable management system or the assurance examination. The relationships below are the ones cloud security programmes most often read together. Programmes that try to operate STAR in isolation rebuild the same evidence multiple times; programmes that thread STAR through the underlying regimes carry one evidence pack across several buyer-side and regulator-side reads.

STAR vs CSA Cloud Controls Matrix

The CCM is the control catalogue. STAR is the assurance overlay that operates on top of the CCM. A provider can map against the CCM internally without publishing in the STAR Registry, but the buyer-side trust signal requires the registry entry. Programmes that adopt the CCM as the control framework typically publish the STAR posture as the buyer-facing artefact the CCM mapping enables.

STAR Certification vs ISO/IEC 27001

ISO/IEC 27001 is the certifiable ISMS standard. STAR Certification is ISO/IEC 27001 audited by an accredited certification body with the CCM layered on at the same audit. Programmes already operating ISO/IEC 27001 typically add CCM scope and pursue STAR Certification rather than running a parallel cloud-security audit. The certification cycle, the surveillance cadence, and the recertification cycle are the same; the CCM scope is the incremental addition.

STAR Attestation vs SOC 2 Type II

SOC 2 Type II is the AICPA examination against the Trust Services Criteria. STAR Attestation is SOC 2 with the CCM layered on at the same examination. The Trust Services Criteria control mapping reads against the CCM cross-walk, with the audit firm report covering both lenses. Providers selling into US enterprise markets typically run SOC 2 Type II already; STAR Attestation is the buyer-facing addition that turns the SOC 2 report into a registry-published assurance.

STAR vs FedRAMP

FedRAMP is the US federal cloud authorisation programme that reads against NIST SP 800-53. STAR is the enterprise-side cloud assurance programme that reads against the CCM. The two are adjacent. Many providers selling into both federal and enterprise markets publish a FedRAMP authorisation and a STAR Level 2 registry entry from the same underlying security programme. The CCM cross-walks to NIST SP 800-53; the STAR Level 2 evidence pack reads against the federal-side cloud control evidence with the CCM mapping shown.

STAR vs ISO/IEC 27017 and ISO/IEC 27018

ISO/IEC 27017 is the cloud-specific extension to ISO 27002. ISO/IEC 27018 is the privacy extension for personal data in public cloud. STAR Certification reads against ISO/IEC 27001 with the CCM; the CCM cross-walks to both ISO/IEC 27017 and ISO/IEC 27018. Programmes already operating ISO 27017 and ISO 27018 typically present the CCM cross-walk in the STAR Level 2 evidence pack to show the alignment.

STAR vs sector-aligned cloud regimes

Several regulators reference STAR as supporting evidence for cloud-side third-party assurance: FFIEC and the regulator-issued guidance for US banking, EBA cloud outsourcing guidance for EU banking, MAS TRM for Singapore financial services, APRA CPS 234 for Australian financial services, RBI cyber-security framework for Indian banking, HKMA C-RAF for Hong Kong banking. STAR posture is not the regulator-issued assurance, but it is the cloud-side third-party assurance regulators increasingly read alongside the cloud provider attestations.

Where STAR sits next to other framework pages

STAR is one regime in a wider stack of cloud and management-system frameworks programmes read against. The pages below cover the adjacent regimes most cloud security programmes operate alongside STAR.

  • The CSA Cloud Controls Matrix framework page covers the underlying control catalogue STAR sits on. CCM is the framework; STAR is the assurance overlay; the CAIQ is the assessment companion.
  • The ISO/IEC 27001 framework page covers the certifiable ISMS standard. STAR Certification reads against ISO/IEC 27001 with the CCM layered on at the same audit.
  • The SOC 2 framework page covers the AICPA Trust Services Criteria. STAR Attestation reads against SOC 2 with the CCM layered on at the same examination.
  • The ISO/IEC 27017 framework page covers the cloud-specific extension to ISO 27002. CCM cross-walks to ISO/IEC 27017 explicitly; STAR Level 2 evidence often pairs the ISO 27001 certificate with the ISO 27017 extension.
  • The ISO/IEC 27018 framework page covers the privacy-extension for personal data in public cloud. CCM domain DSP cross-walks to ISO 27018; STAR Level 2 evidence for providers processing personal data in public cloud reads ISO 27018 alongside the ISO 27001 certification.
  • The FedRAMP framework page covers the US federal cloud authorisation programme. STAR and FedRAMP are adjacent; many providers publish both a FedRAMP authorisation (for federal customers) and a STAR Level 2 entry (for commercial enterprise customers) from the same underlying security programme.
  • The NIST SP 800-53 framework page covers the federal-side control catalogue underlying FedRAMP. CCM cross-walks to NIST SP 800-53 Rev. 5 directly; the cross-walk reads against the federal-side cloud-control evidence the STAR Level 2 evidence pack covers.
  • The NIST SP 800-161 framework page covers cybersecurity supply chain risk management. CCM domain STA (Supply Chain Management, Transparency, and Accountability) cross-walks to NIST SP 800-161; cloud providers running mature supply-chain programmes read the two together to evidence the cloud-side third-party obligations.
  • The Cloud Security Posture Management explainer covers the operational tool category for cloud-control enforcement. CSPM evidence (configuration baselines, drift detection, public exposure register) feeds the CCM IVS, CCC, and IAM domain evidence the STAR Level 2 audit and the STAR Level 3 cadence both read against.
  • The cloud security assessment guide covers the operational assessment cadence cloud security programmes run against the cloud estate. The assessment cadence feeds the CCM evidence pack the STAR posture publishes.

Where SecPortal fits in a STAR programme

SecPortal is the operating layer for the cloud-side security evidence the STAR posture reads against, not a STAR Registry submission engine, not a CAIQ auto-completion tool, and not a STAR Certification or STAR Attestation audit firm. The platform handles the workstreams that produce the underlying evidence the CAIQ references and the STAR Level 2 audit reads through: engagement structure for the per-cycle STAR posture work, finding intake from external scanning, authenticated DAST, code scanning, and pentest reads, severity scoring under CVSS 3.1, retest evidence paired to the original finding, exception register with named owner and expiry, document management for the CAIQ and the audit deliverables, and the activity log audit firms and buyer-side reviewers read against. The same workspace that hosts the engagement record hosts the scan-side evidence the CCM TVM, AIS, IVS, and LOG domains read against, so the line from artefact to CAIQ answer to the published STAR Registry entry stays traceable across cycles.

  • Compliance tracking that maps the same finding and the same control evidence across CSA CCM, ISO/IEC 27001 Annex A (for STAR Certification), SOC 2 Trust Services Criteria (for STAR Attestation), ISO/IEC 27017 cloud-specific obligations, ISO/IEC 27018 privacy-extension obligations, NIST SP 800-53 (for FedRAMP cross-walk), PCI DSS v4.0, HIPAA, and the regulator-aligned cloud regimes the provider sells into, so the cross-framework footprint reads from one record
  • Findings management with CVSS 3.1 severity, structured fields, and named owners so the cyber findings raised through external scanning, authenticated DAST, code scanning, and pentest reads feed the CCM TVM (Threat and Vulnerability Management) domain evidence the STAR Level 1 CAIQ and the Level 2 audit both read against
  • Engagement management dedicated to the per-cycle STAR posture work, with the scope decision, the CAIQ completion, the per-CCM-domain evidence collection, the Level 2 audit liaison, and the Level 3 cadence operation tracked as a structured workstream rather than as a one-off submission cycle
  • Document management for the CAIQ, the STAR Registry submission record, the ISO/IEC 27001 certificate and Statement of Applicability, the SOC 2 Type II report, the CCM cross-walk to ISO/IEC 27017, ISO/IEC 27018, SOC 2, NIST SP 800-53, FedRAMP, PCI DSS, and HIPAA, and the per-cycle Level 3 evidence packages
  • Activity log with CSV export capturing every state change to a finding, a control mapping, a CAIQ answer revision, a CCM domain owner assignment, an exception decision, or an evidence document version, with timestamp and named user, so the trail is reproducible without a multi-team excavation when the audit firm or the buyer-side review pulls the evidence string
  • External, authenticated, and code scanning landing into the same finding record so the CCM AIS (Application and Interface Security), IVS (Infrastructure and Virtualization Security), and TVM domain evidence reads consistently across surfaces rather than as parallel data silos the STAR Level 2 audit then has to reconcile
  • Encrypted credential storage (AES-256-GCM) so the credentials authenticated scanning uses against cloud-hosted applications meet the CCM CEK (Cryptography, Encryption, and Key Management) expectations for the testing surface rather than introducing a control gap inside the assessment workflow
  • Repository connections via GitHub, GitLab, and Bitbucket OAuth so the AIS code-side evidence reads from the same source-control record the engineering function operates against, with the build provenance the buyer-side and the STAR Level 2 audit both expect
  • Continuous monitoring with daily, weekly, biweekly, and monthly scan schedules so the CCM LOG (Logging and Monitoring) and TVM domain evidence covers the cadence STAR Level 3 (Continuous) reads against rather than reconstructing it per cycle
  • Compliance tracking with the CCM domain set covered alongside ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, SOC 2, NIST SP 800-53, FedRAMP, PCI DSS, HIPAA, NIST CSF 2.0, NIST SP 800-161, and regulator-aligned cloud regimes so the cross-walk lives on one record rather than parallel spreadsheets the audit firm or the buyer-side review then has to reconcile manually
  • Team management with role-based access so the named CAIQ owner, the named CCM domain owners, the audit firm liaison, the STAR Registry submission owner, the Level 3 cadence operator, and the GRC reviewer each have the right permissions, and the access decisions read into the activity log
  • AI report generation that turns the CCM evidence and the per-cycle operating record into a buyer-facing STAR-shaped summary or a board-ready third-party-risk briefing without manual rewriting at each cycle
  • MFA enforcement (TOTP) on the SecPortal workspace itself so the IAM (Identity and Access Management) discipline the CCM expects from the provider security programme is not undermined at the platform that holds the assurance evidence

What SecPortal does not do

The STAR programme is a publishing and certification regime that depends on the provider operating the underlying programme well. SecPortal is the operating record, not the certifying body, not the registry, and not the customer-facing trust portal. The honest scope below reads against the STAR boundary so the platform commitment is unambiguous.

  • SecPortal does not generate STAR Registry submissions automatically. The registry submission is a workspace decision routed through the CSA submission process; the platform holds the evidence pack the submission references.
  • SecPortal does not maintain a directory of accredited STAR Certification or STAR Attestation audit firms. The audit firm relationship is a workspace decision; the platform holds the audit liaison record, the engagement documentation, and the evidence the audit firm reads against.
  • SecPortal does not auto-complete the CAIQ from underlying evidence. The CAIQ is the assessment answer the provider commits to; the platform holds the CCM evidence the CAIQ answer references and the per-domain owner record, but the CAIQ completion is a workspace decision.
  • SecPortal does not perform third-party STAR audits. STAR Certification reads against an accredited ISO/IEC 27001 certification body. STAR Attestation reads against a licensed CPA firm. SecPortal is the operating record, not the audit firm.
  • SecPortal does not push STAR posture to Jira, ServiceNow, Slack, PagerDuty, SIEM, or SOAR. The STAR posture is held on the workspace record; alerts and ticketing run through the workspace policy and the named escalation paths rather than a built-in connector.
  • SecPortal does not run a managed STAR Continuous cadence service. The Level 3 cadence is a provider commitment that the workspace records and that the underlying programme (vulnerability management, configuration baseline, access reviews) operates against; the platform holds the per-cycle evidence rather than running an autonomous attestation engine.
  • SecPortal does not maintain an external trust portal that publishes STAR posture to customers automatically. Customer-facing trust pages, vendor security review portals, and procurement portals are downstream of the STAR posture; the platform holds the underlying record the trust page reads against.

The day-to-day cloud security operating work is where the CCM evidence the STAR Level 1 CAIQ and the Level 2 audit both read against gets produced. The cloud security assessment workflow covers the per-cycle cloud security examination that produces the CCM-domain finding evidence. The control mapping crosswalks workflow keeps the CCM mapping readable under ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, SOC 2, NIST SP 800-53, FedRAMP, PCI DSS, HIPAA, and the regulator-aligned cloud regimes from one underlying record. The vendor security questionnaire response workflow covers the buyer-side questionnaire load the published STAR posture deflects. The audit evidence retention workflow covers the retention and disposal discipline the CAIQ evidence pack and the Level 2 audit record both read against.

For cloud security teams carrying the per-cycle STAR posture work, the cloud security teams workspace bundles the platform with the engagement structure the buyer-side review reads against. For the GRC function that owns the cross-framework evidence pack and the STAR submission cycle, the GRC and compliance teams workspace covers the audit firm liaison and the cross-walk record. For CISOs and security leaders carrying the board-side third-party-risk cadence, the CISOs and security leaders workspace covers the audit committee read against the third-party assurance posture per critical vendor.

For deeper reading on the disciplines this assurance regime supports, the cloud security assessment guide covers the operational cloud security examination cadence the CCM evidence pack reads against. The third-party vendor risk assessment guide covers the buyer-side third-party risk discipline that reads the STAR Registry as the provider-side assurance signal. The cloud security posture management explainer covers the operational tool category whose evidence feeds the CCM IVS, CCC, IAM, and LOG domain reads the STAR Level 3 cadence depends on. The board-level security reporting guide covers the cadence and structure the audit committee read against third-party-risk posture per critical vendor follows.

Key control areas

SecPortal helps you track and manage compliance across these domains.

The CSA STAR programme: framework, questionnaire, registry, levels

CSA STAR is a four-part programme buyers and regulators read together. The CSA Cloud Controls Matrix (CCM) is the control catalogue. The Consensus Assessments Initiative Questionnaire (CAIQ) is the assessment companion that reads against the CCM. STAR is the publishing and certification regime where the assurance evidence lands. The public STAR Registry is the searchable index buyers and procurement teams use to read provider posture before they open the bespoke security review.

STAR Level 1: Self-Assessment

STAR Level 1 is self-assessment. The provider completes a CAIQ (or publishes a CCM mapping) and lodges it in the STAR Registry. The submission is free, the registry entry is the published artefact, and the buyer-side review reads the answers against the responsibility split. Level 1 is the entry assurance posture; procurement teams that previously accepted no published artefact now flag the absence of a Level 1 entry as a red flag.

STAR Level 2: Third-Party Certification or Attestation

STAR Level 2 is third-party assessment. STAR Certification is an ISO/IEC 27001 audit performed by an accredited certification body with the CCM layered on at the same audit. STAR Attestation is an AICPA SOC 2 examination with the CCM layered on. Both are independent third-party assessments that read against the underlying regime and the CCM control mapping. Level 2 is the dominant enterprise assurance commitment; many enterprise RFPs name STAR Level 2 specifically.

STAR Level 3: Continuous Self-Assessment (STAR Continuous)

STAR Level 3 is the continuous self-assessment programme that pairs with Level 1 or Level 2 to keep the assurance current. The provider commits to a published cadence (typically monthly or quarterly) for selected CCM control specifications, with structured evidence published per cycle. Level 3 is the most operationally demanding level and the one regulator-aligned and federal-adjacent buyers increasingly read against rather than annual audit cycles alone.

The level-vs-level matrix: audience, assurance, cost, cadence

The level comparison reads cleanly across five dimensions. Level 1 is entry-tier self-assessment with no third-party audit, an internal-effort cost, and a self-set refresh cadence. Level 2 is third-party-audited assurance with an external audit cost tied to the underlying regime (ISO 27001 surveillance cycle or SOC 2 Type II examination period) and a renewal cadence tied to the audit cycle. Level 3 is internal continuous assurance with the published cadence as the assurance value and the cost shape sitting in the operating discipline rather than the external audit fee.

How buyers read STAR posture during procurement and vendor risk

Enterprise procurement and vendor risk teams that filter the vendor longlist against the STAR Registry shorten the security review cycle: the registry entry covers the bulk of the questionnaire load, and bespoke follow-ups are scoped to the residual. Vendor risk programmes pin the required STAR level to the contract tier (Level 1 for medium-tier, Level 2 for enterprise and regulated, Level 3 for regulator-aligned critical). CISO and audit-committee briefings cite STAR posture per critical vendor because the signal is independent, public, and verifiable.

How providers operate the STAR posture across the assurance cycle

Most providers start with a CAIQ at Level 1. Providers selling into enterprise add Level 2 (Certification or Attestation) on the cadence the buyer cycle expects. Providers selling into regulator-aligned and federal-adjacent buyers add Level 3 (Continuous). The CCM scope decision drives the assessment cost; the STAR Registry entry is a controlled artefact with a named owner, a versioning trail, a review cadence, and a renewal cycle rather than a one-off submission.

STAR posture failure modes that erode buyer-side trust

Common failure modes: publishing a CAIQ without the underlying evidence pack so follow-up cycles pull the evidence string anyway; treating Level 1 as a substitute for Level 2 in enterprise sales where procurement names Level 2 specifically; confusing STAR Certification (ISO 27001 with CCM) with STAR Attestation (SOC 2 with CCM); letting the STAR Registry entry expire; adopting Level 3 (Continuous) without the operating discipline to sustain the cadence; and treating STAR as a marketing artefact rather than a security operating commitment.

The STAR evidence pack across Level 1, Level 2, and Level 3

A defensible STAR evidence pack covers the published registry entry per service, the completed CAIQ v4 with per-question evidence references, the CCM mapping with documented responsibility splits, the underlying audit evidence for Level 2 (ISO/IEC 27001 certificate plus Statement of Applicability with CCM cross-walk for Certification; SOC 2 Type II report with CCM cross-walk for Attestation), the published cadence and per-cycle evidence for Level 3, the operating programme records the CAIQ and audit both read against (ISMS records, vulnerability management cycle output, configuration baselines, access management, incident records, change records, training records, sub-processor records), and the cross-walk pack to ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, SOC 2, NIST SP 800-53, FedRAMP, PCI DSS v4.0, HIPAA, NIST CSF 2.0, and NIST SP 800-161.

STAR cross-walk to ISO/IEC 27001, SOC 2, FedRAMP, and ISO/IEC 27017/27018

STAR Certification reads against ISO/IEC 27001 with the CCM; the certification cycle, the surveillance cadence, and the recertification cycle are the same with the CCM as the incremental scope addition. STAR Attestation reads against SOC 2 Type II with the CCM at the same examination. FedRAMP is the US federal cloud authorisation programme that reads against NIST SP 800-53; many providers publish both a FedRAMP authorisation (for federal customers) and a STAR Level 2 entry (for commercial enterprise customers). ISO/IEC 27017 and ISO/IEC 27018 are cloud-specific and privacy-extension standards CCM cross-walks to explicitly.

STAR as supporting evidence for regulator-aligned cloud regimes

Several regulators reference CSA STAR as supporting evidence for cloud-side third-party assurance: FFIEC for US banking, EBA cloud outsourcing guidance for EU banking, MAS TRM for Singapore financial services, APRA CPS 234 for Australian financial services, RBI for Indian banking, HKMA C-RAF for Hong Kong banking. STAR posture is not the regulator-issued assurance; it is the cloud-side third-party assurance regulators increasingly read alongside the cloud provider attestations and the customer-side cloud security programme evidence.

The buyer-side audit lens: coverage, continuity, decisions, alignment, defensibility

STAR Level 2 assessments, customer security questionnaires, vendor risk reviews, regulator examinations, and audit-committee briefings read the STAR record against five lenses. Coverage: every cloud service in scope is mapped against the relevant CCM domains, the CAIQ is complete with per-question evidence references, and the responsibility split is documented per shared row. Continuity: the registry entries are current, the Level 2 underlying audit cycle is current, and the Level 3 cadence has the per-cycle evidence published. Decision durability: exception decisions persist with named owners, rationales, expiries, and review cadences. Framework alignment: the CCM cross-walks live on one record. Defensibility: the buyer-side review can pull the evidence string from a CAIQ answer to the CCM control specification to the underlying programme record without a multi-team excavation.

Related features

Compliance tracking without a full GRC platform

Vulnerability management software that tracks every finding

Orchestrate every security engagement from start to finish

Document management for every security engagement

Every action recorded across the workspace

Collaborate across your entire team

Monitor continuously catch regressions early

Test web apps behind the login

Vulnerability scanning tools that map your attack surface

Find vulnerabilities before they ship

Multi-factor authentication on every workspace

AI-powered reports in seconds, not days

Hold the CCM evidence the STAR registry reads against on one workspace

Run the per-cycle CCM evidence pack, the CAIQ companion record, the STAR Level 2 audit liaison, and the STAR Level 3 cadence on one operating workspace. Carry the same record into ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, SOC 2, NIST SP 800-53, FedRAMP, PCI DSS, HIPAA, and the regulator-aligned cloud regimes without rebuilding the evidence pack. Start free.

Get Started Free

No credit card required. Free plan available forever.