Anonymized client report examples
Anonymized report based on a startup SaaS client with a small team, live production workloads, and limited platform capacity.
Startup · Final audit vote
SCORE
72/100
YELLOW · 70-84
Good baseline, targeted remediation required
The account can continue operating, but the P1 findings should be fixed before adding more production workloads or compliance commitments.
VOTE LEGEND
Green 85-100 — Strong baseline
Yellow 70-84 — Good, needs targeted fixes
Orange 50-69 — Remediation required
Red 0-49 — High-risk account
Finding distribution
3/22
OPERATIONAL EXCELLENCE
Operational Excellence
3/22
Security
8/22
Reliability
2/22
Performance Efficiency
2/22
Cost Optimization
5/22
Sustainability
2/22
Total findings
21
Critical path
6 P1
Quick wins
8
Estimated effort
18-30 days
Executive summary
This startup account has several fixable security and operations gaps, plus deliberate startup tradeoffs around cost and time-to-market. The remediation should start with public exposure and account visibility, then move into patching, workload boundaries, cost cleanup, and growth-triggered architecture upgrades.
- 6 P1 findings should start first.
- 8 quick wins can be handled without large architecture changes.
- Accepted tradeoffs are documented with triggers for when the startup grows.
Findings
18 / 18 FINDINGS
Selected finding detail
Priority
P2
Pillar
Reliability
Subcategory
Network resilience
Effort
Medium
Status
Context
NAT Gateway not deployed per Availability Zone
AWS best practice is one NAT Gateway per AZ for resilient private egress, but this would increase recurring cost for a small startup workload.
Classified as P2 because the issue affects reliability and has medium remediation effort in this client scenario.
Remediation steps
Keep the lower-cost proxy/controlled-egress pattern for now, document the tradeoff, and define the traffic or availability trigger for moving to NAT per AZ.
# Startup tradeoff
# Keep controlled egress through proxy now
# Move to nat_gateways_per_az = true when traffic/SLA requires itContinuous check status
Last checked: 2026-07-06 · Frequency: Monthly
Method: Architecture review + custom AWS check
Current signal: Tradeoff is documented and monitored against growth/cost triggers
Next action: Revisit when traffic, compliance, or availability requirements increase
Remediation roadmap
A practical order of work so the client knows where to start right away, which fixes can be grouped together, and which items are accepted tradeoffs to revisit later.
Start today
Stop public exposure
Reduce the public attack surface before deeper architecture work starts.
Actions
- Move admin access to SSM
- Block public S3 exposure
- Attach WAF to the public edge
Findings covered
This week
Enable account visibility
Make the account observable enough to investigate changes and incidents.
Actions
- Enable GuardDuty
- Enable AWS Config
- Centralize delivery to S3
- Set CloudWatch retention
Findings covered
This sprint
Reduce operational risk
Remove recurring maintenance gaps that become painful as the team grows.
Actions
- Add SSM patching
- Define RDS patch policy
- Create RDS parameter group
Findings covered
Next sprint
Tighten workload boundaries
Make service access more explicit and reduce lateral movement risk.
Actions
- Replace broad VPC security group rules
- Evaluate mTLS for sensitive paths
- Evaluate Cognito integration
Findings covered
Parallel quick wins
Clean up cost waste
Remove low-risk waste without slowing product delivery.
Actions
- Delete unattached EBS
- Archive or remove unused EFS
- Review log growth
Findings covered
Trigger-based
Plan growth upgrades
Document accepted startup tradeoffs and the signal for when to upgrade.
Actions
- Define trigger for account split
- Define trigger for RDS HA/RDS Proxy
- Define trigger for NAT per AZ
Findings covered