Cloud security analysts don’t miss misconfigurations because they aren’t paying close enough attention, but because there’s nothing to look for. In June 2026, the NCSC put it bluntly in an expert blog post about misconfigurations as an open door to sensitive data: in the case of a misconfiguration, there is no technical vulnerability that can be patched; the functionality works exactly as intended, but access is configured incorrectly. There is no exploit, no malware, and no unusual connection. There is an API that responds to anyone who asks.
Why On-Premise Detection Mechanisms Fail Here
Cloud security analysts trained in a traditional environment look for anomalies: a process that shouldn’t be running, traffic to an unknown address, a file with a suspicious hash. In the case of cloud abuse, those clues simply don’t exist.
The NCSC explains exactly why this is the case. Malicious actors use automated tools to scan the internet, and in many cases, a single HTTP request is enough to determine whether an environment is misconfigured. The data is then retrieved using the platform’s standard features via legitimate requests, making the traffic virtually indistinguishable from regular usage. For cloud security analysts, this means a fundamentally different approach: not looking for what shouldn’t be there, but for what is happening too much or too often.
For cloud security analysts, this represents a shift in thinking that doesn’t come naturally. The focus of detection is shifting from signatures to behavior, volume, and context. Someone who normally retrieves five customer records a day but retrieves 40,000 today isn’t doing anything that’s technically prohibited. Only someone who knows what normal use of that specific platform looks like will recognize this as an incident.
There is another factor that complicates the comparison with on-premises environments. In a private data center, the separation between administration and usage is physically visible; in the cloud, the two are intertwined. An employee with the appropriate permissions can make a storage bucket public via a web interface, without any involvement from IT administration and without going through a change management process. Cloud security analysts must therefore monitor not only attackers but also their own organization, because most open doors are left open internally rather than forced open from the outside.
The scale of the problem in the Netherlands
The figures cited by the NCSC make it clear why cloud security analysts cannot ignore this issue. According to research by the Cloud Security Alliance, 58 percent of organizations struggle to properly configure access and permissions for SaaS applications, while organizations use an average of more than 100 SaaS applications. That represents an attack surface that no administrator can monitor manually.
The incidents from 2025 and 2026 cited by the NCSC illustrate the challenges cloud security analysts face in practice. In misconfigured Salesforce Experience Cloud environments, guest users were granted overly broad permissions, allowing data to be retrieved via the Aura API without authentication. Salesforce confirmed that this was not due to a vulnerability in the platform but rather to configuration errors on the part of customers. An attack group claimed to have affected between 300 and 400 organizations as a result.
Closer to home, the DIVD investigated authorization misconfigurations in applications built on the Mendix low-code platform. A large-scale scan in February 2026 revealed that several applications had granted overly broad permissions to anonymous or newly registered users, exposing names, contact information, addresses, and identity documents. This touches on the supply chain issues we described in our article on supply chain security: the misconfiguration often lies not with you but with a platform you use.
Specifically, what cloud skills are your analysts lacking?
The gap between traditional and cloud security analysts can be broken down into four specific competencies. The first is reading cloud audit logs. While a Windows event log has a familiar structure, a cloud log requires knowledge of that platform’s specific API calls, which actions are and aren’t recorded, and the delay with which they appear.
The second skill required of cloud security analysts is the ability to assess permissions and roles in cloud environments. An analyst who receives an alert about an account must be able to determine what that account was authorized to do and whether that was appropriate. Without an understanding of role structures and inheritance rules, that question remains unanswered.
The third is an understanding of identity federation and application permissions. Much cloud abuse occurs through an application that was once granted permission and that no one is monitoring anymore. The fourth is knowledge of hardening standards such as the CIS Benchmarks, so that an analyst can not only determine that something happened, but also whether the configuration under which it occurred was sound.
Together, these four competencies make the difference between a team that forwards cloud alerts to operations and cloud security analysts who handle them themselves. It’s the same dependency we described regarding SIEM investments without trained analysts: connecting the log source is the easy part; interpreting the data is the hard part.
Set up detection based on behavior rather than signatures
The NCSC explicitly outlines the approach: because attacks exploit legitimate platform functionality, detection can be difficult; therefore, focus detection on anomalies in behavior, volume, and context, enable audit logging, and ensure that logs are collected centrally and analyzed periodically.
In practical terms, this provides cloud security analysts with a handful of detections that are valuable in virtually any cloud environment. A sharp increase in the volume of data requests by a single account or a single session. Access to data by anonymous or guest users where it is not permitted. New application permissions with broad privileges. Changes to the configuration of critical services outside the usual change windows. And initial access from infrastructure you normally never see.
Start small and make deliberate choices. An organization that tries to monitor everything at once will be overwhelmed by noise and give up within a quarter. Select the two or three platforms that contain the most sensitive data, identify which users and applications have access to them, and focus your initial detection efforts there. Only once those are running smoothly and the team knows what constitutes a valid alert should you move on to the next environment. This way, detection coverage grows in tandem with the team’s skills rather than getting ahead of them.
None of these detections work unless someone knows the thresholds for their own environment. That is exactly why cloud security analysts need to understand their own platforms—not just the detection platform. Document those thresholds and the corresponding actions in a way that’s usable under pressure, in the same spirit as our article on practical SOC playbooks.
Once a team has run these scans, it can take the next step: proactively searching for misconfigurations before an attacker finds them. We described this approach in “Threat Hunting Within Your Existing Team.” The NCSC rightly notes that the longer a misconfiguration exists, the greater the chance that it will eventually be exploited.
Practicing in an environment you actually use
Cloud security analysts can’t really learn their craft from a book. The difference between knowing that audit logging exists and knowing which call in your environment gives away a guest user comes from actually doing it. That’s why hands-on training in your own environment works better than a generic course—a principle we’ve explored before in “Hands-On Training vs. Certification” and in our article on cybersecurity boot camps for businesses.
The path to becoming a fully-fledged cloud security analyst builds on the roles you already hold. Analysts who need to be able to triage cloud alerts start with the SOC T1 + T2 Analyst training, which focuses on structured investigation based on an alert. For independently determining the scope of a cloud incident—for example, when it turns out that an API had been left open for months—the SOC T3 Analyst training comes into play. If you’re unsure which level you need, our article on Tier 1 versus Tier 2 will help you make that choice.
Two additional specializations are valuable for cloud security analysts. Anyone who wants to understand how an attacker actually exploits a misconfigured environment will benefit from the Penetration Testing course, because thinking like an attacker is the fastest way to identify weaknesses in your own configuration. And if a cloud incident leads to the need to present evidence to the Dutch Data Protection Authority or an insurer, the quality of the investigation matters; the Cyber Forensics Expert course focuses on evidence that stands up to scrutiny.
With all this in mind, pay attention to the workload of your cloud security analysts. Cloud logs generate a lot of data, and a team that’s already struggling with alert fatigue is more likely to become less effective—rather than more effective—when faced with a new log source. Therefore, build up detection capabilities step by step and measure whether it’s working, following the guidelines in our article on meaningful cybersecurity KPIs.
From Isolated Alerts to Structural Control
The NCSC concludes its analysis by noting that misconfigurations are nothing new and are often the result of working under time pressure; for that very reason, they require ongoing attention rather than just an occasional check. That is precisely the difference between a scan you run once a year and a team that checks every week. You can determine where your organization stands on that scale using the cybersecurity maturity model.
The conclusion is the same as in “Structurally Improving Information Security”: the problem cannot be solved with an additional product, because the attack specifically exploits the standard functionality of products you already have. What does work are cloud security analysts who know your environment inside and out. The roles you need for this are outlined in “Putting Together Your First Security Team.”
The page for employers explains how to build that capacity based on your current staffing levels, from open-class courses to in-company training programs on your own cloud environment. You’ll find the complete overview of course levels for all programs, including the comprehensive Cyber Security Specialist program for administrators looking to advance into a security role.
Would you like to test whether your team would notice an exposed API in its own environment? Check out the upcoming start dates or schedule an introductory meeting to discuss the possibilities.
