Cloud Security Compliance for AWS, Azure and Google Cloud

Engaging a cloud security compliance CPA tends to happen after an auditor has asked a question the cloud team could answer and the finance team could not, or, less comfortably, after an assessment discovered that a storage bucket holding customer data was reachable from the public internet.

The specifics repeat across engagements: an over-permissive IAM policy, a public bucket, an unrotated access key committed to a repository, a security group left open to the world because it was convenient during a migration and nobody went back to close it. None of those are exotic, and none of them are the provider's fault.

Why cloud security compliance needs a CPA: the shared responsibility model

The provider secures the cloud, physical infrastructure, hypervisor, managed service internals. The customer secures what they put in it, identity, configuration, data, network design, application layer.

Everyone can recite this. The misreading is subtler and it happens at the boundary: with managed services, responsibility shifts depending on which service you use, and companies consistently assume more is covered than is. Choosing a managed database does not mean encryption at rest is enabled, that backups are retained to your requirement, that logging is on, or that the network path to it is restricted. Those remain yours, and they are exactly the items an assessment finds unaddressed.

What the assessment covers

Identity and access management

Consistently the highest-value area, and consistently the worst-maintained. Root and global administrator account protection. Whether human access runs through federated identity or through long-lived local users. Service accounts and access keys, how many exist, when they were last rotated, and how many are unused. Privilege scope against actual usage, since IAM policies are written broadly during a build and never narrowed. Cross-account and cross-tenant trust relationships. And the permission that quietly defeats everything else: the ability to modify IAM itself.

Network architecture

Segmentation between environments, whether production and non-production genuinely separate, security group and NSG rules with any-any exposure, public endpoints on services intended to be internal, egress controls, and private connectivity for data services.

Data protection

Encryption at rest and in transit, key management and who can access the keys, storage exposure across S3, Blob Storage and Cloud Storage, backup and restore capability actually tested rather than configured, retention aligned to legal obligation, and cross-region replication where residency matters.

Logging, monitoring and detection

CloudTrail, Azure Activity Log or Cloud Audit Logs enabled across all regions and accounts, log integrity protected against the account that generated them, retention meeting the framework's requirement, alerting on the events that matter rather than on everything, and (the failure mode that renders the rest academic) whether anyone is actually receiving and acting on the alerts.

Configuration and change control

Whether infrastructure is defined as code and subject to review, drift between the declared and actual state, guardrails through service control policies or Azure Policy, and baseline benchmarks such as CIS applied and monitored.

FedRAMP and FISMA readiness

For companies selling to federal agencies, cloud security compliance becomes a formal authorisation process rather than an assessment. The distance between a commercially-secure environment and an authorisation-ready one is routinely underestimated, the control set is prescriptive, the documentation burden is substantial, and continuous monitoring obligations persist after authorisation.

Work here covers gap assessment against the applicable baseline, boundary definition, System Security Plan development, control implementation guidance, POA&M management, and preparation for assessment by a third-party assessment organisation.

The honest advice given at the outset: FedRAMP is a multi-year, seven-figure commitment for most organisations. It is worth undertaking when federal revenue justifies it and not because it appeared on a roadmap.

DLP and CASB deployment

Data loss prevention and cloud access security broker tooling are frequently bought after an incident and deployed badly, usually in blocking mode on day one, generating false positives that interrupt legitimate work until someone disables the policy entirely.

The workable sequence is: classify what actually needs protecting first, run in monitoring mode long enough to understand real data flows, tune against observed behaviour, then enforce progressively starting with the highest-confidence patterns. Sanctioned-application discovery through CASB typically also reveals a shadow IT population several times larger than IT expected, which feeds directly back into the vendor risk work described on the cybersecurity risk assessment page.

Where this connects to the audit

Where cloud infrastructure hosts financially significant systems, this assessment and the ITGC work examine substantially the same controls against different criteria. Running them as one engagement removes real duplication, the same IAM evidence, the same change control evidence, the same logging evidence, tested once and reported against both frameworks.