Cloud platforms are secure by design. Configuration is still on you.
Microsoft, AWS and Azure secure the infrastructure underneath. Everything above that line — identity, access, sharing and logging — is configured by your team, and that's where nearly every cloud incident we investigate actually starts.
The shared-responsibility line is where things go wrong.
Microsoft 365, Azure and AWS all operate under a shared-responsibility model: the provider secures the physical infrastructure, the hypervisor and the core platform, and the customer is responsible for identity, access control, data classification and how services are configured on top. That line is well documented, but in practice it's poorly understood, and the assumption that 'it's in the cloud so it's secure' still causes real incidents.
Identity is usually the first place this shows up. Entra ID tenants accumulate privileged roles over time as staff change jobs, projects wrap up and access is granted but never revoked. Global administrator rights sitting with accounts that no longer need them, break-glass accounts with weak or shared passwords, and legacy authentication protocols left enabled purely for compatibility with an old application are all common findings that bypass modern MFA controls entirely.
Conditional access is frequently half-configured rather than absent. Policies exist, but they don't cover guest accounts, they exempt certain user groups for reasons nobody remembers, or they were built before the tenant had the licensing to enforce them properly and were never revisited once it did. A policy that looks comprehensive in the admin centre can still leave a meaningful gap in practice.
Data exposure is the other recurring theme. SharePoint and OneDrive sharing links set to 'anyone with the link' rather than restricted to the organisation, Teams channels created with external guests who were never removed, and publicly accessible AWS S3 buckets or Azure storage accounts are all things that don't show up on an external scan because they're configuration decisions, not vulnerabilities in the traditional sense.
Logging and monitoring gaps compound all of this. Many tenants don't retain sign-in logs for long enough, don't forward them to a SIEM, or don't have alerting configured for the specific events that would flag a compromised account — impossible travel, new mail forwarding rules, or a sudden change in conditional access policy. Without that visibility, a compromise can sit undetected for weeks.
- Privileged and administrative accounts accumulated without review
- Conditional access policies with unintentional gaps or exemptions
- Data shared externally or made public without anyone noticing
- Sign-in and audit logging not retained or alerted on effectively
We test configuration, identity and data exposure together.
We start by agreeing which platforms and tenants are in scope — Microsoft 365 and Entra ID, Azure subscriptions, AWS accounts, or a combination — and confirm the testing approach sits within each provider's published policy for security assessments. Most configuration review work is permitted without prior notification, but we check and document this before anything starts.
For Microsoft 365 and Entra ID, we review the tenant against the relevant CIS benchmark, covering identity and access management, conditional access coverage, privileged role assignment, guest account handling, mail flow security and sharing defaults across SharePoint, OneDrive and Teams. We look specifically for legacy authentication methods still enabled and for break-glass accounts that aren't properly protected.
For Azure and AWS, we assess identity and access management configuration, network and storage exposure, logging and monitoring coverage, and adherence to the relevant CIS benchmark for each platform. This includes checking for publicly accessible storage, over-permissive security groups or network security rules, and service accounts holding more privilege than their function requires.
Where the engagement includes an offensive element rather than configuration review alone, we test what's achievable from a low-privilege or compromised-account starting point — privilege escalation paths, lateral movement between cloud resources, and whether logging would actually detect the activity we're generating. This gives a realistic answer to 'what happens if one account is compromised' rather than a theoretical one.
Findings are mapped against the relevant CIS benchmark and the provider's shared-responsibility guidance, so it's clear which fixes sit with your team and which, if any, require a support ticket with the provider. We prioritise by real impact — an exposed storage bucket with customer data outranks a benchmark item that's technically non-compliant but low risk in your specific setup.
- Testing approach confirmed against each provider's published policy first
- Configuration reviewed directly against CIS benchmarks for the platform
- Identity, conditional access and privilege reviewed as a single thread
- Findings mapped to shared-responsibility ownership, not just severity
Everything in the engagement, set out up front.
A scoped review of your cloud tenants covering identity, configuration, data exposure and logging.
CIS benchmark review
Configuration assessed directly against the relevant CIS benchmark for Microsoft 365, Azure or AWS.
Identity and privilege audit
Review of administrative roles, privileged accounts, break-glass accounts and stale access.
Conditional access assessment
Coverage check across user groups, guest accounts and legacy authentication protocols.
Data exposure review
Sharing settings and public access checks across SharePoint, OneDrive, Teams and cloud storage.
Logging and alerting review
Assessment of sign-in and audit log retention, SIEM forwarding and detection coverage for key events.
Provider policy alignment
Confirmation that testing activities sit within Microsoft, AWS and Azure's published security testing rules.
What you receive.
- Risk-rated findings report mapped to CIS controls
- Executive summary for leadership and auditors
- Privileged account and role inventory
- Conditional access gap analysis
- Data exposure findings with evidence
- Logging and detection coverage summary
- Remediation guidance by ownership (customer vs provider)
- Retest report confirming remediation
- 30-minute debrief call to walk through results
Built for organisations that need the work done properly.
Organisations migrated to Microsoft 365 or Azure
Businesses that moved to cloud identity and productivity platforms without a configuration review at the time.
Companies running production AWS or Azure workloads
Teams deploying infrastructure as code or manually, without independent verification of the resulting security posture.
Firms needing evidence for compliance or insurance
Organisations required to demonstrate cloud configuration has been independently assessed against a recognised benchmark.
Businesses that have grown their tenant organically
Organisations where accounts, guest access and sharing settings have accumulated without a central owner reviewing them.
What changes once the work is done.
What changes once identity, configuration and data exposure have been reviewed.
Privileged access brought under control
Administrative roles reduced to who genuinely needs them, with break-glass accounts properly protected.
Conditional access closing real gaps
Policies extended to cover guest accounts and legacy protocols that previously bypassed MFA.
Public data exposure removed
Externally shared links, guest access and public storage brought back to an intended, reviewed state.
Detection capability confirmed
Logging and alerting verified to actually catch the events that would indicate a compromised account.
Clear ownership of remaining risk
A findings list mapped to shared-responsibility, so it's clear what sits with your team versus the provider.
A benchmark to measure future change against
A dated CIS-aligned baseline to compare against after platform changes or tenant growth.
What the cloud providers will and won't let you test.
Both Microsoft and the major cloud providers publish policies setting out what customers are permitted to test against their own tenants and subscriptions without prior authorisation. In general, configuration review, identity and access testing, and most forms of application-level testing against your own resources are permitted. Certain activities — simulating denial-of-service conditions, testing shared or multi-tenant infrastructure, or scanning IP ranges that don't belong to you — require separate written permission or are excluded entirely.
This matters because it shapes what a cloud security engagement can honestly claim to cover. We're transparent with clients about the difference between testing we can run directly against your tenant and configuration we can only assess through review, and we agree the boundary before work starts rather than discovering a restriction partway through.
It's also worth being clear that a cloud security review is not a substitute for the provider's own security tooling — Microsoft Secure Score, AWS Security Hub or Azure Security Centre all have a role to play, and we often find they've been switched on but never actioned. Part of our value is turning those existing signals, plus our own testing, into a single prioritised list rather than leaving three separate dashboards for someone to reconcile.
We carry out this work for clients across Chesterfield, Sheffield, Derby, Nottingham, Leeds, Manchester, Birmingham and London, and the recurring theme is the same across Microsoft 365, Azure and AWS environments alike: the platform itself is rarely the weak point. The way identity, sharing and logging have been configured on top of it usually is, and that's entirely within your control to fix.
Questions we are asked most often.
What's the difference between cloud security testing and infrastructure penetration testing?
Infrastructure testing looks at exposed services from the outside in. Cloud security testing reviews the configuration of the platform itself — Microsoft 365, Entra ID, Azure or AWS — including identity, privilege, conditional access and data exposure settings, most of which aren't visible from an external scan at all. Many clients commission both together for full coverage.
Do you need admin access to our tenant to test this?
Yes, typically read-only or configuration-review access at global reader or an equivalent scoped role, agreed with you in advance. This is a configuration and identity assessment rather than an attempt to break in from outside, so it relies on visibility into settings that only privileged access provides.
Are you allowed to test AWS and Azure without breaching the provider's terms?
Yes, within limits. AWS and Azure both permit configuration review and most forms of testing against your own resources without prior notification, though a small number of activities such as certain denial-of-service simulations or testing shared infrastructure require separate authorisation. We work within each provider's published testing policy and agree the boundaries with you before starting.
What frameworks do you test against?
We benchmark against the CIS Controls for Microsoft 365, Azure and AWS, alongside each provider's own security baseline and the shared-responsibility model that defines what the provider secures versus what you're responsible for configuring. Where you hold specific compliance obligations, such as Cyber Essentials or ISO 27001, we map findings against those too.
Can you test our conditional access and MFA setup specifically?
Yes, this is usually one of the highest-value parts of the engagement. We review conditional access policies for gaps, coverage of privileged and guest accounts, break-glass account handling, and whether legacy authentication protocols that bypass MFA are still enabled anywhere in the tenant.
Does this cover our data stored in SharePoint, OneDrive and Teams?
Yes, we review sharing settings, external access policies and publicly accessible links across Microsoft 365, since misconfigured sharing is one of the most common causes of accidental data exposure we find. The same principle applies to publicly accessible AWS S3 buckets and Azure storage accounts if those are in scope.
How long does a cloud security assessment take?
Most single-tenant Microsoft 365 and Entra ID reviews take three to five days. Adding Azure or AWS infrastructure, or reviewing multiple subscriptions and accounts, extends that depending on the size and complexity of the environment. We agree scope and timescale together before the engagement starts.
What happens if you find an actively exploitable exposure?
We contact you immediately rather than waiting for the final report, particularly for anything like a publicly accessible storage bucket containing sensitive data or an over-privileged account with no MFA. The written report follows once testing is complete, but urgent exposures are flagged the same day.
Penetration testing
The full range of manual-led testing services, from web applications to external infrastructure.
Managed security
Continuous monitoring of the identity and logging signals this review checks are actually in place.
Vulnerability management as a service
Ongoing tracking to keep infrastructure patched and configuration drift under control between reviews.
Not sure how your tenant configuration actually stacks up?
Tell us which platforms you run and we'll scope a straightforward cloud security review, no pressure and no obligation.
Scope a cloud security review