Third-Party Data, Platforms, and Digital Ecosystems

Introduction

Business analytics increasingly depends on data that an organization does not collect, store, or control entirely by itself. A retailer may use a cloud analytics platform, purchase demographic data from a broker, connect to payment and logistics APIs, and share customer information with advertising partners. A bank may rely on software-as-a-service providers, credit-reporting agencies, identity-verification firms, and international support centers. These arrangements create value, but they also create governance, privacy, ethical, contractual, cybersecurity, and data-sovereignty risks.

The central governance problem is that responsibility is distributed while harm is often experienced by the individual or community. A contract may allocate duties between firms, but it does not automatically make data processing lawful, ethical, secure, or socially legitimate. Similarly, a cloud provider may operate the infrastructure without determining the business purpose for which data are analyzed. Effective governance therefore requires organizations to understand the entire data supply chain, assign accountability explicitly, and monitor relationships throughout their life cycle.

This chapter examines vendors, cloud services, data brokers, APIs, partnerships, digital platforms, and international data transfers. It treats third parties not merely as procurement concerns but as participants in an organization’s information ecosystem.

Learning Objectives

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

1. Explain how third-party data relationships create business value and governance risk.
2. Distinguish the responsibilities of data controllers, processors, custodians, suppliers, and users.
3. Evaluate vendors, cloud services, data brokers, APIs, and partnerships using a structured risk framework.
4. Interpret contractual, privacy, security, ethical, and data-sovereignty requirements.
5. Design practical controls for third-party data life-cycle management.
6. Apply these ideas to a realistic business analytics case.

1. Digital Ecosystems and the Extended Data Enterprise

A digital ecosystem is a network of organizations, technologies, data resources, platforms, and users whose interactions produce products, services, or decisions. Unlike a traditional supply chain, an ecosystem may be many-sided: a platform connects buyers, sellers, advertisers, developers, payment providers, and regulators. Data can move in several directions, be transformed repeatedly, and be combined with other datasets.

An organization’s effective data boundary is therefore larger than its legal entity. It includes:

• Direct suppliers, such as cloud-hosting and software vendors.
• Data suppliers, such as brokers, public-record aggregators, survey firms, and credit agencies.
• Technology intermediaries, such as API providers, identity services, analytics tools, and advertising exchanges.
• Business partners, such as distributors, insurers, marketplaces, universities, and joint ventures.
• Subprocessors and subcontractors, which a primary vendor uses to perform its obligations.
• Customers and users, who generate data and may also redistribute it through platform interactions.

Data value often increases through combination. A firm might join its first-party transaction data with location, demographic, or behavioral data supplied externally. However, combination can also increase identifiability and enable inferences that were not apparent in any original dataset. A dataset described as “anonymous” may become identifying when linked with another dataset.

The ecosystem perspective introduces two important principles. First, accountability must follow the data, not merely the organizational chart. Second, data lineage must be visible: an organization should be able to identify where data originated, how it was transformed, who accessed it, where it was stored, and when it must be deleted.

2. Roles and Allocation of Responsibility

Terminology varies by jurisdiction and contract, but several roles are widely useful.

A contract can allocate operational duties, but it cannot eliminate an organization’s statutory or ethical responsibilities. For example, outsourcing payroll processing does not eliminate the employer’s responsibility to ensure that employee data are handled appropriately. Nor does using an external artificial-intelligence service remove the need to assess bias, explainability, or inappropriate secondary use.

A useful accountability statement identifies, for each processing activity:

1. the business purpose;
2. the categories of data and affected people;
3. the legal and ethical basis for processing;
4. the organizations and individuals with access;
5. the retention and deletion rules;
6. the security controls;
7. the mechanism for complaints, correction, and incident response.

3. A Risk Model for Third-Party Relationships

Third-party risk is multidimensional. A vendor may be technically secure but use data in ways that conflict with customer expectations. A data broker may offer accurate information but have weak evidence of consent or source legitimacy. A cloud service may provide excellent availability while creating jurisdictional uncertainty about where backups are stored.

A practical assessment considers at least six dimensions:

3.1 Privacy and purpose risk

Privacy risk arises when collection, use, disclosure, or retention exceeds what people were told or could reasonably expect. Key questions include whether the purpose is specific, whether only necessary data are used, whether sensitive categories are involved, and whether individuals can exercise applicable rights.

3.2 Security and resilience risk

Security review should cover identity management, encryption, logging, vulnerability management, backup, disaster recovery, incident notification, and subcontractor controls. Resilience includes the ability to continue operations and retrieve data if the vendor fails, is attacked, or becomes unavailable.

3.3 Legal and regulatory risk

Requirements may arise from privacy, consumer-protection, employment, financial, health, telecommunications, competition, records-management, and sector-specific laws. A vendor’s location does not by itself determine which law applies; the location of individuals, the nature of processing, and the organization’s activities may also matter.

3.4 Ethical and social risk

Lawful processing may still be unfair. Ethical concerns include discriminatory profiling, exploitation of vulnerable people, opaque data brokerage, manipulation, surveillance, and the creation of power asymmetries. A predictive model can disadvantage a group even when no protected attribute is explicitly supplied, because proxy variables may reproduce historical inequalities.

3.5 Operational and concentration risk

Dependence on one cloud provider, identity service, or API can create a single point of failure. A widely used provider may also become too important to replace quickly. Assessment should consider service-level commitments, portability, exit costs, and the provider’s financial and operational stability.

3.6 Sovereignty and jurisdiction risk

Data sovereignty concerns the authority of a state or jurisdiction over data, including rules about storage, access, transfer, government requests, and local processing. Sovereignty is not identical to data residency: residency describes where data are physically stored, while sovereignty concerns which legal authority can regulate or access them.

Organizations can summarize these dimensions in a qualitative matrix. A simple risk score may be used internally, but it should not create false precision. If a score is calculated as a weighted sum, the organization must document the scale, weights, evidence, and decision thresholds. A low numerical score should never override a non-negotiable legal prohibition or a severe unresolved ethical issue.

4. Vendor and Cloud Governance

Vendor governance begins before procurement and continues after termination. The life cycle normally includes planning, due diligence, contracting, onboarding, monitoring, renewal, and exit.

Pre-contract due diligence

A risk-based review should examine:

• ownership, financial stability, and relevant experience;
• data flows, processing locations, and subprocessors;
• security architecture and independent assurance reports;
• privacy notices, retention practices, and rights-support capabilities;
• incident history and notification procedures;
• model-training or secondary-use practices;
• accessibility, ethical commitments, and environmental factors where material;
• business continuity, disaster recovery, and data portability.

Questionnaires are useful but insufficient. Evidence should be proportional to risk. A supplier processing public marketing content does not require the same scrutiny as a supplier processing health, financial, biometric, or children’s data.

Cloud-specific issues

Cloud services are commonly described through service models:

• Infrastructure as a Service (IaaS): the provider supplies computing, storage, and networking infrastructure; the customer usually manages operating systems and applications.
• Platform as a Service (PaaS): the provider manages a development platform while the customer controls applications and data.
• Software as a Service (SaaS): the provider operates the application; the customer configures it and supplies data.

These models involve a shared-responsibility principle. The provider is responsible for some underlying infrastructure, while the customer remains responsible for appropriate configuration, identity management, data classification, access authorization, and lawful use. The division differs by service and must be verified rather than assumed.

Important cloud controls include role-based access, multi-factor authentication, encryption in transit and at rest, customer-managed keys where justified, immutable logging, segregation of environments, secure deletion, backup testing, and documented recovery objectives. Organizations should ask whether provider personnel can access plaintext, whether support access is logged, and whether data can be exported in a usable format.

A contract should address service availability, support, audit rights, breach cooperation, subprocessors, geographic processing, deletion, return of data, intellectual property, liability, and termination assistance. Service-level agreements are not substitutes for governance: an uptime guarantee does not establish that processing is lawful or ethical.

5. Data Brokers and Purchased Data

Data brokers collect and combine information from public records, commercial transactions, mobile applications, loyalty programs, surveys, cookies, and other sources. They may sell raw attributes, segments, scores, or derived predictions.

Purchased data creates particular risks because the buyer may not know the original context of collection. A person who supplied an address to receive a service may not expect that information to be used for credit scoring, insurance pricing, political targeting, or employment screening. Consent obtained for one context may not meaningfully support another.

A responsible buyer should require evidence of:

• source provenance and collection methods;
• notice and consent practices where relevant;
• legal authority and permitted uses;
• accuracy, update frequency, and correction procedures;
• treatment of sensitive attributes and vulnerable groups;
• suppression of opted-out or restricted individuals;
• controls against re-identification and unlawful discrimination.

Data quality has multiple dimensions. Accuracy means values correctly represent the relevant attribute; completeness concerns missing values; timeliness concerns currency; consistency concerns agreement across systems; and validity concerns conformity to required formats or meanings. High accuracy does not make an inappropriate dataset ethical. A perfectly accurate location history can still be excessively intrusive.

Analysts should also distinguish observed data from inferred data. An observed age may be supplied by a person, while an inferred purchasing propensity is a prediction produced by a model. Inferences can affect people materially and should be governed with the same seriousness as directly collected attributes.

6. APIs, Data Sharing, and Partnerships

An application programming interface (API) allows systems to exchange data through defined requests and responses. APIs support real-time analytics, payments, identity verification, logistics, and partner integration. Their convenience can obscure significant governance risks.

API governance should address:

• authentication and authorization, preferably with least privilege;
• scope-limited tokens and secure secret management;
• rate limits and denial-of-service protection;
• schema validation and input sanitization;
• logging of requests, responses, and administrative actions;
• prevention of excessive fields and unnecessary replication;
• version control and change notification;
• consent and purpose restrictions;
• error handling that does not expose personal information;
• revocation when a partnership ends.

Data-sharing partnerships require a clear data-sharing agreement. It should define the dataset, permitted purposes, matching method, responsibilities, retention, security, onward disclosure, intellectual property, audit, incident response, individual-rights support, and dispute resolution. Joint projects should specify who can publish results and whether outputs could identify individuals or communities.

A common failure occurs when a partner receives a broad export for a narrow purpose. A safer design uses data minimization, field-level controls, pseudonymization where appropriate, secure enclaves, query interfaces, or aggregated outputs. Pseudonymization reduces direct identification but does not make data anonymous if re-identification remains reasonably possible.

7. International Data Supply Chains and Sovereignty

International processing may improve efficiency and access to specialist expertise, but it creates a chain of legal and operational dependencies. A dataset may be collected in one country, processed by a vendor in a second, backed up in a third, and accessed by support staff in a fourth.

Organizations should map:

1. the origin and collection context;
2. every processing and storage location;
3. remote-access locations;
4. subprocessors and onward transfers;
5. applicable transfer mechanisms and contractual safeguards;
6. government-access and disclosure risks;
7. deletion and retrieval capabilities in each location.

Transfer mechanisms differ across legal systems and must be assessed under current applicable law. Contractual clauses alone may not resolve conflicts where a foreign authority can compel access. Risk assessment may require technical measures such as encryption with keys controlled separately from the processor, minimization, tokenization, regional storage, or processing that avoids exporting identifiable data.

Data localization can reduce some transfer risks but may increase cost, fragmentation, and dependence on local infrastructure. It is not automatically a complete solution: local insiders, poor security, or unauthorized replication can still cause harm. Sovereignty should therefore be treated as a design and governance question rather than a simple geographic checkbox.

8. Contractual Governance and Control Design

Contracts translate governance expectations into enforceable obligations. Important clauses include:

Contracts should be consistent with operational reality. A clause requiring deletion within 24 hours is ineffective if immutable backups remain for six months and the contract does not explain how they are handled. Likewise, an audit right is weak if the customer lacks the resources or authority to use it.

Control design should combine preventive, detective, and corrective measures. Preventive controls limit access and use; detective controls identify anomalies and noncompliance; corrective controls contain incidents, restore services, and improve future practice. Ownership should be assigned to named roles, with evidence retained for review.

9. A Practical Third-Party Governance Framework

A business analytics organization can implement the following cycle:

Discover. Maintain an inventory of vendors, data sources, APIs, subprocessors, data categories, purposes, and locations.

Classify. Rate relationships according to sensitivity, volume, criticality, affected populations, international exposure, and potential harm.

Assess. Review privacy, security, legal, ethical, operational, concentration, and sovereignty risks. Interview business owners and technical specialists rather than relying only on procurement documents.

Contract. Translate requirements into specific, measurable obligations and establish escalation routes.

Implement. Configure least privilege, encryption, logging, retention, segregation, secure interfaces, and approval workflows.

Monitor. Review access logs, incidents, assurance reports, service performance, subprocessor changes, data quality, and compliance evidence.

Reassess. Trigger review when the purpose, dataset, model, vendor, geography, law, or threat environment changes.

Exit. Revoke access, retrieve required records, delete data and copies, verify deletion, and document residual obligations.

This cycle should be integrated with enterprise risk management, privacy impact assessments, information-security management, procurement, records management, and internal audit.

10. Ethical Decision-Making in Ecosystems

Ethical governance asks more than “Can the organization do this?” It asks whether the organization should do it and whether affected people would regard the practice as fair and legitimate. Useful questions include:

• Would a reasonable person be surprised by this use?
• Are benefits and risks distributed fairly?
• Could the practice exploit people with limited choice or understanding?
• Does the analysis create a sensitive inference?
• Can affected people challenge errors or decisions?
• Is there a less intrusive way to achieve the same business objective?
• Would the organization defend the practice publicly?

Three ethical perspectives are especially useful. A rights-based perspective emphasizes autonomy, privacy, dignity, and due process. A consequence-based perspective weighs benefits against foreseeable harms, including harms to groups. A justice perspective examines whether burdens and benefits are distributed equitably. No single perspective resolves every case, so responsible governance often uses all three.

Analytics professionals should avoid treating contractual permission as ethical permission. They should document assumptions, limitations, affected stakeholders, and escalation decisions. Where risks are material, independent review or an ethics committee may be appropriate.

11. Illustrative Case: Northstar Retail’s Personalization Ecosystem

Background

Northstar Retail, a fictional national retailer, wants to improve online recommendations and reduce fraud. It plans to combine loyalty-card transactions, website activity, a location-data product purchased from a broker, a cloud analytics platform, and an identity-verification API. The cloud provider uses subprocessors in several countries.

Problem

The marketing team assumes that loyalty-program terms permit all forms of personalization. The data broker cannot clearly document whether mobile-location data were collected with meaningful notice. The fraud API requests more customer fields than the fraud model requires. No inventory identifies where backups are stored, and the proposed contract permits the cloud provider to use “aggregated data” for service improvement without defining aggregation.

Analysis

The proposed ecosystem presents several risks. First, purpose limitation is uncertain because loyalty data, location data, and fraud data were collected in different contexts. Second, combining transaction and location records may produce highly intrusive profiles. Third, excessive API fields increase exposure without clear analytical benefit. Fourth, undefined aggregation may permit re-identification or secondary use. Fifth, international support access creates sovereignty and transfer questions. Finally, concentration risk is high because the retailer has no tested exit plan for the cloud platform.

Approach and solution

Northstar establishes a cross-functional review involving privacy, security, procurement, legal, analytics, and customer-experience staff. It rejects the broker dataset until provenance and notice evidence are satisfactory. It redesigns the fraud API to send only the minimum required fields and uses short-lived, scope-limited credentials. It separates marketing and fraud purposes, documents retention periods, and creates a data lineage register.

The cloud contract prohibits independent use of customer data, requires disclosure of subprocessors, specifies processing locations, establishes incident cooperation, and requires deletion or secure return at exit. Encryption keys are managed separately from the provider where feasible. A privacy impact assessment evaluates location-based inferences and introduces an opt-out mechanism. Northstar tests export of analytics data and documents how backups are deleted or expire.

Outcome

The project launches with fewer data sources but a more defensible purpose, lower exposure, and clearer accountability. Recommendation performance is slightly lower than the original proposal predicted, but customer complaints decline and the fraud team obtains sufficient information. The organization also discovers that a smaller, better-governed dataset produces more stable results than a larger dataset of uncertain quality.

Learning points

1. Data minimization can improve governance without preventing useful analytics.
2. Provenance and context matter as much as technical accuracy.
3. Contracts must be supported by architecture and operational tests.
4. Different purposes should not be silently combined.
5. Exit planning is part of vendor selection, not an afterthought.

12. Technology, AI, and Emerging Developments

AI services intensify third-party governance issues. A provider may use customer prompts, uploaded records, or model outputs to improve a general model. Organizations must determine whether confidential or personal data can enter the service, whether outputs are retained, how human review occurs, and whether training or inference creates intellectual-property, privacy, or bias risks.

Model supply chains also include pretrained models, external datasets, labeling firms, cloud accelerators, monitoring tools, and application developers. Governance should record model provenance, data sources, evaluation results, known limitations, and update procedures. Procurement should not accept claims such as “private” or “enterprise-grade” without defining retention, access, training, and deletion behavior.

Other developments include data clean rooms, confidential computing, privacy-enhancing technologies, federated analytics, and automated vendor-monitoring tools. These technologies can reduce exposure but do not eliminate governance duties. A clean room may limit raw-data access while still enabling sensitive inferences; confidential computing may protect data during processing but not solve poor purpose specification.

Challenges and Limitations

Third-party governance faces persistent limitations. Supply chains can be opaque, especially when vendors change subprocessors rapidly. Small suppliers may lack mature compliance programs even when they provide critical services. Audits are often periodic snapshots rather than continuous assurance. Legal requirements differ across jurisdictions and may change faster than contracts. Risk scoring can disguise uncertainty or encourage organizations to focus on numerical thresholds rather than substantive harm.

Data lineage is also difficult in modern analytics because copies, extracts, logs, backups, and derived features may proliferate. Deletion may be technically complex, particularly in distributed systems and machine-learning pipelines. Finally, no governance framework can predict every misuse or breach. Effective programs therefore require escalation, learning from incidents, and willingness to stop or redesign a project.

Best-Practice Checklist

Before approving a significant third-party data relationship, ask:

• Is the purpose specific, necessary, and ethically defensible?
• Do we know the data source, collection context, and provenance?
• Have we identified all processors, subprocessors, locations, and access paths?
• Are privacy, security, sovereignty, and continuity risks assessed together?
• Does the contract define permitted use, retention, deletion, incidents, and exit?
• Are APIs and exports minimized and protected by least privilege?
• Can individuals obtain correction, explanation, or other applicable remedies?
• Have we tested monitoring, incident response, portability, and deletion?
• Is there an owner accountable for ongoing oversight?
• Would the organization be prepared to explain the arrangement publicly?

Chapter Summary

Third-party data relationships are a core feature of modern business analytics. Vendors, cloud providers, brokers, APIs, and partners extend organizational capability but also extend accountability. Effective governance follows data through its full life cycle and distinguishes legal responsibility from operational delegation.

A robust assessment covers privacy and purpose, security and resilience, legal requirements, ethics, operational dependence, and sovereignty. Vendor due diligence should be risk-based and supported by evidence. Contracts must address purpose, security, subprocessors, incidents, international transfers, retention, deletion, audit, liability, and exit. Technical controls—including minimization, least privilege, encryption, logging, secure APIs, and tested portability—must make contractual promises real.

International supply chains require mapping of storage, processing, remote access, and government-access risks. Data brokers require scrutiny of provenance, notice, accuracy, and inferred attributes. Ethical analysis asks whether a use is fair, expected, proportionate, and contestable, not merely whether it is permitted. Finally, governance is continuous: organizations must discover, classify, assess, contract, implement, monitor, reassess, and exit third-party relationships responsibly.

Key Terms

API: A defined interface through which software systems exchange requests and data.

Cloud computing: On-demand access to shared computing resources delivered through a network.

Controller: The organization that determines the purposes and essential means of processing personal data.

Custodian: A person or organization responsible for operating systems and maintaining data.

Data broker: An organization that collects, aggregates, analyzes, or licenses data about individuals or groups.

Data lineage: A record of data origin, movement, transformation, access, and disposition.

Data minimization: Limiting collection, use, disclosure, and retention to what is necessary.

Data residency: The physical or designated location where data are stored or processed.

Data sovereignty: The authority of a jurisdiction over data and activities involving those data.

Digital ecosystem: A network of organizations, technologies, data, platforms, and users that interact to create value.

Exit plan: Procedures for returning, migrating, deleting, and securing data when a relationship ends.

First-party data: Data collected directly by an organization through its own relationship with individuals or customers.

Least privilege: Granting only the access necessary for an authorized task.

Pseudonymization: Replacing direct identifiers with alternatives while retaining a possibility of re-identification.

Processor: A service provider that processes data on behalf of another organization.

Purpose limitation: Restricting data use to specified, legitimate, and compatible purposes.

Subprocessor: A third party engaged by a processor to perform part of the processing service.

Third-party risk: The possibility of harm arising from an external organization’s data, technology, or operational relationship.

Vendor due diligence: The investigation of a supplier’s capabilities, controls, risks, and compliance before and during engagement.

Review Questions

Short Answer Questions

1. Why does outsourcing data processing not eliminate the customer organization’s accountability?
2. Distinguish data residency from data sovereignty.
3. Identify four issues that should be addressed in an API governance program.
4. Why can pseudonymized data still present privacy risk?
5. What is the purpose of an exit plan in a cloud contract?

Long Answer Questions

1. Explain how a digital ecosystem differs from a conventional linear data supply chain, and analyze the governance implications.
2. Discuss the six dimensions of third-party risk and explain why a single numerical score may be misleading.
3. Compare the governance challenges associated with cloud providers, data brokers, and business partnerships.
4. Explain how contractual requirements and technical controls should reinforce one another in third-party governance.
5. Analyze the ethical issues that arise when organizations combine first-party customer data with purchased behavioral or location data.

Analytical / Application Questions

1. A supplier requests access to a full customer database even though its API needs only name, postal region, and transaction value. Design a safer data-sharing arrangement and justify each control.
2. A cloud provider stores primary data domestically but allows overseas support engineers to access production systems. Identify the key sovereignty, privacy, security, and contractual questions that should be resolved before approval.
3. Using the Northstar Retail case, propose three governance metrics that management should monitor after launch and explain what decision each metric would support.

Multiple Choice Questions with Answers

Question 1

Which statement best describes the accountability effect of outsourcing data processing?

A. The supplier assumes all legal and ethical responsibility.

B. The customer organization remains accountable even when operational tasks are delegated.

C. Accountability disappears if the contract includes an indemnity clause.

D. Only the cloud infrastructure owner is accountable.

Correct Answer: B. The customer organization remains accountable even when operational tasks are delegated.

Question 2

What is the main distinction between data residency and data sovereignty?

A. Residency concerns storage location, while sovereignty concerns applicable authority and control.

B. Residency concerns data accuracy, while sovereignty concerns data completeness.

C. Residency applies only to paper records, while sovereignty applies only to digital records.

D. There is no meaningful distinction between them.

Correct Answer: A. Residency concerns storage location, while sovereignty concerns applicable authority and control.

Question 3

Which practice best demonstrates data minimization in an API integration?

A. Sending every available customer field for future analysis.

B. Creating a permanent copy of the partner’s entire database.

C. Sending only the fields necessary for the defined business purpose.

D. Allowing unrestricted access and relying on the partner’s privacy policy.

Correct Answer: C. Sending only the fields necessary for the defined business purpose.

Question 4

Why may a data broker’s dataset be ethically problematic even when it is accurate?

A. Accuracy automatically makes a dataset anonymous.

B. Accurate data cannot be used in analytics.

C. Accuracy is irrelevant to governance.

D. The data may have been collected or reused outside people’s reasonable expectations.

Correct Answer: D. The data may have been collected or reused outside people’s reasonable expectations.

Question 5

Which control is most directly associated with least privilege?

A. Giving every analyst administrator access.

B. Granting a supplier only the permissions required for its approved task.

C. Retaining all user accounts indefinitely.

D. Disabling access logs to improve performance.

Correct Answer: B. Granting a supplier only the permissions required for its approved task.

Question 6

In a shared-responsibility cloud model, which duty normally remains with the customer?

A. Manufacturing the provider’s physical servers.

B. Managing the provider’s building security.

C. Configuring appropriate access controls and using data lawfully.

D. Maintaining the provider’s power supply.

Correct Answer: C. Configuring appropriate access controls and using data lawfully.

Question 7

Which contractual provision is most relevant when a vendor uses other companies to process customer data?

A. Subprocessor approval, notification, and oversight requirements.

B. A prohibition on all internal employee access.

C. A guarantee that no system will ever fail.

D. A requirement that the customer publish all vendor information.

Correct Answer: A. Subprocessor approval, notification, and oversight requirements.

Question 8

Why is an exit plan important in a third-party relationship?

A. It guarantees that the vendor will never experience an incident.

B. It allows the organization to retrieve data, revoke access, and manage deletion when the relationship ends.

C. It removes the need for monitoring during the contract.

D. It permits the vendor to retain all data permanently.

Correct Answer: B. It allows the organization to retrieve data, revoke access, and manage deletion when the relationship ends.

Question 9

Which situation most clearly illustrates concentration risk?

A. Using two independent suppliers for a noncritical service.

B. Storing public marketing content in a version-controlled repository.

C. Depending on one provider for identity, analytics, and recovery with no tested alternative.

D. Reviewing vendor performance every quarter.

Correct Answer: C. Depending on one provider for identity, analytics, and recovery with no tested alternative.

Question 10

Which question is primarily ethical rather than purely technical?

A. Are API credentials rotated regularly?

B. Are backups encrypted at rest?

C. Can the dataset be exported in a standard format?

D. Would affected people reasonably expect this secondary use of their data?

Correct Answer: D. Would affected people reasonably expect this secondary use of their data?