Skip to content
PL EN
CLOUD SECURITY / AWS · AZURE · GCP

AWS, Azure and GCP cloud security assessment

We test how IAM, network, data and automation combine into realistic privilege-escalation scenarios.

Cloud risk rarely comes from one critical checkbox. It emerges between an IAM policy, a CI/CD role, a secret, a public service and missing telemetry. We assess those relationships as one system.

Discuss a cloud assessment View public work
AWS · AZURE · GCP
Platforms
IAM FIRST
Effective permissions
IaC + RUNTIME
Code and live state
ROADMAP
Hardening plan
01 / DECISION CONTEXT

When to assess cloud

  • 01Before production launch or further migration.
  • 02After rapid growth in accounts, subscriptions, projects and roles.
  • 03After an incident, exposed secret or organisational change.
  • 04Ahead of customer, ISO 27001, NIS2 or DORA requirements.
02 / TEST SURFACE

Assessment layers

01

IAM and organisation

We analyse effective rights and administrative boundaries.

  • Roles, policies, service accounts and federation
  • Organisations, accounts, projects and guardrails
  • Keys, secrets and workload identity
02

Data and infrastructure

We test service exposure and data resilience.

  • Networks, ingress/egress and public services
  • Storage, databases, backups and encryption
  • Kubernetes, serverless and container images
03

DevOps and detection

We assess deployment paths and abuse detection.

  • CI/CD, IaC and software supply chain
  • CloudTrail, Activity Logs and Audit Logs
  • Alerting, retention and response readiness
03 / DELIVERY

Assessment process

  1. BR / 01

    Organisation and data model

    We agree accounts, owners, critical data, regions and permitted trust boundaries.

  2. BR / 02

    Configuration and IaC review

    Runtime state is connected to Terraform, policies and pipelines when available.

  3. BR / 03

    Escalation-path analysis

    We test whether a limited role can control another workload, secret or identity.

  4. BR / 04

    Hardening and verification

    The backlog includes owners, impact and a safe implementation sequence.

04 / EVIDENCE STANDARD

A CI/CD role can grant itself access to production secrets

FINDING MODEL / NO CLIENT DATA

We test effective permissions rather than the role name or intended purpose.

This example demonstrates the analysis format and is not client work.

E-1

The pipeline can modify the runtime workload definition

E-2

The workload inherits a broader runtime identity

E-3

That identity can read secrets outside the application scope

E-4

The fix separates roles, constrains trust and adds an alert

05 / OUTPUT

What you receive

01
Map of accounts, trust boundaries and critical data
Included deliverable
02
Confirmed escalation and exposure paths
Included deliverable
03
Detection and response-readiness assessment
Included deliverable
04
Prioritised hardening backlog and quick wins
Included deliverable
05
Cloud/DevOps workshop and retest
Included deliverable
06 / QUESTIONS

Common questions

← All services
01Do you need administrator access?+

Not always. We prefer dedicated read-only roles plus controlled permissions for agreed tests. Access is minimised and actions are logged.

02Does the assessment include Terraform?+

Yes when IaC is available. Comparing code with runtime state exposes drift and lets the team fix the source rather than one resource.

03Is this a compliance audit?+

Findings can be mapped to a standard, but technical risk is the primary objective. The assessment is not a certification.

BR / NEXT STEP

Is cloud growing faster than the permission model?

We will map accounts, critical data and the most credible escalation paths.

Discuss a cloud assessment
NDA · clear scope · direct communication