Data Access, Sharing, and Third-Party Governance

Introduction

Data has value only when authorized people and systems can use it for legitimate purposes. Excessive restriction prevents innovation and weakens operational performance; excessive access increases the probability and impact of misuse, breach, discrimination, and regulatory violation. Data governance therefore treats access and sharing as controlled institutional capabilities rather than merely technical permissions.

The challenge is especially significant in business analytics. Analysts may require granular records, cloud platforms may process data across jurisdictions, vendors may combine organizational data with external sources, and artificial-intelligence systems may transmit prompts or training data to third parties. Governance must connect business purpose, legal authority, information security, privacy, contractual control, and ethical responsibility.

This chapter develops an integrated approach to role- and attribute-based access, data-sharing agreements, licensing, open-data controls, vendor due diligence, data residency, cloud governance, supply-chain oversight, and responsible data monetization.

Learning Objectives

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

1. Distinguish discretionary, mandatory, role-based, attribute-based, and risk-adaptive access control.
2. Design access policies using least privilege, separation of duties, purpose limitation, and lifecycle review.
3. Evaluate data-sharing agreements, licenses, open-data releases, and cross-border transfers.
4. Conduct proportionate due diligence on vendors, cloud providers, and data suppliers.
5. Explain data residency, localization, sovereignty, and cloud governance risks.
6. Assess third-party and fourth-party supply-chain exposure.
7. Evaluate responsible data monetization proposals using financial, legal, privacy, and ethical criteria.

1. Access Governance as a Business Control

Access governance answers four questions:

• Who is requesting access?
• What data or operation is requested?
• Why is access needed?
• Under what conditions may access occur?

Authentication establishes an identity; authorization determines what that identity may do. Governance adds accountability: the organization must be able to show that access was justified, approved, monitored, and withdrawn when no longer necessary.

A useful access decision can be represented conceptually as:

This is a logical model, not a numerical multiplication formula. The decision is permitted only when all required policy conditions are satisfied. Context may include device security, network location, time, data sensitivity, employment status, and incident state.

Core principles

Least privilege grants only the access necessary for an approved task. Need to know limits access to information relevant to a person’s responsibilities. Separation of duties prevents one person from initiating and approving a high-risk activity. Default deny requires an explicit policy basis for access. Zero trust assumes that network location alone does not establish trust. Accountability requires reliable records of decisions and activity.

Least privilege is not equivalent to giving everyone the smallest possible dataset. A data scientist may need a broad analytical population but not direct identifiers; a payroll specialist may need identifiers but not unrestricted access to behavioral data. Good governance minimizes unnecessary sensitivity while preserving legitimate utility.

2. Access-Control Models

Discretionary and mandatory access control

In discretionary access control, an owner decides who may use an object. It is flexible but can produce inconsistent permissions and uncontrolled onward sharing. Mandatory access control assigns centrally enforced classifications, such as Public, Internal, Confidential, and Restricted. Users cannot override classification rules, making the model appropriate for highly sensitive or regulated environments, although administration can be complex.

Role-based access control

Role-based access control (RBAC) assigns permissions to job roles rather than directly to individuals. A user receives permissions through role membership.

Figure: RBAC separates people from permissions through governed roles.

RBAC is efficient where responsibilities are stable. Its weakness is role explosion: organizations may create hundreds of narrowly tailored roles that are difficult to understand and audit. Role design should therefore follow a role catalogue, ownership model, approval workflow, and periodic certification.

Attribute-based access control

Attribute-based access control (ABAC) evaluates attributes of the subject, resource, action, and environment. A policy might state: “Permit a clinician to view a patient record when the clinician has an active treatment relationship, is on an approved device, and the request is for care delivery.”

ABAC supports fine-grained decisions and dynamic context. However, poorly governed attributes can be inaccurate, discriminatory, stale, or difficult to explain. Organizations must define authoritative sources, update frequency, policy owners, conflict-resolution rules, and an appeal process.

RBAC and ABAC are complementary. A role may establish baseline permissions, while attributes narrow or condition them. For high-risk data, an organization may combine role, purpose, location, time, device posture, and sensitivity classification.

Privileged and emergency access

Administrative accounts require enhanced controls: separate credentials, phishing-resistant authentication where feasible, session recording, just-in-time elevation, approval, and retrospective review. “Break-glass” access may be justified in emergencies, but it should be time-limited, logged, and automatically flagged for investigation. Emergency necessity does not eliminate privacy obligations.

3. Designing an Access-Governance Lifecycle

A mature lifecycle contains six stages:

1. Inventory: identify datasets, owners, classifications, processing purposes, interfaces, and retention periods.
2. Design: map business functions to roles, attributes, permissions, and risk tiers.
3. Approve: require data-owner or delegated approval, with enhanced review for sensitive data.
4. Provision: implement through identity and access-management systems, preferably automatically.
5. Monitor: review logs, unusual behavior, dormant accounts, privilege escalation, and policy violations.
6. Recertify and revoke: periodically confirm continuing need and terminate access promptly after transfer, leave, contract expiration, or purpose completion.

Access reviews should test more than whether a manager clicked “approve.” They should ask whether the role remains necessary, whether the dataset is overbroad, whether actual use matches stated purpose, and whether downstream copies exist.

Useful measures include the percentage of privileged accounts reviewed on time, median revocation time, number of orphaned accounts, policy exceptions by business unit, and confirmed inappropriate-access incidents. Metrics should be interpreted carefully: a low incident count may reflect effective control or weak detection.

4. Data Sharing and Data-Sharing Agreements

Sharing can occur internally, between affiliated entities, with public bodies, with customers, or with commercial partners. Before sharing, the organization should document purpose, lawful authority, necessity, sensitivity, recipients, onward transfers, retention, security, individual rights, and termination conditions.

A data-sharing agreement (DSA) should normally address:

A DSA is not a substitute for due diligence or technical control. Contractual promises are weak if the organization cannot monitor them. High-risk sharing should use data minimization, pseudonymization, secure APIs, query limits, output review, watermarking, and contractual prohibitions on re-identification.

Data licensing

A license defines what a recipient may do with data and under what conditions. Important terms include permitted purpose, geographic scope, duration, exclusivity, attribution, modification, redistribution, sublicensing, quality disclaimers, intellectual-property rights, and termination. A license should not imply that the licensor owns rights it does not possess, especially where personal information, confidential information, or third-party intellectual property is involved.

A “commercial use permitted” clause does not necessarily authorize personal-data processing. Privacy, confidentiality, consumer-protection, and sector-specific obligations may impose independent limits.

5. Open Data and Public Release

Open data can improve transparency, research, civic participation, and innovation. It can also enable re-identification, discrimination, surveillance, or harmful inference. Removing names is not automatically anonymization: dates, locations, rare occupations, transaction patterns, and combinations with public data may identify individuals.

An open-data release should pass a documented release assessment:

• Is publication necessary and proportionate?
• What legal authority and public-interest rationale exist?
• Could individuals or small groups be re-identified?
• Are vulnerable populations exposed?
• Can sensitive geography, time, or categories be generalized?
• Is the license clear about reuse and attribution?
• Are quality limitations and collection biases disclosed?
• Is there a takedown, correction, and re-evaluation process?

Statistical disclosure controls include aggregation, suppression of small cells, generalization, perturbation, and controlled-access repositories. Each reduces utility or introduces analytical limitations. Claims of anonymization should be supported by a documented threat model, not by intuition alone.

6. Vendor Due Diligence and Third-Party Governance

Third-party risk exists because another organization may access, store, transform, infer from, or further disclose the data. The risk extends to fourth parties: cloud providers, subprocessors, data brokers, model providers, and infrastructure operators used by the primary vendor.

A proportionate due-diligence process includes:

1. Inherent-risk classification: assess data sensitivity, volume, criticality, jurisdiction, connectivity, and potential harm.
2. Evidence review: examine security certifications, independent assurance reports, penetration-test summaries, privacy documentation, business continuity plans, and incident history.
3. Capability assessment: evaluate access controls, encryption, logging, secure development, deletion, personnel screening, and model-governance practices.
4. Contract negotiation: establish use limits, audit rights, notification periods, subprocessor approval, deletion, indemnity, and exit assistance.
5. Ongoing monitoring: review changes in ownership, service architecture, certifications, incidents, geographic processing, and control performance.
6. Exit testing: verify that data can be returned or destroyed and that operational continuity is possible.

Evidence must be matched to risk. A security certificate may demonstrate a management system, but it does not prove that a particular dataset is appropriately used. Questionnaires alone are especially weak where the vendor handles sensitive data or makes consequential automated decisions.

Supply-chain oversight

A data supply chain can be mapped as:

At each link, governance should identify data transformations, new purposes, access paths, copies, and accountability. Provenance records should document origin, collection method, consent or legal basis where relevant, timestamps, transformations, quality limitations, and permitted uses. For AI systems, provenance should also cover training-data sources, labeling, model version, prompt or retrieval sources, and restrictions on provider reuse.

7. Data Residency, Localization, and Cloud Governance

Data residency describes where data is physically stored or processed. Data localization refers to requirements that data remain within a specified jurisdiction or that certain processing occur locally. Data sovereignty concerns the legal authority that may apply to data because of location, provider, subject, organization, or governmental power. These concepts overlap but are not interchangeable.

Cloud services complicate location because data may be replicated across regions, placed in backups, accessed by support personnel, or processed by subprocessors. A contract naming one storage region may not answer where logs, metadata, disaster-recovery copies, or support sessions occur.

Cloud governance should address:

• approved regions and prohibited locations;
• encryption and independent key management;
• identity federation and privileged-access controls;
• tenant isolation and secure configuration;
• logging, monitoring, and evidence retention;
• backup, disaster recovery, and deletion propagation;
• subprocessor visibility;
• portability and exit plans;
• legal requests and government-access procedures;
• restrictions on provider training or secondary use of customer data.

A practical architecture uses classification-based placement. Public and low-risk data may use broad cloud options; restricted data may require dedicated environments, customer-managed keys, confidential-computing features, tokenization, or local processing. These controls reduce exposure but do not eliminate legal or operational risk.

8. Responsible Data Monetization

Data monetization includes selling datasets, licensing insights, providing analytics services, embedding data in products, or creating data-enabled decisions. Monetization should be evaluated as a governance decision, not merely a revenue opportunity.

A responsible proposal should establish:

• provenance and rights to commercialize;
• legitimate purpose and compatible use;
• transparency to affected people;
• sensitivity and re-identification risk;
• impacts on vulnerable groups;
• quality, bias, and representativeness;
• customer restrictions and monitoring;
• pricing and value distribution;
• security, retention, and deletion;
• remedy if misuse or harm occurs.

The economic value of a data product is not simply its price. A decision model should consider expected revenue, implementation cost, expected remediation cost, regulatory exposure, and expected harm. A simplified expected-value expression is:

where EV is expected value in currency units, R is expected revenue, C is implementation and operating cost, p is the estimated probability of a harmful event, and L is the financial loss if that event occurs. This model assumes the quantities are estimated on a comparable time horizon and that risk can reasonably be represented by a probability-loss product. It is not sufficient for ethical decisions because severe rights violations may be unacceptable even when expected financial loss is small.

Better monetization often means selling aggregated insights, secure queries, synthetic or strongly transformed data, or a governed analytical service rather than transferring raw personal records. Differential privacy, for example, can provide formal protection against the influence of any one individual under specified assumptions, but it introduces a privacy–utility trade-off and requires careful parameter selection and composition accounting. It should not be presented as a universal guarantee of safety.

9. Applied Case: Meridian Health Marketplace

The following is an illustrative case.

Background

Meridian, a regional health marketplace, operates a claims analytics platform. It proposes licensing de-identified member data to a pharmaceutical-market research company and uses a cloud-based AI assistant to summarize provider-performance reports.

Problem

The proposal contains three risks. First, the dataset includes detailed geography, dates, rare diagnoses, and longitudinal events that may permit re-identification. Second, the research company intends to combine Meridian’s data with commercial location data. Third, the AI assistant’s standard contract permits the provider to retain prompts for service improvement, while the cloud architecture replicates logs outside Meridian’s approved region.

Analysis

Meridian classifies the data as restricted. The access review finds that analysts have broad table-level access, although most require only aggregated views. Vendor due diligence reveals that the research company cannot identify all downstream data brokers. The cloud provider offers regional storage but not regional support access under the standard plan.

A risk committee evaluates purpose compatibility, member expectations, re-identification risk, contractual enforceability, residency requirements, and alternatives. It rejects raw-data licensing. It also rejects the AI deployment in its default configuration.

Approach and solution

Meridian creates a governed data product containing aggregated statistics with small-cell suppression and generalized geography. The license prohibits re-identification, linkage with specified external datasets, onward transfer, and use for individual eligibility or pricing decisions. Customers must submit intended queries and accept monitoring.

For analytics access, Meridian combines RBAC and ABAC: analysts receive an “approved research” role, while attributes restrict access by project, geography, sensitivity, and purpose. Direct identifiers are held in a separate controlled environment. The AI assistant is replaced with a contractually restricted enterprise service configured not to retain prompts for training, using approved regional processing and customer-managed encryption keys. Outputs are reviewed for disclosure and unsupported claims.

Outcome

Meridian accepts a lower initial licensing price but reduces exposure, improves auditability, and creates a reusable governed data product. It records the decision, sets a six-month review, and requires evidence of deletion at contract termination. The AI deployment proceeds only after a residency test, access review, and incident-response exercise.

Learning points

1. De-identification is a risk-management process, not a label.
2. A contract is effective only when technical architecture and monitoring support it.
3. Data minimization can preserve commercial value while reducing harm.
4. AI suppliers must be assessed for prompts, logs, training reuse, subprocessors, and output risk.
5. Governance decisions should consider affected people, not only the purchasing organization and its customer.

10. Challenges, Limitations, and Contemporary Developments

Access policies become fragile when data inventories are incomplete, identity attributes are stale, or mergers create duplicated systems. Fine-grained controls can increase complexity and encourage workarounds. Automated risk scoring may reproduce bias or deny legitimate access without understandable reasons. Monitoring can itself become intrusive, particularly when employee behavior analytics are used without clear purpose and proportionality.

Generative AI intensifies these issues. Users may paste confidential data into public tools; retrieval systems may expose documents across authorization boundaries; model providers may retain prompts; and generated outputs may combine information in ways not anticipated by the original access model. AI governance therefore requires both input controls and output controls, including prompt filtering, retrieval authorization, logging, human review for high-impact uses, and testing for data leakage.

Contemporary governance also emphasizes data contracts, machine-readable policy tags, privacy-enhancing technologies, confidential computing, software bills of materials, and continuous control monitoring. These tools are valuable, but technology cannot resolve unclear purposes, unjustified collection, or inadequate accountability.

Best-Practice Checklist

An organization should be able to answer “yes” to the following questions:

• Are datasets classified, owned, inventoried, and linked to purposes?
• Are RBAC roles limited, understandable, and periodically certified?
• Are high-risk decisions conditioned on relevant attributes and context?
• Are privileged and emergency accesses separately controlled?
• Do sharing agreements specify use, retention, onward transfer, deletion, and remedies?
• Has open-data release been tested against realistic re-identification threats?
• Is vendor due diligence proportionate to sensitivity and criticality?
• Are subprocessors, fourth parties, and supply-chain dependencies visible?
• Are residency, support access, backups, logs, and government requests addressed?
• Does monetization preserve rights, transparency, quality, and meaningful remedy?
• Can the organization demonstrate compliance through evidence rather than assurances alone?

Chapter Summary

Data access and sharing are governance functions that combine identity, authorization, purpose, risk, law, ethics, and accountability. RBAC provides manageable role-based permissions, while ABAC adds contextual precision. Both should operate within least privilege, separation of duties, default deny, monitoring, and timely revocation.

Data-sharing agreements and licenses define permissible uses but must be supported by technical safeguards, due diligence, and ongoing monitoring. Open-data publication requires a realistic assessment of re-identification and group harms. Third-party governance extends beyond the immediate vendor to subprocessors and fourth parties, with attention to provenance and supply-chain accountability.

Data residency, localization, and sovereignty create distinct cloud-governance questions involving regions, backups, logs, support access, keys, and government requests. Responsible monetization evaluates rights, purpose, bias, quality, security, and remedy alongside revenue. The central managerial principle is to design data products and access pathways that deliver legitimate value without transferring unacceptable risk to individuals, communities, or society.

Key Terms

Access control: Rules and mechanisms that determine who or what may perform actions on resources.

Attribute-based access control (ABAC): Authorization based on attributes of the subject, resource, action, environment, and purpose.

Data localization: A requirement that specified data or processing remain within a jurisdiction.

Data monetization: Generating economic value through data, insights, analytics, or data-enabled services.

Data provenance: Evidence about a dataset’s origin, transformations, custody, and permitted uses.

Data residency: The physical or logical location where data is stored or processed.

Data sovereignty: The legal authority and jurisdiction applicable to data.

Data-sharing agreement: A formal instrument defining data-sharing purposes, responsibilities, controls, and restrictions.

Default deny: A security principle under which access is refused unless explicitly authorized.

Fourth party: A supplier or service provider used by an organization’s direct vendor.

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

Mandatory access control: Centrally enforced access based on security classifications and rules.

Open data: Data made available for public access and reuse under specified conditions.

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

Role-based access control (RBAC): Authorization based on permissions assigned to organizational roles.

Separation of duties: Dividing responsibilities so that no single actor controls a sensitive process end to end.

Supply-chain risk: Exposure arising from dependencies, transformations, or failures across connected providers.

Vendor due diligence: Evaluation of a supplier’s risk, capability, controls, and contractual fitness before and during engagement.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorization.
2. What are two advantages and one limitation of RBAC?
3. Why is removing names insufficient to guarantee anonymization?
4. Define data residency and explain how it differs from localization.
5. Identify three issues that should be addressed in a data-sharing agreement.

Long Answer Questions

1. Explain how an organization can combine RBAC and ABAC for sensitive analytics data.
2. Evaluate the role of vendor due diligence across the full data supply chain.
3. Discuss the governance challenges created by cloud replication, backups, logs, and support access.
4. Explain why responsible data monetization must consider factors beyond expected revenue.
5. Design a lifecycle for access approval, monitoring, recertification, and revocation.

Analytical / Application Questions

1. A vendor requests unrestricted access to a customer dataset to improve its AI model. Analyze the request using purpose limitation, contractual controls, provenance, residency, and output-risk criteria. Recommend conditions under which access could be approved or rejected.
2. An open-data team plans to publish neighborhood-level health statistics. Develop a release assessment addressing small-cell suppression, geography, linkage attacks, vulnerable groups, licensing, and post-publication monitoring.
3. A multinational firm discovers that a cloud provider stores primary records in the approved region but sends support logs to another country. Analyze the governance implications and propose technical, contractual, and operational responses.

Multiple Choice Questions with Answers

Question 1

Which access-control model evaluates attributes of the subject, resource, action, and environment?

A. Discretionary access control

B. Role-based access control

C. Attribute-based access control

D. Mandatory access control

Correct Answer: C. Attribute-based access control

Question 2

Which principle requires an explicit policy basis before access is granted?

A. Default deny

B. Open access

C. Data portability

D. Purpose expansion

Correct Answer: A. Default deny

Question 3

Why can removing names fail to anonymize a dataset?

A. Names are always required for analysis

B. Other attributes may enable re-identification through linkage

C. Encryption automatically restores names

D. Aggregation increases direct identifiers

Correct Answer: B. Other attributes may enable re-identification through linkage

Question 4

Which item is most appropriate for a data-sharing agreement?

A. A prohibition on documenting subprocessors

B. A requirement for unlimited onward transfer

C. Retention, deletion, and incident-notification obligations

D. A waiver of all recipient responsibilities

Correct Answer: C. Retention, deletion, and incident-notification obligations

Question 5

What is a fourth party?

A. An internal data owner

B. A supplier used by an organization’s direct vendor

C. A regulator conducting an audit

D. A user with emergency access

Correct Answer: B. A supplier used by an organization’s direct vendor

Question 6

Which statement best distinguishes data residency from data localization?

A. Residency concerns location; localization generally imposes a legal requirement to keep data or processing local

B. They are always exact synonyms

C. Localization concerns only encryption keys

D. Residency applies only to paper records

Correct Answer: A. Residency concerns location; localization generally imposes a legal requirement to keep data or processing local

Question 7

A contract prohibits vendor reuse of prompts, but the system retains prompts for provider training. What is the primary governance conclusion?

A. The contract is sufficient regardless of system behavior

B. The technical configuration conflicts with the contractual restriction

C. Prompt retention is unrelated to data governance

D. Training reuse improves compliance automatically

Correct Answer: B. The technical configuration conflicts with the contractual restriction

Question 8

In the expression EV = R − C − pL, what does pL represent?

A. Expected loss from a harmful event

B. Guaranteed revenue

C. Implementation cost only

D. The data license price

Correct Answer: A. Expected loss from a harmful event

Question 9

Which practice best supports separation of duties?

A. Allowing one administrator to request, approve, and audit access

B. Assigning all permissions to the data owner permanently

C. Requiring different people to approve and implement sensitive access

D. Eliminating access logs

Correct Answer: C. Requiring different people to approve and implement sensitive access

Question 10

Which is the strongest reason to conduct open-data release testing?

A. To guarantee that no dataset has analytical value

B. To identify potential re-identification and group-harm risks before publication

C. To remove the need for licensing terms

D. To ensure that all data becomes confidential

Correct Answer: B. To identify potential re-identification and group-harm risks before publication