ISACA CCAK common mistakes
ISACA CCAK · Understand the traps and how to avoid them.
Draws the shared responsibility line at the infrastructure boundary and applies the same control ownership assumptions to IaaS, PaaS, and SaaS.
On-premises experience teaches that the provider supplies a facility and the customer owns everything above the operating system. CCAK tests responsibility allocation by service model and by control layer, so a single boundary produces wrong answers for managed databases, serverless, and SaaS.
What to do instead
Build a responsibility matrix per service model and per control domain (identity, network, data, logging, patching, configuration) and reconcile it with the provider's published shared responsibility model before answering scope questions.
Accepts a provider's ISO 27001 certificate or SOC 2 report as evidence that the candidate's own workload meets PCI DSS, HIPAA, or internal policy.
Provider attestations cover the provider's scope, not the tenant's configuration, data classification, identity management, or use of the service. Candidates conflate inherited controls with complete compliance.
What to do instead
Perform a scope and control-gap analysis that maps the attestation scope to the workload's obligations, and document which controls are inherited, shared, or customer-owned. Do not treat a certificate as workload certification.
Assumes the organization can conduct a traditional site audit of a public cloud data center or demand raw infrastructure logs from the provider.
Outsourcing audit habits carry over from managed hosting. In public cloud, tenants share infrastructure and have no physical access, and provider logs are not tenant-scoped evidence.
What to do instead
Rely on provider third-party attestations, contractual right-to-audit or audit-assistance clauses, and customer-side telemetry. Read SOC 2 carve-outs and complementary user entity controls rather than requesting data center access.
Treats CSA CCM or CAIQ as a mandatory checklist and marks every control as applicable to every cloud workload.
Tool familiarity is mistaken for scoping. CCM is a control catalog, not a tailored baseline, and CAIQ answers describe a provider, not the candidate's system.
What to do instead
Use a risk-based applicability assessment: link each selected control to a threat, obligation, or business requirement, and document exclusions with rationale and approval.
Defines cloud governance as reviewing the provider contract and leaves decision rights, policy exceptions, and cloud portfolio oversight undefined.
Governance is conflated with procurement or legal review. CCAK expects governance structures that direct and constrain cloud use, not just commercial terms.
What to do instead
Establish a cloud governance framework covering decision rights (workload approval, data classification, exception handling), policy, roles, and portfolio oversight, aligned with COBIT or ISO 38500 concepts.
Records cloud risk as transferred to the provider because the contract contains indemnities and service-level agreements.
Risk transfer is misunderstood as a contract label. The provider may bear service availability risk, but the customer retains data, configuration, identity, and compliance risk.
What to do instead
Assess residual risk after contract terms and classify each risk as avoided, reduced, shared, retained, or transferred. Document the customer-owned controls that remain necessary.
Omits exit, data portability, and secure deletion from the cloud risk assessment, focusing only on availability and security incidents.
Operational monitoring dominates risk workshops. Exit is a lifecycle risk that affects lock-in, regulatory response, and data protection.
What to do instead
Add exit and termination scenarios to the risk register. Evaluate data formats, migration effort, escrow, deletion certificates, termination assistance, and contractual transition obligations.
Assumes logical tenant isolation is equivalent to physical separation and does not test hypervisor, network, or metadata-service isolation.
Virtualization hides boundaries, and provider certifications are assumed to cover every isolation concern. Tenant isolation is a shared control that still requires customer assurance.
What to do instead
Include tenant-isolation controls in assurance scope: network segmentation, metadata service protections, encryption and key separation, and provider isolation attestations. Design tests that address cross-tenant access paths.
Relies on a SOC 2 Type I report or an out-of-period Type II report as ongoing assurance and ignores complementary user entity controls.
Report literacy is weak. Type I is point-in-time, Type II covers a period, and both can exclude services or rely on customer-side controls that the candidate has not implemented.
What to do instead
Check report type, period, scope, exceptions, and complementary user entity controls. Obtain bridge letters for gaps and map each user entity control to an internal control with evidence.
Applies static on-premises change-management and log-retention expectations to ephemeral cloud resources, then concludes that controls are missing.
Asset-centric audit habits expect durable servers and manual change tickets. Cloud changes occur through APIs, infrastructure as code, and auto-scaling, so evidence lives in identity and configuration history.
What to do instead
Audit identity and API activity, configuration history, CI/CD pipeline approvals, and immutable infrastructure evidence rather than server images or manual tickets. Adjust retention and sampling to the cloud operating model.