10.1 The Goals Cascade

Quick Answer: The goals cascade is how COBIT 2019 turns provide stakeholder value into work. Official order: stakeholder drivers and needs → enterprise goals → alignment goals → governance and management objectives (and the components that support those objectives). Cascading is many-to-many. Metrics exist at each layer. Start from stakeholder needs — never from an IT project.

Governance and Management Objectives is 23% of the 75-question COBIT 2019 Foundation exam — roughly seventeen items. This chapter opens that domain. Chapter 4 taught the cascade as the translation engine inside the first governance-system principle. This section is the operational version: official order, many-to-many mapping, metrics, a full hospital walk-through, and the traps that reverse or flatten the cascade.

Why the cascade exists

A board that says “create stakeholder value” has not yet told anyone what to run on Monday. The cascade is the official translation chain. It takes messy, competing stakeholder drivers and needs and turns them into enterprise goals, then into I&T alignment goals, then into selected governance and management objectives and the components that make those objectives real.

Read it down when you design: needs become enterprise goals, enterprise goals become alignment goals, alignment goals become selected objectives and the processes, structures, information, culture, people, and services that support them. Read it up when you explain a control or a project: this objective exists because this alignment goal exists because this enterprise goal exists because this stakeholder need exists. If you cannot walk up, you are looking at activity, not EGIT.

The cascade is not a project methodology, not a software workflow, and not a replacement for strategy. It is the COBIT mechanism that keeps I&T work attached to the people the enterprise exists to serve. Design factors (strategy, size, threat landscape, sourcing) shape how you tailor a system later. The cascade translates needs into goals and objectives. Different tools.

Official four-layer order

Memorize the official sequence. Foundation items love to reverse it or insert an IT project at the top.

Alignment goals were called IT-related goals in COBIT 5. COBIT 2019 renamed them so candidates would stop treating the layer as the IT department’s private scorecard. The next section develops that rename. Here, lock the order: alignment goals sit under enterprise goals and above objectives.

The last layer is not “pick an objective ID and stop.” Objectives are achieved through components. A cascade that ends on a poster of objective names — with no process, no decision rights, no information, no culture, no skills, and no hosting services — has not become a governance system.

Many-to-many, not one-to-one

Cascading is many-to-many. One enterprise goal is typically supported by several alignment goals. One alignment goal is typically supported by several governance and management objectives. Official mapping tables in COBIT 2019 Framework: Introduction and Methodology mark those links as primary or secondary. You do not need to memorize every cell. You do need to reject the idea that each need, goal, or objective has exactly one partner.

A 1:1 reading produces two exam mistakes. First, a candidate maps “compliance” to a single objective and ignores risk, security, continuity, and assurance. Second, a candidate treats the cascade as a wiring diagram you draw once and never revisit. Real enterprises have overlapping needs. Patient safety, privacy, and throughput all pull on the same clinical systems. The cascade is allowed to look like a net, not a ladder with one rung per item.

Metrics at every layer

Each layer has its own metrics. Do not steal a lower-layer measure and call it an enterprise goal.

• Stakeholder / enterprise layer: infection rates, reportable events, regulatory findings, patient-experience scores, cost per case.
• Alignment layer: clinical-system availability, time to restore a critical application, security incidents that touch care, quality of I&T management information used in quality review.
• Objective / component layer: residual I&T risk versus appetite (EDM03), security-process evidence (APO13), recovery-test results (DSS04), privileged-access and security-service metrics (DSS05).

If the only number in the board pack is “we closed 400 tickets,” the cascade has collapsed into operations. Ticket volume can be a useful management metric. It is not an enterprise goal.

Worked example: Cedar Ridge Medical Center

Cedar Ridge is a regional hospital. The loudest stakeholder need this year is patient safety. Families, clinicians, the board, and the regulator all drive it — after two near-miss medication events and a weekend imaging outage that delayed diagnoses.

Do not start with “we need a new electronic health record project.” That is the trap: starting from an IT project and decorating it with goals later.

Step 1 — Stakeholder drivers and needs. Patients need to be treated without preventable harm. Clinicians need reliable systems at the point of care. The regulator needs evidence that safety and privacy duties are met. Insurers and the community need the hospital to remain a going concern after a cyber or continuity event.

Step 2 — Enterprise goals. Those needs become board-level outcomes, not an IT backlog. Cedar Ridge writes enterprise goals in official-style language: managed business risk, compliance with external laws and regulations, quality of management information for quality review, and business service continuity and availability for care itself. Several enterprise goals, one cluster of needs. Already many-to-many.

Step 3 — Alignment goals. I&T must now say what it will achieve so those enterprise goals are possible. Cedar Ridge names security of information, processing infrastructure, applications, and privacy; delivery of I&T services in line with business requirements; and managed I&T-related risk. Clinical identity, medication-order integrity, imaging availability, and backup of the medication record are alignment outcomes — not “IT department goals” parked in a server room.

Step 4 — Governance and management objectives and components. The alignment cluster is supported by several official objectives, not one:

• EDM03 Ensured Risk Optimization — the board sets I&T risk appetite for clinical systems and monitors residual risk.
• APO13 Managed Security — security is planned and directed as an enterprise I&T practice, not a weekend firewall change.
• DSS04 Managed Continuity — the hospital can continue or recover care processes when imaging or the medication record fails.
• DSS05 Managed Security Services — identity, logging, vulnerability, and related security services actually run.

Components make those objectives real: a clinical-risk forum (organizational structures), a safety-and-security policy (principles, policies and frameworks), a living incident and exception log (information), a culture that reports near misses (culture, ethics and behavior), people who can run clinical identity and recovery (people, skills and competencies), and the monitoring and backup platforms that host the work (services, infrastructure and applications). Selecting four objective IDs without filling those slots is not a completed cascade.

Notice the direction. Needs came first. The EHR vendor demo, if it appears at all, appears after the hospital can say which enterprise and alignment goals the product would serve. If a stem starts with “the CIO has already funded a clinical app, now write the goals,” the COBIT answer is that the cascade was run backwards.

Exam traps

1. Reversing the cascade. Objectives or projects at the top; stakeholder needs invented at the bottom to justify a purchase.
2. Treating the cascade as 1:1. One need, one enterprise goal, one alignment goal, one objective. Official mapping is many-to-many, with primary and secondary support.
3. Starting from IT projects. “We are implementing a data lake; which enterprise goal should we attach?” is the wrong opening question. Ask what stakeholders need, then which enterprise goals, then which alignment goals, then which objectives.
4. Stopping at objective IDs. The cascade includes supporting components. An objective name on a slide is not a governance system.
5. Confusing the cascade with design factors. Design factors shape tailoring. The cascade translates needs into goals and objectives.

How this shows up on the exam

Prefer the answer that (1) keeps stakeholder drivers and needs → enterprise goals → alignment goals → governance and management objectives in that order, (2) allows many-to-many mapping, (3) keeps metrics at each layer, and (4) includes components under the selected objectives. Reject any stem that starts at a project, a tool, or a single objective and works upward. The hospital pattern — patient safety → quality and compliance enterprise goals → security and continuity alignment goals → EDM03 / APO13 / DSS04 / DSS05 — is the picture to reuse.