I Audited a Health Startup's AWS Infrastructure: 36 Vulnerabilities, 9 Critical

The Context

A French health-tech startup hired me to audit their AWS infrastructure. Their application stores user health data — special category data under GDPR Article 9, the highest level of protection that exists.

The audit result: 36 vulnerabilities found, 9 critical. AWS Well-Architected security score of 2 out of 10.

Here are the major issues I found, and how to fix them.

The State of Affairs

1. Database Exposed to the Internet

The production database — containing all user health data — was publicly accessible from the internet. It was only protected by a security group allowing specific IP addresses.

If that security group is accidentally modified (one click in the AWS console), the entire database becomes open to the world.

Additionally:

• No deletion protection
• Password unchanged for 3.5 years
• A personal home IP was whitelisted for direct access

Fix: Migrate database to private (isolated) subnet, enable deletion protection, set up automatic credential rotation via AWS Secrets Manager.

2. Zero Security Monitoring

Every AWS monitoring service was disabled:

• No CloudTrail (no record of who does what)
• No GuardDuty (no threat detection)
• No AWS Config (no configuration change tracking)
• No VPC Flow Logs (no network visibility)

In case of a breach, the company couldn't detect the intrusion, investigate it, or report it to authorities within the GDPR-required 72 hours.

Fix: Enable CloudTrail in all regions, deploy GuardDuty, configure AWS Config with compliance rules, set up CloudWatch alerts.

3. Plaintext Secrets in CloudFormation

Production Stripe keys (sk_live_...), webhook secrets, and third-party API keys were visible in plaintext in CloudFormation templates — accessible to anyone with basic read access.

Worse: staging and production shared the same API keys for some services.

Fix: Migrate all secrets to AWS Secrets Manager, reference by ARN in CloudFormation, separate staging/production keys.

4. Staging and Production in the Same Account

Both environments lived in a single AWS account. A compromised staging credential gave production access. The CI/CD pipeline had administrator rights on both environments with a password not rotated in 18 months.

Fix: Multi-account AWS Organizations architecture:

• Production account (isolated)
• Staging account (isolated)
• Shared account (CI/CD, artifacts)
• Security account (centralized logs)

5. Zero MFA, SSH Open to the World

No account had two-factor authentication. Not even root. SSH was open on 0.0.0.0/0 in both staging AND production.

Fix: Mandatory MFA on all accounts, migrate to AWS SSO/Identity Center, immediately close public SSH, use Session Manager for instance access.

The Deliverable

I delivered:

1. Complete audit report: 36 findings categorized (critical, high, medium, low) with framework references (ISO 27001, SOC2, GDPR, AWS Well-Architected)
2. Technical remediation plan: multi-account architecture, CloudFormation stacks, dependency graph and execution order
3. Costed estimation: two options (15-22K EUR security only, 22-31K EUR with container modernization)
4. Non-technical CEO briefing: risk summary in business language, legal/financial consequences, recommendation

Takeaways

Most startups I audit have similar issues. Infrastructure was built quickly to ship the product, and security was pushed to "later." The problem is that "later" usually arrives as an incident.

Regular audits — even lightweight ones — catch risks before they materialize. It's an investment, not a cost.

Worried about your AWS infrastructure security? Let's talk.