Cloud Security Configuration Assessment

We fix the CIS Foundations Benchmark version per provider during scoping, and controls you cannot meet stay visible on the scorecard as accepted deviations with a reason rather than being quietly marked as passed. Your AWS accounts, Azure subscriptions and GCP projects each get the benchmark published for that platform, agreed in the first phase alongside the read-only roles and the regions, services and maintenance windows you want excluded. Pinning the version matters because control numbering shifts between releases: if we grade you against one release and your auditor reads another, the references stop lining up and you spend the audit reconciling paperwork. The same discipline runs in the other direction. Where an automated check fires on something that is not a real problem, the false positive is discarded with a documented reason rather than silently, and where your own internal cloud policy differs from the benchmark, that deviation is flagged too, so the next assessment opens from a written position instead of reopening the same argument.

Read-only assessor roles are all we take, and that boundary does limit what the assessment can tell you, which is worth understanding before you buy it. We provision the roles with you in the first phase, and every change to your estate stays in your hands: we write the fix steps, your engineers apply them during your own change windows. What those roles read is configuration. They see identity and policy, network rules, storage exposure and public access settings, encryption and key rotation on data stores, and whether logging is switched on and retained. They do not read the contents of your data stores, decrypt anything, or reach into running application logic, so a broken authorisation check inside your own code will not surface here. Read-only access also cannot prove that an over-permissive role is exploitable in practice, because proving that means using it. Our Cloud Penetration Testing service covers that question.

We rank by real exposure and blast radius, not by the volume the automated checks produce. A first pass across a mature estate routinely flags hundreds of items, and much of that is duplicated across accounts or technically true but unreachable, which is why an unfiltered scanner dump tends to sit unread. The manual review phase exists for this. We confirm by hand which buckets and endpoints are genuinely reachable from the internet, trace wildcard permissions to where they actually lead, check encryption and key rotation on data stores, verify multi-factor and conditional access on privileged identities, and discard false positives with a written reason so nobody re-litigates them next quarter. What survives is rated on exposure and blast radius, listed with the affected resource identifiers, and grouped by the team that owns the account, so the report splits into work queues. We then walk your engineering team through the top items, because a report read cold rarely lands the same way.

A retest is included in the engagement: once your changes land we re-run the checks and reissue the scorecard showing the movement, so you can see which controls actually closed rather than taking the fix on trust. That said, be honest about what a scorecard is. It is a photograph of one moment, taken from a timestamped evidence set, and a console change made the week after will not appear in it. Drift is the normal condition of a cloud estate, not a failure on your side, which is why the hardening runbook is written to outlive the report: fix guidance is mapped to each control with infrastructure-as-code snippets, so the correction goes into the pipeline that builds the environment instead of being clicked in once. Teams who fold the same benchmark checks into their own deployment pipeline and reassess at an agreed interval hold their score; teams who only remediate by hand watch it slide back.

This assessment tells you which settings are wrong across your estate; a cloud penetration test tells you how far an attacker gets by abusing them. The difference is breadth against depth. Here we read configuration across identity, networking, storage, logging and compute in every in-scope account, grade it against the benchmark, and verify the risky items by hand, but we stop short of exploiting anything. Our Cloud Penetration Testing service begins where this one ends: it follows identity attack paths from a foothold, escalates privileges across roles, pivots between services, and traces the blast radius of a leaked credential, with a proof of concept behind each finding. Which comes first depends on where you are. If your accounts have never been benchmarked, start here, because paying for exploitation of a public bucket teaches you little. If your baseline is already clean, the penetration test is the sharper spend.