ISO 27017 vs CSA STAR: what hands-on cloud assessments actually find
Amara OkaforApril 29, 2026
Key takeaways
ISO 27017 certification audits review documentation and sampled evidence — they do not test whether cloud controls are working. Organizations can pass an audit with CloudTrail logging disabled and overprivileged serverless execution roles in production.
CSA STAR self-assessment, the most commonly used assurance level, is completed by the organization itself with no external validation. It should not be treated as equivalent to third-party certification when evaluating cloud vendor security posture.
The shared responsibility matrix required by ISO 27017 section 6.1.3 is the most consistently under-implemented control. Most organizations have a generic template; few have one that reflects their actual cloud architecture and has been tested against a real incident scenario.
Serverless functions fall outside the scope of malware protection and access control assessments in the majority of ISO 27017 implementations. Functions with overprivileged execution roles represent a lateral movement vector that standard audit processes do not surface.
A cloud security gap analysis that relies only on ISO 27017 or CSA STAR evidence will miss assets that were never declared to the compliance program. Active discovery before scoping is not optional — it determines whether the assessment is measuring the real environment.
TL;DR
ISO 27017 and CSA STAR are both legitimate cloud security frameworks. Neither one will find what attackers find. ISO 27017 measures whether your documented controls are implemented consistently. CSA STAR, at the self-assessment level that most organizations use, measures whether you believe your controls are implemented. What both miss is the gap between documented scope and actual cloud infrastructure — and that gap is where most real cloud incidents happen.
The audit that passed and the environment that did not
A SaaS company, around 180 employees, completed an ISO 27017 gap assessment as part of their enterprise sales process. The auditor reviewed their shared responsibility documentation, sampled their access control evidence, confirmed CloudTrail was enabled, and noted that malware protection was in place across their EC2 fleet. The assessment closed clean. Four months later, a routine external review found an AWS Lambda function with an execution role that had S3:GetObject and S3:PutObject permissions across every bucket in the account. The function had been deployed by the dev team to handle file processing. It had never been reviewed in an access control audit because nobody had mapped it to the ISO 27017 control scope. The execution role had been broad because it was faster to write that way. It had been that way for 14 months.
The auditor did not miss anything they were supposed to check. Serverless functions were simply not in the scope definition that the organization submitted. The control coverage looked complete on paper because the scope document said it was complete. The Lambda function was real infrastructure. It just was not in any document the auditor had seen.
What ISO 27017 actually requires versus what auditors check
ISO 27017 adds cloud-specific guidance to the ISO 27002 control set. The 37 additional controls cover areas that general information security management does not address: shared responsibility documentation, virtual machine hardening, cloud service monitoring, multi-tenant isolation, and customer data handling by cloud service providers. The standard is structured to apply to both cloud service providers and cloud service customers, with different obligations depending on which side of the relationship you are on.
What auditors typically validate: that documented controls exist, that a sample of evidence supports the documentation, and that the shared responsibility matrix has been completed. What they do not typically do is run an active scan of the cloud environment, verify that logging is intact and tamper-resistant, test isolation between tenant environments, or check whether the asset inventory submitted for scoping matches the actual cloud footprint.
The standard does not require auditors to do any of those things. ISO 27017 is a documentation-and-evidence standard. The evidence standard is satisfied by paperwork that reflects a point in time. If the environment changes between audits — a new cloud account, a new serverless deployment, a new SaaS integration — the evidence does not update automatically.
The result is that organizations can hold a current ISO 27017 certification against a cloud environment that looks meaningfully different from the one the auditor reviewed. This is not a failure of the audit process. It is a limitation of what a documentation audit can certify.
Example
In one healthcare client assessment, ISO 27017 section 8.1.5 required documented incident response procedures for cloud-specific scenarios. The documentation existed and covered account hijacking and data exfiltration. What it did not cover was multi-tenant isolation failure — a scenario where a misconfiguration in the shared environment could expose one tenant's data to another. The auditor approved the incident response documentation because it was complete against the scenarios listed. The missing scenario was not listed anywhere in the control evidence. It was not a gap the auditor was looking for.
ISO 27017 control A.8.1.12 requires protection against malware in cloud environments. The standard does not define what counts as a cloud environment for this purpose. Most organizations interpret it to mean EC2 instances and containers, which already have EDR tooling deployed. Lambda functions, ECS tasks running in serverless mode, and AWS Batch workloads typically fall outside this interpretation by default — not by deliberate decision, but because nobody extended the scope definition when those services were adopted.
What CSA STAR is and what the assurance levels actually mean
CSA STAR is an assurance program, not a single standard. It is built around the Cloud Controls Matrix, a spreadsheet-format control framework covering 197 controls across 17 security domains. The domains include application security, audit assurance, business continuity, change control, data security, datacenter security, encryption, governance, human resources, identity and access management, infrastructure, interoperability, mobile security, supply chain, threat intelligence, and universal endpoint management.
The three assurance levels work as follows. Level 1 is self-assessment — the organization completes a Consensus Assessments Initiative Questionnaire against the CCM and publishes the results in the CSA STAR registry. No external validation. Level 2 is third-party certification, combining the CCM assessment with either an ISO 27001 audit or a SOC 2 examination. Level 3 is continuous monitoring, which is still emerging as a market offering and is not widely adopted.
The majority of CSA STAR entries in the registry are Level 1. When a cloud vendor points to their CSA STAR listing as evidence of security posture, the first question should be which level. A Level 1 entry means the vendor filled out a questionnaire themselves. It is useful as a starting point for due diligence conversations. It is not an independent verification of anything.
Example
In digital footprint assessments involving cloud vendors that clients had vetted using CSA STAR registry entries, we have consistently found that the CCM self-assessment reflected intended configuration rather than actual configuration. Vendors had answered questions based on their security architecture documentation. The running environment contained deviations from that documentation that had accumulated over time — unused firewall rules left open, deprecated API versions still active, overprivileged service accounts that predated a role restructure. None of those deviations would appear in a self-completed questionnaire.
CSA CCM control IAM-02 requires identification, classification, and documentation of cloud service customer and provider identities. In practice, the control is satisfied by documenting that an identity management process exists. It does not require enumeration of actual identities or validation that dormant accounts have been deprovisioned. In our assessments, over 68 percent of IAM permissions in client environments were assigned to roles or accounts that had not been used in the prior 90 days — a consistent finding regardless of whether the organization had a CSA STAR entry or an ISO 27017 certification.
What the assessments find that the frameworks do not
Assessment base: Vulnox assessment data, 2024-2025, cloud security and compliance engagements
Serverless functions are systematically excluded from cloud security control scope
In cloud security assessments where the client held or was pursuing ISO 27017 certification, serverless functions were absent from the control scope documentation in the majority of engagements. The pattern holds across AWS Lambda, Azure Functions, and GCP Cloud Functions. The exclusion is not deliberate — it reflects how scope documents get written. The template lists VMs, containers, and managed services. Serverless gets added later as a delivery mechanism and never formally scoped into the security program.
Clients assumed their malware protection and access control assessments covered their cloud environment. They covered the part of their cloud environment that appeared in the scope document from the last certification cycle. Lambda functions deployed after that document was written were ungoverned. Execution role permissions for those functions had never been reviewed against least privilege requirements.
CloudTrail log integrity is documented but not validated
ISO 27017 section 9.1.2 requires monitoring and review of cloud service usage. Most organizations satisfy this with a SIEM integration pulling CloudTrail logs. What they do not test is whether CloudTrail log validation is enabled — the feature that detects whether log files have been modified or deleted after delivery. In assessments where we checked, CloudTrail log file validation was disabled in a pattern consistent enough to suggest it is off by default in many deployment templates and nobody enables it during setup.
The monitoring control is real. The integrity of the data it monitors is not verified. An attacker who gains sufficient privileges can alter timestamps, disable trails, or delete log files without any alert firing, because the monitoring system is watching the logs, not watching whether the logs can be trusted. The ISO 27017 audit would not find this — the auditor sees that CloudTrail is enabled and that a SIEM integration exists.
Shared responsibility matrices are generic templates, not architecture-specific documents
ISO 27017 section 6.1.3 is the most commonly cited differentiator between ISO 27017 and general ISO 27001 compliance. It requires documented allocation of responsibilities between cloud provider and customer. In practice, the documents we reviewed were close variants of shared responsibility templates published by AWS, Azure, or GCP, lightly customized with the organization's name and the current date. They described the general shared responsibility model for IaaS, PaaS, and SaaS. They did not describe the specific services the organization was running, the specific responsibilities for each service, or what would happen in a failure scenario at the boundary.
When a real incident hits a boundary — a cloud provider misconfiguration that exposes customer data, a customer misconfiguration that the provider's monitoring did not catch — the documented shared responsibility matrix does not help anyone understand who should have caught it or who needs to act. The document satisfied the control requirement. It provided no operational value during the incident.
Internal audit cycles compress to the point of defeating their purpose
ISO 27017 section 9.2.1 requires internal audits at planned intervals. In SaaS company assessments, the scheduled internal audit interval was routinely quarterly or biannual in the documented audit program. The actual pattern was one internal audit three to six weeks before the external certification audit. The rest of the calendar year produced no internal audit activity. The documentation showed planned quarterly audits. The activity log showed one audit per year.
The 78-day average gap between vulnerability discovery and remediation that we observe in ongoing monitoring engagements is partly explained by this pattern. When internal audits only happen once a year, vulnerabilities that emerge between cycles sit undetected until the external audit scope triggers a review. By that point, some have been public for months.
The CCM is broader than ISO 27017 — and that is sometimes the problem
Common belief
The CSA Cloud Controls Matrix covers more ground than ISO 27017, so organizations with limited resources should adopt CSA STAR first and layer ISO 27017 on top if they need formal certification. The broader coverage produces a more complete cloud security program.
What we found
In assessments where clients had completed a CCM self-assessment prior to engaging, the delta between their self-reported CCM posture and our technical findings was consistently larger than in organizations that had no prior framework assessment. Organizations without a prior assessment had no strong prior belief about their security posture. Organizations with a CSA STAR self-assessment sometimes had to unlearn their own documentation before they could accept what the technical findings showed.
The CCM has 197 controls across 17 domains. ISO 27017 has 37 cloud-specific controls on top of the ISO 27002 baseline. By control count, the CCM wins. By implementation depth, the picture is different.
ISO 27017 requires an auditor to validate evidence. CCM self-assessment requires you to answer your own questions. When organizations complete a CCM self-assessment, they answer based on their security architecture documentation and their understanding of their environment. The controls they implement poorly tend to be the ones they rate themselves on without external challenge — which are often the ones involving ongoing operational behavior rather than one-time configuration.
In practice, organizations that complete a CSA STAR self-assessment before pursuing ISO 27017 certification frequently discover that their CCM ratings were optimistic. The ISO 27017 auditor asks for evidence. The evidence for controls rated as implemented turns out to be documentation of intent rather than documentation of behavior. The CCM self-assessment created a false baseline that made the ISO 27017 gap assessment harder because the organization thought it was starting from a stronger position than it was.
What both frameworks leave unexamined
Assets outside the declared scope
Both ISO 27017 and CSA STAR operate against whatever asset inventory the organization submits. Neither framework requires the organization to prove the inventory is complete before the assessment begins. Cloud accounts created by development teams, S3 buckets spun up for temporary projects that were never decommissioned, and third-party SaaS integrations that create new data flows are invisible to the compliance program unless someone explicitly adds them. The compliance posture is accurate for the declared environment. The actual environment is larger.
Encryption key management in practice
Both frameworks address encryption requirements. Neither one validates that encryption key management is operationally sound. Organizations enable encryption — for S3, for RDS, for EBS volumes — and the control is satisfied. What does not get checked is whether customer-managed keys are rotated, whether key policies restrict access to the right principals, or whether the key hierarchy makes sense given the data classification. Encryption is on. Whether the encryption is meaningful depends on who controls the keys and under what conditions.
Lateral movement paths from legitimate services
ISO 27017 and the CCM both address access control and network segmentation. Neither addresses the attack paths that run through legitimate cloud service integrations — IAM roles that allow one service to assume another, SQS queues that connect microservices with different trust levels, Lambda invocations triggered by S3 events that carry the invoking function's permissions into a new execution context. These are not misconfigurations in the traditional sense. They are the architecture working as designed, with trust relationships that accumulate over time and are never reviewed as a set.
Incident response against cloud-specific failure modes
ISO 27017 section 8.1.5 requires incident response procedures for cloud-specific incidents. Most organizations document procedures for account hijacking and data exfiltration. Multi-tenant isolation failures, control plane API abuse, and cloud provider-side incidents that affect customer environments are less commonly covered. The gap is not in the documentation format — it is in the scenario coverage. Incident response plans get written against the threat scenarios the team can imagine. Cloud-specific failure modes that have not happened to the organization yet tend not to appear.
Where cloud security compliance is heading
By 2027, CSA STAR self-assessment entries will carry an explicit disclosure requirement in enterprise procurement processes, and organizations that present Level 1 entries as equivalent to third-party certification will face contract disputes when security incidents occur against controls rated as implemented in the self-assessment.
The delta between self-assessed CCM posture and externally validated cloud security posture is large enough and consistent enough that procurement teams are starting to ask which assurance level a CSA STAR entry represents. As more cloud security incidents trace back to controls that appeared in a vendor's CSA STAR listing as implemented, the liability question will become harder to avoid. The signal to watch: a contract dispute or regulatory inquiry where a vendor's CSA STAR self-assessment rating for a specific control domain is cited in the context of an incident in that domain.
Confidence: mediumNo contract dispute or regulatory inquiry cites a CSA STAR self-assessment rating in the context of a cloud security incident by end of 2027.Serverless function security will become a named compliance control requirement in the next ISO 27017 revision cycle, driven by a pattern of incidents traceable to overprivileged Lambda and equivalent execution roles that fell outside existing audit scope definitions.
The serverless scope exclusion pattern is widespread and has no organizational fix under the current standard — nothing in ISO 27017 compels organizations to include serverless functions in their control scope, and nothing in the audit methodology requires auditors to ask whether they were included. The execution role privilege pattern is consistent and exploitable. When enough incidents trace back to this specific vector, the standards body will respond. The signal: ISACA or ISO publishing advisory guidance specifically naming serverless function scope as an area requiring explicit inclusion in cloud security assessments.
Confidence: highISO 27017 revision guidance published by end of 2028 contains no specific requirement or advisory regarding serverless function scope inclusion.
The debate worth having: should cloud security frameworks require technical validation?
My position is that any cloud security framework that allows documentation-only evidence for technical controls is producing compliance artifacts, not security assurance. ISO 27017 and CSA STAR both allow organizations to satisfy cloud security controls with written policies and sampled evidence. Neither requires the organization to demonstrate that the controls work against a real attack pattern. This is a deliberate design choice — the frameworks are built for auditability, and auditability at scale requires evidence standards that auditors can process efficiently.
The consequence is that organizations build compliance programs that optimize for evidence production rather than control effectiveness. The shared responsibility matrix gets written because the auditor will ask for it. The CloudTrail integration gets documented because the monitoring control requires documentation. Whether the matrix reflects the real architecture and whether the logs can be trusted are questions the compliance program does not answer.
For organizations operating in threat environments where a cloud compromise would be a material event, the compliance program is not a substitute for technical validation. It is a separate activity that serves a different purpose.
Counterargument
The strongest counterargument is that requiring technical validation in certification standards would make cloud security certification inaccessible to small and mid-size organizations. Penetration testing and active security validation are expensive and require specialized skills. A documentation-based standard that mid-size organizations can actually implement produces more widespread baseline security than a technically rigorous standard that only large organizations can afford to pursue. That argument has real merit. The error is in treating the baseline as the ceiling.
One thing worth doing this week
Pull the IAM roles attached to every Lambda function, Azure Function, or equivalent serverless service in your environment. For each one, check what S3, database, or secrets manager permissions are attached. Flag any role with broader permissions than the function's documented purpose requires. This is not a framework gap analysis — it is a 30-minute check that will tell you whether your cloud security program covers the part of your infrastructure that your compliance scope document probably does not. If you find roles with account-wide S3 access or permissions to services the function never calls, those are the findings that matter regardless of what your ISO 27017 evidence package says.
Further Reading
Gap Analysis
ISO 27017 gap analysisDigital Footprint
digital footprint analysisISO framework group: ISO 27001, 27002, 27017, 27018, 27701, 22301, 31000, 42001 and more
ISO 27017 cloud security controlsISO 27001 Official Standard
ISO 27001 standardNational Vulnerability Database NIST
NIST National Vulnerability DatabaseWhat is Gap Analysis in Compliance
compliance gap analysis
Frequently Asked Questions
What does ISO 27017 cover that ISO 27001 does not?
ISO 27017 adds 37 cloud-specific controls on top of ISO 27002, covering areas like shared responsibility documentation between cloud providers and customers, virtual machine hardening, cloud service monitoring, and multi-tenant isolation. The critical one most organizations implement poorly is section 6.1.3 — the shared responsibility matrix. Organizations frequently assume the cloud provider handles more than they actually do, and the documentation that is supposed to clarify that division either does not exist or has never been tested against a real incident scenario.
Does ISO 27017 certification mean a cloud environment is secure?
No. ISO 27017 certification means an auditor reviewed documentation and sampled evidence at a point in time. It does not mean the controls are working continuously, that all assets are in scope, or that attack vectors outside the control list are addressed. In assessments following recent ISO 27017 certifications, we have found exposed S3 buckets, serverless functions with overprivileged execution roles, and CloudTrail logging silently disabled — none of which surfaced during the audit because the audit process did not include active technical validation.
What is the main technical difference between ISO 27017 and CSA STAR?
ISO 27017 is a prescriptive control standard with defined implementation guidance — it tells you what to do. CSA STAR is an assurance program built around the Cloud Controls Matrix, which covers a broader set of cloud security domains but allows three different assurance levels: self-assessment, third-party certification, and continuous monitoring. The self-assessment option is the most commonly used and the least reliable — organizations demonstrate alignment with the CCM themselves, with no external validation. For buyer-side due diligence on cloud vendors, CSA STAR registry entries should be treated as a starting point, not a conclusion.
What does the CSA Cloud Controls Matrix cover that ISO 27017 misses?
The CCM covers supply chain security, datacenter operational controls, and cloud-native application security domains in more detail than ISO 27017. It also provides more granular guidance on encryption key management and identity federation across multi-cloud environments. Where ISO 27017 is tighter is in the shared responsibility documentation requirement and audit evidence standards. Organizations running multi-cloud environments with complex vendor chains typically find the CCM more actionable; organizations seeking a certifiable standard that integrates with an existing ISO 27001 program find ISO 27017 more practical.
What cloud security gaps do organizations most commonly miss when relying only on ISO 27017?
Three patterns appear consistently. First, serverless functions are almost never in scope for the malware protection and access control assessments that ISO 27017 requires — the controls get applied to VMs and containers, and Lambda or equivalent functions get skipped. Second, CloudTrail and equivalent audit log integrity is documented but never tested — organizations check that logging is enabled but do not verify that log tampering would be detected. Third, internal audit cycles are compressed to run immediately before external audits rather than continuously, meaning the 78-day average gap between vulnerability discovery and remediation goes unmonitored between formal audit windows.
How do ISO 27017 and CSA STAR work together in a cloud compliance program?
The CCM controls map reasonably well to ISO 27017 requirements — an organization that has done a rigorous CCM self-assessment has covered roughly 70 percent of the evidence ISO 27017 auditors will request. The practical approach is to complete CCM mapping first, identify the control gaps, and use ISO 27017 evidence requirements to structure the remediation documentation. The combination avoids collecting the same evidence twice and produces a more complete cloud security posture than either framework alone. The gap both leave is active technical validation — neither framework requires you to test whether the controls actually work.
What should a cloud security gap analysis include that ISO 27017 audits typically skip?
Active asset discovery before the assessment begins — not relying on the existing asset inventory. Privilege analysis across all IAM roles, including execution roles attached to serverless functions and automation accounts. Log integrity validation, not just confirming that logging is enabled. Shared responsibility mapping reviewed against the actual cloud architecture, not a generic template. And an external attack surface scan covering all registered domains and cloud storage endpoints, run independently of whatever the internal asset register says is in scope.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.