ISACA CCAK cheat sheet

NIST SP 800-145 defines five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service.

Service-model control boundary: in IaaS the consumer manages the guest OS and above; in PaaS the provider manages OS/runtime and the consumer manages applications and data; in SaaS the provider manages the application stack.

Shared responsibility rule: the provider is responsible for security of the cloud (physical, hypervisor, managed service infrastructure); the consumer is responsible for security in the cloud (data, identities, configurations, and, for IaaS, OS and applications).

Deployment models: public, private, community, and hybrid; multi-cloud uses two or more public providers, while hybrid combines public and private with orchestration or integration.

Zero trust decision rule: trust is not derived from network location; each request is authenticated and authorized using identity, device posture, and policy, with microsegmentation limiting lateral movement.

Resilience design: RTO is maximum acceptable downtime, RPO is maximum acceptable data loss; multi-AZ addresses zone failure, multi-Region addresses regional failure.

Data classification rule: higher sensitivity drives stronger controls such as customer-managed keys, tokenization, private connectivity, and residency constraints.

Attack surface includes public APIs, identity endpoints, metadata services, and the management plane; these require logging, least privilege, and network restriction.

Governance sets direction, decision rights, risk appetite, and oversight; management plans, builds, runs, and monitors within that direction.

A cloud policy baseline typically includes acceptable use, data classification, residency, approved service models, procurement, identity, encryption, logging, and exit requirements.

Cloud Center of Excellence (CCoE) is a cross-functional body that defines standards, reference architectures, and reusable controls; it does not replace accountable service owners.

COBIT separates governance objectives (EDM: evaluate, direct, monitor) from management objectives (APO, BAI, DSS, MEA).

Three lines model: first line owns and manages risk; second line provides oversight, frameworks, and challenge; third line provides independent assurance.

Decision rule: approval tier rises with data classification and business criticality; low-risk SaaS may use expedited review, while high-risk workloads require architecture, security, legal, and risk sign-off.

Exceptions are time-bound, documented, risk-accepted at the correct authority level, and tracked to closure; expired exceptions revert to the baseline control.

Governance metrics include policy-compliance rate, tagging and chargeback accuracy, SLA attainment, access-review completion, and exit-plan test status.

Risk = likelihood × impact; inherent risk exists before controls, residual risk remains after controls, and risk appetite is the amount of risk an organization is willing to accept.

Cloud risk treatment options: avoid (stop activity), mitigate (reduce likelihood or impact), transfer (contract or insurance), and accept (formal risk ownership).

Shared responsibility changes control ownership but not accountability: the customer remains accountable for its data and for configuring inherited provider controls.

Quantitative formulas: SLE = asset value × exposure factor; ALE = SLE × annualized rate of occurrence (ARO).

Concentration risk arises when critical workloads depend on one provider, region, identity provider, or network path; fourth-party risk is risk from the provider's subcontractors.

Key risk indicators include misconfigured public storage, excessive privileged identities, stale access, unpatched assets, failed control tests, and SLA breaches.

Provider assurance reports (SOC 2 Type II, ISO/IEC 27001/27017 certificates, CSA STAR) are inputs to risk assessment; they do not prove the customer's own controls are effective.

Decision rule: residual risk above appetite requires additional treatment or formal acceptance by the accountable risk owner; acceptance must be documented and time-bound.

Compliance scope is determined by data types, processing purposes, legal entities, customer contracts, and data location; the same workload can create multiple overlapping obligations.

Data residency requires data to remain in a specified geography; data sovereignty adds that the data is subject to the laws of the host country.

GDPR cross-border transfer mechanisms include adequacy decisions, standard contractual clauses, and binding corporate rules; contractual and technical safeguards must match the transfer.

ISO/IEC 27001 defines ISMS requirements; ISO/IEC 27017 adds cloud-specific controls; ISO/IEC 27018 addresses PII in public clouds; ISO/IEC 27701 addresses privacy management.

SOC 1 covers controls relevant to financial reporting; SOC 2 covers security, availability, processing integrity, confidentiality, and privacy; SOC 3 is a public summary.

Compliance inheritance rule: provider certifications cover only the provider's scope; the customer must implement complementary user entity controls (CUECs) and its own configurations.

Continuous compliance uses policy as code, configuration evaluation, immutable audit logs, and control mapping (for example CSA CCM to ISO, NIST, and PCI DSS).

Decision rule: contractual and regulatory requirements define notification timelines, audit rights, data-return/deletion terms, and subcontractor flow-down obligations.

Audit provides independent assurance against criteria; consulting creates or improves controls and impairs independence if performed for the same audited subject.

Audit evidence must be sufficient, appropriate, relevant, and reliable; cloud evidence includes API exports, configuration snapshots, logs, contracts, and provider attestations.

SOC 2 Type I reports design at a point in time; Type II reports operating effectiveness over a period; CUECs identify controls the customer must implement.

CSA STAR levels: Level 1 self-assessment, Level 2 third-party audit, and Level 3 continuous monitoring; STAR is not a substitute for customer-scope testing.

Cloud audit challenges include no physical access, multi-tenancy, volatile logs, jurisdiction, and reliance on provider-generated evidence; compensating procedures include configuration review and independent log extraction.

Right-to-audit clauses may be satisfied through provider reports, agreed-upon procedures, or direct audit; the contract determines access, notice, and confidentiality terms.

Audit sampling in cloud environments can use continuous/API-based population extraction; evidence integrity requires timestamps, hashes, chain of custody, and retention.

Control testing covers identity and access, privileged access, encryption and key management, network segmentation, logging/monitoring, backup/restore, change management, and vendor oversight.