AWS Security Hub CSPM vs. Manual Auditing: Which Approach Actually Works?
A cloud engineer’s honest take on automated posture management vs. traditional security reviews - and why the answer is “both.”
Picture this: you’re running a quarterly security review. You pull up your spreadsheet, run through your checklist, and everything looks good. Green across the board. Three months later, you discover an S3 bucket has been publicly accessible the entire time - it was misconfigured two days after your last audit.
This isn’t a hypothetical. It’s one of the most common failure modes in cloud security, and it happens because of a fundamental mismatch: cloud infrastructure changes daily, but manual audits happen quarterly.
I’ve spent years working in cloud security and DevOps. The question I hear most often is: ”Do we really need Security Hub if we’re already doing audits?” The short answer is yes. The longer answer is more nuanced -because Security Hub alone isn’t enough either.
Let me break down both approaches, where each one fails, and the hybrid model that actually keeps environments secure.
Quick context: At re:Inforce 2025, AWS separated Security Hub’s CSPM functionality into its own named product - AWS Security Hub CSPM (Cloud Security Posture Management). It’s the same posture-checking engine you already know, now explicitly branded as a CSPM tool. I’ll refer to it as Security Hub CSPM throughout.
What “Manual Auditing” Actually Looks Like
When teams say they “audit their cloud security,” here’s what that usually means in practice:
- Spreadsheet trackers with a checklist reviewed every quarter (or annually, if we’re being honest)
- Ad-hoc CLI scripts - running aws configservice queries, pulling IAM credential reports, spot-checking security groups
- Console walkthroughs before compliance deadlines - clicking through the AWS console to visually verify configurations
- Annual penetration tests or third-party assessments that produce a point-in-time PDF report
This isn’t lazy engineering. For years, this was the standard. And in small environments with a handful of accounts, it can still work - barely.
Where it breaks down
Drift between audits. Cloud infrastructure isn’t static. Developers push changes daily. Someone opens port 22 for debugging on a Friday afternoon. By Monday they’ve moved on to something else, and that security group stays wide open for three months until the next audit catches it. Maybe.
- Scale kills it. Five AWS accounts? You can probably eyeball it. Fifty accounts across multiple regions? You’re now maintaining a spreadsheet with hundreds of rows, and you will miss things.
- Human error compounds. Different people audit differently. Checklists evolve informally. The engineer who built the original audit process leaves, and institutional knowledge walks out the door with them.
- It’s inherently reactive. You find problems only at audit time - not when they’re introduced. The gap between “misconfiguration created” and “misconfiguration discovered” can be days, weeks, or months.
What Security Hub CSPM Actually Does
Security Hub CSPM isn’t just “another dashboard” - it’s continuous, automated security posture evaluation that runs against your environment around the clock.
Core capabilities (practical terms, not marketing):
- Standards-based checks: CIS AWS Foundations Benchmark, AWS Foundational Security Best Practices, PCI DSS, NIST 800–53 - each maps to specific automated controls
- 400+ automated checks that run continuously across all enabled accounts and regions
- Central configuration - deploy across an entire AWS Organization from one place, not account-by-account
- Automation rules (introduced 2023) - auto-suppress, auto-update severity, or auto-escalate findings without writing Lambda functions
- EventBridge integration - trigger automated remediation workflows when specific findings appear
- Cross-account aggregation - single-pane view across dozens or hundreds of accounts
What it does NOT do:
- No business context. It can tell you a security group allows 0.0.0.0/0 inbound. It cannot tell you whether that’s intentional for a public-facing load balancer or an accident from a debugging session.
- No application-layer security. It checks infrastructure configuration. If your custom app has an IDOR vulnerability or a broken authentication flow, Security Hub CSPM won’t catch it.
- No “should this resource exist?” judgment. It evaluates how resources are configured, not whether they should exist in the first place.
- No organizational risk weighting. A finding in your sandbox account and a finding in your production account get the same severity score unless you manually adjust it.
Cost reality (because nobody talks about this):
Security Hub CSPM charges per security check per resource per month, plus a per-finding ingestion fee. For a mid-size organization (~50 accounts, standard workloads), expect roughly $200–500/month (as of mid-2025 pricing - verify against [current pricing](https://aws.amazon.com/security-hub/pricing/) before budgeting). Not expensive - but findings volume can surprise you if you don’t tune from Day 1.
If you’re already running a third-party CSPM (Wiz, Prisma Cloud, Orca), evaluate overlap before enabling - you may not need both, but you should have something running continuously.
When Automation Wins: Common Scenarios
These are patterns that play out repeatedly in cloud environments. I’ve seen variations of each across multiple organizations.
Scenario 1: “It was never right from the start”
A team deploys a new service. Somewhere in the Terraform, an S3 bucket gets created with overly permissive ACLs - maybe a copy-paste from a dev environment template that was never locked down. Nobody reviews the IaC diff closely enough. The quarterly audit doesn’t cover newly provisioned resources in detail because the checklist hasn’t been updated for the new workload. Months pass. The bucket was never configured correctly - but nobody noticed because no one was watching at deploy time.
Security Hub CSPM would flag this within hours via controls like `[S3.2] S3 buckets should prohibit public read access`. This is a prevention gap - the misconfiguration existed from Day 0, and only continuous monitoring catches what was wrong from birth.
Scenario 2: “It was fine last quarter - then someone changed it”
This is different from Scenario 1. Here, the configuration was correct. It passed the last manual audit legitimately. Then, two weeks later:
- A developer widens a security group to debug a connectivity issue and forgets to revert it
- An encryption-at-rest setting gets toggled off during a migration dry run
- An IAM policy gets a new statement attached that grants `s3:*` instead of `s3:GetObject`
Each change is individually small. Each was made by someone with good intentions. And each will sit unnoticed until the next scheduled review - which could be 90 days away.
Get Venkat Karthik Vanam’s stories in your inbox
Join Medium for free to get updates from this writer.
This is a drift detection gap. The system was healthy, something changed, and there was no mechanism to notice. Security Hub CSPM evaluates changes as they happen - not at the next scheduled audit.
When Automation Falls Short
Here’s where I see the opposite failure mode: teams that enable Security Hub CSPM, assume they’re covered, and stop thinking about security.
Scenario 3: “We turned it on and drowned”
A team enables Security Hub CSPM across their Organization with all standards activated. Day one: 3,000+ findings. The Slack channel fills with alerts. After a week of noise, the team starts ignoring everything. Six months later, Security Hub is technically running, but nobody has looked at the findings dashboard in months.
Automated tooling without a triage and suppression strategy is just expensive noise.
Scenario 4: “We were 100% compliant and still got breached”
Every Security Hub control shows “PASSED.” The compliance score is green across all standards. But the application itself has a business logic flaw - an endpoint that exposes data to unauthorized users through parameter manipulation.
Security Hub CSPM checked 400+ infrastructure controls and found nothing wrong. Because there was nothing wrong with the infrastructure. The vulnerability was in the application logic - a domain CSPM was never designed to cover.
When manual review is genuinely the right tool:
- Threat modeling - understanding attack vectors specific to your architecture
- ”Should this exist?” decisions - right-sizing, decommissioning, evaluating whether a resource still serves a purpose
- IAM trust policy reviews - understanding who should have cross-account access and why
- Compliance narratives - SOC 2 Type II evidence requires human-written explanations, not just automated pass/fail
- New service evaluation - when AWS launches a new service, Security Hub may not have controls for it yet. Human review fills the gap.
- Context-dependent exceptions - that security group allowing broad access might be intentional for a partner integration. Only a human can validate that.
The Hybrid Approach That Actually Works
After working across both over-automated and under-automated environments, here’s the model I recommend.
Start here (if you have zero automation today):
If you do nothing else: enable the AWS Foundational Security Best Practices standard with one automation rule to suppress known exceptions for your environment. That alone closes the majority of the gap between “we audit quarterly” and “we have continuous visibility.” Everything else below builds on this foundation.
Automated layer (continuous):
1. Enable Security Hub CSPM with AWS Foundational Security Best Practices. This is your always-on baseline.
2. Deploy via central configuration for multi-account Organizations. Don’t enable account-by-account or you’ll have coverage gaps.
3. Set up automation rules from Day 1. Before findings pile up, suppress known-acceptable patterns (e.g., intentionally public static website buckets). This prevents alert fatigue before it starts.
4. Automate the “easy wins.” Auto-remediate clearly wrong configurations: public S3 buckets in non-website accounts, unused security groups, unencrypted EBS volumes. Use EventBridge + Lambda or Security Hub automation rules.
5. Integrate with your ticketing system. Findings should become tickets with owners. If a finding doesn’t have a human accountable for resolving it, it will be ignored.
Manual layer (periodic + event-driven):
6. Quarterly deep-dives focused on what automation can’t do:
- IAM trust policy reviews (who should have access?)
- Resource purpose validation (does this infrastructure still serve a business need?)
- Architecture-level risk assessment (are we designing this correctly?)
7. Trigger manual reviews on specific events:
- New workload launches
- Major architecture changes
- Post-incident reviews
- New compliance requirements
8. Review new AWS services manually - don’t assume Security Hub covers everything. Check the [Security Hub controls reference](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html) to see what’s actually being evaluated.
Who owns this?
This is the question nobody writes about, but everyone argues about internally.
- Security/Platform team owns the automated layer: enabling Security Hub CSPM, defining suppression rules, building auto-remediation, and maintaining the standards configuration. They set the guardrails.
- Application/DevOps teams own the findings for their workloads: triaging, remediating, or requesting exceptions. They know the business context.
- Quarterly manual reviews should be joint: security brings the methodology, application teams bring the “why.”
If you centralize everything to the security team, findings get ignored because they lack context. If you push everything to dev teams, the automated baseline never gets maintained. Shared accountability with clear ownership of each layer is what makes this work.
Final Thoughts
Here’s what I think about when I look at where cloud security is heading: the “context gap” - the reason manual review still exists - is shrinking.
AI-driven remediation is getting smarter. Tools are starting to infer intent from resource naming, tags, architecture patterns, and deployment history. Today, Security Hub CSPM tells you “this security group is open” and a human has to decide if that’s intentional. As these tools mature, the tooling might say “this security group is open, but based on the attached load balancer and CloudFront distribution, this is likely intentional - here’s a confidence score.”
When that happens, the manual layer doesn’t disappear - but it shrinks. The quarterly review becomes less about “is this configured correctly?” and more about “is our architecture the right one?” The human role shifts from auditor to strategist.
Until then, though, we live in the messy middle. And in the messy middle, the answer is both.
If you’re still relying entirely on quarterly spreadsheet audits in 2026, you’re leaving gaps that can persist for months. If you think enabling Security Hub CSPM alone makes you secure, you’re leaving blind spots that no automated control can cover.
The right question isn’t “which one?” - it’s “who owns each layer, and how do we make the handoff seamless?”
What does your security posture setup look like? Are you fully automated, fully manual, or somewhere in between? I’d love to hear about your approach in the comments.
