Provider best-practice baselines
Every hyperscaler ships an opinionated security baseline of its own, distinct from the CIS consensus: the AWS Foundational Security Best Practices standard in Security Hub, the Microsoft Cloud Security Benchmark in Defender for Cloud, and the Security Health Analytics detectors in Security Command Center. These encode the provider's current guidance for how its own services should be configured, and they reach into service-specific defaults and newer features that a cross-industry benchmark never covers. Left to run untended, they emit thousands of findings and a single rolled-up secure score that climbs but never reaches a hundred percent, so teams learn to glance at the number and mute the dashboard rather than work it. This sub-topic is about reading that provider signal properly: confirming the posture service is switched on across every account, subscription, project, and region; separating the findings that represent real exposure from the long tail of low-risk noise; and governing suppressions so an accepted risk is a documented decision and not just a way to quiet an alert. Our review reads that signal for you and reports where it is unmanaged, muted, or never enabled — it does not change any of your cloud configuration.
Overview
What this check looks like in practice
Beyond CIS, each cloud provider ships its own security posture service — AWS Security Hub, Microsoft Defender for Cloud, and Google Security Command Center. These tools generate real signal, but on their own they produce long, unranked lists that teams learn to ignore. We read the provider's own posture findings, deduplicate them, and translate them into a prioritized set of actions.
Why it matters
The provider's baseline is the most authoritative statement of how its own services should be configured, and it updates as the platform ships features — so a resource that passed last quarter can fail a control the vendor added last week without anyone touching that resource. An attacker benefits from exactly the findings teams have trained themselves to ignore: a public snapshot, a permissive default policy, a disabled protection buried in a backlog of thousands. Because these posture services are enabled per account or per subscription rather than everywhere by default, the most dangerous gaps are usually the accounts, projects, and regions where the service was never turned on at all — blind spots that never generate a finding to overlook. Auditors and cyber-insurers increasingly ask for the secure score and the underlying posture report directly, which turns an unmanaged, muted, or partially-enabled posture service into a finding in its own right rather than a convenience.
What we assess
What we look for
- Native posture services enabled organization-wide through a delegated administrator or management-group assignment, not switched on account by account or subscription by subscription
- The provider's own best-practice standard active alongside CIS — AWS Foundational Security Best Practices, the Microsoft Cloud Security Benchmark, and Security Health Analytics — not just the CIS pack
- Secure score and control findings triaged by real exposure and asset criticality rather than chased as a single headline percentage
- High- and critical-severity findings that have sat open well past any reasonable remediation window for their severity
- Suppressed, muted, and risk-accepted findings reviewed to confirm each was a deliberate, documented decision with a named owner and an expiry
- Coverage gaps where whole accounts, subscriptions, projects, regions, or resource types fall outside the posture service entirely and generate no findings
- Whether findings feed a central hub or SIEM with an accountable owner instead of living in per-account consoles nobody opens
- Whether the free foundational tier is sufficient, or a paid tier (Defender CSPM, SCC Premium/Enterprise) is warranted where coverage like agentless scanning or attack-path analysis is missing
Across your clouds
AWS, Azure & Google Cloud
AWS
AWS Security Hub with the AWS Foundational Security Best Practices standard as the provider's opinionated baseline, evaluated against AWS Config rules; the aggregated Security Hub security score and per-control pass/fail status; delegated-administrator and central configuration for organization-wide, auto-enrolling coverage; and Trusted Advisor security checks plus the Well-Architected Tool security pillar as complementary best-practice signal.
Azure
Microsoft Defender for Cloud secure score, driven by the Microsoft Cloud Security Benchmark applied as the default Azure Policy initiative across management groups and subscriptions; security recommendations and the regulatory-compliance dashboard; and the split between the free foundational CSPM and the paid Defender CSPM plan, which adds agentless scanning, attack-path analysis, and broader resource coverage.
Google Cloud
Security Command Center with Security Health Analytics detectors as Google's best-practice baseline, alongside posture and risk findings mapped to compliance standards; organization-level activation so every folder and project is in scope by inheritance; and the Standard versus Premium/Enterprise tiers, since many detectors and continuous scanning require a paid tier.
Example finding
Defender for Cloud enabled on the main subscription only, with three subscriptions outside it and a 61% secure score nobody owns
Risk: The subscriptions outside the posture service generate no findings at all, so their misconfigurations are invisible rather than merely low-priority — and the visible score drifts sideways because no one is assigned to work the recommendations behind it, so it functions as a dashboard nobody reads.
Fix: Enable the posture service at the management-group level so every current and future subscription inherits it, apply the provider's best-practice benchmark as the default policy initiative, and assign an owner to triage high-severity recommendations on a set cadence with remediation windows by severity.
Remediation
How to close it
- 1 Turn the posture service on across the whole organization from a single control point — a Security Hub delegated administrator, a Defender for Cloud management-group assignment, or organization-level Security Command Center — so new accounts, subscriptions, and projects inherit it automatically.
- 2 Enable the provider's own best-practice standard (AWS Foundational Security Best Practices, the Microsoft Cloud Security Benchmark, Security Health Analytics) alongside CIS, and confirm the underlying evaluation engine — AWS Config, Azure Policy — is recording in every region and subscription.
- 3 Aggregate findings into one hub or SIEM and assign a named owner, so posture signal lands somewhere accountable instead of in per-account consoles nobody opens.
- 4 Triage the backlog by real exposure — internet-reachable and sensitive-data resources first — rather than chasing the secure-score percentage, and set remediation windows by severity.
- 5 Govern suppressions: review every muted or risk-accepted finding, require a documented owner and rationale, and expire acceptances so they are revisited rather than left permanent.
- 6 Where the free tier leaves material gaps, evaluate the paid posture tier (Defender CSPM, SCC Premium/Enterprise) for the coverage — agentless scanning, attack paths, continuous detection — the baseline needs.
Questions
Isn't a good secure score enough to prove we are secure?
No. Secure score is a weighted average that rewards volume, so a high number can hide a handful of critical, internet-facing findings while a low number is often dominated by low-risk noise. We read the findings behind the score and rank them by real exposure, so the priority is the risk, not the percentage.
How is this different from the CIS Benchmark part of the assessment?
CIS is a cross-industry consensus baseline that applies broadly; the provider's baseline is the platform vendor's own service-specific guidance, and it changes as new features ship. They overlap but neither is a superset — the provider standard catches defaults and services CIS never covers — so we read both and deduplicate where they agree.
What about findings our team has already suppressed?
Suppression is legitimate; not every finding warrants action. But a muted finding with no owner or rationale is indistinguishable from a risk someone hid to clean up the dashboard. We review the suppressions and accepted risks to confirm each was a deliberate, documented decision, because an un-governed mute list is where real exposure quietly lives.
More in configuration & posture
See where you stand
A health check finds and prioritizes real exposure. It is not a certification or a promise you will never be breached — closing the findings is what changes your risk.
Related domain surfaces
The rest of what we assess
The same read-only assessment covers every domain — see what else it looks at.
