Study guide
17.2 Seven Implementation Phases
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.2 Seven Implementation Phases
Key Takeaways Explain This Topic AI
Memorize the seven official questions in order: drivers, current state, target, what to do, how to get there, did we get there, keep the momentum.
Phase 2 recognizes the current state; phase 3 defines the target, including capability targets that come from design.
Phase 4 plans the gap; phase 5 executes; phase 6 reviews benefits — do not treat documents as outcomes.
Phase 7 embeds continual improvement so the cycle does not die when the increment closes.
The high-yield traps are swapping phase 2 with phase 3, and ending the lifecycle at phase 5.
Last updated: August 2026
Quick Answer: Memorize the seven official questions in this order : (1) What are the drivers? (2) Where are we now? (3) Where do we want to be? (4) What needs to be done? (5) How do we get there? (6) Did we get there? (7) How do we keep the momentum going? Phase 2 is current state. Phase 3 is the designed target, including capability targets . Phase 5 executes. Phases 6 and 7 still remain. The exam traps are swapping 2 and 3 and ending at phase 5 .
This is the highest-yield list in the 8% Implementation domain. If you can write the seven questions from memory, match each to its job, and refuse two swaps, you have most of the domain. Recognition, not a programme-manager simulation, is what Foundation tests.
The questions are the official phase titles. Under each question the enterprise does real work: recognize, define, plan, execute, review, embed. Learn the question first. Then learn what happens. Do not replace the official questions with homemade labels such as “assess / design / build / run” and hope ISACA will accept the paraphrase.
The seven questions, in order
Phase Official question What happens Typical output
1 What are the drivers? Recognize why change is needed now; collect pain points and trigger events ; start the programme and the case for sponsorship Desire to change, outline business case, executive air cover
2 Where are we now? Recognize the current state : issues, practices, and current capability Honest as-is picture, problem and opportunity list
3 Where do we want to be? Define the target state , including capability targets from design , and a roadmap toward it To-be profile, target capabilities, roadmap
4 What needs to be done? Translate the gap into a prioritized plan of improvements — not all 40 objectives at once Programme plan, prioritized initiatives
5 How do we get there? Execute the plan: change processes, structures, skills, culture, and services Delivered improvements, not only documents
6 Did we get there? Review benefits against the target, not against the volume of binders Benefits review, gap-to-target status
7 How do we keep the momentum going? Embed continual improvement so the cycle restarts when pain or a trigger returns Sustained ownership, next-pass drivers
Read the middle column as a verb chain: recognize current → define target → plan → execute → review benefits → embed . That chain is the lifecycle. The left column is what you must recite on the exam.
Phase 1 — What are the drivers?
Phase 1 is not a capability assessment. It is the why now . The team gathers pain points and trigger events, turns them into a story the board can fund, and initiates a programme with an executive sponsor . Without this phase, later work is a hobby inside IT.
Aether’s driver story is a completed acquisition plus a supervisory letter plus shadow SaaS the board can no longer ignore. Northline’s driver story is a line-stopping near-miss plus unit cost the chair no longer believes. Both stories belong here. Neither story is “we should adopt COBIT because a peer did.”
Phase 1 also creates the political conditions for design and for later phases. A sponsor who will not attend phase 1 will not save phase 5.
Phase 2 — Where are we now?
Phase 2 is the as-is . Assess current EGIT, current management practices, current issues, and current capability . Be honest. Inflating the current state so the gap looks small is how programmes later claim success they did not earn.
This phase recognizes current state . It does not set the destination. Candidates who load target capability into phase 2 have already swapped 2 and 3.
Northline discovers that DSS01 Managed Operations is performed on some lines and incomplete on others, that BAI09 Managed Assets is a spreadsheet two quarters behind, and that APO06 Managed Budget and Costs cannot explain plant-IT spend. Aether discovers that APO13 and DSS05 are uneven across acquired banks, that APO14 Managed Data has no owner, and that release practices under BAI06 collide weekly. That is “where we are now.” It is not yet “where we want to be.”
Phase 3 — Where do we want to be?
Phase 3 is the to-be . The target is not a slogan (“world-class IT”). It is a designed profile: which of the 40 objectives matter more, and at what target capability . Those targets come from the Design Guide workflow — conclude the design, including capability — and are used here as the destination the lifecycle aims at.
Aether’s target may raise security, data, vendors, and architecture above Northline’s, with different capability numbers on the same objective IDs. Northline’s target may raise operations, assets, and budget. Capability 5 on every row is not a phase-3 answer. It is the equal-implementation trap wearing a roadmap badge.
If a stem asks which phase uses design’s capability targets, the answer is phase 3 — where do we want to be? — not phase 2.
Phase 4 — What needs to be done?
Phase 4 turns the gap into a plan . What initiatives will close the distance between phase 2 and phase 3? In what order? With which owners, components, and funding? This is where boiling the ocean is refused. A designed system that prioritized twelve objectives does not become a forty-workstream programme at the planning table.
Phase 4 is still planning. It is not execution. Writing a plan is not “how do we get there?” Getting there is phase 5.
Phase 5 — How do we get there?
Phase 5 executes . Process owners change work. Structures meet. Skills are hired or built. Culture is confronted. Services and tools are adjusted. The seven components move, not only the process narratives.
This is the phase energetic sponsors love, and it is why the exam traps you into stopping here. Execution feels like the finish. It is not. You can execute the wrong plan, execute without measuring benefits, or execute once and then drift. Phases 6 and 7 exist because phase 5 is necessary and insufficient.
Phase 6 — Did we get there?
Phase 6 is a benefits review , not a deliverable count. Compare outcomes to the phase-3 target. Did capability actually move? Did the pain that started phase 1 recede? Did the merger, the outage, or the supervisory letter get a governance response that stuck?
Aether shipped a policy pack and a new committee. If incidents, data ownership, and vendor risk did not move, phase 6’s answer is no — even if the PMO’s dashboard is green. Northline published an asset procedure. If the line still cannot see what is running, phase 6’s answer is no.
Phase 7 — How do we keep the momentum going?
Phase 7 embeds continual improvement . Ownership stays with process owners and the governing body, not with a departing consultant. The next pain or trigger is allowed to restart phase 1. Design factors that changed — a new sourcing model, a new regulation, another acquisition — send the enterprise back through design and then around the cycle again.
Ending at phase 5 skips this on purpose. Treating phase 7 as “write a lessons-learned slide and close the project forever” also skips it. Momentum is the difference between a COBIT project and EGIT as a system.
Exam traps: swap 2 with 3, or stop at 5
Wrong instincts:
“Where do we want to be?” comes before “Where are we now?” because strategy is more important than assessment.
Phase 2 is where you set target capability.
Phase 5 is the last official question, so the lifecycle ends at execution.
Phase 6 is optional if the plan was delivered on time.
Phase 7 is a close-out meeting, not a return to the cycle.
The seven questions are the same as the four-step design workflow.
Right instincts:
Drivers first.
Current state next.
Target — including design’s capability targets — after you know the as-is.
Plan the gap.
Execute.
Review benefits.
Keep momentum and circle again.
If a stem puts the target before the current state, reject the swap. If it treats a delivered plan as “we got there,” reject the stop at 5. If it offers the seven questions in the official order and uses phase 3 for the designed to-be, take it.