What Does a CSA2 Audit Cover?
Alexander Sverdlov
Security Analyst
💫 Key Takeaways
- CSA STAR Level 2 audits evaluate your controls against all 17 domains of the Cloud Controls Matrix (CCM) v4
- The audit is conducted as an extension of either SOC 2 (Attestation) or ISO 27001 (Certification)
- Auditors review policies, technical configurations, evidence artifacts, and interviews with your team
- A typical Level 2 audit takes 5-15 days of on-site or remote fieldwork, depending on scope
- The most common findings involve identity management, change control, and logging gaps
- You will need involvement from security, engineering, DevOps, HR, and executive leadership
I have guided dozens of organizations through CSA STAR Level 2 audits, and the question I hear most often during the kickoff call is always some variation of: “So what exactly are they going to look at?”
It is a fair question. The Cloud Controls Matrix has 197 control specifications across 17 domains, and the prospect of an auditor methodically working through all of them can feel overwhelming. But once you understand the structure, the process becomes much more manageable - and honestly, most organizations find fewer surprises than they expected.
Let me walk you through exactly what a CSA2 audit covers, domain by domain, day by day, and person by person.
The Framework
All 17 CCM v4 Control Domains Explained
The Cloud Controls Matrix version 4 organizes security controls into 17 domains. Each domain contains multiple control specifications that the auditor will evaluate. Here is what each domain covers and why it matters:
| # | Domain | What Auditors Examine |
|---|---|---|
| 1 | Audit & Assurance (A&A) | Internal audit programs, audit planning, independent assessments, compliance monitoring |
| 2 | Application & Interface Security (AIS) | Secure SDLC, API security, application vulnerability management, security testing |
| 3 | Business Continuity & Operational Resilience (BCR) | BC/DR plans, RTOs/RPOs, backup strategies, resilience testing |
| 4 | Change Control & Configuration Management (CCC) | Change management processes, configuration baselines, unauthorized change detection |
| 5 | Cryptography, Encryption & Key Mgmt (CEK) | Encryption at rest and in transit, key lifecycle management, cryptographic standards |
| 6 | Datacenter Security (DCS) | Physical security controls, environmental protections, asset management |
| 7 | Data Security & Privacy Lifecycle Mgmt (DSP) | Data classification, data flow mapping, privacy controls, data retention and deletion |
| 8 | Governance, Risk & Compliance (GRC) | Risk management framework, policy governance, regulatory compliance tracking |
| 9 | Human Resources Security (HRS) | Background checks, security training, acceptable use policies, offboarding procedures |
| 10 | Identity & Access Management (IAM) | Access provisioning, MFA, privileged access management, access reviews |
| 11 | Interoperability & Portability (IPY) | Data portability, API standards, vendor lock-in avoidance |
| 12 | Infrastructure & Virtualization Security (IVS) | Network segmentation, virtualization hardening, cloud infrastructure configurations |
| 13 | Logging & Monitoring (LOG) | Security logging, log integrity, monitoring alerting, SIEM configuration, log retention |
| 14 | Security Incident Mgmt, E-Discovery & Forensics (SEF) | Incident response plans, breach notification procedures, forensic capabilities |
| 15 | Supply Chain Management, Transparency & Accountability (STA) | Third-party risk management, vendor assessments, supply chain security |
| 16 | Threat & Vulnerability Management (TVM) | Vulnerability scanning, penetration testing, threat intelligence, patch management |
| 17 | Universal Endpoint Management (UEM) | Endpoint security, mobile device management, endpoint detection and response |
Not all 17 domains carry equal weight in every audit. The auditor will scope the assessment based on your service model (IaaS, PaaS, SaaS), your infrastructure architecture, and the shared responsibility model with your cloud provider. If you are a pure SaaS company running on AWS, for instance, the Datacenter Security (DCS) domain will be largely addressed by your cloud provider’s certifications, while Identity & Access Management (IAM) and Application Security (AIS) will be heavily scrutinized.
Auditor Perspective
What Auditors Actually Look For
Understanding the auditor’s mindset is half the battle. They are not trying to catch you out - they are trying to determine whether your controls are (a) designed effectively and (b) operating as intended over the review period. For each control specification, the auditor evaluates three things:
1. Policy and documentation. Is there a formal, approved policy that addresses this control? Is it current, communicated to relevant personnel, and reviewed at least annually?
2. Implementation evidence. Can you demonstrate that the policy is actually implemented? This means screenshots, configuration exports, system logs, or tool outputs that show the control is in place - not just written down.
3. Operating effectiveness. Has the control been functioning consistently over the review period? The auditor will sample evidence from multiple points in time to verify that the control was not just implemented for the audit but has been operating continuously.
What Trips Companies Up
The most common audit finding I see is not a missing control - it is a control that exists on paper but is not consistently followed. For example: you have an access review policy requiring quarterly reviews, but the last review was seven months ago. Or you have a change management process documented, but your git history shows multiple production deployments that bypassed the approval workflow. Auditors are very good at spotting these gaps between policy and practice.
Evidence Guide
Evidence Requirements: What to Prepare
The evidence request list for a CSA2 audit is substantial. Here is a representative breakdown of what auditors typically request across the most scrutinized domains:
| Domain | Typical Evidence Requested |
|---|---|
| IAM | User access lists, MFA configuration screenshots, privileged account inventory, access review records, onboarding/offboarding tickets |
| CCC | Change management tickets (sample of 25+), approval workflows, rollback procedures, emergency change records |
| LOG | SIEM dashboard screenshots, log retention configuration, alerting rules, sample incident alerts, log integrity controls |
| CEK | Encryption configuration for databases and storage, TLS certificate inventory, key rotation schedules, KMS policies |
| AIS | SDLC documentation, code review records, SAST/DAST scan results, penetration test reports, vulnerability remediation tracking |
| DSP | Data classification policy, data flow diagrams, privacy impact assessments, data retention schedules, deletion procedures |
| HRS | Security awareness training records, background check policy, acceptable use policy acknowledgments, offboarding checklists |
A well-prepared organization will have 80-150 evidence artifacts ready before the audit begins. This sounds daunting, but most of this evidence already exists in your systems - it just needs to be collected, organized, and mapped to the CCM controls. This is where readiness consulting pays for itself: a good consultant will provide you with a complete evidence request list mapped to your specific scope months before the auditor arrives.
The Process
How the Audit Works: Day by Day
While every audit is different, here is a typical timeline for a mid-sized SaaS organization going through a CSA STAR Level 2 Certification (ISO 27001 path) audit:
Pre-Audit (4-8 weeks before): The audit firm provides a formal evidence request list. You collect and upload evidence to a shared secure repository. The lead auditor reviews documentation and prepares their testing plan. Any obvious gaps are flagged early so you can address them before fieldwork begins.
Day 1 - Opening Meeting & Management Review: The auditor meets with executive leadership and the security team lead. They confirm audit scope, review organizational context, and discuss any significant changes since the last audit (or since readiness assessment). They typically begin with GRC, A&A, and HRS domains - the governance layer.
Days 2-3 - Technical Deep Dive: The auditor works with your engineering and DevOps teams to review technical controls. This covers IAM, CEK, IVS, LOG, AIS, and CCC. Expect live walkthroughs of your cloud console, CI/CD pipelines, monitoring dashboards, and access management systems. The auditor will ask to see specific configurations in real time.
Days 4-5 - Data, Privacy, and Operations: Focus shifts to DSP, BCR, SEF, TVM, STA, and UEM. The auditor reviews data handling practices, backup and recovery procedures, incident response plans, vulnerability management processes, and third-party risk management. They will interview team members responsible for each area.
Days 6-7 - Follow-up Testing & Sampling: The auditor conducts additional testing on any areas where initial evidence was insufficient. They pull samples from change management tickets, access review logs, and incident records to verify operating effectiveness over time.
Day 8 - Closing Meeting: The lead auditor presents preliminary findings, including any nonconformities (major or minor) and observations. You have an opportunity to discuss findings and provide additional evidence before the final report is issued. The final report typically arrives 4-6 weeks after fieldwork.
Duration Varies
The 8-day timeline above is representative for a mid-sized SaaS company with 50-200 employees. Smaller organizations may complete fieldwork in 5 days; larger or more complex environments (multi-cloud, multiple data centers, complex data processing) may require 10-15 days. Your audit firm will provide a detailed schedule during the planning phase.
Your Team
Who Needs to Be Involved
A CSA2 audit is not just a security team exercise. You will need availability from multiple functions:
| Role | Domains Involved | Time Commitment |
|---|---|---|
| CISO / Security Lead | All domains - primary audit liaison | Full audit duration |
| CTO / VP Engineering | AIS, CCC, IVS, LOG | 2-3 days |
| DevOps / Platform Engineer | IVS, CCC, LOG, CEK | 2-3 days |
| HR Manager | HRS | Half day |
| CEO / COO | GRC, BCR (opening/closing meetings) | Half day |
| DPO / Privacy Officer | DSP, GRC | 1 day |
The key is to brief all participants before the audit. People who have never been through a security audit often worry about saying the wrong thing. Reassure them: the auditor wants honest answers. If a control is not fully implemented, it is better to say so than to improvise an answer that does not hold up under follow-up questions.
Lessons Learned
Most Common Audit Findings
After guiding numerous organizations through CSA2 audits, I have seen certain findings appear repeatedly. Addressing these proactively during your readiness phase will dramatically smooth the audit:
Incomplete access reviews. Policy says quarterly; reality is ad hoc. Auditors will pull your access review records and cross-reference dates. Set up calendar reminders and keep documented evidence of every review cycle.
Change management bypasses. Emergency changes deployed without following the documented approval process. Have a formal emergency change procedure and make sure emergency changes are retrospectively documented and approved.
Logging gaps. Not all critical systems are sending logs to your SIEM, or log retention does not meet policy requirements. Audit your log sources before the auditor does.
Stale accounts. Former employees or contractors with active accounts discovered during the audit. Run an access reconciliation before fieldwork begins.
Missing encryption. Data at rest encryption not enabled on all datastores, or TLS certificates expired or using deprecated protocols. Audit your encryption posture proactively.
Incomplete vendor assessments. Third-party risk management policy exists but vendor risk assessments are not current or do not cover all critical vendors. Identify your critical vendors and ensure assessments are up to date before the audit.
Scope Overlap
How CSA2 Relates to SOC 2 and ISO 27001 Audit Scopes
If you already hold SOC 2 or ISO 27001, a significant portion of the CSA2 audit scope will be familiar. Here is how they overlap:
ISO 27001 overlap: Approximately 70-80% of CCM controls map directly to ISO 27001 Annex A controls. If you have a mature ISMS, the incremental effort for CSA STAR Certification focuses on cloud-specific controls that go beyond what ISO 27001 covers - particularly in areas like multi-tenancy, virtualization security, data portability, and cloud-specific identity management.
SOC 2 overlap: The SOC 2 Trust Services Criteria (Security, Availability, Confidentiality, Processing Integrity, Privacy) align with roughly 60-70% of CCM domains. The CSA STAR Attestation audit extends the SOC 2 examination with CCM-specific testing, adding depth in areas like interoperability, supply chain security, and cloud infrastructure controls.
The net result: If you have one or both of these certifications, your CSA2 preparation is primarily about filling the cloud-specific gaps and aligning your existing evidence with CCM control specifications. You are not starting from zero - you are extending what you already have.
FAQ
Frequently Asked Questions
How many evidence artifacts should we prepare?
For a typical mid-sized SaaS organization, expect to prepare 80-150 evidence artifacts. This includes policy documents, configuration screenshots, log samples, training records, access review documentation, change management tickets, and more. A readiness consultant can provide you with a precise evidence request list mapped to your specific scope and CCM domains.
What happens if the auditor finds a major nonconformity?
A major nonconformity means a control is either missing or fundamentally ineffective. For the ISO 27001 path, you typically have 90 days to remediate the finding and provide evidence of correction before the certification can be issued. For the SOC 2 path, the finding will be reported as an exception in the audit report. This is why readiness assessments are critical - you want to find and fix these issues before the audit, not during it.
Can the audit be conducted remotely?
Yes. Since the COVID era, remote audits have become standard practice for cloud-native organizations. The auditor will conduct interviews via video conference and review evidence through a secure shared repository. For cloud-native companies with no physical data centers, a fully remote audit is completely normal. Some auditors may request a brief on-site visit for larger organizations, but this is increasingly optional.
Do we need to audit controls our cloud provider is responsible for?
No. The CCM is designed around the shared responsibility model. Controls that fall entirely within your cloud provider’s responsibility (such as physical datacenter security for AWS, Azure, or GCP) are typically addressed by referencing your provider’s own CSA STAR listing, SOC 2 report, or ISO 27001 certificate. However, you are responsible for demonstrating that you have reviewed and rely on these provider certifications as part of your own supply chain management.
Should we choose the SOC 2 path or the ISO 27001 path for Level 2?
It depends on your market. If you primarily serve US-based customers, the SOC 2 path (CSA STAR Attestation) may be more valuable since SOC 2 is the dominant standard in North America. If you serve European or global customers, the ISO 27001 path (CSA STAR Certification) is generally preferred since ISO 27001 is the global standard and is specifically referenced in EU regulations like NIS2. If you serve both markets, consider pursuing both paths or starting with ISO 27001 + CSA STAR, which tends to have broader international recognition.
How often do we need to be re-audited?
For the ISO 27001 path, the certification cycle is three years with annual surveillance audits (lighter-touch audits in years two and three). For the SOC 2 path, you typically need a new examination each year covering the most recent 12-month period. In both cases, maintaining the certification requires ongoing effort - it is not something you achieve once and forget.
Published: March 2026 · Author: Alexander Sverdlov
This article is for informational purposes only and does not constitute legal or professional advice. CSA STAR audit scope and requirements may vary based on your organization’s specific context, service model, and chosen audit path. Contact us for a tailored readiness assessment.
Alexander Sverdlov
Founder of Atlant Security. Author of 2 information security books, cybersecurity speaker at the largest cybersecurity conferences in Asia and a United Nations conference panelist. Former Microsoft security consulting team member, external cybersecurity consultant at the Emirates Nuclear Energy Corporation.