7. Governance Principles, Structures, and Decision Rights

Introduction and Context

IT governance is the institutional arrangement through which an organization directs, controls, and evaluates the use of information technology. It is not synonymous with IT management. Management concerns planning, building, operating, and monitoring technology services; governance determines who has authority to make consequential decisions, how competing interests are reconciled, how accountability is assigned, and how technology contributes to organizational purpose.

The distinction becomes especially important when digital capabilities are distributed across business units, subsidiaries, cloud providers, data platforms, strategic partners, and public ecosystems. A centralized technology department may once have controlled most systems and budgets. Contemporary organizations frequently operate through a mixture of enterprise platforms, local applications, citizen development, outsourced services, artificial intelligence, and shared data assets. In such settings, governance cannot depend solely on hierarchy. It must combine authority, participation, transparency, expertise, and enforceable decision rights.

This chapter examines governance as a design problem. It considers the principles that make governance legitimate and effective, the structures through which decisions are made, the roles of boards, executives, CIOs, and CDOs, and the choices among centralized, decentralized, federated, and ecosystem-based arrangements. Particular attention is given to accountability, escalation, policy, stakeholder participation, and the relationship between formal structures and actual organizational power.

Learning Objectives

By the end of this chapter, students should be able to:

1. Distinguish IT governance from IT management and explain their relationship.

2. Evaluate governance principles such as accountability, transparency, proportionality, subsidiarity, and strategic alignment.

3. Design decision rights for boards, executive committees, CIOs, CDOs, business units, and technology partners.

4. Compare centralized, decentralized, federated, and ecosystem governance models.

5. Construct escalation, policy, and stakeholder-participation mechanisms.

6. Analyze governance failures involving unclear authority, weak accountability, data ownership, or excessive centralization.

7. Assess ethical, regulatory, security, and emerging technology implications of governance design.

Governance as an Organizational Capability

Governance is best understood as a capability rather than a committee. A committee may approve projects, but governance exists only when decisions are made consistently, authority is recognized, consequences are visible, and organizational behavior changes as a result. Governance therefore includes structures, processes, rights, responsibilities, information, controls, and cultural expectations.

A useful distinction is between decision rights and decision execution. Decision rights specify who is entitled to decide, recommend, veto, ratify, or be consulted. Execution involves carrying out the decision and managing its effects. Confusing these levels produces two common failures. First, a committee may be held responsible for outcomes over which it has no real authority. Second, operational managers may make strategic decisions without appropriate review because formal governance is slow or unclear.

IT governance is also a problem of collective action. Technology investments create benefits and risks across organizational boundaries. A business unit may gain speed by adopting an independent platform while imposing security, integration, or data-quality costs on other units. Governance provides a means of internalizing those externalities. It creates rules for deciding when local autonomy is beneficial and when enterprise coordination is necessary.

Governance quality should not be judged by the number of policies or meetings. A large body of procedures can coexist with poor governance if decisions are delayed, accountability is diffused, or informal influence overrides formal authority. Conversely, a relatively lean structure may be effective when material decisions are clearly allocated, evidence is available, and exceptions are handled transparently.

Principles for Designing Governance

Strategic alignment and value realization

Technology decisions should be connected to organizational objectives rather than evaluated only by technical elegance or local efficiency. Alignment does not mean that every technology decision requires executive approval. It means that decision criteria reflect agreed priorities, such as resilience, service quality, growth, research impact, regulatory compliance, or cost sustainability. Governance should also examine whether expected benefits are realized after implementation. Approval without post-implementation accountability encourages optimistic business cases and weak learning.

Accountability and answerability

Accountability has two dimensions. Answerability requires an actor to explain a decision and its results. Consequential accountability means that performance, negligence, or misconduct can lead to corrective action. Assigning a committee as the owner of everything often weakens both dimensions. Committees deliberate collectively, but a named executive or product owner usually must remain accountable for a defined outcome.

Transparency and traceability

Material decisions should be explainable to affected stakeholders. Transparency does not require publication of every sensitive detail; it requires an intelligible record of the decision, alternatives considered, evidence used, risks accepted, and authority exercised. Traceability is particularly important for data access, automated decisions, cybersecurity exceptions, and high-value investments.

Proportionality and risk-based control

Governance controls should correspond to the scale, reversibility, uncertainty, and potential harm of a decision. A low-risk configuration change should not follow the same route as a decision involving critical infrastructure or sensitive personal data. Proportionality reduces bureaucracy while preserving scrutiny where consequences are serious.

Subsidiarity and appropriate autonomy

Subsidiarity assigns a decision to the lowest competent level unless coordination, risk, or external effects require a higher level. It avoids both unnecessary centralization and uncontrolled fragmentation. The principle requires clear boundaries: local autonomy is meaningful only when standards, funding responsibilities, security obligations, and escalation routes are understood.

Independence and challenge

Governance benefits from participants who can question proposals without being dependent on the proposal's sponsor. Independent risk, audit, security, privacy, or compliance functions can provide challenge. Independence should not become detachment: challenge is most useful when it is timely, evidence-based, and connected to practical alternatives.

Inclusion and legitimacy

Technology affects employees, customers, citizens, suppliers, researchers, and communities. Stakeholder participation improves the quality and legitimacy of decisions, especially where systems influence access to services, employment, privacy, or public trust. Participation must be designed carefully; consultation without influence can create cynicism. Governance should specify which stakeholders are informed, consulted, represented, or empowered to approve.

Stewardship and sustainability

Information, algorithms, platforms, and digital infrastructure are organizational assets whose effects extend beyond a single budget cycle. Stewardship requires attention to data quality, institutional memory, maintainability, environmental impact, accessibility, and intergenerational risk. It challenges decisions that produce short-term savings by creating long-term technical debt or social harm.

The Architecture of Governance Structures

Governance structures operate at several levels. At the highest level, the board or governing body oversees purpose, risk appetite, major investments, and executive accountability. It normally does not select software products or manage daily service operations. An audit, risk, technology, or digital committee may support the board by examining specialized issues, but delegated authority must be explicit.

The executive level translates organizational strategy into priorities and resource choices. An executive technology or digital committee may include the chief executive, chief financial officer, CIO, CDO, chief risk officer, business executives, and other leaders. Its value lies in cross-enterprise trade-offs: whether to fund resilience over a discretionary feature, consolidate platforms, accept a risk, or sequence transformation initiatives.

The CIO is commonly accountable for enterprise technology capability, including architecture, infrastructure, service management, cybersecurity coordination, vendor management, technology talent, and delivery performance. The exact scope varies by organization. The CIO should not be treated merely as the head of a technical department; the role is fundamentally concerned with translating institutional strategy into dependable digital capability.

The CDO role has several interpretations. In some organizations, the Chief Data Officer leads data governance, quality, stewardship, literacy, analytics, and data-sharing policy. In others, the Chief Digital Officer leads customer experience, digital products, transformation, and new business models. The title alone therefore does not establish decision rights. A governance design must specify whether the CDO owns data policy, digital product outcomes, analytics standards, or some combination, and how these responsibilities intersect with the CIO, privacy officer, security officer, and business owners.

Business executives and product owners remain essential. Technology value is realized in business processes, services, research activities, and customer interactions. If technology is governed solely by technical leaders, investment decisions may be disconnected from outcomes. Conversely, if business units control technology without enterprise constraints, integration and risk problems may proliferate.

Three lines of accountability are often useful. Operational management owns and manages risks in daily work. Risk, security, privacy, and compliance functions provide specialist oversight and challenge. Internal audit provides independent assurance about the effectiveness of governance and controls. These lines should cooperate without collapsing into one another.

Choosing Among Centralized, Decentralized, and Federated Models

A centralized model concentrates technology standards, architecture, procurement, security, and often budgets in an enterprise function. It can produce economies of scale, consistent controls, shared platforms, and stronger bargaining power. It is particularly suitable where data is highly sensitive, infrastructure is shared, regulation is stringent, or interoperability is critical. Its dangers include slow response, distance from users, excessive standardization, and the tendency to treat local needs as exceptions.

A decentralized model gives business units substantial authority over technology priorities, suppliers, applications, and budgets. It can encourage innovation, responsiveness, and domain expertise. It is attractive in diversified organizations where units have distinct markets or operating models. Its risks include duplicated systems, inconsistent security, incompatible data, weak enterprise architecture, and competition for scarce expertise.

A federated model combines enterprise guardrails with local decision authority. The center establishes principles, mandatory standards, shared platforms, risk thresholds, and common services; domains retain control over product priorities and locally relevant choices. Federation is not simply a compromise between centralization and decentralization. It requires an explicit allocation of rights and a mechanism for resolving boundary disputes.

A practical federated design can distinguish four categories of decisions:

• Enterprise-mandated decisions, such as identity standards, minimum security controls, privacy obligations, and critical architecture principles.
• Shared decisions, such as data definitions, integration patterns, cloud strategy, and platform road maps.
• Domain decisions, such as product features, workflow configuration, and local service improvements.
• Individual decisions, such as routine operational choices within approved standards.

Ecosystem governance extends the problem beyond the legal organization. Cloud providers, software vendors, application developers, universities, regulators, industry consortia, and customers may all influence technology outcomes. Contracts are necessary but insufficient. Ecosystem governance also requires shared standards, assurance rights, incident coordination, data-sharing rules, portability expectations, and mechanisms for managing dependency. The organization must understand not only who supplies a capability but who controls the data, model, interface, and continuity of that capability.

Decision Rights: From Organizational Charts to Operating Rules

An organizational chart shows reporting relationships; it does not show who decides. Decision-rights design makes authority explicit. A decision-rights register may identify the decision, accountable owner, recommender, required consultees, approval authority, veto rights, evidence required, time limit, and escalation route.

A RACI matrix can distinguish who is Responsible, Accountable, Consulted, and Informed, although it should not be used mechanically. A single decision should normally have one accountable owner, even when many parties contribute. For more complex decisions, a RAPID-style model may distinguish the person who recommends, agrees, performs, provides input, and decides. The specific tool matters less than the clarity it produces.

Decision rights should be allocated according to several questions:

1. Who bears the consequences if the decision fails?

2. Who possesses the knowledge needed to make it well?

3. Does the decision create enterprise-wide externalities?

4. Is the decision reversible, and how quickly?

5. What legal, ethical, security, or financial thresholds apply?

6. Who has authority to allocate the required resources?

7. What evidence must be available before a decision is made?

A useful distinction is between approval rights, veto rights, and advisory rights. A security function may veto a deployment that violates a mandatory control, but it should not automatically own the product roadmap. A finance function may approve funding, while a business owner remains accountable for benefits. A privacy officer may require a privacy impact assessment without deciding every feature. Explicit boundaries prevent specialist assurance from becoming either irrelevant or overcentralized.

Decision latency is a governance metric. Excessive approval layers create shadow decision-making, while insufficient review creates avoidable risk. Governance should specify service levels for decisions, delegated authorities for routine matters, and temporary authority during incidents. Emergency powers must be documented retrospectively; urgency should accelerate accountability, not eliminate it.

Policies, Escalation, and Exception Management

A policy expresses a mandatory principle or rule. A standard provides a more specific requirement, while a procedure explains how work is performed. A guideline offers recommended practice. Confusing these categories creates either false rigidity or weak compliance. Policies should state their purpose, scope, authority, responsibilities, exceptions, enforcement mechanism, review date, and relationship to law or external obligations.

Effective policy systems are risk-based and usable. A policy that cannot be interpreted by practitioners becomes symbolic. A policy that is too detailed becomes obsolete as technologies change. Organizations should therefore combine stable principles with periodically updated standards and implementation guidance.

Exceptions are inevitable in complex organizations. The objective is not to eliminate them but to govern them. An exception request should identify the requirement, reason, duration, affected assets, risk assessment, compensating controls, accountable owner, and expiry or review date. Permanent exceptions usually indicate that the underlying standard is unsuitable or that noncompliance has been normalized.

Escalation should be triggered by defined conditions rather than personal influence. Examples include unresolved cross-unit conflict, risk above approved appetite, missed critical milestones, material security incidents, inability to meet a regulatory requirement, or a decision whose consequences exceed delegated authority. Escalation routes should move from operational resolution to domain leadership, executive governance, and, where appropriate, the board or regulator. Each level should have authority to act; escalation to a body that can only discuss the problem merely delays resolution.

Stakeholder Participation and the Politics of Governance

Governance is partly technical and partly political because it allocates scarce resources, visibility, autonomy, and risk. Stakeholder mapping can identify affected groups, their interests, influence, knowledge, and exposure to harm. Participation may involve representation on committees, design workshops, user research, public consultation, employee forums, supplier dialogue, or independent review.

Participation should be matched to the decision. Users may help define service requirements; data subjects may require meaningful information about processing; technical specialists may evaluate feasibility; communities may identify social impacts that internal experts overlook. The governing body should record how input affected the final decision and why contrary views were not adopted.

Power asymmetries deserve explicit attention. A technically sophisticated supplier may dominate a small client. A central technology group may control standards that determine whether local innovation is possible. A data team may claim ownership over information generated by operational staff. Good governance makes such dependencies visible and creates routes for challenge, appeal, and review.

A Design Method for Governance Arrangements

Governance design can proceed through a sequence of analytical steps, although the steps are iterative rather than strictly linear.

First, identify the organization's strategic objectives, risk appetite, operating model, regulatory setting, and technology dependencies. Governance that is appropriate for a regulated financial institution may be inappropriate for a small creative enterprise.

Second, inventory major decision domains: strategy and investment, architecture, data, cybersecurity, privacy, sourcing, service operations, digital products, artificial intelligence, and workforce capability.

Third, classify decisions by impact, reversibility, interdependence, urgency, and affected stakeholders. This prevents every decision from receiving the same level of control.

Fourth, assign decision rights and accountabilities. Name the accountable role, not merely a committee. Identify required expertise, consultation, approval, veto, and information rights.

Fifth, design forums and information flows. A committee without reliable dashboards, risk information, options, and decision records cannot govern effectively.

Sixth, define escalation and exception routes, including emergency authority. Test them through simulations or scenario exercises.

Seventh, establish assurance and learning. Measures may include decision cycle time, unresolved exceptions, benefit realization, policy compliance, security exposure, architecture debt, stakeholder satisfaction, and the recurrence of governance failures.

Finally, review the arrangement. Governance must evolve as the organization adopts cloud services, platforms, artificial intelligence, new partnerships, or different structures of work.

Applied Case: Federating Governance in a Public Health Network

Background

The following is an illustrative case. Meridian Health Network is a multi-site public health organization with hospitals, laboratories, community clinics, and research units. Its central IT department historically controlled infrastructure, procurement, and clinical systems. Research and community-care units increasingly adopted cloud analytics tools independently because central delivery was slow.

Situation and problem

An audit found duplicated patient-identification processes, inconsistent access controls, incompatible analytics environments, and unclear responsibility for data quality. Clinical leaders argued that central IT obstructed innovation. Central IT argued that local units created unacceptable privacy and cybersecurity exposure. The board could not determine who was accountable for the combined risk because budgets and authority were distributed informally.

Analysis

The problem was not simply technological fragmentation. It reflected an unsuitable governance model. Centralized authority had been designed for infrastructure stability but was being applied to fast-moving analytical and service decisions. At the same time, local autonomy had expanded without enterprise rules for identity, data classification, model validation, and vendor assurance. Decision rights were ambiguous: data owners, system owners, clinical leaders, and security specialists all believed they had final authority over different parts of the same decision.

Approach and solution

Meridian adopted a federated model. The board retained oversight of material cyber, privacy, and continuity risks. An executive digital and data committee, chaired by the chief executive and including the CIO, CDO, clinical leadership, research, finance, privacy, and security, approved enterprise priorities and risk thresholds.

The CIO became accountable for shared infrastructure, identity, service reliability, enterprise architecture, and technology suppliers. The CDO became accountable for data governance, common definitions, stewardship practices, data quality reporting, and responsible analytics standards. Clinical and research executives retained accountability for domain outcomes and product priorities.

A decision-rights register classified identity, minimum security controls, patient-data standards, and integration architecture as enterprise decisions. Product features, workflow design, and research questions remained domain decisions, subject to mandatory safeguards. A data council coordinated definitions and stewardship. An architecture forum reviewed exceptions rather than every local design. High-risk analytics required documented validation, privacy assessment, clinical review, and an accountable business sponsor.

The network also introduced an exception register with expiry dates and quarterly reporting. During incidents, the operational incident commander could act immediately, while material decisions were reviewed afterward by the appropriate governance body. Dashboards reported unresolved high-risk exceptions, access-control performance, service availability, data-quality trends, and benefits from shared platforms.

Outcome

The arrangement reduced disputes about who could decide and shifted debate from control versus autonomy to risk and value. Local units retained the ability to innovate within defined boundaries. The central function gained legitimacy because its mandatory controls were limited to areas with genuine enterprise consequences. The case does not imply that federation eliminates conflict; rather, it makes conflict visible, structured, and resolvable.

Learning points

The case demonstrates that governance redesign should begin with decision domains and consequences, not with the creation of another committee. It also shows that CIO and CDO responsibilities must be complementary, that accountability should remain attached to outcomes, and that exceptions require active management. Most importantly, federated governance succeeds when enterprise standards are specific enough to protect shared interests but not so broad that they eliminate responsible local judgment.

Governance Risks, Ethical Issues, and Contemporary Developments

A major governance risk is accountability diffusion, in which many people participate but no one owns the outcome. Another is committee inflation, where additional forums create the appearance of control while slowing decisions. Shadow IT may indicate rule-breaking, but it may also reveal unmet demand caused by poor central services. Treating it solely as misconduct can drive technology further underground.

Other risks include vendor lock-in, concentration in cloud or platform providers, inadequate succession for key technology roles, obsolete policies, weak records of decisions, conflicts of interest, and metrics that reward delivery speed while ignoring resilience or harm. Governance can also fail through excessive centralization: risk avoidance becomes the dominant objective and the organization loses adaptive capacity.

Ethically, governance must address privacy, fairness, accessibility, explainability, human oversight, and the distribution of benefits and harms. Automated systems require more than technical accuracy. Decision makers must ask whose data was used, who may be excluded, whether affected individuals can challenge outcomes, and who is accountable when a system behaves unexpectedly. AI governance increasingly requires model inventories, risk classification, documentation, testing, monitoring, human accountability, and controls over third-party models and data.

Digital sovereignty and resilience are also gaining importance. Organizations are examining dependence on foreign jurisdictions, proprietary interfaces, scarce suppliers, and concentrated infrastructure. Resilience governance considers not only prevention but the ability to detect, respond, continue, recover, and learn. Sustainability considerations include energy use, equipment lifecycles, data retention, and the environmental effects of large-scale computation.

Best-Practice Guidance

Sound governance arrangements generally share the following characteristics:

• They connect technology decisions to institutional outcomes and risk appetite.
• They assign one accountable owner for each material outcome.
• They distinguish strategic, tactical, operational, advisory, approval, and veto rights.
• They use proportional controls rather than universal bureaucracy.
• They preserve local autonomy where enterprise consequences are limited.
• They make exceptions visible, time-bound, and owned.
• They provide independent challenge without separating assurance from operational reality.
• They maintain decision records and use evidence-based dashboards.
• They include affected stakeholders and document how their input was handled.
• They test emergency authority, escalation routes, and continuity arrangements.
• They review governance performance rather than assuming that compliance proves effectiveness.

Chapter Summary

IT governance establishes how technology-related authority, accountability, participation, and control are organized. It differs from management because it focuses on direction, oversight, decision rights, and consequences rather than only execution. Effective governance rests on alignment, accountability, transparency, proportionality, subsidiarity, independence, inclusion, and stewardship.

Boards oversee purpose, major risk, and executive accountability; executive committees coordinate enterprise trade-offs; CIOs generally lead enterprise technology capability; and CDOs may lead data governance, digital transformation, or both, depending on explicit design. Centralized, decentralized, federated, and ecosystem models each offer benefits and risks. Federated arrangements are often effective where organizations need both enterprise safeguards and domain responsiveness.

Decision-rights registers, policy hierarchies, escalation routes, exception management, stakeholder participation, and independent assurance convert principles into operating practice. Governance must address ethical and regulatory obligations, third-party dependence, cybersecurity, privacy, AI, resilience, and sustainability. Its effectiveness should be evaluated by the quality, timeliness, legitimacy, and consequences of decisions—not by the number of committees or documents produced.

Key Terms

IT governance: The system by which an organization directs, oversees, and evaluates the use of information technology.

IT management: The planning, building, operating, and monitoring of technology services and capabilities.

Decision rights: Explicit authority to decide, approve, veto, recommend, execute, consult, or receive information.

Accountability: Obligation to explain decisions and accept consequences for outcomes.

Answerability: Responsibility to provide reasons and evidence for an action or decision.

Risk appetite: The amount and type of risk an organization is willing to accept in pursuing objectives.

Subsidiarity: Allocation of decisions to the lowest competent level unless wider coordination or control is required.

Federated governance: A model combining enterprise-wide guardrails with delegated authority in organizational domains.

Centralized governance: Governance in which major technology authority and resources are concentrated in an enterprise function.

Decentralized governance: Governance in which business units retain substantial authority over technology decisions and resources.

Ecosystem governance: Coordination of technology-related decisions across organizational and external partners.

CIO: Executive responsible, in a defined organizational context, for enterprise technology capability and performance.

CDO: Executive whose remit may include data governance, analytics, digital products, or transformation, as explicitly defined.

Policy: An authoritative statement of mandatory organizational intent or requirements.

Standard: A specific mandatory rule or technical requirement supporting a policy.

Exception management: The controlled process for approving, recording, mitigating, reviewing, and closing departures from requirements.

Escalation: Movement of an unresolved or high-impact issue to a level with greater authority or expertise.

RACI: A responsibility model identifying who is Responsible, Accountable, Consulted, and Informed.

Stakeholder participation: Structured involvement of affected or interested parties in governance decisions.

Assurance: Independent or specialist evaluation of whether governance, risk, and control arrangements are effective.

Review Questions

Short Answer Questions

1. How does IT governance differ from IT management?

2. What is meant by subsidiarity in technology governance?

3. Why should a material decision normally have one accountable owner?

4. Distinguish a policy, a standard, and a procedure.

5. What is the purpose of an exception register?

Long Answer Questions

1. Explain the principles of accountability, transparency, proportionality, and stewardship in IT governance.

2. Compare centralized, decentralized, and federated governance models, including the conditions under which each may be appropriate.

3. Discuss the potential division of responsibilities between a CIO and a CDO.

4. Explain how boards, executive committees, operational management, risk functions, and internal audit contribute to governance.

5. Describe a method for designing decision rights and escalation arrangements in a complex organization.

Analytical / Application Questions

1. A university permits faculties to procure cloud analytics tools independently, but student-data controls and integration quality are inconsistent. Design a federated governance arrangement and identify at least five decision rights.

2. A cybersecurity officer blocks every proposed digital product until all possible risks are eliminated. Analyze the governance problem using proportionality, accountability, and veto-right principles.

3. Using the Meridian Health Network case, propose two measures that could determine whether the new governance arrangement is improving both innovation and risk control.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes IT governance from IT management?

A. Governance concerns only cybersecurity, while management concerns all technology.

B. Governance allocates authority and oversees outcomes, while management executes and operates technology capabilities.

C. Governance is performed only by the CIO, while management is performed only by vendors.

D. Governance approves software products, while management sets organizational strategy.

Correct Answer: B. Governance allocates authority and oversees outcomes, while management executes and operates technology capabilities.

Question 2

In a federated governance model, which decision is most likely to be enterprise-mandated?

A. The wording of a local department’s workflow form

B. The research question selected by an academic team

C. Minimum identity and security controls

D. The visual design of a local customer portal

Correct Answer: C. Minimum identity and security controls

Question 3

Why is assigning a committee as accountable for every technology outcome problematic?

A. Committees cannot ever provide advice.

B. Committees eliminate the need for executive leadership.

C. Collective participation may obscure the individual who must explain and own the outcome.

D. Committees are always less informed than operational staff.

Correct Answer: C. Collective participation may obscure the individual who must explain and own the outcome.

Question 4

Which governance principle assigns a decision to the lowest competent level unless wider coordination is needed?

A. Subsidiarity

B. Independence

C. Transparency

D. Stewardship

Correct Answer: A. Subsidiarity

Question 5

A security function rejects a product because it violates a mandatory control but does not own the product roadmap. This illustrates the distinction between:

A. A veto right and an outcome-ownership right

B. A policy and a procedure

C. A centralized and decentralized budget

D. A consultation right and an information right

Correct Answer: A. A veto right and an outcome-ownership right

Question 6

What is the primary purpose of time-bounded exception management?

A. To make all policies optional

B. To conceal noncompliance from auditors

C. To permit justified deviations while keeping risks visible and subject to review

D. To transfer accountability from managers to committees

Correct Answer: C. To permit justified deviations while keeping risks visible and subject to review

Question 7

Which arrangement most directly supports independent challenge and assurance?

A. Having the project sponsor approve the audit report

B. Separating operational risk ownership from specialist oversight and internal audit

C. Allowing vendors to define their own control requirements

D. Requiring all stakeholders to report to the CIO

Correct Answer: B. Separating operational risk ownership from specialist oversight and internal audit

Question 8

A decentralized organization experiences duplicated platforms and inconsistent data definitions. Which response best reflects federated governance?

A. Allow every unit to continue independently without standards

B. Centralize every technology decision permanently

C. Set common enterprise standards while retaining domain authority for local products and priorities

D. Eliminate business-unit technology budgets

Correct Answer: C. Set common enterprise standards while retaining domain authority for local products and priorities

Question 9

Which information is most important in a material decision record?

A. Only the name of the person who attended the meeting

B. The decision, alternatives, evidence, accepted risks, and authority exercised

C. The technical supplier’s marketing description

D. An assurance that no stakeholder disagreed

Correct Answer: B. The decision, alternatives, evidence, accepted risks, and authority exercised

Question 10

Why must the CIO and CDO relationship be explicitly defined?

A. Their titles always have identical meanings.

B. The CDO role may cover data, analytics, digital products, or transformation, creating possible overlaps with the CIO.

C. The CIO has no responsibility for enterprise technology.

D. The CDO should automatically approve all infrastructure decisions.

Correct Answer: B. The CDO role may cover data, analytics, digital products, or transformation, creating possible overlaps with the CIO.