Cloud security reviews and fixes for AWS, Azure and Google Cloud accounts

A cloud security assessment reviews how your accounts, identities, networks, data stores, secrets, encryption and logging are configured, and ranks what needs fixing. We combine automated configuration scans against provider benchmarks with manual review of IAM policies, network paths and, where relevant, Kubernetes clusters. You receive a written report explaining each finding and its likely impact, plus a prioritised remediation plan your team or ours can work through.

Only partly. Under the shared responsibility model, AWS, Microsoft Azure and Google Cloud secure their data centres, hardware and underlying platform, while you remain responsible for how you configure and use it. That includes who has access, which ports are open, whether storage is public, how keys are managed and whether logging is switched on. Managed services move some tasks, such as database patching, to the provider, but access and data settings stay with you. That customer side is where our work sits.

We start by recording who and what actually uses each permission, then replace broad roles with narrower ones that match real tasks. People sign in through single sign-on with multi-factor authentication and assume roles rather than holding personal keys. Applications and pipelines get their own workload identities scoped to the resources they touch. Administrative access is time-bound where the platform supports it, and a sealed break-glass account covers emergencies.

You can tell from the provider's audit logs, which record every API call made with that key, provided logging was enabled before the leak. We deactivate the key first, then review its activity in AWS CloudTrail, the Azure Activity Log or Cloud Audit Logs on Google Cloud from the moment it was exposed. We look for calls from unfamiliar addresses or regions, new users or keys, permission changes, bulk data reads and unexpected compute such as crypto-mining instances, and agree containment steps with you.

Workloads should sit in private subnets by default, with only load balancers or gateways exposed to the internet and every other path explicitly allowed. We separate production from non-production, usually in different accounts or projects, and restrict traffic between tiers so a web server cannot reach systems it does not need. Managed services are reached through private endpoints, and administrative access goes through audited session tooling rather than open SSH or RDP ports.

Many cloud storage and database services encrypt data at rest by default, but that alone rarely answers the questions customers and auditors ask. The important decisions are who controls the keys, who is allowed to use them, whether backups and snapshots are covered, and whether every connection uses TLS. We configure customer-managed keys where you need that control, restrict key usage policies and confirm encryption in transit between services.

Cloud security posture management is the continuous checking of cloud configuration against agreed rules, so risky settings are caught soon after they appear rather than at the next annual review. Typical checks flag public storage, open management ports, disabled logging, unencrypted volumes and over-permissive roles. We run these checks across every account and region, suppress rules that do not apply to your estate with a recorded reason, and route each remaining finding to a named owner.

Start with the native tools, because they already see your provider's identity, configuration and audit data and are quick to enable. Services such as AWS Security Hub, Microsoft Defender for Cloud and Google Security Command Center cover the posture checks most single-cloud estates need. A third-party platform becomes worth its cost when you run several clouds and want one view, or need coverage the native tools lack. We recommend based on your estate, not a preferred vendor.

At a minimum, log every control-plane action, sign-in, permission change and access to sensitive data stores, and keep those logs where an attacker cannot alter them. We enable provider audit trails across all accounts or projects, send them to a separate archive with restricted access and retention set by your legal and contractual needs, and add network flow logs where they help investigations. Alerts then cover high-risk events such as root sign-ins and policy changes.

It can support the technical side, but we do not certify environments, issue audit reports or declare anyone compliant. Those frameworks are assessed by independent auditors across your whole organisation, including policies and people. Our part is implementing and documenting the cloud controls they examine, such as access reviews, encryption, logging and controlled change through code, so your compliance lead has clear evidence to present. We work within the requirements they set.

We need read-only access through a role you create and can revoke at any time, not an administrator login. On AWS that is typically a cross-account role with the SecurityAudit and ViewOnlyAccess policies, on Azure the Reader and Security Reader roles, and on Google Cloud viewer-level roles such as Security Reviewer. Assessing a bucket or database configuration does not require reading the data inside it. Remediation later runs through your pipeline or a separate, time-limited role agreed in the written scope.

It should not, because we change permissions and network rules in stages with a way back at each step. Before removing access we check audit logs to see what is actually used, then apply changes in a non-production environment first. Production changes go through Terraform pull requests at agreed times, with monitoring watched closely afterwards. If a service fails because of a missing permission, the change is reverted from code rather than patched by hand.

Timelines typically depend on the number of accounts or projects, how many services and regions you use, whether Kubernetes is in scope and how quickly we can speak to the people who own each system. A single production account running a handful of services is a far smaller review than an estate spread across several providers. After discovery we give you a written plan, report urgent findings as soon as we confirm them, and run remediation in stages you review every one to two weeks.

Cost depends on scope: the number of accounts and environments, the services in use, whether Kubernetes is involved and how much remediation you want us to carry out rather than advise on. We start with a discovery call, then give a fixed quote for the assessment and a separate estimate for the remediation work it reveals. You decide which findings we fix, which your team handles and which are accepted as known risks.

We tell your named contact as soon as we confirm it, rather than holding it for the final report. Exposed credentials, publicly readable data or signs of unauthorised activity are escalated with a clear description of what we saw and where. We do not change anything without your agreement. Instead we agree immediate containment steps with you, such as rotating a key or closing a port, and record every action for later investigation.