Cloud Security
Cloud compliance assessments, configuration reviews, and platform-specific penetration testing across AWS, Azure, GCP, and AliCloud, anchored to the shared responsibility model and mapped to your regulatory environment.
Cloud is now the default control plane for modern enterprises. It is also where the most damaging breaches of the last decade have started: a misconfigured storage bucket, an over-privileged role, a forgotten access key in a CI pipeline, a service exposed to the public internet by accident. Cloud security testing has to keep pace with how quickly the environment changes, and how easily a single configuration error can become a data exposure event.
Vantage Point delivers cloud security through two complementary engagement types. Configuration and compliance assessments give you auditor-grade visibility into IAM, posture, segmentation, and governance. Platform-specific penetration testing then validates whether those controls hold up against an authenticated adversary moving through the environment.
Engagements run on the Velocity platform, with cloud test cases mapped to CIS Benchmarks, sector regulators, and the security baselines published by each cloud provider. Every finding is reproduced, scored, and traced back to a specific control, built for audit defensibility, not just a list of risks.
No endpoint agents. No SOC. Just your production estate exposed to the internet.
Configuration drifts faster than governance
Every infrastructure change is a potential security change. Without continuous testing, posture decays between audits, and a single broken IAM policy can undo months of hardening work.
The shared responsibility model has sharp edges
Cloud providers secure the platform; you remain accountable for identity, configuration, data, and workload security. Most cloud breaches sit squarely on the customer side of that line.
The standards exist, and we benchmark to them
CIS Benchmarks publish line-by-line hardening baselines for every major cloud provider, AWS, Azure, GCP, AliCloud. We review your environment against them, so you get a consistent industry-standard assessment that confirms you are using the security features your cloud provider already gives you, and that your configuration matches the consensus best practice that the industry has already agreed on.
What we test.
Cloud engagements look across three concurrent layers, identity, configuration, and runtime, because that is where real-world cloud compromises chain together.
Identity & access
IAM is where most cloud compromises actually escalate. We map permissions, trust paths, and lateral movement opportunities the way an attacker would.
- Least-privilege validation across roles, groups, and users
- Cross-account and cross-tenant trust paths
- Service-to-service identity boundaries
- Dormant credentials, long-lived access keys, and key-rotation gaps
- Privilege escalation paths via misconfigured policies
Configuration & posture
Auditor-level configuration review against CIS Benchmarks and provider baselines, then a sense-check from an offensive-security perspective.
- Public storage exposure (S3, Blob, GCS, OSS)
- Network segmentation, VPCs, security groups, NSGs
- Encryption at rest and in transit, key management
- Logging, monitoring, and alerting coverage
- Secrets management and pipeline credential hygiene
Workloads & data
Where in-scope, we test the workloads and data flows that sit on top of the platform, because configuration alone never tells the full story.
- Cloud-hosted application and API surfaces
- Container, Kubernetes, and serverless workloads
- Data protection across storage, databases, and warehouses
- Backup and disaster-recovery posture
- Cloud-native incident response readiness
Serverless Functions
We review AWS Lambda, Azure Function Apps, and GCP Cloud Functions against the CIS Benchmark controls for function-as-a-service, execution-role privilege, environment-variable encryption, authentication, networking, and audit logging, and surface which functions sit outside the baseline.
- AWS Lambda, execution roles, KMS env vars, function URL auth, VPC, CloudWatch
- Azure Function Apps, managed identity, HTTPS-only, VNet integration, storage hardening
- GCP Cloud Functions, service-account scope, KMS env vars, VPC connector, audit logs
- Cross-provider, public reachability, secrets, supply-chain, abuse paths
Where cloud engagements consistently land.
Drawn from common categories our consultants surface across engagements of this type. Severity and prevalence vary by environment and maturity.
Over-privileged identities
Production roles with wildcard permissions, human users with administrator policies attached "temporarily", service accounts with cross-account trust they no longer need.
Public exposure of internal data
Storage buckets with object-level public ACLs, internal services published through load balancers without an authentication layer, debug endpoints reachable from the internet.
Pipeline & secret leakage
Long-lived static keys in CI/CD variables, secrets committed to repositories, build agents with broader cloud permissions than the workloads they deploy.
Network segmentation gaps
Flat VPC topology, overly permissive security-group rules, peered networks that allow lateral movement, missing egress restrictions on workload subnets.
Logging & detection blind spots
Audit logging disabled on critical services, log retention shorter than incident-response requirements, alerts that exist but are not routed to anyone on-call.
Recovery & resilience weaknesses
Backups stored in the same account they protect, missing immutability, untested restore procedures, single-region dependencies for tier-1 workloads.
Mapped to recognised baselines.
Cloud test cases in Velocity are mapped against both technical baselines and the regulatory requirements that drive most engagements in the region.
Reports built for audit, engineering, and executive review.
Every engagement produces verifiable, traceable, regulator-ready artefacts, generated by Velocity and signed cryptographically.
PDF · JSON · XML · CSV · Multi-Language Reporting Supported · CVSS 3.0 / 3.1 / 4.0
- Cryptographically signed final report
- Per-finding test-case mapping and CVSS scoring
- Reproduction steps, payloads, and screenshots
- Configuration remediation with policy and code examples
- Executive summary and risk heatmap
- Standards / regulator coverage matrix
- Stakeholder debrief and retest cycle
Common buyer questions.
How is a cloud penetration test different from a network penetration test? +
A traditional network penetration test focuses on perimeter exposure and lateral movement across hosts. Cloud engagements add identity-driven attack paths, configuration drift, control-plane access, and provider-specific service abuse. We typically combine the two when a workload is partially on-prem and partially in cloud.
Do you need full admin access to the cloud account? +
No. We tailor access to the engagement, anything from black-box external testing, to read-only audit credentials for configuration review, to a scoped identity for authenticated attack-path testing. Rules of Engagement define exactly what is in scope and what is not.
Can you test production safely? +
Yes, with controls. Configuration and identity review is non-disruptive by design. Active attack-path testing in production runs under written Rules of Engagement, change windows, and pre-agreed abort criteria so that there is no operational impact.
How does this map to PCI DSS or ISO 27001 audit requirements? +
Every test case in Velocity is mapped to the standards it supports. Reports include a coverage matrix you can hand directly to auditors, with traceability from a finding back to the specific control it relates to.
Do you handle multi-cloud environments? +
Yes. Most regional enterprises now run multi-cloud, typically AWS plus Azure, with GCP for analytics or AliCloud for China workloads. Engagements can cover a single platform or stitch multiple platforms into one assessment with cross-platform attack-path mapping.
Will the test trigger your cloud provider's abuse detection? +
Cloud providers expect customer-initiated security testing. For invasive testing we file the appropriate provider notifications and operate within published terms of service. Your incident-response team is briefed in advance so any internal detections can be correlated to our activity.
Test the cloud the way it actually fails.
Talk to a CREST-accredited consultant about scoping a cloud engagement, configuration, identity, and attack-path testing built around your regulatory environment.