15.3 Design Workflow and Toolkit

Quick Answer: The official COBIT 2019 design workflow is: (1) understand the enterprise context and strategy, (2) determine the initial scope of the governance system using design factors 1–4, (3) refine the scope using design factors 5–11, and (4) conclude the design — resolve priority conflicts, complete the system, and set target capability levels. ISACA’s design toolkit scores the 40 objectives (initial / refined / concluded). Foundation candidates must know the steps and the purpose, not operate the spreadsheet. The Design Guide decides what to implement and at what capability; the Implementation Guide decides how to get there. The exam trap is starting implementation without a design.

This is the last section in the 7% Designing domain. If you can recite the four steps, match 1–4 to initial and 5–11 to refined, and keep Design versus Implementation from swapping jobs, you have the domain.

The workflow lives in the COBIT 2019 Design Guide, with the concepts also introduced in Introduction and Methodology. It is a design sequence, not the seven-phase continual-improvement lifecycle. Do not merge “understand / initial / refine / conclude” into “what are the drivers / where are we now / where do we want to be.” Those seven questions belong to implementation chapters.

Step 1 — Understand the enterprise context and strategy

Before anyone opens a scoring sheet, the design team has to understand the enterprise. That sounds obvious and is where rushed programs fail.

Understanding means: what the enterprise is, what it is trying to become, who the stakeholders are, how I&T currently creates or destroys value, and which constraints are real. Strategy, business model, geography, regulation, and the current I&T operating model all belong here. Northline’s context is plants, unit cost, and uptime. Aether’s context is a banking license, a growth-by-acquisition story, and product teams shipping weekly.

This step is not yet “score the 40.” It is the sense-making that keeps later scoring from becoming a numerology exercise. If the team cannot explain the enterprise in plain language, the toolkit will happily produce a precise-looking profile of a company that does not exist.

Board and executive time belongs here. A CIO workshop that skips context and starts coloring cells is already doing management arithmetic without governance input. Remember the split: the governing body still evaluates, directs, and monitors. Design supports that loop. It does not replace EDM01 Ensured Governance Framework Setting and Maintenance with a spreadsheet.

Step 2 — Determine the initial scope (factors 1–4)

Initial scope uses the first four design factors:

1. Enterprise strategy
2. Enterprise goals
3. Risk profile
4. I&T-related issues

These four draw the outline. Northline’s outline is cost leadership, cost-and-reliability goals, a plant-and-availability risk profile, and issues around aging assets and project overruns. Aether’s outline is innovation/client-service/growth, customer and growth goals, a high digital-risk profile, and issues around shadow SaaS, release collisions, and post-acquisition data.

The toolkit’s initial view scores the 40 objectives from that outline. Some objectives jump. Some recede. That is the point. The output is a candidate priority profile, not a signed design. Candidates who treat initial scope as the finished system skip the next two steps and then wonder why the CISO and the plant manager cannot both live with the result.

Do not smuggle factors 5–11 into this step because they feel important. Cloud, Agile, first-mover, and “we are a bank” all matter. They matter in refinement. ISACA split the eleven for a reason: first decide who we are and what hurts, then adjust for environment and operating model.

Step 3 — Refine the scope (factors 5–11)

Refinement applies the remaining seven:

1. Threat landscape
2. Compliance requirements
3. Role of IT
4. Sourcing model for IT
5. IT implementation methods
6. Technology adoption strategy
7. Enterprise size

The toolkit’s refined view reshapes the initial scores. Aether’s high threat, high compliance, strategic role, cloud hybrid sourcing, Agile/DevOps methods, first-mover adoption, and large-enough size will lift security, compliance, vendors, architecture, innovation, data, and change-related objectives beyond what strategy-and-issues alone produced. Northline’s normal threat, normal compliance, factory role, insourced model, traditional methods, slow adoption, and mid-size reality will pull the profile back toward operations, assets, budget, and a smaller structure variant.

Refinement is also where variants and focus areas become practical. Aether may apply information-security or DevOps overlays on the core model. Northline may use small-or-midsize structure variants rather than Aether’s forum stack. Overlays still sit on the 40. They do not open a side door that retires EDM or APO.

Step 4 — Conclude the design

Conclude is a named step with three jobs. Memorize all three.

1. Resolve priority conflicts. Initial and refined scores will disagree. Innovation and cost leadership both shouting, or a first-mover culture colliding with a high-compliance rating, is normal. Someone has to decide. That someone is not the loudest consultant. Conflicts go back to strategy, appetite, and the governing body’s direction.
2. Complete the system. A score profile is not yet a governance system. Completing means selecting the governance and management objectives that will be in the designed system, deciding how the seven components will be realized — including variants — and making sure the result can actually work as a system (holistic approach), not as forty disconnected posters.
3. Set target capability levels. Each in-scope process objective needs a target capability (the 0–5 capability scale taught in Performance Management). Targets can and should differ. Aether may want APO13 and DSS05 higher than BAI09. Northline may want DSS01 and APO06 higher than APO04. Capability 5 on every row is not a conclusion. It is the equal-implementation trap wearing a new badge.

The toolkit’s concluded view is the designed profile: prioritized objectives plus targets, ready to hand to implementation. Foundation candidates will not be asked to key the cells. They will be asked what “conclude” includes. If a stem offers only “pick the highest initial score and stop,” that is not conclude.

The design toolkit — purpose, not operation

ISACA provides a design toolkit, typically a spreadsheet, that scores the 40 objectives through initial, refined, and concluded stages. It applies the published mappings from design-factor options to objective importance, using risk rating for risk profile and importance for the other factors.

What Foundation requires:

• Know that the toolkit exists and that it lives with the Design Guide.
• Know that it scores the 40 objectives, not the seven implementation phases.
• Know the three views: initial, refined, concluded.
• Know you are not expected to operate it on the exam.

What Foundation does not require:

• Cell formulas, macro steps, or a vendor’s clone of the sheet.
• Reciting every mapping from “cloud” to a specific numeric bump on APO10.
• Treating the toolkit output as automatically correct without management judgment at the conclude step.

A stem that says the certificate tests spreadsheet operation is describing a different assessment. A stem that says the toolkit replaces the governing body’s conclude judgments is equally wrong.

Design Guide versus Implementation Guide

Keep the companion books in their lanes.

Design without implementation is a binder. Implementation without design is motion. The exam loves the second failure more than the first, because energetic programs like to “stand up COBIT” by launching a seven-phase project before anyone has decided which objectives matter.

Aether’s CISO wants a security program started this quarter. That urgency is real. It still does not authorize skipping design. The CISO’s threat and compliance factors are the design inputs that will raise security objectives. Using them inside the workflow is how urgency becomes a target capability instead of a side project that bypasses EGIT.

Northline’s plant manager wants to “just implement ITIL and COBIT” on the shop-floor tools and call governance done. That is implementation without design, plus a category error about what COBIT is. Northline still needs the four steps. Its concluded design will simply look different from Aether’s — heavier on operations, assets, and cost, lighter on innovation theater.

Exam trap: start implementation without a design

Wrong instincts:

• “The seven implementation phases are the design workflow.”
• “Open the Implementation Guide first so we show progress this quarter.”
• “The toolkit is optional once we have a program manager.”
• “Conclude means accept the initial scores.”
• “Target capability is always 5, so we can skip that decision.”
• “Foundation candidates must know how to operate the spreadsheet.”

Right instincts:

1. Understand context and strategy.
2. Initial scope with factors 1–4.
3. Refine with factors 5–11.
4. Conclude: resolve conflicts, complete the system, set target capability.

Then — and only then — the Implementation Guide answers how to close the gap. Next chapters teach that journey. This chapter’s job is to stop you from starting it blind.

If a stem offers a program that launches seven phases before anyone has used design factors, reject it. If it offers a Design Guide workshop that produces a prioritized, capability-targeted system and then hands that system to implementation, take it.