COBIT 2019 was published by ISACA before most enterprises had fully migrated to the cloud. Its control objectives, process definitions, and maturity models were built for an era when IT infrastructure meant owned servers, licensed software, and internal data centers. That era is over.
Today, the average mid‑sized enterprise runs on a combination of Amazon Web Services or Microsoft Azure (Infrastructure as a Service), managed database and development platforms (Platform as a Service), and dozens of SaaS applications — Salesforce, HubSpot, Workday, Slack, Zendesk — that are purchased by business units with credit cards, not IT procurement reviews.
The gap between what COBIT 2019 explicitly addresses and what most organizations actually manage is significant. This does not mean COBIT is obsolete. It means COBIT needs to be read with a cloud‑native lens, translated into a service‑model context, and supplemented where its original text no longer maps cleanly.
This article covers how to govern IaaS, PaaS, and SaaS environments using COBIT 2019 as your foundation — what the framework gets right, where it needs adaptation, and how to close the gaps it leaves open.
What COBIT 2019 Gets Right About Cloud Governance
Before diagnosing the gaps, it is worth acknowledging what COBIT 2019 already provides that translates well to cloud environments.
COBIT 2019 defines governance as a system with five guiding principles, the most relevant for cloud governance being the fifth: separating governance from management. Governance sets direction and evaluates outcomes; management executes plans. This distinction is exactly what cloud governance needs — someone must own the policy decision of which cloud providers are approved, what data can be stored in each service tier, and how vendor risk is assessed, while the day‑to‑day operations of provisioning and managing cloud resources can be distributed.
COBIT 2019's structure around 40 governance and management objectives, organized into five domains (EDM, APO, BAI, DSS, MEA), provides a complete taxonomy for classifying cloud governance decisions:
| COBIT Domain | Cloud Governance Relevance |
|---|---|
| EDM (Evaluate, Direct, Monitor) | Strategy‑level decisions: which cloud model to prioritize, risk appetite for cloud adoption |
| APO (Align, Plan, Organise) | Planning: cloud migration roadmap, resource allocation, architecture decisions |
| BAI (Build, Acquire, Implement) | Execution: cloud onboarding, migration projects, change management for cloud resources |
| DSS (Deliver, Service, Support) | Operations: monitoring cloud service performance, managing incidents across providers |
| MEA (Monitor, Evaluate, Assess) | Compliance: auditing cloud configurations, assessing vendor compliance posture |
The framework also introduced Focus Areas — specialized themes for emerging concerns. Cloud Computing is explicitly listed as a Focus Area in COBIT 2019, meaning the framework acknowledges the topic, even if its detailed process guidance predates the cloud‑native era.
The Gaps: Where COBIT 2019 Meets the Cloud and Falls Short
COBIT 2019's five domains provide governance structure, but the process‑level detail was written for on‑premises IT. Three gaps are most significant in practice.
Gap 1: Procurement and Lifecycle Management
COBIT's BAI domain assumes a formal procurement lifecycle — purchase orders, licensing agreements, hardware acquisition. When a product manager subscribes to a SaaS application with a company credit card and a free trial, none of that applies. The BAI01 "Manage IT Programs and Projects" and BAI02 "Manage Requirements Definition" processes have no natural landing point for a subscription product that was never submitted through IT.
A 2024 survey by BetterCloud found that the average enterprise uses over 130 SaaS applications, with a significant portion outside of formal IT oversight. Legacy COBIT text still references perpetual hardware licenses, so the policy addendum should replace "purchase date" with "subscription start date" and treat each seat as a metered resource subject to renewal review.
Gap 2: Multi‑Cloud Complexity
COBIT 2019 was not designed for multi‑cloud environments. When an organization uses AWS for compute, Azure for identity management, and GCP for data analytics, the governance question of "who controls access to what environment" becomes significantly more complex. COBIT's APO07 "Manage the IT Management Framework" and APO10 "Manage Vendors" processes provide conceptual guidance but no operational specificity for multi‑cloud service accounts, API‑key governance, or cross‑provider role assignments.
Gap 3: Shared Responsibility Model
In on‑premises environments, the organization owns the entire stack. In IaaS, PaaS, and SaaS, security responsibility is split between the cloud provider and the customer. COBIT does not have a native concept for the shared responsibility model — it assumes the organization controls the infrastructure it operates on. This is a fundamental structural gap that must be addressed with policy addenda.
Governing Infrastructure as a Service (IaaS)
IaaS environments — AWS EC2, Azure Virtual Machines, GCP Compute Engine — are the closest COBIT analogue. The organization manages the operating system and above; the provider manages the physical infrastructure. Governance controls that apply:
| COBIT Process | IaaS Application |
|---|---|
| DSS05 – Manage Security Services | Apply security groups, network ACLs, and IAM policies at the cloud account level. AWS Organizations or Azure Management Groups provide the hierarchical structure COBIT expects for organizational governance. |
| BAI06 – Manage IT Changes | Every infrastructure change goes through AWS CloudFormation, Azure ARM templates, or Terraform. Version control on infrastructure‑as‑code replaces the change‑management log COBIT assumes. |
| MEA01 – Monitor, Evaluate, Assess Performance | Cloud‑native monitoring — AWS CloudWatch, Azure Monitor — tracks compute utilization, network traffic, and service health. COBIT's MEA01 maps directly to these dashboards. |
The governance principle for IaaS is infrastructure as code with a mandatory review gate. No production environment should be modified manually. All changes are proposed as code, reviewed in a pull request, and deployed through an automated pipeline. This satisfies COBIT's BAI06 change‑management requirement while enabling the velocity IaaS environments demand.
Governing Platform as a Service (PaaS)
PaaS environments — managed databases (RDS, Azure SQL), development platforms (Heroku, AWS Elastic Beanstalk), container services (EKS, AKS) — shift more operational responsibility to the provider, but governance requirements do not disappear. They shift upstream: the governance question becomes what managed services are approved, how access is controlled, and how data‑residency requirements are met.
COBIT governance for PaaS centers on the APO03 – Manage Enterprise Architecture process, which governs which technology components are used and how they fit together:
- Service cataloging: Maintain a registry of approved managed services. For each service, document provider, data classification allowed, who has provisioning access, and cost structure.
- Access governance: PaaS access should flow through central identity providers. AWS IAM Identity Center (formerly SSO), Azure Active Directory, or Google Cloud IAM provide the role‑assignment controls COBIT expects.
- Configuration baselines: PaaS services ship with default configurations that are rarely secure. COBIT's DSS05 security controls require documented baselines — encryption settings, network exposure rules, backup configurations — applied to every managed service.
Governing Software as a Service (SaaS)
SaaS governance is where most organizations feel the sharpest gap between COBIT's structure and operational reality. SaaS applications are not provisioned by IT — they are subscribed by business units, often without formal IT involvement. The governance challenge is not technical control; it is portfolio management.
A combined ITIL and COBIT approach works best for SaaS environments. ITIL's service‑management lifecycle — Service Strategy, Service Design, Service Transition, Service Operation, Continual Service Improvement — pairs with COBIT's governance domains to create a structured approach to SaaS governance:
| Governance Need | COBIT Process | ITIL Practice |
|---|---|---|
| Defining why an app exists | EDM01 – Ensure Governance Framework Setting and Maintenance | Service Strategy |
| Who approves purchases | APO07 – Manage the IT Management Framework | Service Design |
| Onboarding new SaaS | BAI02 – Manage Requirements Definition | Service Transition |
| Managing daily operations | DSS01 – Manage Operations | Service Operation |
| Reviewing renewals and waste | MEA01 – Monitor, Evaluate, Assess Performance | Continual Service Improvement |
The critical COBIT process for SaaS governance is APO10 – Manage Vendors, which requires organizations to assess vendor risks, monitor service levels, and maintain contracts that protect organizational interests. For each approved SaaS application, the vendor‑management record should include: the data processed, the security certifications the vendor holds, the contract's data‑processing agreement (DPA), and the renewal date.
Updating COBIT for Cloud: A Practical Translation Layer
Organizations should not rewrite COBIT — they should build a cloud‑specific translation layer that maps cloud governance decisions to COBIT's existing process framework. The following table provides a practical mapping for practitioners.
| Cloud Governance Scenario | COBIT Process That Applies | Cloud‑Specific Adaptation Needed |
|---|---|---|
| New SaaS subscription approval | APO10 (Manage Vendors), BAI02 (Manage Requirements) | Replace "procurement review" with "SaaS intake workflow" requiring data classification and security questionnaire |
| IaaS change deployment | BAI06 (Manage IT Changes) | All changes via infrastructure‑as‑code; PR review gate satisfies COBIT's change‑approval requirement |
| Multi‑cloud access review | DSS05 (Manage Security Services), MEA01 (Monitor and Evaluate) | Quarterly access review across all cloud providers; consolidate evidence in a central log |
| SaaS vendor risk assessment | APO10 (Manage Vendors) | Vendor security questionnaire as standing requirement; track TPRM evidence in vendor record |
| Cloud cost governance | MEA03 (Monitor, Evaluate and Assess Compliance) | Budget variance alerts at 80 % of quota; map to APO07 resource allocation process |
| Incident response in cloud | DSS02 (Manage Service Requests and Incidents), DSS03 (Manage Problems) | Incident taxonomy includes cloud‑specific scenarios: misconfigured S3 bucket, API‑key compromise, provider outage |
The Shared Responsibility Model: COBIT's Missing Chapter
The shared responsibility model — where the cloud provider secures the underlying infrastructure and the customer secures what they deploy on it — has no direct analogue in COBIT 2019. Organizations must build this concept into their governance framework explicitly.
A practical approach: map every security control to either the cloud provider or the customer organization, then assign ownership accordingly. AWS publishes a Shared Responsibility Model; Azure and GCP have equivalent documentation. Use these as the authoritative source for your organization's control‑assignment matrix.
The COBIT process that benefits most from this exercise is DSS05 (Manage Security Services). Security services in a cloud context include configuring firewalls, managing encryption keys, and monitoring identity‑and‑access controls. By annotating each control with “provider‑owned” or “customer‑owned,” you create a clear accountability trail that satisfies auditors and reduces the risk of blind spots.
Key Takeaways
- Leverage COBIT’s existing domains – EDM, APO, BAI, DSS, and MEA still map cleanly to cloud decisions; treat them as the high‑level scaffolding.
- Add a cloud‑specific translation layer – replace on‑premise terminology (e.g., “hardware purchase”) with cloud‑centric concepts such as “subscription start date” or “infrastructure‑as‑code.”
- Address procurement gaps – institute a SaaS intake workflow that feeds into APO10 and BAI02, ensuring every subscription is evaluated for risk, cost, and data classification.
- Manage multi‑cloud complexity – schedule quarterly cross‑provider access reviews and centralize IAM evidence to satisfy DSS05 and MEA01.
- Formalize the shared responsibility model – create a control‑ownership matrix and embed it in DSS05 to clarify who secures what.
- Tie cost governance to COBIT – use MEA03 alerts to trigger APO07 resource‑allocation decisions, keeping cloud spend under control.
Conclusion
Updating COBIT for the cloud isn’t about discarding a proven framework; it’s about extending it so it speaks the language of today’s hybrid, multi‑cloud reality. By anchoring cloud‑specific policies—subscription intake, infrastructure‑as‑code change gates, shared‑responsibility matrices—to COBIT’s established processes, organizations gain the rigor of a mature governance model while retaining the agility the cloud demands. Take the mapping tables above, adapt them to your environment, and start embedding cloud‑native controls into your existing COBIT governance program. The result is a unified, auditable, and future‑ready approach that keeps risk in check, costs transparent, and business value flowing.