ITIL 4 Cloud Services cheat sheet

Service strategy decision rule: a cloud service is justified only when its utility (fit for purpose) and warranty (fit for use) together close a defined outcome gap at acceptable cost and risk.

Deployment models: public (provider-owned, multi-tenant), private (single-organization use), hybrid (two or more distinct models bound by technology enabling data and portability), community (shared by organizations with common concerns).

Service models shift the responsibility boundary: IaaS leaves OS and above to the consumer; PaaS leaves application and data; SaaS leaves only configuration and data governance.

Cloud design must treat elasticity, multi-tenancy, and measured service as design constraints, not options: capacity, isolation, and metering are architectural decisions.

Demand management: separate baseline demand from variable and peak demand; match each tier to a sourcing pattern (reserved, on-demand, spot) rather than sizing for peak only.

Service level design starts from the customer outcome and works backward to SLIs; an SLA without a measurable indicator and an agreed consequence is not a service level.

Exit and portability are design requirements: define data export formats, identity federation, and contractual exit assistance before selecting a provider.

Service portfolio logic: each cloud service is classified as pipeline (in design), catalogue (live), or retired; only catalogue services appear in the service catalogue.

Design constraint: data residency, sovereignty, and classification determine the eligible provider and deployment model before cost or feature comparison.

Transition rule: a release is not complete until the change is authorised, the configuration items are recorded in the CMDB, and the service is accepted against agreed acceptance criteria.

Change types: standard (pre-authorised, low risk, defined trigger), normal (assessed and authorised by change authority), emergency (expedited path with retrospective review).

Deployment patterns: blue/green (two identical environments, instant switch and rollback), canary (progressive traffic shift), rolling (incremental replacement); each changes the rollback cost profile.

Incident priority = impact x urgency; major incident triggers a separate escalation path and dedicated communications, not the standard queue.

Event management classifies every alert as informational, warning, or exception; only exceptions create incidents, which prevents alert fatigue.

Problem management seeks root cause of one or more incidents; a known error is a problem with a documented root cause and workaround recorded in the known error database.

Request fulfilment handles standard, pre-approved user requests through the service catalogue; it does not pass through change authorisation.

Service desk is the single point of contact for users; cloud operations additionally monitor provider status feeds and shared responsibility boundaries during outages.

Configuration management in cloud: tag-based discovery replaces manual inventory, but untagged resources are invisible and must be treated as a control failure.

Shared responsibility model: the provider secures the cloud (facilities, hypervisor, managed service internals); the consumer secures what is in the cloud (identity, data, configuration).

Governance decision rule: every cloud service must have a named accountable owner, an approved risk treatment, and a compliance mapping before go-live.

Identity is the primary control plane: enforce least privilege, role-based access, multi-factor authentication, and periodic access recertification.

Compliance evidence: certifications such as ISO/IEC 27001, SOC 2, and PCI DSS attest the provider's controls, not the consumer's configuration; consumer-side evidence must be collected separately.

Cloud risk categories to assess: lock-in and concentration, data residency and sovereignty, provider availability, sub-processor chain, and misconfiguration exposure.

Policy as code converts governance intent into automated guardrails (deny public storage, enforce encryption, restrict regions); manual review does not scale to elastic environments.

Audit rights and transparency: contracts should secure access to audit reports, breach notification timelines, and sub-processor change notification.

Data classification drives control selection: retention period, encryption at rest and in transit, geographic location, and deletion verification follow from the classification.

Third-party risk: the provider's own suppliers form the sub-processor chain; each layer adds a dependency that must appear in the risk register.

Value is co-created: the provider supplies the service, the consumer supplies usage and configuration; outcomes emerge only from both, so improvement must span the boundary.

Continual improvement model sequence: what is the vision, where are we now, where do we want to be, how do we get there, take action, did we get there, keep momentum.

Measure outcomes, not activity: track SLIs and SLOs against customer-defined outcomes; ticket counts and uptime percentages alone do not evidence value.

Error budget = 1 minus SLO; it converts reliability into an explicit trade-off between release velocity and stability.

Cost optimisation is a value lever: rightsizing, eliminating idle resources, and matching commitment models to demand reduce waste without reducing utility.

Feedback loops: incident reviews, service reviews, and usage analytics feed the improvement register; each improvement entry needs an owner, a measure, and a review date.

Improvement prioritisation rule: rank by expected value (outcome impact) divided by effort and risk, and validate with the customer, not the provider alone.

Post-implementation review after each significant change confirms whether the intended value was realised and records deviations in the improvement register.