16.1 Business Case for EGIT

Quick Answer: A formal business case is required before an EGIT improvement program because EGIT is an investment, not a documentation project. The case states the problem or opportunity (pain points and trigger events), stakeholder needs, proposed EGIT scope from design factors, options (do nothing / minimal / tailored COBIT), benefits, costs, risk, timeline, success measures, and governance of the program itself. The audience is the board and executive sponsors, under EDM02 Ensured Benefits Delivery. Do not start Phase 5 (How do we get there?) with no approved case.

Business Case is 3% of the 75-question COBIT 2019 Foundation exam — roughly two items. Those items are cheap if you know why a case exists, what it contains, who reads it, and that Phase 5 is the execution gate. They are expensive if you treat COBIT as a binder to print, treat “implement COBIT” as a budget line with no problem statement, or start executing before the governing body has approved the investment.

Chapter 15 designed a tailored system from eleven design factors. This chapter asks the question that design does not answer by itself: why should the enterprise spend scarce attention and money standing that system up? Chapter 17 will walk the seven implementation phases. Learn the case first. The case is the reason Phase 5 is allowed to start.

EGIT is an investment, not a documentation project

Enterprise governance of information and technology (EGIT) consumes the same scarce things every other enterprise investment consumes: executive time, skilled people, change capacity, and cash. A board that would not fund a payments-rail rewrite on the sentence “we should modernize” should not fund an EGIT program on the sentence “we should implement COBIT.”

COBIT 2019 is a governance and management framework. It is not software you install. It is not a certificate you hang. It is not a stack of policies that become governance because they were copied from the core model. If the program’s output is a SharePoint folder, the enterprise did not buy EGIT. It bought documentation.

The first governance-system principle is Provide stakeholder value. Value is the balance of benefits realization, risk optimization, and resource optimization. A business case is how that principle becomes a decision: here is the pain or opportunity, here are the options, here is what we will spend, here is what “good” will look like, here is how we will know. Without that thesis, “implement COBIT” is a slogan competing unfairly with product work, control remediation, and customer programs that did state their case.

EDM02 Ensured Benefits Delivery is the board-owned objective that optimizes value from investments in processes, services, and assets. An EGIT program is exactly that kind of investment. The case is the artifact the governing body uses to evaluate whether the investment is worth directing, and later to monitor whether benefits appeared. The CIO may draft the case. The CIO does not own the benefits conversation.

Pain points, trigger events, and stakeholder needs

ISACA’s implementation lifecycle opens with Phase 1 — What are the drivers? Drivers are not “we want a framework.” They are pain points the enterprise already feels and trigger events that make delay more expensive than action.

Typical pain points you should recognize:

• Repeated audit findings that do not close
• Unplanned downtime no one can explain in governance language
• A change cycle so slow that product teams route around it
• Unclear decision rights (two committees think they accept residual risk)
• Shadow I&T and unsanctioned tools
• Projects that ship and never change a customer or risk outcome
• A risk appetite that exists as a slide and is not used in decisions

Typical trigger events:

• A merger or acquisition
• A new regulation or examination finding
• A board-directed digital strategy
• A major incident
• A new CIO or chair
• A failed transformation that spent money without benefits

Stakeholder needs come from the goals cascade (Chapter 10), not from the I&T department talking to itself. The board, executives, regulators, customers, and operating leaders have needs the EGIT system must serve. If the case cannot name those needs, it cannot later claim benefits.

Typical contents of an EGIT business case

Foundation does not grade you on a consulting template. It does expect you to recognize the kinds of content a serious case carries.

Read the table as a board packet, not as ten extra chapters. If any row is empty, the request is not yet a case.

Options: do nothing, minimal, tailored COBIT

A case that presents one option is a request, not a case. Three options are enough for Foundation.

Do nothing. Keep the current operating model. Residual pain continues. Residual risk stays where it is. The opportunity cost is the value the enterprise will not create and the findings it will keep paying for. Do nothing is a real option. It is sometimes the right option for a quarter if the enterprise has no sponsor and no capacity. It is not “free.”

Minimal. Publish a few policies, stand up one committee, buy a tool, print RACI charts, and stop. Minimal can look cheap. It often produces governance theater: artifacts without behavior change. If the trigger is a regulatory exam on decision rights and the minimal option does not change who may accept residual risk, it does not address the problem.

Tailored COBIT. Use the Design Guide workflow: understand context, set initial scope with factors 1–4, refine with factors 5–11, resolve conflicts, set target capability on the objectives that actually matter. This option costs more attention up front. It is the option that matches the principles Tailored to enterprise needs and Holistic approach. It is not “stand up all 40 objectives at capability level 5.”

Proposed scope comes from design factors

The case does not invent scope in a vacuum. Chapter 15 already taught the eleven design factors and the four-step design workflow. Proposed EGIT scope in the case is that design, written so a sponsor can fund it.

Aether Digital Bank — licensed, first-mover, innovation plus client service, IT strategic, hybrid/cloud, Agile/DevOps, high threat and compliance, still product-team first after an acquisition — should not fund the same EGIT shape as Northline, the cost-leader manufacturer. Aether’s case should say which objectives and components will be emphasized (decision rights, risk appetite, security, change, data, compliance monitoring) and which will stay lighter. Northline’s case would lean availability, cost, and operational process discipline.

If the case says “implement the entire core model equally,” the design work was skipped. That is a resource failure waiting to happen (EDM04 Ensured Resource Optimization) dressed up as ambition.

Audience: the board and executive sponsors

The primary audience is the board (or other governing body) and executive sponsors. That is an EDM02 Ensured Benefits Delivery conversation: evaluate whether this investment should be directed, then monitor whether it delivers. EDM01 Ensured Governance Framework Setting and Maintenance cares that the EGIT system itself is being set and maintained on purpose. EDM04 cares that people, process, and technology are adequate at a sensible cost. EDM05 Ensured Stakeholder Engagement cares that the right stakeholders see the performance and conformance story.

Middle management still uses the case. The PMO still schedules the work. BAI01 Managed Programs will run the program. None of that moves ownership of the investment decision off the governing body.

Scenario: a CIO asking for budget to “implement COBIT”

Aether’s CIO takes ten minutes at the end of a board meeting. “We need budget this year to implement COBIT. Other banks have it. I will hire a firm, we will map the 40 objectives, and we will be compliant.” There is no problem statement. No trigger. No design-factor scope. No options. No benefits that a director can measure. No costs beyond a vendor estimate. No program sponsor named besides the CIO. The chair hears a documentation project with a brand name.

The right board move is to send the request back, not to approve Phase 5 because the slide used the word COBIT.

A repaired case for Aether would read more like this: After the acquisition we run two change processes and three informal risk appetites. The last examination found unclear I&T decision rights. Unplanned downtime on the payments rail is still explained as “an IT issue.” Access recertification findings repeat. Product teams ship weekly around a committee no one respects. We compared doing nothing, a policy-and-committee-only path, and a tailored COBIT design that emphasizes EDM decision rights and appetite, APO risk/security/data, BAI change and organizational change, DSS security and continuity, and MEA performance, compliance, and assurance — not all 40 at level 5. Here is the cost in people, workshops, training, light tooling, and the product work we will defer. Here is how we will know in two quarters: fewer repeat findings, a single change path with a measured lead time, downtime hours, and decisions that cite a written appetite. Here is the sponsor, the cadence, and the kill criteria.

That is a case. The first speech was a shopping request.

Do not start Phase 5 with no approved case

ISACA’s seven implementation phases, which Chapter 17 will teach in full, are:

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?

Phases 1–4 are how the enterprise earns the right to execute. The business case is assembled from those answers and approved before Phase 5. Phase 5 is How do we get there? — the build, the organizational change, the process and structure work. Starting Phase 5 with no approved case is the classic Foundation trap: you are spending the investment before the governing body directed it.

The case is also not “a document we write after we finish so audit has a folder.” Writing the case in Phase 6 is theater. Approval is a gate, not a souvenir.

Exam traps for the EGIT business case

• Calling EGIT a documentation project or treating a binder as the outcome.
• Starting Phase 5 (How do we get there?) with no approved case.
• A CIO request to “implement COBIT” with no problem statement, no drivers, and no options.
• Treating the audience as the PMO or a vendor, not the board and executive sponsors under EDM02.
• Inventing an ISACA rule that the case must be filed with a Foundation certificate application.
• Using “stand up all 40 objectives equally” as the only option.
• Confusing the business case with a software purchase.
• Confusing the case with the Design Guide toolkit spreadsheet. The toolkit informs scope. It does not replace the investment decision.

Prefer the answer that treats EGIT as an investment, requires a problem-led case with options and design-factor scope, keeps the board as audience under EDM02 Ensured Benefits Delivery, and refuses to start Phase 5 without approval.