3.2 Core Workflows and Decision Points

Committees: Strategy vs. Steering

A classic Domain 2 distinction is the IT strategy committee versus the IT steering committee. Confusing them is a common miss because both touch IT direction.

The strategy committee is advisory and forward-looking; it does not run projects. The steering committee is where prioritization, budget approval, and milestone monitoring happen, and its chair should be a senior executive with authority to decide. If a stem asks who approves a project budget, the steering committee is correct; if it asks who advises the board on IT direction, the strategy committee wins.

The Policy Document Hierarchy

Governance intent cascades through a documented hierarchy. CISA expects you to place a document at the right level:

1. Policy — high-level statement of management intent and direction; mandatory; changes rarely. Example: "All sensitive data must be protected in transit and at rest."
2. Standard — mandatory, specific rules that implement a policy. Example: "Use AES-256 for data at rest."
3. Procedure — step-by-step instructions to perform a task in compliance with standards.
4. Guideline — recommended (not mandatory) best practice that helps people meet standards.

The trap is treating a standard as optional or a guideline as binding. Policies are approved at a high level (often the board or executive committee), while procedures live with process owners. When a finding says a control "isn't enforced," check whether the requirement was written as a mandatory standard or merely a guideline.

Enterprise Architecture and IT Risk Treatment

Enterprise architecture (EA) documents the current ('as-is') and target ('to-be') state of business and IT, providing a roadmap that keeps investments aligned. The Zachman Framework is a classification matrix (perspectives such as planner, owner, designer, builder, against the interrogatives what, how, where, who, when, why) — it describes what artifacts exist, not a process. TOGAF is a process (the Architecture Development Method) for building and governing architecture. EA prevents redundant, point-solution spending and supports strategic alignment.

For IT risk management, the workflow is identify → assess → treat → monitor. The four treatment options are:

• Avoid — eliminate the activity creating the exposure.
• Mitigate — add controls to reduce likelihood or impact.
• Transfer/share — shift exposure to a third party (e.g., insurance, outsourcing).
• Accept — knowingly retain the risk because it is within appetite or treatment is not cost-effective.

What remains after treatment is residual risk, which must fall within the organization's risk appetite/tolerance and be formally accepted by an authorized risk owner — never silently by IT alone.

Two definitions the exam separates: risk appetite is the amount of risk the enterprise is willing to pursue or retain to meet its objectives, set by the board; risk tolerance is the acceptable variation around that appetite for a specific objective. A control that drives residual risk below appetite is fine; one that leaves residual risk above appetite requires either more treatment or an explicit, documented exception approved at the right level.

Maturity and the Decision Pattern

Maturity/capability models describe how disciplined a process is. COBIT 2019 uses capability levels (drawn from CMMI concepts) ranging from incomplete/initial through repeatable, defined, managed, and optimized states. They are not pass/fail scores; they help the enterprise prioritize improvement where the gap between current and target capability is widest and the business impact is highest.

The recurring decision pattern across these workflows: identify the role and level in the stem (board vs. management), match it to the right structure or document, and pick the option that preserves accountability, alignment, and authorization. The safest answer usually follows official policy, documented authority, and independent oversight rather than a quick technical shortcut.

Tailoring Governance with COBIT 2019 Design Factors

COBIT 2019 stresses that a governance system should be tailored, not copied. It provides 11 design factors and a goals cascade to derive priorities. The goals cascade translates stakeholder drivers into enterprise goals, then alignment goals (IT-related goals), and finally the specific governance and management objectives that matter most for that enterprise.

Design factors are grouped as contextual (outside the enterprise's control, such as the threat landscape and regulatory environment), strategic (decisions the enterprise makes, such as its growth strategy and risk profile), and tactical (implementation choices, such as sourcing models, IT methods like Agile or DevOps, and technology adoption).

For the exam, the takeaway is conceptual: there is no single correct set of controls for every organization. The right governance design depends on the enterprise's goals, risk appetite, size, and threat exposure. Distractors that prescribe 'implement all COBIT objectives' or 'apply the same controls as the competitor' miss this tailoring principle. The auditor evaluates whether the chosen governance design is appropriate for that enterprise's context, then whether it operates as designed.