Cloud Security Assessment
Most cloud incidents are not breaches of the platform. They are configurations someone set once, correctly for that day, and nobody revisited.
We review how your cloud and SaaS estate is actually configured — identity, permissions, exposure, logging and the services nobody remembers turning on — and tell you which findings could be chained into a real compromise. The output is a prioritised list of what to fix, not a benchmark score.
Four situations that bring people here
You migrated and never reviewed
The move was delivered under time pressure by people focused on making it work, not on making it defensible.
Permissions have accumulated
Roles were granted for a project and never withdrawn. Nobody can now say who can reach what.
SaaS arrived without anyone deciding
Departments bought their own tools and connected them to your identity provider and your data.
Someone is asking for assurance
A customer, insurer or auditor wants evidence that the cloud environment is controlled.
Where cloud environments actually fail
Identity and entitlement
Who and what can do what. Standing privilege, service accounts, role assumption paths, conditional access, and administrative access that bypasses it.
Configuration and posture
Reviewed against recognised hardening benchmarks, with the findings interpreted for your environment rather than handed over as a raw scanner export.
Exposure
What is reachable from the internet, intentionally or otherwise — storage, management interfaces, APIs and forgotten test environments.
Data and storage
Where data sits, how it is encrypted, who can read it, and whether deletion actually deletes.
Logging and detection coverage
Whether the events you would need after an incident are being captured, retained and actually looked at.
Tenant and SaaS estate
Your productivity tenant and the applications connected to it: sharing defaults, third-party app consent, and the integrations nobody inventoried.
Findings you can act on, ranked by what they lead to
Scope
Which accounts, subscriptions, tenants and applications are in, and what read access we need to see them.
Collect
Configuration and identity data gathered directly from the platforms, supported by tooling but reviewed by hand.
Analyse
We look for the chain rather than the checklist item — the combination of a permission, an exposure and a missing control that together mean something.
Report and debrief
Written findings with reproduction detail for the engineers, and a plain summary for whoever has to fund the fixes.
What you receive
- A findings report ranked by realistic impact, with the evidence needed to reproduce and verify each one
- An identity and permissions picture showing the access paths that matter, including the ones nobody intended
- A benchmark comparison where a recognised standard applies, with deviations explained rather than merely flagged
- A remediation plan sequenced so the changes that reduce most exposure come first
- A technical debrief with the team who will make the changes
Timing and cost
Cost depends on how many accounts and tenants are in scope, how many platforms are involved, and whether we are looking at infrastructure, the SaaS estate, or both. A single cloud account is a very different exercise from a multi-account estate with federated identity.
We do not publish packages or rates. Every engagement begins with a short call, followed by a written scope and a fixed price for that scope before any work starts.
What we need to scope it
Which platforms you use, roughly how many accounts or subscriptions exist, whether identity is federated, and whether a previous assessment has been done.
Common questions
Is this the same as a penetration test?
What access do you need?
Do you just run a scanner?
Can you fix what you find?
Will this disrupt anything?
Tell us what your estate looks like
Even roughly. Thirty minutes is usually enough to tell you whether this is worth doing now and what it would cover.
Start with a scoping call