ISACA CCAK key terms

A framework that divides security and compliance duties between the cloud service provider and the customer; the split varies by service model, with providers securing the cloud and customers securing what they place in it.

The three standard categories-IaaS, PaaS, and SaaS-that describe how much of the computing stack the provider manages versus the customer; each shifts the boundary of the shared responsibility model.

The architectural patterns describing who owns and can access the cloud infrastructure: public, private, hybrid, and community. Each has different tenancy, control, and compliance implications for the customer.

An architecture where a single provider instance of an application or infrastructure serves multiple customers whose data and workloads are logically isolated; isolation failures are a primary cloud risk.

The ability to automatically provision and release resources to match current demand, so capacity scales up quickly and shrinks when load drops, often with metered pay-per-use billing.

A model where the provider manages servers and scales functions on demand; the customer supplies code that runs in short-lived, event-triggered executions and is billed only for consumption.

A control point placed between users and cloud services that enforces policy, discovers unsanctioned applications, and adds visibility, data loss prevention, and threat protection to cloud traffic.

A pre-configured, governed baseline environment-accounts, networks, identity, logging, and guardrails-that lets teams deploy workloads into the cloud consistently and securely from the start.

The set of decision rights, policies, and oversight mechanisms an organization uses to direct and control cloud adoption, balancing business value, risk, and compliance across the cloud lifecycle.

A cross-functional team that centralizes cloud expertise, defines standards, and guides adoption across business units, often owning reference architectures, guardrails, and reusable patterns.

Cloud services adopted by business units without IT or security approval, creating unmanaged data stores, unpatched configurations, and gaps in the organization's compliance and risk visibility.

Dependence on a provider's proprietary services, APIs, or data formats that makes migrating to another provider costly or technically difficult, reducing negotiating leverage and resilience.

A documented plan describing how data, applications, and configurations will be migrated off a provider, including formats, timelines, cost, and validation steps if the relationship ends.

A contract defining measurable service commitments-availability, performance, support response, and remedies such as credits-against which the provider's delivery is monitored and enforced.

The process of categorizing information by sensitivity and business value so that handling, access, retention, and protection controls can be applied consistently, including to data stored in cloud services.

A structured process that identifies threats and vulnerabilities, estimates likelihood and impact, and evaluates risk against criteria so that treatment decisions can be prioritized and documented.

The amount and type of risk an organization is willing to accept in pursuit of its objectives, expressed as qualitative statements or quantitative thresholds that guide cloud adoption and control decisions.

The selection and implementation of options-mitigate, transfer, avoid, or accept-that modify the likelihood or impact of an identified risk to bring it within the organization's tolerance.

The risk remaining after controls and treatment actions have been applied; it must be compared with risk tolerance and formally accepted by an accountable owner.

The ongoing process of assessing, monitoring, and controlling risks introduced by external providers, including their security posture, subcontractors, financial stability, and contractual obligations.

A structured technique for identifying potential threats, attack paths, and weaknesses in a system design early, so that controls can be built into architecture rather than added later.

An analysis that identifies critical business processes and quantifies the effect of disruption over time, producing recovery time and recovery point objectives that drive resilience and cloud architecture decisions.

A metric that provides early warning of rising risk exposure, such as the number of unpatched cloud instances or failed access reviews, tracked against thresholds and reported to management.

The principle that data is subject to the laws and regulations of the country where it is stored or processed, which may conflict with the laws of the customer's own jurisdiction.

Adherence to applicable laws, regulations, industry standards, and contractual obligations; in cloud environments, it depends on combining provider attestations with evidence of customer-side controls.

The practice of translating each legal or regulatory requirement into specific controls and owners, showing where obligations are met by the provider, the customer, or shared processes.

Monitoring and evaluating controls automatically and frequently, rather than at annual audit points, so configuration drift and policy violations in cloud environments are detected and corrected quickly.

An independent practitioner's opinion that a provider's description of its system and the suitability of its controls are fairly presented, typically covering a defined period and scope.

A cloud security assurance program combining the Cloud Controls Matrix with a self-assessment, third-party audit, or certification, letting providers publicly demonstrate security posture against a common framework.

A contractual clause granting the customer or its appointed auditor access to provider records, personnel, and facilities, or to audit reports, to verify control effectiveness.

An independent examination of cloud controls, configurations, and evidence against defined criteria, assessing whether security, compliance, and governance objectives are met across provider and customer responsibilities.

Information-such as logs, configurations, screenshots, reports, and interviews-that supports audit conclusions; in cloud it is often obtained remotely and may be generated by the provider rather than the customer.

Examining and evaluating controls through inquiry, observation, inspection, or re-performance to determine whether they are designed and operating effectively over the period under review.

An attestation report on a service organization's controls relevant to security, availability, processing integrity, confidentiality, or privacy, covering design and operating effectiveness over a period.

An international assurance standard for reports on controls at a service organization, giving user entities and their auditors evidence about controls relevant to financial reporting.

The use of automated tools and data analytics to test controls and transactions on an ongoing or near-real-time basis, rather than only at scheduled audit intervals.

A documented conclusion that a control is missing, poorly designed, or not operating effectively, supported by evidence and rated by severity, with a recommended remediation action.

The threshold at which an omission or misstatement could influence decisions; it guides auditors in choosing scope, sampling, and which findings to report to stakeholders.