Your Cloud Provider Is Secure. Your Configuration Isn't.

A healthcare SaaS startup in the Hudson Valley—roughly sixty employees, about eighteen months into a cloud-first architecture, serving regional medical practices with a platform that handled protected health information—came to us after passing their cloud provider’s built-in security assessment with flying colors. Their security posture score was green across the board. Their CISO equivalent, a technically capable infrastructure lead wearing several hats, was reasonably satisfied. Then we ran a configuration review against their actual AWS environment. Within the first two hours, we had found S3 buckets containing PHI with public access enabled, IAM roles with administrative-equivalent permissions attached to application workloads that needed nothing of the sort, and zero CloudTrail logging—meaning there was no record of who had accessed what, ever. The cloud provider’s platform was secure. Their use of it was not.

This is the shared responsibility model gap in its most dangerous form. Cloud providers—AWS, Azure, Google Cloud—are exceptionally good at securing the infrastructure layer. The physical data centers, the hypervisor, the managed service internals, the global network fabric: that is their problem, and they solve it at a level no mid-market organization could replicate independently. What they do not secure, cannot secure, and explicitly disclaim responsibility for is how you configure the services running on top of that infrastructure. That part is yours. And according to the Cloud Security Alliance’s State of Cloud Security 2026 report, misconfiguration remains the leading cause of cloud security incidents for the fourth consecutive year.

The AWS Well-Architected Framework describes this clearly in its Security Pillar: the customer is responsible for security in the cloud, while AWS is responsible for security of the cloud. It is a clean distinction on paper. In practice, it gets blurred constantly—particularly among organizations that are moving fast, running lean, and treating “our cloud provider is SOC 2 certified” as a proxy for “we are secure.”

A SOC 2 report covers the provider’s controls. It says nothing about whether your S3 bucket is public, your IAM roles are scoped correctly, or anyone is logging API calls in your account.

The Shared Responsibility Model—What It Actually Means

The shared responsibility model is not a technicality buried in a service agreement. It is the foundational operating premise of every public cloud deployment, and misunderstanding it is how organizations end up with exposed data despite using enterprise-grade infrastructure. The model divides security obligations cleanly: the provider owns everything below the virtualization layer, and the customer owns everything above it.

For Infrastructure as a Service (IaaS) deployments—EC2 instances, raw storage, networking—the customer responsibility surface is substantial. You own the operating system, the application stack, the network configuration, the identity and access management layer, the encryption settings, and the monitoring configuration. For Platform as a Service (PaaS) and managed services, the provider takes on more of the stack, but critical configuration decisions remain the customer’s domain. Who can access this S3 bucket? Which IAM roles can assume which permissions? Is data encrypted at rest and in transit? Are API calls being logged? None of those questions are answered by your provider’s security certifications.

The Hudson Valley startup understood this in the abstract. What they hadn’t done is translate that understanding into a systematic review of their actual configuration. They had provisioned services quickly during a growth sprint, made reasonable-at-the-time decisions about access and permissions, and never gone back to audit whether those decisions still made sense—or whether they had made mistakes in the first place. That is not negligence. It is the normal trajectory of a fast-moving technical team. It is also exactly how PHI ends up in a public S3 bucket.

Provider’s Responsibility

Physical infrastructure, hypervisor, hardware, global network, managed service internals, platform availability. Covered by their compliance certifications.

Shared Zone

Patch management on managed services, encryption options, network controls—provider enables these, but the customer must activate and configure them correctly.

Your Responsibility

IAM configuration, S3 bucket policies, security group rules, CloudTrail logging, data classification, application-level access controls, encryption key management.

Five Misconfigurations That Show Up Everywhere

After thirty-eight years in this field, including the last several focused heavily on cloud security assessments for SMB and mid-market organizations, I have stopped being surprised by what we find. The specifics vary. The categories do not. These five misconfigurations account for the majority of material findings in every cloud environment we review.

The Recurring Findings

Public S3 Buckets with Sensitive Data: Object storage configured for public or unauthenticated access—sometimes intentionally for a specific use case, sometimes left over from a development configuration that was never locked down before the bucket received production data. The Hudson Valley startup had three buckets in this state. One contained patient intake forms.

Over-Permissioned IAM Roles: Application workloads, Lambda functions, and EC2 instances running with IAM roles that grant far broader permissions than the application actually requires. The principle of least privilege exists for exactly this scenario: when an application is compromised, the blast radius is bounded by what that role can do. When every service runs as AdministratorAccess, there is no bound.

No CloudTrail Logging: AWS CloudTrail is the audit log for your entire AWS account—every API call, every console action, every configuration change. Disabling it, or never enabling it, means you have no forensic record of anything that has happened in your environment. You cannot detect unauthorized access, you cannot investigate incidents, and you cannot demonstrate compliance. The startup had CloudTrail disabled in two of their three active regions.

Permissive Security Groups: EC2 security groups and network ACLs configured with overly broad inbound rules—0.0.0.0/0 on port 22, administrative interfaces exposed to the internet, database ports reachable without VPN. Often a residual of initial development configurations where convenience was prioritized over restriction.

Encryption Not Enforced: S3 buckets, RDS instances, and EBS volumes without encryption at rest enabled. In HIPAA-covered environments, encryption of PHI at rest is not optional. We regularly find healthcare-adjacent organizations that have encryption available but not activated—because the default was off, and no one audited whether the default was acceptable.

What makes these findings particularly consequential for organizations handling regulated data is that the regulatory exposure does not care about intent. A HIPAA breach notification obligation attaches to unauthorized access to PHI regardless of whether that access resulted from a sophisticated attack or a misconfigured bucket. The Cloud Security Alliance’s 2026 report found that 68% of cloud security incidents traced back to misconfiguration—not exploited vulnerabilities, not nation-state actors. Configuration decisions made by internal teams.

The attacker who finds your public S3 bucket containing PHI did not beat your cloud provider’s security. They typed your bucket name into a browser.

How to Audit Your Own Configuration

A cloud configuration review does not require a third-party engagement to get started. AWS provides native tooling that, used consistently, surfaces the most critical misconfiguration risks. The challenge is not capability—the tools exist and most of them are either free or low-cost. The challenge is making the review a disciplined practice rather than a one-time event.

AWS Security Hub is the starting point. When enabled, it aggregates findings from multiple sources—AWS Config rules, GuardDuty, Inspector, Macie—and maps them against the AWS Foundational Security Best Practices standard and the CIS AWS Foundations Benchmark. For organizations that want a structured starting point, the CIS Benchmark Level 1 controls are a reasonable minimum bar: they cover IAM configuration, logging, monitoring, and networking basics. Enable Security Hub, run the CIS assessment, and work through the findings by severity. This is not a comprehensive security program, but it will surface the most critical issues in your environment within hours.

Tool	What It Catches	Cost Model
AWS Security Hub	Aggregates findings across services; maps to CIS Benchmark and AWS FSBP; consolidated risk view across accounts and regions.	First 10,000 findings/month free; low per-finding cost beyond that.
AWS Config	Continuous configuration tracking; detects drift from defined baselines; evaluates resources against managed and custom rules.	Per configuration item recorded; per rule evaluation. Modest for typical SMB environments.
Amazon Macie	Discovers and classifies sensitive data in S3; flags buckets containing PII, PHI, or financial data; identifies public or unencrypted buckets with sensitive content.	Per GB scanned for data discovery; flat rate for bucket inventory evaluation.
AWS IAM Access Analyzer	Identifies resources shared externally or accessible beyond intended scope; surfaces overly permissive policies; generates least-privilege policy recommendations.	Free for basic external access findings within a single account.
CloudTrail Lake	Queryable audit log of all API activity; enables anomaly detection, incident investigation, and compliance reporting; multi-region and multi-account capable.	Pay per GB ingested and per GB scanned in queries. Foundational logging should be enabled regardless.

Beyond native tooling, the AWS Well-Architected Tool allows you to conduct a formal review against the five pillars of the Well-Architected Framework—Operational Excellence, Security, Reliability, Performance Efficiency, and Cost Optimization. The Security Pillar review is a structured questionnaire that walks through identity and access management, detection controls, infrastructure protection, data protection, and incident response readiness. It produces a prioritized list of high-risk findings and improvement recommendations. It is free, and it takes a half-day to complete seriously. For organizations that have never done a formal security review of their cloud environment, this is one of the highest-value activities available.

For healthcare organizations and anyone handling PHI, Macie deserves particular attention. It does something that many teams haven’t thought to do: it tells you what is actually in your S3 buckets. You may have a clear mental model of what data goes where. Macie will test that model. The startup’s public bucket containing patient intake forms was not intentional—a developer had moved files there temporarily during a migration and forgotten to restrict access. Macie would have flagged both the sensitive data classification and the public access configuration in the same finding.

The HIPAA Configuration Baseline

For organizations operating under HIPAA, cloud configuration is not just a security best practice—it is a compliance obligation with specific technical requirements. The HIPAA Security Rule’s technical safeguards map directly to cloud configuration decisions. Access controls, audit controls, integrity controls, and transmission security are not abstract principles. They translate into concrete configuration choices that need to be made correctly and maintained consistently.

Access Controls

IAM policies implementing least privilege for all users and roles. MFA required for all console access and privileged API operations. No shared credentials. Service accounts scoped to minimum required permissions.

Audit Controls

CloudTrail enabled in all regions with log file validation and integrity checking. Logs stored in a dedicated S3 bucket with restricted access. Minimum 7-year retention for HIPAA audit purposes. Security Hub and GuardDuty actively monitoring.

Integrity Controls

S3 Object Lock or equivalent for PHI at rest to prevent unauthorized modification. CloudTrail log file validation enabled. Versioning on buckets containing PHI. Hash verification on data exports.

Transmission Security

TLS 1.2 minimum enforced on all S3 bucket policies and API endpoints. VPC endpoints for internal AWS service communication to avoid internet transit. No PHI over unencrypted channels under any configuration path.

The startup’s configuration failures were not exotic. They were the baseline requirements unmet. No CloudTrail meant no audit controls. Public S3 buckets meant no access controls on the data. No encryption meant transmission security was partially dependent on application-layer controls that had not been audited. An OCR investigation following a breach would have found a pattern of Basic Security Rule technical safeguard failures—not a sophisticated attack that overwhelmed a compliant program.

AWS publishes a HIPAA on AWS whitepaper and maintains a list of HIPAA-eligible services. The Business Associate Agreement with AWS covers the infrastructure layer. It does not cover your configuration choices within that infrastructure. The BAA is necessary but not sufficient. What makes it sufficient is the configuration work that sits on top of it.

Diagnostic Questions for Business Leaders

Cloud security configuration is often treated as purely a technical domain, invisible to business leadership until something goes wrong. That is the wrong governance posture. The configuration decisions that create material risk are business decisions—about acceptable risk, about investment in controls, about organizational priority. Business leaders at organizations running cloud workloads with sensitive data should be able to answer these questions. If you cannot, the conversation needs to happen before an incident forces it.

Questions Every CTO and IT Director Should Be Able to Answer

These are not technical deep-dives. They are the minimum situational awareness a business leader needs to manage cloud security risk responsibly.

Has your team ever run a configuration review against the CIS AWS Foundations Benchmark or equivalent framework—not just the cloud provider’s built-in compliance score, but a structured audit of how your account is configured?
Do you know which S3 buckets in your environment contain sensitive data, and can you confirm none of them have public access enabled? When did you last verify this?
Is CloudTrail logging enabled across all regions in your AWS account? Where are those logs stored, and when did you last confirm they have not been tampered with or deleted?
Can your team produce, within 24 hours, a complete list of IAM roles with administrative or broadly-scoped permissions and the workloads they are attached to? Do those permissions reflect what those workloads actually need?
When a developer or engineer provisions a new service or resource, is there a review process before it reaches production—or does configuration happen ad hoc and get reviewed after the fact, if at all?
If a misconfiguration exposed customer data today, do you have the audit logs necessary to determine what was accessed, when, and from where? If the answer is no, you do not have the foundation for an incident response.
Has your cloud configuration been reviewed since your last significant infrastructure change or migration? Configuration drift is real—what was correct six months ago may not be correct today.

The Hudson Valley startup’s infrastructure lead was technically skilled. He knew what CloudTrail was. He knew what S3 access policies were. The problem was not knowledge—it was prioritization and process. During a growth sprint, getting features out mattered more than going back to audit the access configuration on a bucket provisioned three months earlier. There was no scheduled review cadence. There was no automated alerting on configuration drift. There was no one asking these questions at a leadership level.

That is a solvable problem. It requires building configuration review into the operational cadence, not treating it as a one-time project. It requires enabling the native tooling that provides continuous visibility rather than relying on manual audits. And it requires business leaders who understand enough about the risk surface to ask the right questions of their technical teams.

What Remediation Actually Looks Like

The startup’s remediation was completed in four weeks. Not because the work was trivial, but because once the findings were clear and prioritized, the path forward was technically straightforward. The infrastructure lead knew how to fix these issues. He had not known they existed.

Finding	Remediation	Timeline
Public S3 Buckets	Enabled S3 Block Public Access at the account level. Reviewed and updated bucket policies on all 23 buckets. Moved two buckets with PHI to private with VPC endpoint access only. Enabled Macie for ongoing data classification monitoring.	Week 1
Over-Permissioned IAM	Used IAM Access Analyzer to generate least-privilege policy recommendations for all application roles. Replaced AdministratorAccess attachments with scoped policies. Enabled permission boundaries on developer IAM users. Established quarterly IAM access review process.	Weeks 1–2
No CloudTrail Logging	Enabled CloudTrail in all regions with log file validation. Created dedicated S3 bucket with restrictive access policy and MFA delete requirement. Configured CloudWatch Alarms for critical API activity. Established 7-year log retention for HIPAA compliance.	Week 1
Security Group Drift	Audited all security groups against the principle of least access. Removed 0.0.0.0/0 inbound rules on administrative ports. Moved SSH and RDP access behind VPN with MFA. Enabled AWS Config rule for ongoing security group monitoring.	Weeks 2–3
Encryption Gaps	Enabled default encryption on all S3 buckets using AWS KMS. Encrypted remaining unencrypted RDS instances and EBS volumes. Enforced TLS-only access via bucket policies. Documented encryption configuration in updated BAA supplemental controls inventory.	Weeks 3–4

The total infrastructure cost of the remediation was negligible. CloudTrail logging at their scale runs under twenty dollars a month. Security Hub and Macie added roughly fifty dollars monthly. The IAM work and security group review were pure engineering hours—approximately forty hours of the infrastructure lead’s time across four weeks. For a sixty-person company handling PHI, that is an extraordinarily favorable risk-reduction-per-dollar ratio.

What they also built, and what mattered as much as the immediate fixes, was a configuration review process. AWS Config rules now alert on public S3 bucket creation. IAM Access Analyzer runs continuously. Security Hub provides a weekly summary that goes to both the infrastructure lead and the CEO. The one-time project became an operational control. That is the difference between remediation and security posture improvement.

The goal is not a clean report. The goal is a configuration state you can verify, maintain, and defend—on any given day, not just the day after an assessment.

Your cloud provider has built some of the most secure infrastructure ever operated at commercial scale. The engineers who designed those systems are genuinely exceptional at what they do. None of that secures the choices you make inside your account. The shared responsibility model is not a legal technicality. It is a description of reality—and the half of it that belongs to you requires the same disciplined, continuous attention as any other operational risk in your business.