COBIT 2019 governance objectives vs management objectives
By Sam Rivera, Founder, SentinelPanda · April 10, 2026 · 3 min read · COBIT 2019
Governance directs. Management plans, builds, runs, monitors. COBIT 2019 makes the distinction explicit because confusing the two is how IT investments end up disconnected from enterprise value.
Why COBIT splits them
COBIT 2019 inherits from earlier versions a clear separation between governance and management. Governance is the responsibility of the board or equivalent body: it evaluates stakeholder needs, sets direction through prioritisation and decision-making, and monitors performance, conformance, and progress against agreed direction. Management plans, builds, runs, and monitors activities aligned to the direction set by governance to achieve enterprise objectives.
The split matters because conflating governance and management — having executives "manage" by approving project plans, or having boards "govern" by reviewing operational metrics — is how organisations end up with IT spend disconnected from business value. COBIT is opinionated about this division.
The 5 governance objectives (EDM domain)
- <strong>EDM01 Ensured Governance Framework Setting and Maintenance</strong> — establish and maintain a governance framework: principles, decision-making model, accountability for major decisions.
- <strong>EDM02 Ensured Benefits Delivery</strong> — optimise the value contribution to the business from IT-enabled investments, services, and assets.
- <strong>EDM03 Ensured Risk Optimisation</strong> — ensure enterprise risk appetite and tolerance are understood, articulated, and communicated, and IT-related risk is identified and managed.
- <strong>EDM04 Ensured Resource Optimisation</strong> — ensure adequate and sufficient IT-related resources (people, processes, technology) are available to support enterprise objectives effectively.
- <strong>EDM05 Ensured Stakeholder Engagement</strong> — ensure stakeholders' needs, conditions, and options are evaluated to determine balanced, agreed-on enterprise objectives.
The 35 management objectives (APO, BAI, DSS, MEA domains)
Management objectives are split across four domains:
- <strong>APO — Align, Plan and Organise.</strong> 14 objectives covering enterprise architecture, portfolio management, budget and costs, human resources, relationships, agreements, suppliers, quality, risk, security, data, organisational change, programs, performance and conformance.
- <strong>BAI — Build, Acquire and Implement.</strong> 11 objectives covering programs, requirements, solutions identification, availability and capacity, organisational change, IT changes, change acceptance and transitioning, knowledge, assets, configuration, and projects.
- <strong>DSS — Deliver, Service and Support.</strong> 6 objectives covering operations, service requests and incidents, problems, continuity, security services, and business process controls.
- <strong>MEA — Monitor, Evaluate and Assess.</strong> 4 objectives covering performance and conformance monitoring, system of internal control, compliance with external requirements, and assured services.
How to use the split
The most common COBIT mistake is treating it as a single 40-objective checklist. The framework is more useful as a separation of concerns: which decisions belong to the board (EDM), which to executive management (APO, BAI), and which to operational owners (DSS, MEA). When the same person or committee owns objectives across the split — board members signing off on incident response procedures, or operations directors setting risk appetite — the assignment is wrong and the assessment will be misleading.
In practice, most COBIT 2019 programs start with EDM (to establish the governance framework) and APO (to align IT planning to it), then work into the operational domains. Starting with DSS and back-filling EDM is possible but tends to surface contradictions late.
Capability vs maturity
Each objective is rated on a 0–5 capability scale (process-level), which can be aggregated to a 0–5 maturity score (organisation-level). Capability is the rigour of the process itself; maturity is how consistently and broadly that rigour has been institutionalised. A high-capability process in one team and a low-capability process across the rest of the organisation produces a high process-capability rating and a low organisational-maturity rating. The two ratings are complementary — see the companion article on capability levels for the detail.