11. Sourcing, Cloud, Platforms, and Ecosystem Governance

Introduction and Context

Information technology sourcing has moved from a relatively simple choice between internal development and external procurement to a complex question of how an organization participates in interconnected technological ecosystems. An enterprise may operate its own data centres, consume infrastructure from several cloud providers, contract with specialist vendors, use shared services, expose application programming interfaces (APIs), and depend on digital platforms whose rules are controlled by other organizations. Strategic planning must therefore address not only who performs a technical activity, but also who controls capabilities, data, standards, relationships, risks, and future options.

Sourcing decisions are governance decisions because they allocate authority, accountability, knowledge, investment, and exposure. A poorly designed outsourcing arrangement can weaken institutional capability even when it reduces short-term cost. A cloud strategy can improve scalability while creating concentration, portability, regulatory, and financial risks. A platform partnership can accelerate innovation while making the organization dependent on proprietary interfaces and commercial policies. The central challenge is to obtain external capabilities without surrendering the strategic control required for resilience, accountability, and long-term adaptability.

This chapter examines insourcing, outsourcing, multisourcing, shared services, cloud sourcing, platforms, and strategic ecosystems. It develops an analytical approach to contracts, service levels, interoperability, vendor lock-in, intellectual property, concentration risk, and ecosystem dependency. The subject is especially important for doctoral study because sourcing outcomes are shaped by institutional context, power asymmetry, organizational learning, regulation, architecture, and evolving technology—not by procurement price alone.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Distinguish among insourcing, outsourcing, multisourcing, shared services, cloud services, platforms, and ecosystem partnerships.

2. Evaluate sourcing options using strategic, economic, architectural, operational, and governance criteria.

3. Design governance mechanisms for contracts, service levels, data, intellectual property, interoperability, and exit.

4. Diagnose vendor lock-in, concentration risk, and dependency across technology ecosystems.

5. Apply cloud and platform governance principles to practical organizational situations.

6. Critically assess emerging sourcing models, including artificial-intelligence services and sovereign or regulated cloud environments.

From Make-or-Buy to Capability Orchestration

Insourcing means that an organization owns and manages the people, processes, technology, and accountability required to deliver a service. It can preserve institutional knowledge, support differentiation, and provide direct control over sensitive operations. Its disadvantages may include high fixed costs, recruitment difficulty, slower access to specialized expertise, and the risk that internal teams become isolated from external innovation.

Outsourcing transfers the performance of a defined activity to an external provider. Traditional outsourcing often involved a long-term contract for a relatively stable service, such as infrastructure operations, application maintenance, or a service desk. Outsourcing can provide scale, specialist skills, and variable cost structures. However, the purchaser may lose tacit knowledge, become dependent on the supplier, or discover that contractual specifications cannot capture all important aspects of service quality.

Multisourcing uses several providers for different services, components, regions, or layers of a technology landscape. It may create competition and reduce dependence on one supplier, but it also creates integration and coordination costs. A multisourced environment requires clear service ownership, common architecture, shared operational processes, and effective dispute resolution. Without these, each supplier may optimize its own contract while the end-to-end service deteriorates.

Shared services consolidate common capabilities for multiple business units, subsidiaries, or public agencies. A shared service centre can reduce duplication and standardize processes, but it may become a central bottleneck or fail to respond to the distinctive needs of its stakeholders. Its success depends on a transparent service catalogue, funding model, prioritization process, and performance agreement.

A strategic partnership differs from a conventional supplier relationship because the parties jointly pursue innovation, market access, capability development, or ecosystem growth. Partnerships may involve co-investment, shared intellectual property, joint product development, or reciprocal access to data and distribution channels. They demand relationship governance in addition to transactional contract management.

The relevant unit of analysis is therefore not merely the supplier. It is the organizational capability and its network of dependencies. A sourcing decision should ask: Which capabilities are strategically distinctive? Which risks can the organization tolerate? What knowledge must remain internal? What interfaces must remain open? How easily can the arrangement be changed? These questions lead to a portfolio approach rather than a single universal sourcing policy.

A Strategic Portfolio for Sourcing Decisions

A useful sourcing assessment evaluates each capability across at least five dimensions: strategic importance, required control, market maturity, operational criticality, and substitutability. A capability that differentiates the organization and contains sensitive knowledge usually merits strong internal ownership, even if selected components are externally supported. A standardized, non-differentiating capability with a mature supplier market may be suitable for outsourcing or shared services. A capability with high operational criticality and low substitutability requires special resilience measures regardless of its delivery model.

The resource-based view of the firm explains why sourcing can be strategically significant. Capabilities that are valuable, difficult to imitate, and embedded in organizational routines may generate advantage; transferring all of them to a vendor can erode that advantage. Transaction cost economics adds another perspective: organizations compare the costs of market contracting with the costs of internal coordination, while considering uncertainty, transaction frequency, and asset specificity. High asset specificity and uncertainty increase the risk of opportunistic behaviour and contractual disputes.

Dynamic capability theory extends the analysis. Organizations need not only current efficiency but also the ability to sense change, seize opportunities, and reconfigure resources. A sourcing arrangement that is efficient today but difficult to modify may weaken this capability. Relational views of governance emphasize trust, joint problem-solving, repeated interaction, and mutual adaptation, particularly where services are complex and outcomes cannot be completely specified in advance.

A practical portfolio can classify services as follows:

• Core differentiating capabilities: retain strategic ownership and internal architectural knowledge; use external providers selectively.
• Regulated or highly sensitive capabilities: apply enhanced control over data, access, location, auditability, and personnel.
• Commodity capabilities: consider cloud, managed services, or shared services where portability and competition are credible.
• Innovation capabilities: use partnerships, laboratories, or co-development arrangements with explicit intellectual-property rules.
• Critical ecosystem dependencies: diversify providers, maintain contingency plans, and monitor systemic exposure.

This classification should be revisited because a capability may move between categories as technology, regulation, competition, or business strategy changes.

Cloud Sourcing and the New Control Boundary

Cloud computing changes the location and form of control. Infrastructure as a service provides configurable computing, storage, and networking; platform as a service provides managed runtime and development capabilities; software as a service provides complete applications. These models reduce the need to own physical infrastructure, but they do not eliminate governance responsibilities. The customer remains accountable for appropriate configuration, identity management, data classification, legal compliance, resilience, and the business consequences of service failure.

Cloud governance begins with a decision framework rather than a presumption that everything should move to the cloud. Workloads should be assessed for data sensitivity, latency, availability, portability, licensing, integration complexity, regulatory requirements, and economic behaviour. A workload that is variable and loosely coupled may benefit from cloud elasticity. A stable workload with expensive data movement, specialized hardware, or strict location requirements may not.

The shared-responsibility model is central. The provider may secure the physical facilities and underlying service, while the customer remains responsible for identities, permissions, data, application configuration, and use of the service. The precise boundary varies by service model and contract. Governance must therefore translate technical responsibility into named organizational accountability.

Cloud economics also require discipline. Consumption-based pricing can turn unused capacity into a visible cost, but it can also create unanticipated expenditure through data transfer, premium services, duplicated environments, or poorly controlled automated workloads. Financial operations practices, often called FinOps, connect engineering decisions with budgeting, forecasting, cost allocation, and value measurement. Cost optimization should not be pursued by weakening security, resilience, or service quality.

Hybrid and multicloud architectures may improve flexibility or satisfy regulatory requirements, but they are not automatically more resilient. They can increase identity complexity, monitoring gaps, inconsistent controls, data-transfer costs, and skills requirements. Resilience results from tested recovery processes, independent failure assumptions, appropriate architecture, and operational competence—not simply from having multiple provider logos.

Platforms, APIs, and Ecosystem Power

A platform provides reusable technical and commercial foundations on which other products, services, or participants operate. Examples include cloud platforms, enterprise data platforms, digital payment ecosystems, mobile application ecosystems, and industry exchanges. Platforms create value through reuse, network effects, standards, and reduced coordination costs. They also create power because the platform owner may determine access conditions, technical rules, pricing, data visibility, certification requirements, and the treatment of competing services.

Platform governance should examine both technical and institutional rules. Technical governance includes API stability, identity federation, data schemas, version control, event standards, observability, and developer access. Institutional governance includes participation rights, dispute procedures, revenue arrangements, data-use permissions, liability, competition concerns, and change-notification requirements.

Interoperability is more than the existence of an API. It requires semantic compatibility, reliable authentication, stable contracts, acceptable performance, and the ability to transfer data and processes without unreasonable loss of meaning. Open standards can reduce dependency, but an organization may still become locked in through proprietary data models, specialized skills, workflow redesign, or accumulated operational knowledge.

Lock-in exists when switching costs become sufficiently high that a customer cannot credibly change provider, even if the provider’s performance or price becomes unacceptable. Technical lock-in may result from proprietary interfaces or services. Economic lock-in may arise from discounts, licensing structures, or data-egress charges. Knowledge lock-in occurs when only the supplier understands the implementation. Contractual lock-in may be created by renewal terms, restrictive rights, or expensive exit assistance. Effective governance identifies all four forms.

Contract and Service-Level Governance

A technology contract should express the governance model, not merely describe a purchase. It should define scope, assumptions, responsibilities, dependencies, security controls, data rights, performance obligations, change procedures, audit rights, remedies, termination rights, and transition assistance. Ambiguous allocation of responsibility is particularly dangerous in integrated services, where a failure may cross organizational boundaries.

Service-level agreements (SLAs) translate selected service expectations into measurable commitments. Availability is important, but an SLA should also consider response time, restoration time, data durability, incident communication, support quality, security-event notification, recovery-point objectives, recovery-time objectives, and customer experience. Metrics must be meaningful to the business. A provider can meet an infrastructure availability target while a critical business process remains unusable.

Service-level objectives should be accompanied by measurement rules. The parties need agreement on the measurement point, excluded events, maintenance windows, sampling method, evidence, reporting frequency, and treatment of chronic minor failures. Financial service credits may compensate for an incident but often do not restore lost reputation, revenue, or trust. Governance should therefore include root-cause analysis, corrective-action plans, escalation, and the possibility of termination for persistent underperformance.

Contracts for evolving services need controlled flexibility. Change boards, architecture review, security review, and price-adjustment mechanisms can prevent uncontrolled scope expansion. At the same time, excessive approval requirements can obstruct innovation. The appropriate principle is differentiated governance: routine low-risk changes should be automated, while changes affecting data, criticality, architecture, or legal exposure should receive deeper review.

Concentration Risk, Resilience, and Exit

Concentration risk arises when an organization, sector, or economy depends heavily on one provider, one region, one technology, or one small group of specialists. It may be deliberate because scale produces efficiency, but it becomes a governance concern when a common failure can affect many services simultaneously. Concentration can exist at several layers: infrastructure provider, software component, telecommunications carrier, identity service, data centre region, subcontractor, or skilled labour market.

Risk assessment should map direct and fourth-party dependencies. A provider may outsource critical operations to another provider, making the customer’s apparent diversification misleading. Dependency maps, criticality assessments, scenario analysis, and operational resilience tests help reveal hidden exposure. Relevant scenarios include provider insolvency, prolonged outage, cyberattack, geopolitical restriction, data corruption, sanctions, sudden price changes, and loss of a key subcontractor.

Exit planning is a design activity, not an end-of-contract event. It includes data-export formats, tested restoration, ownership of configurations and documentation, replacement skills, transition periods, parallel running, license portability, deletion verification, and access to necessary logs. A theoretical right to terminate is weak if the organization cannot operate the service during transition. Portability should therefore be tested before a crisis, especially for critical workloads.

Intellectual Property, Data, and Ethical Governance

Sourcing arrangements must distinguish pre-existing intellectual property, newly created work, supplier tools, customer data, derived data, models, documentation, and open-source components. Ownership is not the only issue; the organization also needs sufficient licenses to use, modify, transfer, audit, and preserve relevant artefacts. Artificial-intelligence services make this more complex because training data, prompts, outputs, model weights, fine-tuning assets, and feedback may each have different rights and confidentiality implications.

Data governance must address purpose limitation, retention, access, location, cross-border transfer, classification, deletion, legal hold, and secondary use. Sensitive information should not be sent to an external service merely because the service is convenient. Vendor personnel access, subcontracting, logging, and data-isolation claims require evidence and auditability.

Ethical governance includes fairness, transparency, accountability, accessibility, and respect for affected individuals. A supplier cannot contract away the organization’s ethical responsibility for automated decisions or harmful outcomes. Procurement teams should evaluate whether a provider’s business model creates conflicts of interest, whether surveillance is proportionate, and whether affected stakeholders have meaningful avenues for explanation and remedy.

An Integrated Governance Operating Model

Effective ecosystem governance requires multiple layers. The board or executive committee sets risk appetite and approves strategically consequential dependencies. An enterprise architecture function defines principles for integration, portability, resilience, and technology standards. Procurement and legal functions structure competition, contractual rights, and commercial safeguards. Security and privacy functions establish control requirements. Service owners manage operational performance, while finance monitors total cost and consumption. Business leaders remain accountable for outcomes rather than delegating accountability to vendors.

A practical governance cycle contains six connected activities:

1. Discover: inventory capabilities, suppliers, contracts, data flows, fourth parties, and critical dependencies.

2. Classify: assess strategic value, criticality, sensitivity, substitutability, and regulatory exposure.

3. Design: select the sourcing model, architecture, control boundary, commercial structure, and exit approach.

4. Contract: define responsibilities, service measures, rights, remedies, change mechanisms, and evidence requirements.

5. Operate and monitor: track performance, cost, security, concentration, interoperability, and relationship health.

6. Reassess and transition: test scenarios, review strategic fit, renegotiate where appropriate, and preserve credible alternatives.

Governance metrics may include critical services with tested exit plans, percentage of workloads using approved interfaces, concentration by provider and region, SLA breaches weighted by business impact, time required to restore or migrate, proportion of supplier intellectual property documented, unallocated cloud expenditure, and unresolved high-risk fourth-party dependencies. Metrics should support decisions rather than encourage superficial compliance.

Illustrative Case: Northbridge Health Network

Background

Northbridge Health Network is a fictional regional healthcare organization operating hospitals, clinics, laboratories, and patient-facing digital services. It historically maintained an internal data centre but increasingly adopted cloud-hosted analytics, an external electronic medical-record platform, and specialist cybersecurity services.

Situation and Problem

Northbridge planned to consolidate its patient portal and analytics environment on one major cloud platform. The proposal promised faster deployment and lower infrastructure administration. However, the architecture used proprietary data pipelines, identity services, and machine-learning tools. A single systems integrator would manage implementation and ongoing operations. Clinical leaders were concerned about availability, privacy, and the ability to change providers. The initial business case considered migration cost and projected operating expenditure but did not quantify exit cost, concentration risk, or the value of retained internal capability.

Analysis

A governance review classified the patient portal and clinical data services as highly critical and highly sensitive. The proposed design created concentration at the cloud provider, systems integrator, identity service, and specialist staffing levels. The organization also discovered that the draft contract granted the provider broad rights to use operational data for service improvement and did not clearly distinguish customer data from derived analytics. The SLA measured monthly availability but excluded several dependencies and offered service credits that were immaterial compared with clinical disruption.

Approach and Strategy

Northbridge adopted a controlled hybrid strategy. It retained internal ownership of enterprise architecture, identity policy, data governance, clinical continuity planning, and service management. The cloud provider was used for elastic analytics and selected application components, while critical records were stored using portable formats with independently maintained backups. Open standards and documented APIs were required for integration. The contract included data-use restrictions, audit rights, incident notification, recovery testing, transition assistance, price transparency, subcontractor disclosure, and termination support.

The organization introduced quarterly dependency reviews and annual exit exercises. It also established a small internal platform team capable of operating essential services and reviewing provider designs. A second provider was not used for every workload; instead, portability was prioritized for the most critical data and services where the benefits outweighed added complexity.

Outcome

Northbridge achieved the intended deployment speed for analytics while avoiding a complete transfer of architectural knowledge. Operating complexity increased modestly, and the organization accepted some duplicated controls and skills expenditure as the price of resilience and accountability. The most important result was not the elimination of dependency, which was impossible, but the creation of informed, measurable, and testable dependency.

Learning Points

The case illustrates that cloud adoption is not equivalent to governance maturity. Critical questions concern control boundaries, data rights, operational capability, exit feasibility, and dependency concentration. Selective portability can be more valuable than an unrealistic attempt to make every workload multicloud. Finally, internal capability should be preserved where it is necessary to exercise intelligent ownership.

Challenges and Common Mistakes

Organizations frequently select suppliers primarily on price and later discover that integration, transition, governance, and change costs dominate the total cost of ownership. Another common mistake is outsourcing a service without retaining the capability to specify, evaluate, and challenge it. This produces what may be called intelligent-customer failure.

Other weaknesses include treating compliance certificates as proof of effective security, accepting vague service definitions, ignoring fourth parties, assuming that an API guarantees portability, and failing to test recovery or exit procedures. Multisourcing can also become a fragmentation strategy in which no party owns the end-to-end outcome. Conversely, a single strategic supplier can become an unexamined point of systemic failure.

Governance can itself become excessive. Numerous committees, duplicated audits, and slow approvals may discourage responsible innovation and drive teams toward unauthorized services. Proportionate, risk-based controls are preferable. Governance should make safe choices easier, not merely impose additional documentation.

Current Developments and Emerging Directions

Cloud-native architectures, managed databases, serverless computing, and software marketplaces are increasing the number of externally supplied building blocks in enterprise systems. Generative artificial intelligence is intensifying questions about model dependency, data leakage, output reliability, copyright, explainability, and the portability of prompts, evaluation sets, and fine-tuned models. Organizations are beginning to govern AI services as ecosystem dependencies rather than treating them solely as software features.

Sovereign and sector-specific cloud arrangements are also gaining attention where governments and regulated industries require stronger control over jurisdiction, personnel, data location, and operational authority. These arrangements may reduce some risks but can limit supplier choice or increase cost. Open-source software and open digital public infrastructure can reduce proprietary dependence, although they introduce responsibilities for maintenance, security, community health, and supply-chain assurance.

The broader trend is toward composable organizations: capabilities are assembled from internal teams, cloud services, platforms, partners, and communities. This increases strategic flexibility only when interfaces, accountability, observability, and substitution options are deliberately designed.

Best-Practice Principles

A mature sourcing and ecosystem governance program should:

• decide sourcing from business capability and risk, not fashion or procurement habit;
• retain internal ownership of architecture, data accountability, and critical service outcomes;
• assess total lifecycle cost, including integration, skills, transition, and exit;
• map fourth-party and cross-border dependencies;
• use open interfaces, portable data, documented configurations, and tested recovery procedures;
• align SLAs with business impact and customer outcomes;
• negotiate meaningful audit, data-use, change, termination, and transition rights;
• monitor concentration and lock-in as strategic risks;
• use proportionate governance that supports innovation;
• review sourcing decisions periodically as technology, regulation, and organizational strategy change.

Chapter Summary

Sourcing is a strategic allocation of capability, control, knowledge, risk, and dependency. Insourcing, outsourcing, multisourcing, shared services, cloud consumption, platforms, and partnerships each provide different combinations of flexibility, expertise, scale, and exposure. The appropriate choice depends on strategic importance, sensitivity, criticality, market maturity, substitutability, and the organization’s ability to remain an intelligent customer.

Cloud and platform governance extend beyond procurement. They require clear responsibility boundaries, secure data practices, meaningful service measures, interoperability, intellectual-property protection, financial controls, and credible exit arrangements. Vendor lock-in and concentration risk must be examined across technical, economic, knowledge, contractual, and ecosystem dimensions. Effective governance combines executive accountability, architecture, security, legal, procurement, finance, service management, and business ownership. Its purpose is not to eliminate external dependence but to make dependence visible, proportionate, resilient, and strategically manageable.

Key Terms

Insourcing: Delivery of a capability using organizationally owned and managed resources.

Outsourcing: Contracting an external provider to perform a defined activity or service.

Multisourcing: Use of multiple providers for different services, components, or layers.

Shared services: Centralized capabilities delivered to several organizational units.

Strategic partnership: A collaborative relationship involving shared objectives, investment, innovation, or capability development.

Cloud computing: On-demand access to configurable computing resources delivered through networked services.

Infrastructure as a service: Cloud provision of virtualized computing, storage, and networking resources.

Platform as a service: Managed cloud environment supporting application development and execution.

Software as a service: Complete software application delivered and managed as an online service.

Shared-responsibility model: Allocation of security and operational duties between provider and customer.

Platform governance: Rules governing technical, commercial, and institutional participation in a platform.

Interoperability: Ability of systems and organizations to exchange and use information effectively.

Vendor lock-in: Condition in which switching provider is constrained by high technical, economic, knowledge, or contractual costs.

Concentration risk: Exposure created by excessive dependence on one provider, region, technology, or specialist group.

Service-level agreement: Contractual statement of measurable service commitments and related remedies.

Fourth-party dependency: Dependence on a provider used by an organization’s direct supplier.

Portability: Ability to move data, applications, configurations, or services between environments.

Intellectual property: Legally protected creations, software, data assets, models, documentation, or related rights.

FinOps: Practice integrating cloud consumption, engineering decisions, financial management, and business value.

Exit plan: Documented and tested arrangements for changing, terminating, or transitioning a service.

Review Questions

Short Answer Questions

1. How does multisourcing differ from outsourcing to a single provider?

2. What responsibilities commonly remain with a customer under the cloud shared-responsibility model?

3. Define vendor lock-in and identify two forms it can take.

4. Why is an API alone insufficient to guarantee interoperability?

5. What is meant by fourth-party dependency?

Long Answer Questions

1. Critically compare insourcing, outsourcing, shared services, and strategic partnerships using strategic and governance criteria.

2. Explain how transaction cost economics, the resource-based view, and dynamic capability theory contribute to sourcing decisions.

3. Discuss the governance requirements of a cloud strategy, including security, cost, resilience, data, and exit considerations.

4. Explain how contracts and service-level agreements should be designed for complex, evolving technology services.

5. Examine the relationship between intellectual property, data governance, platform power, and ecosystem dependency.

Analytical / Application Questions

1. An organization wants to place all critical applications with one cloud provider to obtain volume discounts. Develop a governance assessment identifying benefits, risks, controls, and conditions for approval.

2. A multisourcing arrangement meets every supplier’s individual SLA, yet the end-to-end customer service is unreliable. Diagnose the likely governance failures and propose corrective mechanisms.

3. Design a sourcing portfolio for a regulated organization containing a differentiating analytics capability, a commodity collaboration tool, a highly sensitive records system, and an experimental AI service. Justify the sourcing and governance model for each capability.

22. Multiple Choice Questions with Answers

Question 1

Which factor most strongly supports retaining internal ownership of a technology capability?

A. The capability is standardized and widely available from suppliers

B. The capability is strategically differentiating and difficult to imitate

C. The capability has highly variable computing demand

D. The capability requires routine commodity support

Correct Answer: B. The capability is strategically differentiating and difficult to imitate

Question 2

What is the principal governance implication of the cloud shared-responsibility model?

A. The provider assumes all responsibility once data enters the cloud

B. The customer remains accountable for appropriate configuration, identity, data, and use

C. The customer is responsible only for paying the subscription

D. Security responsibility is transferred entirely to the systems integrator

Correct Answer: B. The customer remains accountable for appropriate configuration, identity, data, and use

Question 3

Which situation best illustrates knowledge lock-in?

A. A provider charges for data transfer

B. A contract prevents termination during the first year

C. Only supplier personnel understand the undocumented implementation

D. An application uses a published open standard

Correct Answer: C. Only supplier personnel understand the undocumented implementation

Question 4

Why may multisourcing increase rather than reduce operational risk?

A. It eliminates the need for service management

B. It creates integration and coordination responsibilities across providers

C. It always prevents the use of common standards

D. It transfers all accountability to the customer’s procurement department

Correct Answer: B. It creates integration and coordination responsibilities across providers

Question 5

Which contract provision most directly supports a credible exit strategy?

A. A general promise of future innovation

B. A requirement for data export, transition assistance, and deletion verification

C. A higher volume discount for additional services

D. A restriction on customer audits

Correct Answer: B. A requirement for data export, transition assistance, and deletion verification

Question 6

An organization has portable data but cannot move its service because its workflows depend on proprietary APIs and specialized skills. What does this demonstrate?

A. Portability is multidimensional and data portability alone is insufficient

B. Open standards always eliminate switching costs

C. Concentration risk exists only at the infrastructure layer

D. Service-level agreements guarantee interoperability

Correct Answer: A. Portability is multidimensional and data portability alone is insufficient

Question 7

Which metric is most closely aligned with business-impact-oriented service governance?

A. Number of supplier employees

B. Count of software features released by the vendor

C. Recovery time for a critical business process

D. Provider office locations

Correct Answer: C. Recovery time for a critical business process

Question 8

What is a major limitation of relying solely on provider compliance certificates?

A. Certificates prevent any contractual relationship

B. They prove that every customer configuration is secure and effective

C. They may not demonstrate effective controls for the organization’s specific use

D. They eliminate the need for incident reporting

Correct Answer: C. They may not demonstrate effective controls for the organization’s specific use

Question 9

In the Northbridge case, why was selective portability preferred over making every workload multicloud?

A. Multicloud always costs less than single-cloud use

B. Portability was prioritized where resilience benefits justified added complexity

C. The organization wanted to eliminate all internal technical capability

D. The organization had no critical or sensitive workloads

Correct Answer: B. Portability was prioritized where resilience benefits justified added complexity

Question 10

Which governance response best addresses concentration risk from a critical cloud provider?

A. Ignore the risk if the provider has a strong brand

B. Map dependencies, test recovery and exit, and assess viable alternatives

C. Use more services from the same provider to simplify procurement

D. Measure only monthly availability

Correct Answer: B. Map dependencies, test recovery and exit, and assess viable alternatives