ISACA CISA: Auditing Cloud Environments
Cloud audits are difficult when reviewers treat the cloud as either someone else’s infrastructure or a long list of provider settings. The audit has to connect the provider’s control environment with the customer’s architecture, identity model, data handling, configuration, monitoring, and resilience responsibilities.
Within Security Governance & Assurance, the first task is to identify the business services and data that depend on the cloud environment. Only then can the auditor decide which shared-responsibility boundaries, technical controls, provider attestations, and operational practices are relevant to the risk being assessed.
A useful cloud audit does not try to inspect every service. It selects evidence that can demonstrate whether material cloud risks are understood, owned, controlled, and monitored.
Map responsibility before testing controls
Cloud service models change who operates which layers, but they rarely move all responsibility to the provider. Identity configuration, data classification, network design, workload hardening, logging, key management, backup, and application security can remain largely under customer control even when infrastructure is managed.
Build a responsibility map for the actual services in scope. The auditor should know whether a failed control belongs to the provider, customer, shared process, or a third-party managed service before evaluating evidence.
Create the responsibility map at the level of actual services rather than broad labels such as IaaS or SaaS. Managed databases, serverless functions, container platforms, AI services, and hosted applications can place identity, patching, encryption, network, backup, and logging duties in different places. The audit needs enough granularity to avoid testing a provider-owned control as if the customer operated it—or assuming the provider covers a customer responsibility.
Where the organization uses a managed service provider, distinguish the cloud provider from the operator acting on the customer’s behalf. Contractual responsibility may be outsourced while accountability remains with the organization. Evidence should show how the customer oversees both parties.
Start with identity and privileged access
Cloud environments are operated through identities, roles, service accounts, API credentials, and automation. Review privileged access paths, federation, MFA, emergency access, workload identities, role design, and evidence of periodic review.
Identity governance is central because excessive cloud privilege can bypass otherwise strong network and application controls.
Cloud privilege should be evaluated across human administrators and workload identities. Service accounts, managed identities, CI/CD roles, cross-account trusts, and automation tokens can have access that no person uses directly but that still represents a powerful attack path. Inventory these identities and connect them to an accountable application owner.
Look for privilege that bypasses normal administrative controls, such as long-lived keys, local accounts outside federation, or broad roles used because they simplify deployment. The audit should assess whether those exceptions are justified, monitored, and reviewed.
Review configuration against architecture intent
A configuration scanner can produce thousands of findings, but audit needs to understand which settings matter to the scoped service. Public exposure, overly broad firewall rules, unencrypted data paths, permissive storage, weak logging, and unmanaged administrative interfaces should be evaluated against the intended architecture.
Cloud posture becomes useful when findings are prioritized by business context instead of counted as equal technical defects.
Configuration standards should be versioned and tied to the organization’s reference architecture. If teams use policy-as-code or cloud guardrails, inspect how exceptions are approved and whether drift is detected after deployment. A one-time compliant build does not prove the environment remains compliant months later.
For critical controls, compare configuration evidence with runtime behavior. An ingress rule may look restrictive while an alternate load balancer, service endpoint, or identity path exposes the same workload through another route.
Evaluate logging as an assurance dependency
Audit evidence often depends on cloud logs. Review whether administrative activity, identity events, data access, network security, workload changes, and security alerts are captured for the services in scope and retained long enough to support investigation and assurance.
Logging controls should include protection from tampering, centralized access, time synchronization, and ownership for important alerts. A log that no one can query during an incident is not strong evidence simply because it exists.
Confirm that log retention matches investigation and compliance needs. High-volume services may shorten retention for cost reasons, while critical administrative events require longer preservation. The policy should be based on risk and evidence requirements rather than on the default storage setting.
Where logs feed a SIEM or analytics platform, test the path end to end. A source can be configured to emit logs while a broken connector, filter, or parser prevents the security team from receiving usable events.
Assess encryption and key ownership
Encryption settings should be evaluated together with key management. Determine who controls keys, how access is restricted, how rotation and revocation are handled, whether customer-managed keys are required, and what happens when a key is unavailable.
Key management connects technical cryptography to governance. The control objective includes lifecycle ownership, not only an enabled encryption checkbox.
Test resilience beyond provider availability claims
A provider may offer highly available regional or multi-zone services, but the customer architecture can still create single points of failure through one region, one account, one key, one identity provider, or one network path.
Business continuity should be evidenced through tested recovery, dependency mapping, backup restoration, failover behavior, and recovery objectives that reflect the business service.
Test the recovery path with application dependencies included. Restoring a database is not enough if DNS, secrets, identity, queues, certificates, or external integrations are missing in the recovery environment. Service-level resilience exists only when the critical business transaction can be completed after the failure scenario.
Hybrid data protection deserves attention when backups, replicas, or analytics copies cross providers and regions. Recovery design should preserve security and data-governance expectations while improving availability.
Use provider attestations appropriately
SOC reports, certifications, and other provider assurance can reduce the need to test controls operated exclusively by the cloud provider. They do not prove that the customer configured its tenant securely or that its own processes are effective.
Review the scope, period, control objectives, subservice organizations, complementary customer controls, and exceptions in provider assurance. A logo on the provider website is not enough to support a specific audit conclusion.
Confirm that the attestation period overlaps the audit period and that the services used by the organization are actually within scope. Review exceptions and complementary customer controls instead of treating the report as a binary pass. A significant provider exception may require the customer to strengthen a compensating control or accept documented residual risk.
If the audit relies heavily on provider assurance, document that reliance in the workpapers and final scope statement. Stakeholders should know which conclusions came from direct customer testing and which depended on independent provider reports.
Include infrastructure as code in the audit trail
Infrastructure-as-code repositories can provide high-quality evidence of intended configuration, review history, testing, and deployment. Compare code to running state where drift is possible, and evaluate who can approve or bypass production changes.
Governed automation requires the documented policy, deployed configuration, and operational behavior to stay aligned over time.
Evaluate third-party and managed-service dependencies
Many cloud environments rely on SaaS platforms, managed security providers, marketplace software, external APIs, and cross-cloud integrations. The audit should include the material dependencies that can affect confidentiality, integrity, availability, or compliance.
Dependency risk is especially important in cloud architectures because operational control can be spread across several providers while the business still experiences one service outage.
Report cloud risk in service language
Cloud findings should describe affected workloads, data, recovery objectives, regulatory obligations, or business processes. A technical label such as “public bucket” becomes decision-ready when the report explains what information is exposed, how access is possible, and which control should prevent it.
ISACA certifications emphasize governance and audit in the context of business objectives. Cloud assurance is valuable when technical evidence is translated into risk that accountable owners can prioritize.
Cloud findings often span several teams. A public endpoint may involve a platform configuration, application design, IAM role, and network policy owned by different groups. The report should identify the control owner responsible for coordinating remediation rather than creating four separate findings that each address only one technical fragment.
The CISA perspective connects cloud technology to audit planning, operations, resilience, and protection of information assets. That breadth is useful because cloud assurance rarely fits inside one traditional infrastructure silo.
Cloud audit findings should also identify whether risk is systemic or workload-specific. A weak organization-wide identity policy demands a different remediation program from one misconfigured development project. Clear classification helps management choose between central guardrails, platform engineering changes, and targeted application fixes.
Follow-up can use continuous configuration evidence where available. Automated policy checks are useful for confirming remediation at scale, but material exceptions should still be reviewed in business context so the assurance process does not become a dashboard-only exercise.
Cloud assurance should also consider cost and capacity when they can affect resilience or control behavior. Quota exhaustion, budget-driven log truncation, undersized recovery environments, and disabled security services can all change the effective risk posture even when the architecture diagram remains the same. Evidence should reflect the operating configuration, not only the intended design.