Security teams often run strong controls that no one can connect to enterprise goals, while boards approve technology strategy with no view of whether the controls beneath it work. COBIT 2019, ISACA's framework for the governance and management of enterprise information and technology (I&T), exists to close that gap. It organises I&T into 40 governance and management objectives across five domains and uses design factors to tailor a governance system to each enterprise rather than imposing one template. This guide explains the structure, what it asks of identity and access management (including non-human identities), how to implement and assess it, and how it maps to NIST CSF 2.0, ISO/IEC 27001 and COSO. It is written for CISOs, IT governance and GRC leads, IT auditors and CIOs.
Key takeaways
- COBIT is a governance framework, not a control catalogue. It tells you which objectives your I&T governance system must achieve and how to measure capability; the detailed security controls still come from standards such as NIST SP 800-53 or ISO/IEC 27001.
- The Core Model has 40 objectives in five domains. One governance domain (EDM) and four management domains (APO, BAI, DSS, MEA).
- Design factors make it tailored. Enterprise strategy, risk profile, threat landscape, compliance requirements, sourcing model and size change which objectives get priority and what capability level is targeted.
- Security sits in APO13, DSS05 and DSS06. Identity and access, including service accounts and machine credentials, is managed through security services and business process controls, governed by risk optimisation in EDM03.
- No successor version is announced. ISACA's COBIT page still presents COBIT 2019 as the current release, with focus area guides added since, including one for implementing the NIST Cybersecurity Framework.
What it is and who it applies to
COBIT 2019 is published by ISACA and is voluntary: no law requires it, but regulators, external auditors and internal audit functions in financial services, the public sector and large enterprises commonly use it as the reference for IT governance. COSO's own cyber guidance names COBIT, alongside ISO 27000 and the NIST Cybersecurity Framework, as a benchmark organisations can compare their controls against. See the COSO for Cybersecurity Guide.
ISACA's core publication set is four books:
- COBIT 2019 Framework: Introduction and Methodology: the structure, principles and an expanded definition of governance.
- COBIT 2019 Framework: Governance and Management Objectives: the Core Model and its 40 objectives, with practices, activities, metrics and components for each.
- COBIT 2019 Design Guide: how to design a tailored I&T governance solution using design factors.
- COBIT 2019 Implementation Guide: an updated version of the COBIT 5 implementation guide for implementing and optimising the solution.
ISACA also publishes focus area guides based on COBIT 2019 for DevOps, Information and Technology Risk, Information Security, and Implementing the NIST Cybersecurity Framework (written against CSF 1.1), plus COBIT 2019 for Small and Medium Enterprises and a COBIT for DevOps Audit Program. ISACA's COBIT page also lists 2025 and 2026 white papers on AI system governance and on NIS2 and DORA; none of these is announced as a new COBIT version.
Who benefits most: organisations that need one governance language across IT, security, risk and audit; regulated firms whose supervisors expect a recognised IT governance framework; and IT audit teams who need a structured basis for scoping. Small organisations can use the SME guide and a reduced objective set rather than the full Core Model.
Structure and key requirements
Domains and the 40 objectives
| Domain | Purpose | Objectives |
|---|---|---|
| EDM: Evaluate, Direct and Monitor (governance) | The governing body evaluates strategic options, directs senior management and monitors achievement | EDM01 governance framework setting and maintenance; EDM02 benefits delivery; EDM03 risk optimisation; EDM04 resource optimisation; EDM05 stakeholder engagement |
| APO: Align, Plan and Organise | Organisation, strategy and supporting activities for I&T | APO01 I&T management framework; APO02 strategy; APO03 enterprise architecture; APO04 innovation; APO05 portfolio; APO06 budget and costs; APO07 human resources; APO08 relationships; APO09 service agreements; APO10 vendors; APO11 quality; APO12 risk; APO13 security; APO14 data |
| BAI: Build, Acquire and Implement | Definition, acquisition and implementation of I&T solutions | BAI01 programmes; BAI02 requirements definition; BAI03 solutions identification and build; BAI04 availability and capacity; BAI05 organisational change; BAI06 IT changes; BAI07 IT change acceptance and transitioning; BAI08 knowledge; BAI09 assets; BAI10 configuration; BAI11 projects |
| DSS: Deliver, Service and Support | Operational delivery and support of I&T services, including security | DSS01 operations; DSS02 service requests and incidents; DSS03 problems; DSS04 continuity; DSS05 security services; DSS06 business process controls |
| MEA: Monitor, Evaluate and Assess | Performance monitoring and conformance | MEA01 performance and conformance monitoring; MEA02 system of internal control; MEA03 compliance with external requirements; MEA04 assurance |
Each objective breaks down into management practices with numbered IDs (for example APO02.01 "Understand enterprise context and direction" through APO02.06 "Communicate the I&T strategy and direction"), and each practice into activities assigned to capability levels.
Goals cascade
COBIT links stakeholder needs to 13 enterprise goals (EG01 to EG13) and 13 alignment goals (AG01 to AG13), which in turn point to the objectives that matter most. ISACA's own example: APO02 Managed Strategy primarily supports EG01, EG05, EG08, EG12 and AG08. The cascade is how a security leader shows that, say, APO13 and DSS05 exist to protect a named enterprise goal rather than for their own sake.
Components of the governance system
For every objective COBIT describes seven types of component that must be in place: processes; organisational structures; principles, policies and procedures; information; culture, ethics and behaviour; people, skills and competencies; and services, infrastructure and applications. A security objective is not achieved by a process document alone: it needs the role, the tooling, the skills and the behaviour too.
Design factors
| Design factor | Effect on a security-heavy design |
|---|---|
| Enterprise strategy | Growth or innovation strategies raise APO04 and BAI priority; client service or cost strategies raise DSS |
| Enterprise goals | Drives the goals cascade to objectives |
| Risk profile | High I&T risk categories (security incidents, third-party, data) raise EDM03, APO12, APO13, DSS05 |
| I&T-related issues | Current pain points, such as repeated audit findings, raise MEA02 and MEA04 |
| Threat landscape | A high threat environment raises target capability for APO13, DSS02, DSS05 |
| Compliance requirements | Heavy regulation raises MEA03 and EDM01 |
| Role of IT | Strategic or factory roles weight objectives differently from support roles |
| Sourcing model for IT | Outsourcing and cloud raise APO09 and APO10 |
| IT implementation methods | Agile and DevOps change BAI emphasis (see the DevOps focus area) |
| Technology adoption strategy | First-mover adoption raises APO04 and BAI risk management |
| Enterprise size | Smaller enterprises can use a reduced set (see the SME guide) |
Capability and maturity
COBIT 2019 measures process capability on a 0 to 5 scale. Activities within each practice are assigned to a capability level, and a process reaches a level once all activities at that level are performed. Focus areas (such as information security) are rated on maturity using the same scale. The design factors produce a target capability level per objective, which becomes the baseline for gap analysis.
Identity and NHI requirements
COBIT does not use the term non-human identity, but its security and control objectives apply equally to service accounts, API keys, certificates and AI agent credentials. Where these are absent from scope, the governance system has a gap even if every human account is well controlled.
- APO13 Managed security: the information security management system and plan should state that machine identities, secrets and workload credentials are in scope, with a named owner.
- DSS05 Managed security services: covers identity and logical access, protection against malware, network and endpoint security, and monitoring of security events. Apply provisioning, review and revocation to service accounts and keys as well as people. See the Service Account Security Guide.
- DSS06 Managed business process controls: roles, responsibilities, access privileges and levels of authority within business processes, which is where segregation of duties for automation and integration accounts belongs. See the Segregation of Duties Guide.
- BAI09 Managed assets and BAI10 Managed configuration: keep machine identities and their permissions in the asset and configuration records so changes to them go through BAI06.
- APO10 Managed vendors: third-party integrations and OAuth applications holding tokens into your systems are vendor relationships with access. See the Third-Party Access Guide.
- EDM03 Ensured risk optimisation: the board's risk appetite for I&T should explicitly cover credential exposure and excessive privilege, not just availability.
The Capital One breach shows why: a firewall's cloud role had far more data access than it needed, and its temporary credentials were used to copy storage buckets. In COBIT terms that is a DSS05 access failure and a BAI10 configuration failure, and the regulator's penalty cited cloud risk management weaknesses, which is EDM03 and APO12 territory. See the NHI Ownership Guide.
Implementation steps
The Design Guide sets out a design workflow, and the Implementation Guide carries forward COBIT 5's seven-phase lifecycle. A practical sequence for a security-led adoption:
- Understand context and strategy. Capture the enterprise strategy, goals, risk profile and current I&T issues (the first four design factors). Interview the board or risk committee, not just IT.
- Determine the initial scope. Use the goals cascade and design factors to rank the 40 objectives and set provisional target capability levels.
- Refine the scope. Apply the remaining design factors (threat landscape, compliance, sourcing, implementation methods, technology adoption, size). Record why each priority changed, because auditors will ask.
- Conclude the design. Resolve conflicts between factors and agree the final target profile with the governing body under EDM01.
- Assess current capability. Rate in-scope objectives against their activities. Start with a pilot of three to five objectives (for example APO12, APO13, DSS05, MEA02) to test the method.
- Plan and implement improvements. Build a roadmap from the gaps, ordered by risk. Assign each improvement to an owner with a component view: process, role, skills, tooling, information.
- Operate, monitor and review. Report progress through MEA01, feed results back into the design annually or after significant change, and keep the previous design version so you can revert priorities if a change in scope proves wrong.
Small vs large organisations: a small firm can target capability level 2 on a dozen objectives using the SME guide; a large regulated group will usually target level 3 or above for security and risk objectives and run formal assessments per business unit.
Evidence and assessment
| Objective | Evidence an assessor will ask for | Metric example |
|---|---|---|
| EDM03 | Board-approved I&T risk appetite, risk committee minutes | Risks outside appetite and time to return within tolerance |
| APO12 | I&T risk register, scenario analysis, risk treatment plans | Percentage of critical risks with an approved treatment plan |
| APO13 | ISMS scope, security plan, policy set | Security plan actions completed on schedule |
| DSS05 | Access review records including service accounts, privileged access logs, security event monitoring | Share of accounts (human and non-human) reviewed on time; orphaned credentials found |
| DSS06 | Role definitions, segregation of duties matrix, conflicts and mitigations | Unmitigated segregation conflicts |
| BAI06 | Change records, emergency change approvals | Unauthorised production changes detected |
| MEA02 | Control self-assessments, deficiency log | Ageing of open control deficiencies |
| MEA04 | Assurance plan, internal and external audit reports | Audit findings closed by agreed date |
Assessments can be self-assessments, internal audit reviews or independent appraisals. Keep the rating evidence at activity level so a capability score can be reproduced. For the audit side, see the Internal Audit for Cybersecurity Guide and the CISA Certification Guide.
Mapping to other frameworks
| COBIT 2019 | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 | COSO ICIF 2013 |
|---|---|---|---|---|
| EDM01, EDM03 | GV.RM, GV.OV | PM-9 | Clauses 5, 6.1 | Principles 2, 6, 7 |
| APO12 | ID.RA | RA-3 | Clauses 6.1.2, 8.2 | Principle 7 |
| APO13 | GV.PO | PL-2 | Clause 4.3, Annex A 5.1 | Principle 12 |
| APO10 | GV.SC | SR-6, PM-30 | Annex A 5.19 to 5.22 | Principle 15 |
| BAI06, BAI10 | PR.PS-01 | CM-3, CM-8 | Annex A 8.9, 8.32 | Principle 11 |
| DSS05 | PR.AA-05, DE.CM | AC-2, AC-6, IA-9, AU-6 | Annex A 5.15, 5.18, 8.2, 8.16 | Principle 11 |
| DSS06 | PR.AA-05 | AC-5 | Annex A 5.3 | Principles 10, 11 |
| MEA02, MEA04 | ID.IM | CA-2, CA-5, CA-7, PM-4 | Clauses 9.2, 10.2 | Principles 16, 17 |
This is NHI Mgmt Group's mapping for orientation, not an official ISACA crosswalk. ISACA's "Implementing the NIST Cybersecurity Framework Using COBIT 2019" focus area was written for CSF 1.1, so check category IDs against CSF 2.0, which added the Govern function. See the NIST CSF to ISO 27001 Mapping Guide.
Common pitfalls
- Implementing all 40 objectives at once. Skipping the design factors produces a large, generic programme that stalls; the framework is built to be tailored.
- Treating COBIT as an audit checklist. Rating capability without the goals cascade loses the link to enterprise value, which is the reason boards adopt it.
- Human-only scope in DSS05. Access reviews and privileged access cover staff but not service accounts, CI/CD tokens and integration keys.
- Capability scores without evidence. Self-assessed level 3 ratings that cannot be reproduced from activity-level evidence lose credibility at the first external review.
- Static design. The design is set once and never revisited after a cloud migration, acquisition or new regulation, even though sourcing, threat landscape and compliance are design factors.
- Old crosswalks. Mapping tables built for COBIT 5 or CSF 1.1 are reused without checking renumbered objectives and the CSF 2.0 Govern function.
Practitioner checklist
- Run the design factor workflow and record the rationale for each objective's priority and target capability level.
- Link APO13 and DSS05 explicitly to named enterprise and alignment goals in the goals cascade.
- Bring service accounts, API keys, certificates and AI agent credentials into DSS05 and DSS06 scope with named owners.
- Pilot the capability assessment on three to five objectives before scaling.
- Keep activity-level evidence for every capability rating.
- Maintain one control matrix mapping COBIT practices to NIST CSF 2.0, SP 800-53 and ISO/IEC 27001 Annex A.
- Review the design after any significant change in sourcing, regulation or threat landscape, and at least annually.
- Report objective capability against target to the governing body through MEA01 and EDM05.
Standards and references
- ISACA: COBIT
- ISACA: Using COBIT 2019 to Plan and Execute an Organization Transformation Strategy
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
- COSO: COSO in the Cyber Age
- COSO: Internal Control Integrated Framework, Executive Summary
Related NHI Mgmt Group resources: Three Lines Model for Cyber Risk Guide · SOX IT General Controls (ITGC) Guide · GRC Maturity Model · ISO 27001 Certification Guide