Cloud Security Assessment
Configuration analysis, architecture review and hands-on penetration testing across Azure, Microsoft 365, Entra ID, AWS, GCP and StackIT, so you know what an attacker could actually do in your environment, not just what is misconfigured.
Your cloud provider's security is not your security
Microsoft, Amazon and Google run some of the best-defended infrastructure in the world. None of that covers the way your organisation has configured it.
Under the shared responsibility model, the provider secures the platform. Everything you build on top, including identities and permissions, network design, storage exposure, secrets handling and workload configuration, is yours. That is also where almost every cloud incident originates: not in a vulnerability in the platform, but in a configuration that made sense in isolation and turned into an attack path once combined with three others.
A cloud security assessment examines the side of the line you are responsible for.
The platforms we assess
Most organisations are not on one cloud. We assess hyperscale, European and private environments, and the connections between them.
Microsoft Azure
Subscriptions, resource configuration, network design, storage, key management and workload security.
Microsoft 365
Tenant configuration, Exchange Online, SharePoint and OneDrive exposure, sharing and collaboration settings.
Entra ID
Identity and access management, role assignments, conditional access, authentication methods and privileged access.
Amazon Web Services
Accounts and organisations, IAM, storage, network segmentation and service configuration.
Google Cloud Platform
Projects and organisation policy, IAM, storage and network controls.
StackIT
European cloud infrastructure, assessed to the same depth as the hyperscalers.
Containers and Kubernetes
Cluster configuration, workload isolation, RBAC, registry and supply chain, and escape paths from container to host or control plane.
Private and hybrid cloud
Including the connections between your on-premises estate and your cloud tenants.
StackIT and European cloud. Organisations moving workloads to European providers for data sovereignty reasons should not have to accept a lower standard of security assurance to get there. We assess StackIT environments to the same depth as Azure or AWS.
Three disciplines in one assessment
A cloud environment cannot be understood from one angle. A configuration check misses design flaws. An architecture review misses what is actually deployed. A penetration test without either wastes time rediscovering the environment. We combine all three in a single engagement, and each one informs the others.
- 01
Configuration analysis
We examine the actual state of your environment against recognised benchmarks and the security baselines published by each cloud vendor: identity and permission structures, network and segmentation controls, storage exposure, logging and monitoring coverage, encryption and key management, and workload configuration. This establishes what is deployed and where it deviates from good practice.
- 02
Architecture review
Configuration tells you what exists. Architecture tells you whether it should. We review how your environment is designed: tenant and account structure, trust relationships, segmentation between environments, the connections between cloud and on-premises, and where your crown jewels sit relative to everything that can reach them. Design flaws do not show up as misconfigurations, and they are the ones that are expensive to fix later.
- 03
Penetration testing on authentication and application level
Then we test. Our testers work hands-on against the authentication layer and the application layer within your cloud environment, probing authentication and authorisation mechanisms, attempting privilege escalation through permission and role structures, and chaining findings into the attack paths that individual issues do not reveal on their own. This is where the assessment stops describing your environment and starts demonstrating what someone could do inside it.
The output is not three reports. It is one picture: what is misconfigured, why the design allows it, and how far someone could get.
In the cloud, attackers do not break in. They sign in.
Cloud compromises rarely begin with an exploited vulnerability. They begin with an identity: a service principal with more permissions than anyone remembers granting, a conditional access policy with an exemption that was meant to be temporary, legacy authentication still enabled on one protocol, a consent grant nobody reviewed, or a role assignment chain that quietly leads to global administrator.
Identity gets particular attention in every CREDS cloud assessment. We map the permission structures in Entra ID, AWS IAM and GCP IAM, look for escalation paths through role and policy combinations, and test whether your authentication controls hold up in practice rather than on paper.
Our testers do this work daily in red team engagements, where identity is usually the route to the objective. The same expertise applies here.
What your cloud security tooling will not tell you
Most organisations already have some visibility: Microsoft Defender for Cloud, AWS Security Hub, Google Security Command Center, or a CSPM product. These are useful, and we will not duplicate what they already do.
What they do not do is establish consequence. They evaluate resources against rules, one at a time. They do not combine a slightly over-permissioned service account with an unsegmented network and an exposed storage container to show you that together those three produce a route to your production data.
That is the difference between a list of findings and an attack path. A scanner tells you what is wrong. An assessment tells you what it is worth fixing first, and why.
Cloud security tooling
A CREDS assessment
Evaluates resources against rules
Tests what those resources allow when combined
Findings rated by severity
Findings prioritised by demonstrated attack path
Continuous, automated, rule-based
Human testing against your specific architecture
Tells you what is misconfigured
Tells you what someone could reach
What we assess against
Testing is only comparable if its yardstick is defined. We assess against published benchmarks, the security baselines of each cloud vendor, and your own risk profile.
CIS Benchmarks. Platform-specific hardening benchmarks for Azure, AWS, GCP and Microsoft 365.
Cloud vendor security baselines. Including the Microsoft Cloud Security Benchmark, the AWS Well-Architected security pillar and Google Cloud security foundations.
NIST guidelines. Where relevant to identity, key management and logging.
Your own risk profile. The assessment is weighted toward the environments and data that matter to your business, not spread evenly across everything.
CREDS checklists. Developed from our own engagements, covering the issues that recur in practice but are not yet in any published benchmark.
A cloud environment changes every week. Your assessment should keep up.
A point-in-time cloud assessment is accurate on the day it is delivered and drifting by the end of the month. New resources get deployed, permissions get granted to unblock someone, a policy exemption gets added and never removed. The environment you had assessed is not the environment you are running.
So we treat the assessment as a baseline, not a conclusion.
The baseline assessment
The full engagement: configuration analysis, architecture review and hands-on penetration testing across your cloud environments. This establishes where you actually stand and produces the remediation roadmap.
Monthly reviews, supported by ART
After the baseline, our ART platform runs monthly reviews of your cloud environments, included with the assessment. Between full assessments that means you see configuration drift as it happens rather than discovering it at the next annual review, new and changed resources are assessed as they appear, and remediation from the baseline is verified rather than assumed.
The baseline tells you where you stand. The monthly reviews tell you whether you are still standing there.
The monthly reviews are included with the assessment, not a separate subscription.
You are not waiting in the dark
Daily start and stop notifications
You are notified when assessment activity begins and ends each day, so your team always knows whether traffic against your environment is us or someone else.
High-risk findings go out immediately
If we find something serious in your environment, you hear about it when we confirm it, not in the report.
We re-aim the assessment with you
An assessment is a time-boxed effort, so there is always a choice about where the remaining hours go. As findings emerge we discuss with your team where to focus next. A permission structure that looks interesting in one subscription often makes another area more worth examining than the original plan assumed.
What you receive
A draft report, discussed before it is final. So that a misunderstanding about your environment gets corrected while there is still room to correct it.
The full report. Every finding, its impact, how to reproduce it and specific remediation guidance.
Attack path analysis. The routes through your environment that individual findings combine to create, which is usually the section that changes remediation priorities.
An architecture review. Covering the design-level issues that no configuration check surfaces.
A summary for your stakeholders. A readable account for the people who approve the work rather than the people doing it.
A prioritised remediation roadmap. Ordered by what actually reduces risk.
Your findings, in one place
Findings are published to the CREDS client portal, where your team can work with them rather than transcribing them out of a document. Findings carry their impact and remediation advice, retests can be requested once fixes are deployed, and findings flow into the tools your engineers already use, including Jira and ServiceNow.
Where monthly ART reviews are in place, their output appears in the same portal, so the baseline and everything after it sit in one timeline.
Questions about cloud security assessments
Which cloud platforms do you assess?
Is this a configuration review or a penetration test?
We already use Defender for Cloud or Security Hub. What does this add?
Will the assessment disrupt our production environment?
Do you assess Microsoft 365 as well as Azure?
How often should we reassess?
How long does an assessment take?
Can you test the connection between our cloud and on-premises environment?
Find out what is actually reachable in your cloud
Tell us which platforms you run and how your environment is structured, and we will scope an assessment that fits.