The CloudCheck 360° methodology

A cloud audit is easy to do badly. Run a scanner, paste the output into a PDF, bill the client. Three weeks later the same scanner surfaces the same findings because nothing moved.

CloudCheck 360° is the structured counter to that. It is not a tool, it is a way of working. Eight categories, visited in a fixed order, each graded on the same rubric, each finding tied to an owner and a remediation path. The goal is a report you can act on next Tuesday morning, not a report that sits in SharePoint until the next SOC 2 renewal.

Cloud environments drift. A config that was correct at provisioning time turns into a risk six months later because someone opened an S3 bucket for a one-off report, or a junior engineer attached AdministratorAccess to a Lambda "temporarily." Checkbox audits miss that kind of drift because they grade on whether policy documents exist, not on whether the running state matches the policy.

A structured methodology catches drift in two ways. It forces every engagement to cover the same ground, so misses are visible across clients and across time. And it separates "control designed" from "control operating," which is the distinction that matters for SOC 2 Type II, ISO 27001 Annex A operating effectiveness, and every other framework we prepare clients for.

The eight categories below are not novel. They follow the structure of NIST SP 800-53 Revision 5 control families and map cleanly onto the six functions of the NIST Cybersecurity Framework 2.0. What is opinionated is the order, the depth at each stop, and the rule that category eight (cost and resource hygiene) is the only one framed as a secondary lens.

Most cloud breaches trace back to an identity problem — a leaked access key, a federated role with an overbroad trust policy, an MFA bypass on a break-glass account. We start here because fixing anything downstream is wasted effort if the identity plane is porous.

What we assess. Root and break-glass account hygiene. MFA enforcement on the console and on long-lived credentials. IAM principal inventory (users, roles, service accounts, workload identity federations). Permission boundaries and SCPs (AWS) or organization policies (GCP) or management-group RBAC (Azure). Cross-account and cross-project trust relationships. Static access keys older than 90 days. Unused principals. Federation and SSO configuration. Privileged access reviews and a documented joiner-mover-leaver process.

Tools and methods. IAM graph walks using AWS IAM Access Analyzer, GCP Policy Analyzer, and Azure Entra ID access reviews. CloudSploit / Prowler / ScoutSuite cross-checked against custom rules. Manual review of trust policies on high-privilege roles. Static key age and usage exported from the provider API and diffed against HR joiner-leaver data when the client provides it.

Typical finding. A service account used by a deployment pipeline has roles/owner on the production project. It was granted during initial provisioning and never scoped down. The remediation is to create a service-specific role with only the APIs the pipeline actually calls, confirmed by a 30-day audit-log diff.

Network security in the cloud is less about firewalls and more about segmentation, east-west controls, and how the environment exposes itself to the internet. A VPC with a single flat subnet is the cloud equivalent of a flat corporate LAN from 2005, and most findings in this category are about segmentation that was never added or was quietly flattened to ship faster.

What we assess. Security groups and network ACLs with overly broad inbound rules (0.0.0.0/0 on anything other than intended HTTPS). VPC peering and Transit Gateway attachments. Subnet tiering (public, private, data, management). Private-link or VPC endpoint coverage. Bastion host patterns and Session Manager / Identity-Aware Proxy adoption. WAF rule coverage for exposed services. DNS egress filtering on outbound traffic. mTLS or service-mesh policy for east-west traffic where applicable.

Tools and methods. Security-group diffs against CIS Benchmarks (AWS 1.5.0, Azure 3.0.0, GCP 2.0.0). VPC Flow Logs sampled for unexpected east-west patterns. Internet-exposure surface enumerated via Shodan, Censys, or equivalent passive recon. Reachability analysis using AWS VPC Reachability Analyzer or Azure Network Watcher.

Typical finding. A production RDS database is in a subnet with a route to an Internet Gateway. The RDS security group blocks inbound traffic from public IPs, so direct exposure is not achievable, but the subnet placement violates defense-in-depth and would turn a single security-group misconfiguration into a data-exfiltration path. Remediation moves the database to a private subnet with a NAT gateway for outbound-only traffic.

Data protection is where most compliance frameworks meet reality. Every framework demands encryption and data classification; few production environments have an up-to-date inventory of where sensitive data lives. We assess both.

What we assess. Encryption at rest on every block, object, database, backup, and snapshot. Encryption in transit on every exposed endpoint (TLS 1.2 minimum, TLS 1.3 preferred). KMS key management — customer-managed keys vs. provider-managed, key rotation, cross-account key policies, envelope-encryption adoption. Backup encryption, retention, and immutability (Object Lock, Backup Vault Lock, Azure Immutable Blob). Data classification inventory. DLP controls for egress (DLP API on GCP, Macie on AWS, Purview on Azure). Database-level controls: row-level security, column encryption, native audit logs.

Typical finding. An S3 bucket holding nightly exports of a customer table is encrypted with the default SSE-S3 key but is also readable by a cross-account role attached to an old analytics project. The bucket is encrypted but not actually protected against a compromise of that role. Remediation: customer-managed KMS key with a key policy that restricts decrypt to only the current analytics accounts, plus a bucket policy that explicitly denies non-current roles.

Workload security spans VMs, containers, serverless, and managed runtimes. The shape of the findings depends on what the client runs, but the categories — image provenance, runtime isolation, patching, secrets handling — are consistent.

What we assess. Container image provenance (signed images, SBOMs, base-image freshness). Kubernetes cluster controls: pod security admission or equivalent, network policies, RBAC, node isolation. Serverless function IAM scoping and cold-path risk. EC2 / VM baselines against CIS Benchmarks. Patch compliance for managed and self-managed instances. Secrets handling — AWS Secrets Manager, GCP Secret Manager, Azure Key Vault adoption, and presence of any hard-coded secrets in environment variables or Git history. Endpoint detection and response coverage.

Tools and methods. Image scans with Trivy, Grype, or provider-native scanners. Cluster baseline scans with kube-bench and kubeaudit. Runtime behavior sampled via Falco or provider-native runtime protection where present. Secret scans via gitleaks or trufflehog against authorized repositories.

Typical finding. A production Kubernetes cluster runs pods without NetworkPolicy resources, so any compromised pod has unrestricted east-west access to every other service. Remediation installs a default-deny NetworkPolicy and adds explicit allow rules per namespace, rolled out behind a feature flag.

Policy is aspirational until logs prove it is operating. This category inventories the log sources that exist, the retention and immutability of those sources, and whether anything actually reads them.

What we assess. CloudTrail (all regions, all management and data events, log integrity validation on). GCP Cloud Audit Logs (Admin Activity, Data Access). Azure Activity Log and diagnostic settings. VPC flow logs and DNS query logs. Kubernetes audit logs. Application-level structured logging. Log destinations — centralized SIEM vs. per-account buckets. Detection rules — Security Hub, Defender for Cloud, Chronicle, or third-party SIEM alert coverage. Alert routing, deduplication, and paging path. Log retention vs. compliance requirements. Log-tamper controls.

Typical finding. CloudTrail is enabled in the primary region but has never been applied as an organization trail, so new accounts created through AWS Organizations in the last six months have no audit logging. Remediation enables an organization trail in a dedicated logging account with S3 Object Lock and KMS-level protection so that account owners cannot delete their own audit trail.

Incident response readiness is less about tooling and more about whether a response actually happens on a Saturday when the on-call rotation is short-staffed. We assess the written plan and, when engaged, run a tabletop exercise to observe the plan under load.

What we assess. The written incident response plan against the structure in NIST SP 800-61 Revision 3 (preparation, detection and analysis, containment and eradication, post-incident activity). Named roles — incident commander, communications lead, technical leads. On-call rotation and paging. Runbooks for the top five likely incident types (credential compromise, exposed data, ransomware, DDoS, insider threat). Evidence collection procedures — forensic snapshot automation, CloudTrail and flow-log retention long enough to investigate. Breach-notification decision tree aligned with the compliance frameworks in scope.

Typical finding. The client has a documented IR plan but no designated incident commander role, and paging is routed to a distribution list that nobody actively monitors outside business hours. The tabletop exercise shows that a simulated credential-compromise alert sits unacknowledged for 37 minutes. Remediation assigns a primary and backup IC, adds an on-call rotation in PagerDuty, and sets a service-level objective of under-five-minutes acknowledgement.

Compliance is last among the security categories because by the time we arrive here we already have evidence for most controls any major framework asks for. This category does the mapping, identifies the framework-specific gaps, and produces a remediation roadmap with effort estimates.

What we assess. Which frameworks are in scope — SOC 2, HIPAA, ISO 27001, PCI DSS, NIST CSF / CIS Controls, GDPR, or a combination. Existing policies, standards, and procedures against the framework's control list. Evidence artifacts (change logs, access-review records, training completion, risk assessments) against the framework's documentation requirements. Any framework-specific control the earlier six categories did not cover (e.g., vendor risk management, business-continuity testing, specific PCI scoping rules).

Typical finding. SOC 2 CC6.6 (restriction of physical access) is marked "not applicable" because the client is fully cloud-hosted, but the working papers do not contain the documented justification. The gap is paperwork, not technical, and is closed in an hour. Contrast: PCI DSS Requirement 3.3.1 (rendering PAN unreadable) is flagged as a real gap because logs include full PAN in clear text and the remediation involves a logging-pipeline change.

The first seven categories are about reducing risk. Cost and resource hygiene is about surfacing the waste that shows up while we are already looking at every resource. We do not sell cost optimization as a primary engagement because framing it that way sets the wrong incentives — a cost-first consultant is motivated to preserve spend-reduction opportunities rather than recommend security-driven consolidations that collapse them.

What we assess. Unused elastic IPs, unattached EBS volumes, orphaned snapshots, old AMIs. Over-provisioned instance families. Compute autoscaling effectiveness. Storage tiering — hot data on nearline or archive tiers and vice versa. Reserved-instance and savings-plan coverage against steady-state consumption. Data-transfer cost surface (cross-region, cross-AZ, NAT gateway egress). Forgotten dev and staging environments. License-included instance types where bring-your-own-license would be cheaper.

Output format. A savings ledger: opportunity × monthly savings × confidence (high/medium/low) × risk (adds risk, neutral, reduces risk). The confidence and risk columns keep us honest about which recommendations are worth acting on.

Typical finding. A dev environment that spins up nightly for integration tests is left running all weekend because the shutdown schedule was disabled during an outage two months ago and never re-enabled. Monthly cost: ~$1,400, risk-neutral, high confidence.

Most CloudCheck 360° engagements fit into four phases over four to eight weeks depending on scope. The cadence is deliberate: fast enough that findings are still current when the report lands, slow enough that the client can participate without derailing their own roadmap.