TL;DR: Common AWS risks spanning unencrypted RDS data, public or unintended IAM exposure, plaintext secrets, non-compliant data flows, and weak logging across S3, RDS, EC2, IAM, and Secrets Manager were found in 2025 telemetry, according to Cyera Research Labs. The governance problem is not AWS itself, but overreliance on static configurations that do not match how data is actually used.
NHIMG editorial — based on content published by Cyera: Assessing the Top Data Security Risks in AWS Environments
Questions worth separating out
Q: How should security teams reduce AWS data security risk across identity and storage controls?
A: Security teams should manage AWS data risk as a shared identity and data problem.
Q: Why do IAM misconfigurations become data security incidents in AWS?
A: IAM misconfigurations become data security incidents when a role, policy, or trust relationship exposes sensitive services to the wrong principal.
Q: What do teams get wrong about secrets in AWS environments?
A: Teams often treat secrets as a storage problem rather than an identity problem.
Practitioner guidance
- Tie each AWS service to a named control owner Assign S3, RDS, EC2, IAM, and Secrets Manager to specific control owners so exposure cannot fall between platform, data, and identity teams.
- Audit for public and unintended IAM exposure paths Review trust policies, cross-account access, and role assumptions for any path that can expose data services to unintended principals.
- Eliminate plaintext secrets from host and volume surfaces Search unprotected volumes, startup scripts, and environment files for credentials and passwords.
What's in the full report
Cyera's full research paper covers the operational detail this post intentionally leaves for the source:
- Per-service risk breakdowns across S3, RDS, EC2, IAM, and Secrets Manager for teams that need implementation context.
- Cyera telemetry examples showing how specific misconfigurations manifest in enterprise AWS environments.
- The paper's detailed explanations of why conventional controls fail in day-to-day cloud operations.
- Operational recommendations that move beyond the summary-level governance framing in this post.
👉 Read Cyera's research on top data security risks in AWS environments →
AWS data security risks: what IAM teams are missing in practice?
Explore further
Static cloud configurations are the wrong security model for dynamic AWS data use. Cyera’s research reinforces a familiar governance failure: teams often secure what they configured, not how data is actually consumed across services. That gap is visible when unencrypted storage, exposed IAM paths, and plaintext secrets coexist in the same environment. The practitioner conclusion is that cloud data security must be treated as an operating model, not a one-time setup.
A few things that frame the scale:
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
- Another finding from the same survey shows that only 44% of organisations have implemented any policies to manage their AI agents, even though 92% agree governing AI agents is critical to enterprise security.
A question worth separating out:
Q: How do you know whether AWS data controls are actually working?
A: You know controls are working when you can trace data access, identify the principal involved, and prove whether the access aligned with policy. If logging is incomplete or inconsistent across services, the programme cannot support incident scoping or compliance evidence. Effective controls are measurable because they leave a verifiable trail.
👉 Read our full editorial: Top data security risks in AWS expose identity gaps at scale