Study guide
17.3 Roles, Pain Points, and Challenges
ISACA COBIT 2019 Foundation Certificate Exam
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current Exam Facts 1.2 Certificate Rules, Retakes, and How to Study
2 Chapter 2: Framework Introduction
2.1 Purpose of COBIT and EGIT 2.2 I&T Versus the IT Function 2.3 COBIT 2019 Product Family 2.4 Stakeholders, Audience, and Benefits
3 Chapter 3: Framework Positioning
3.1 Umbrella Framework and Related Standards 3.2 Evolution from COBIT 5 to COBIT 2019
4 Chapter 4: Governance System Principles I
4.1 Provide Stakeholder Value 4.2 Holistic Approach 4.3 Dynamic Governance System
5 Chapter 5: Governance System Principles II and Framework Principles
5.1 Governance Distinct from Management 5.2 Tailored to Enterprise Needs 5.3 End-to-End Coverage 5.4 Three Governance Framework Principles
6 Chapter 6: Governance System Components Overview
6.1 Seven Governance System Components 6.2 Generic Versus Variant Components 6.3 Focus Areas
7 Chapter 7: Process and Structure Components
7.1 Processes Component 7.2 Practices, Activities, and Metrics 7.3 Organizational Structures 7.4 Principles, Policies, and Frameworks
8 Chapter 8: Information and People Components
8.1 Information Component 8.2 Culture, Ethics, and Behavior 8.3 People, Skills, and Competencies 8.4 Services, Infrastructure, and Applications
9 Chapter 9: Integrating Governance System Components
9.1 How Components Work Together 9.2 RACI Charts and Key Roles 9.3 Components Supporting Objectives
10 Chapter 10: The Goals Cascade
10.1 The Goals Cascade 10.2 Enterprise Goals and Alignment Goals
11 Chapter 11: Core Model and EDM Governance Objectives
11.1 The 40-Objective Core Model 11.2 EDM Governance Objectives 11.3 Governance Versus Management Objectives
12 Chapter 12: APO Align, Plan, and Organize
12.1 APO Strategy, Architecture, and Innovation 12.2 APO Portfolio, Resources, and Relationships 12.3 APO Risk, Security, Data, and Quality
13 Chapter 13: BAI, DSS, and MEA Management Objectives
13.1 BAI Build, Acquire, and Implement 13.2 DSS Deliver, Service, and Support 13.3 MEA Monitor, Evaluate, and Assess
14 Chapter 14: Performance Management
14.1 Performance Management Principles 14.2 Capability Levels 0–5 and Maturity
15 Chapter 15: Designing a Tailored Governance System
15.1 Why Tailor: Design Factors 15.2 The Eleven Design Factors 15.3 Design Workflow and Toolkit
16 Chapter 16: Business Case
16.1 Business Case for EGIT 16.2 Benefits, Costs, Risk, and Tracking
17 Chapter 17: Implementation Lifecycle
17.1 Implementation Lifecycle Overview 17.2 Seven Implementation Phases 17.3 Roles, Pain Points, and Challenges 17.4 Design Guide and Implementation Guide Together
17.3 Roles, Pain Points, and Challenges
Key Takeaways Explain This Topic AI
A board or executive sponsor must own the mandate; consultant-only ownership is a failure mode, not a staffing model.
Internal audit and assurance advise and give independent assurance — they do not own EGIT.
Process owners, business stakeholders, the implementation team, and the PMO each have a job; COBIT is not an IT-only workshop.
Pain points are current burns; trigger events are discrete windows — learn both with examples.
Classic challenges are no sponsorship, IT-only scope, boiling the ocean, culture resistance, no benefits tracking, and binders with no behavior change.
Last updated: August 2026
Quick Answer: Implementation needs a board or executive sponsor , an implementation team , process owners , business stakeholders , and usually a PMO . Internal audit and assurance advise ; they do not own EGIT . Pain points are current burns; trigger events are discrete windows. Classic challenges are no sponsorship , IT-only COBIT , boiling the ocean , culture resistance , no benefits tracking , and consultant-only ownership that produces binders and no behavior change.
The seven questions tell you what the lifecycle asks. This section tells you who has to show up and why programmes die anyway. Foundation will give you short scenarios. Name the missing role or the named challenge. Do not invent a rule that “audit should run COBIT because COBIT used to sound like control objectives.”
Who has to be in the room
EGIT is part of corporate governance . The governing body still evaluates, directs, and monitors . An implementation programme that never reaches the board is a management project wearing a governance badge.
Role Job in the lifecycle Failure if missing
Board / executive sponsor Mandate, resources, visible direction, air cover when culture pushes back The programme becomes optional the first time a line manager is busy
Implementation team Coordinate the seven phases, keep design and implementation connected, chase decisions Work fragments into local tools and unofficial side projects
Process owners Change the actual work under in-scope objectives; accept capability targets Narratives update; behavior does not
Business stakeholders Keep outcomes in business language — value, risk, cost, customers, plants, products COBIT collapses into an IT-only workshop
PMO Programme discipline: plan, dependencies, reporting, increment control Phase 4 and phase 5 turn into an unmanaged pile of initiatives
Internal audit / assurance Advise, provide independent assurance, later assess whether EGIT works If they own EGIT, independence and accountability both break
Read the last row twice. Assurance as advisor, not owner is a Foundation favorite. Audit can be a driver (findings are pain). Audit can be a reviewer (phase 6 and MEA-style assurance). Audit cannot be the executive sponsor, the process owner of APO and DSS, and the independent assurer of the same system.
The implementation team is a coordinator, not a permanent shadow IT department that “does COBIT” so everyone else can ignore it. The PMO is useful. The PMO does not replace process owners. Business stakeholders are not optional guests at an IT kickoff. If only the CIO shop is in the room, you have already hit the IT-only challenge.
Pain points versus trigger events, with examples
Section 17.1 introduced the pair. Here you must be able to classify a stem.
Pain points — already true this quarter, even if nobody launched a programme:
- Failed or chronically late I&T programmes
- Recurring incidents or a standing problem backlog
- Audit findings that reopen every year
- I&T cost the board cannot connect to value
- Business and I&T talking past each other on priorities
- Shadow IT / shadow SaaS
- Security or data issues that never quite become a crisis
Trigger events — a discrete event that opens a window:
- Merger or acquisition
- Regulatory shock or a new supervisory letter
- Major outage that reaches the board
- New CIO, CEO, or chair
- Published digital or transformation strategy
- IPO, new market, or a hard board mandate
Story Classify as Why
Northline’s unit-cost reports have been unexplained for six quarters Pain point Current, ongoing dissatisfaction
Northline’s line stops for a shift after a near-miss, and the chair demands a response Trigger event Discrete event that opens a window
Aether’s acquired banks still run colliding release trains Pain point Current operating problem
Aether closes the acquisition and receives a supervisory letter Trigger event Discrete event plus external shock
Internal audit repeats the same access finding for the third year Pain point Standing issue; also a possible later trigger if the chair finally refuses it
A programme can have both. Aether often will: pain in data and releases, trigger in the acquisition and the letter. Phase 1 collects both. It does not treat them as the same noun.
Challenges that kill the lifecycle
Know these by name. Stems will describe them without labeling them.
Lack of sponsorship. No executive will spend political capital. Phase 1 never really happens. Later phases become evenings-and-weekends work inside architecture.
Treating COBIT as IT-only. The CIO shop “implements COBIT” for systems it owns. OT, digital products, vendor platforms, and business data sit outside the tent. That also violates end-to-end coverage and the I&T-versus-IT-function idea from earlier chapters.
Boiling the ocean. No design, no prioritization. All 40 objectives, capability 5, this year. Phase 4 becomes a fantasy programme. Phase 5 drowns.
Culture, ethics, and behavior resistance. Process narratives change; incentives and habits do not. The culture component was taught for a reason. A lifecycle that ignores it will look complete and change nothing.
No benefits tracking. Phase 6 is skipped. The PMO reports activity. The board never sees whether pain receded.
Consultant-only ownership. The firm writes the system, presents the binders, and leaves. Process owners never accepted the work. When the contract ends, EGIT ends.
These challenges stack. A sponsor-free, IT-only, consultant-led, forty-objective programme with no benefits measures is not six separate unlucky events. It is one failed pattern.
Scenario: binders, no behavior change
Aether hires a firm to “implement COBIT” in ninety days after the acquisition. There is no lasting executive sponsor — the CIO attends the kickoff and then disappears into integration meetings. The firm photocopies generic process narratives for all 40 objectives , prints RACI charts nobody negotiated, and stacks them in branded binders. Internal audit is told it now “owns COBIT” because the word control appears in the framework’s history. Process owners are invited to a readout, not to change a decision right. The PMO closes the project on time. Six months later the audit committee asks what behavior changed in releases, data ownership, or vendor risk. Nothing has. Shadow SaaS grew. The supervisory letter is still open.
That programme hit almost every challenge in one story: weak sponsorship, IT-only framing, boiling the ocean, culture ignored, no benefits tracking, consultant-only ownership, and assurance asked to own EGIT. It produced binders . It did not produce a governance system.
The repair is not a thicker binder. The repair is a sponsor, a designed subset of objectives with capability targets, process owners who change work, business stakeholders in the room, audit back in an assurance seat, and phases 6 and 7 that ask whether Aether actually moved.
Northline can fail the same way at smaller scale: a plant-IT lead buys a “COBIT in a box” pack, labels it implementation, and never involves operations or finance. The pack is still a binder.
Exam instincts
Wrong instincts:
- “Internal audit should own EGIT because COBIT is about controls.”
- “If consultants delivered the documents, implementation succeeded.”
- “Pain points and trigger events are two names for the same start.”
- “Business stakeholders are optional once IT has a PMO.”
- “Doing all 40 objectives proves commitment.”
Right instincts:
Sponsor first.
Audit advises; it does not own.
Process owners and the business must change work.
Pain is current; a trigger is a window.
Binders without behavior change are a failed COBIT project, not a conservative start.
If a stem offers a sponsored, designed, business-inclusive programme with assurance on the side, take it. If it offers a consultant binder that audit is told to own, reject it.