Cloud Security

A cloud security review examines account configuration: identity and permissions, network rules, encryption, secrets, backups and event logging across AWS, Azure or GCP. Containers, Kubernetes clusters, the deployment pipeline and office suite tenants are agreed separately, because each carries a permission model of its own. Application code and business logic normally sit outside this service and call for different work.

Pricing follows how much there is to enumerate: accounts and subscriptions, running services, clusters and separate deployment pipelines. An estate stretched across two platforms costs more than one platform of the same size, because each has its own permission model and its own control names. Remediation help from the provider and a re-check after changes are usually quoted as separate lines.

Moving data to a cloud platform does not move the obligations onto the provider. The customer is usually the controller and the provider a processor, yet roles follow the service and the purpose - a provider processing for its own purposes acts as controller for that part. Roles are settled service by service and written into the processing agreement, and entities under NIS2 add supplier oversight on top.

Remediation is ordered by exposure rather than by the number of items: whatever is reachable from the internet and whatever grants administrative rights goes first. Each item needs a named owner, because a finding nobody answers for returns in the next review. Fixes applied by hand in the console have to move into the infrastructure code, or the next deployment undoes them.

Reading configuration does not change the state of an environment, so the review itself runs on read-only access. Risk arrives with remediation: narrowing a role or closing a network path can break an integration nobody documented. Role and traffic changes are therefore staged, tried outside production first, and watched through denied-request logs before the old rule is switched off.

A cloud configuration review answers how the environment is set up, not whether someone can break into it. The reviewer works from inside the account and sees policies, roles and service settings an attacker never sees, while a penetration test approaches from outside and proves impact. A second misreading concerns platform certifications: they cover the provider layer, not your configuration.

The contract should name the accounts and services under watch and the rule set used to judge configuration. It also needs the notification path for detected drift, a split between who may change something inside your accounts and who may only report it, and how access is withdrawn once the engagement ends. Add a clause keeping reports and monitoring data readable without provider tooling.

A configuration review works on metadata - resource names, policies, network rules and log entries - not on the contents of databases and storage. Read access to stored objects is a separate decision and is rarely needed for this work. Settle up front where collected findings are held, how long the provider keeps them, and whether accounts created for the review are removed afterwards.

Liability for a leak from a resource your organisation configured stays with your organisation, even though the hardware belongs to someone else. The platform owns the physical layer and virtualisation, which providers set out in their shared responsibility model. The auditor is bound by the contract, which normally promises diligence in carrying out the review rather than a guarantee that the environment is secure.

An offer written for a specific environment names your services and your way of working: the accounts, the platforms, whether containers are in use and how changes reach production. A generic one talks about good practice and compliance without touching anything you actually run. Ask for a redacted sample report and check whether its remediation steps can be executed as written on your platform.