We run Security Hub CSPM as the evidence layer on the environments we operate: continuous, account-level configuration and security checks against the AWS Foundational Security Best Practices standard plus CIS, PCI DSS and NIST; GuardDuty, Inspector and Macie findings normalised into the AWS Security Finding Format and correlated so the highest-priority issues surface first; and automation rules with EventBridge actions to route findings straight into triage. It depends on AWS Config recording resources, and it only reports on findings generated after it is enabled — so we enable it across every supported Region at the start, not after an incident.
Any environment where someone will eventually ask for proof: payments and collections platforms in PCI-DSS scope, regulated government workloads, and SaaS products facing enterprise procurement or investor due diligence.
Why posture management, not another scanner
Most organisations can tell you they use AWS. Far fewer can tell you, on any given morning, whether their accounts still match the configuration they were signed off with. That gap is where incidents live. Security Hub closes it by running continuous checks against recognised standards — AWS Foundational Security Best Practices, CIS, PCI DSS and NIST — across every account and Region, and consolidating what it finds into one prioritised view.
The distinction that matters commercially is between asserting security and evidencing it. An annual audit produces a document. Continuous posture management produces a tracked score, a finding history and a remediation record, which is what an enterprise procurement questionnaire, a PCI assessor or an investor doing technical due diligence is actually asking to see.
How we operate it
We enable it across every supported Region at the outset rather than after an incident, because Security Hub only reports on findings generated after it is switched on — a detail that quietly undermines a lot of retrofitted deployments. AWS Config must be recording resources for the checks to work, so that dependency is part of the build rather than an afterthought.
GuardDuty, Inspector and Macie findings are normalised into the AWS Security Finding Format and correlated, so the highest-priority issues surface first instead of arriving as three separate streams. Automation rules and EventBridge actions route findings into triage automatically. What you receive is a prioritised list with named owners and dates, reviewed on a regular cadence — not an unfiltered console export. We measure the engagement on findings closed, not findings counted.
Where it earns its place
Any environment where somebody will eventually ask for proof: payment and collections platforms inside PCI-DSS scope, regulated government workloads, and SaaS products facing enterprise procurement or investor due diligence. In those settings the security question is not whether you take it seriously — everyone says yes — but whether you can produce evidence covering the period in question. This is how we produce it.
It does not replace penetration testing. A test probes at a point in time; posture management catches the misconfiguration introduced three weeks later. Mature programmes run both, and we will tell you when the second one is the gap.
We already have AWS. Why add this?
Because having AWS is not the same as knowing your posture. Security Hub continuously checks your accounts against recognised benchmarks and surfaces drift, which is what turns security from an annual assertion into something you can evidence on any given day.
Does this replace a penetration test?
No. A test is a point-in-time probe; continuous posture management catches the misconfiguration introduced three weeks later. They answer different questions and mature programmes run both.
What do we actually receive?
A prioritised view of real findings with remediation owners and dates, reviewed with you on a regular cadence — not an unfiltered console dump. The measure of success is findings closed, not findings counted.