7.3 Organizational Structures

Quick Answer: The organizational structures component is the set of decision-making bodies and roles that can actually decide — board or other governing body, CEO, CIO, CRO, CISO, business process owners, architecture board, risk committee, audit committee, I&T management, and project/program boards. Good practice covers operating principles, span of control, escalation, and delegation of authority. RACI is how COBIT documents those roles; the full RACI method is Chapter 9. One org chart does not fit every enterprise.

Structures are who can decide, not the drawing on the wall

A process that produces a beautiful risk profile still fails if nobody has authority to accept residual risk, stop an unsafe project, or fund a treatment. Organizational structures are the key decision-making entities — committees, functions, and roles — that make the governance system able to decide.

This component is not “the org chart” as HR publishes it. Many official-looking charts show reporting lines and omit the bodies that actually govern I&T: the audit committee that hears independent assurance, the risk committee that sits between the board and management, the architecture board that can reject a non-standard design, the project or program board that can stop a failing initiative. COBIT models those entities because EGIT decisions happen there.

It is also not a license to stuff management roles into the governing body. Chapter 5 already split governance (board: evaluate, direct, monitor) from management (executive: plan, build, run, monitor). The CIO, CRO, and CISO inform and recommend. They do not become the board by attending the meeting. A Foundation item that places the CIO as the governing body is testing that split.

If the process is the clinical pathway, organizational structures are the medical executive committee, the department chairs, and the attending who can stop a procedure. The pathway does not operate itself.

The named bodies and roles to recognize

Learn the cast, not a seating chart. Foundation items name these entities and ask what they are for.

• Board / governing body — owns EDM. Evaluates stakeholder needs, directs I&T priorities and risk appetite, monitors value, risk, and resource use. In some public or owner-managed enterprises the “board” is a council, commission, or owners’ committee. The function is what the exam cares about.
• CEO — the hinge between governance and management. Translates board direction into executive accountability. Still a management role.
• CIO — leads the I&T management system; does not absorb governance.
• CRO — enterprise or I&T risk leadership; typically advises EDM03 and runs or partners on APO12. Not the audit committee.
• CISO — information-security leadership; typically close to APO13 Managed Security and related DSS work. Advises; does not replace the board.
• Business process owners — accountable for business processes that use I&T. COBIT is end-to-end: I&T governance is not only the IT department.
• Architecture board — decision body for architecture standards, exceptions, and target-state choices.
• Risk committee — focused risk oversight; often a board committee or a management committee that reports up. Read which layer the stem describes.
• Audit committee — independent assurance oversight; typically a board committee. Hears internal and external audit; does not run APO12.
• I&T management — the executive I&T team that plans, builds, runs, and monitors.
• Project / program boards — time-boxed decision bodies for initiatives (BAI-related). They escalate; they are not the enterprise governing body.

You do not need a unique job description for every title. You need the altitude: who evaluates and directs, who assures independently, who runs I&T, who owns the business process, and who can stop a project.

Good-practice themes

COBIT does not grade you on a pretty chart. It grades whether structures can decide.

Operating principles state how the body works: mandate, quorum, what it may approve, what it only advises. A risk committee without operating principles becomes a conversation club.

Span of control asks whether the body is sized to the decisions in front of it. One overworked architecture board that “approves” every change is not control; it is a bottleneck. An SME may combine roles; a global bank may split them. That is variant structure, not non-compliance.

Delegation of authority states which decisions stay at the board, which go to the CEO or CIO, and which a project board may make. Without delegation, every exception climbs to the board and the board starts doing management.

Escalation states when a decision must go up: risk above appetite, architecture exception, program off-track, audit issue unanswered. Escalation is the partner of delegation. Delegation without escalation is abandonment; escalation without delegation is theater.

Document those rules. COBIT’s usual documentation method is a RACI chart: Responsible, Accountable, Consulted, Informed. Chapter 9 teaches how to build and read RACI in depth — including the one-Accountable rule and how practices get rows. In this chapter, remember only that RACI is how structures get written down against practices, not a separate eighth component and not a substitute for naming the bodies.

Exam traps: the board is not the CIO, and one chart is not the model

Trap one: putting management roles in the governing body. A stem that says “the CIO evaluates stakeholder needs and directs risk appetite” is describing EDM work with a management title. That violates governance distinct from management. The CIO may prepare the options. The governing body evaluates and directs.

Trap two: assuming one org chart fits all. Chapter 6 already taught generic versus variant components and design factors such as enterprise size. A 40-person firm will not staff a separate CRO, CISO, architecture board, risk committee, and program board. Combining roles is a variant organizational structure. Inventing a mandatory COBIT org chart is how candidates fail SME items.

Trap three: treating RACI as the structure itself. RACI documents who is accountable for a practice. The structure is the body or role that holds that accountability. You can have a RACI and still lack a real risk committee. You can have a risk committee and still lack a RACI. The component is the decision-making entity; RACI is the documentation method.