Data Preparation & Analysis

Chapter 14
Data Governance, Privacy, Security and Ethics

Post Graduate Program in Data science
Data Preparation & Analysis   •   Post Graduate

Data Governance, Privacy, Security and Ethics

Introduction

Data preparation is not only a technical activity. Decisions about what data are collected, how they are defined, who may use them, how long they are retained, and what inferences are made from them determine whether an analytical system is trustworthy. Weak governance can produce inaccurate reports, unlawful processing, security breaches, discriminatory decisions, and loss of public confidence. Strong governance connects organizational strategy, legal duties, technical controls, and professional ethics.

Data governance is the system of authority, accountability, policies, standards, processes, and technologies used to manage data as an organizational asset. Privacy concerns the appropriate collection, use, disclosure, and protection of information relating to people. Security protects data and systems against unauthorized access, alteration, disclosure, destruction, and disruption. Ethics asks whether data practices are morally defensible, including whether they respect autonomy, distribute benefits and burdens fairly, and avoid preventable harm.

These concerns overlap but are not identical. A dataset may be securely stored yet ethically problematic because it was collected without meaningful consent. A lawful use may still be unfair. Conversely, an organization may have an ethical intention but lack the controls needed to protect confidential information.

Learning Objectives

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

  1. Distinguish data ownership, stewardship, custodianship, and accountability.
  2. Design practical governance structures using catalogs, lineage, quality rules, and data contracts.
  3. Apply privacy principles, consent requirements, retention rules, and access controls.
  4. Evaluate threats, controls, and residual risks across a data lifecycle.
  5. Identify bias, fairness risks, privacy harms, and representational harms in analytical systems.
  6. Establish review, documentation, monitoring, incident response, and responsible-use mechanisms.

1. The Data Governance Operating Model

1.1 Governance as decision rights

Governance answers questions such as:

  • Who may define a business term such as “active customer”?
  • Who approves access to sensitive records?
  • Who is responsible when a data product is inaccurate?
  • Which uses are prohibited even if technically feasible?
  • When must data be deleted or a model withdrawn?

Governance should not be confused with data management. Data management performs activities such as integration, storage, quality improvement, and analysis. Governance establishes the rules and accountability under which those activities occur.

A mature operating model normally includes the following roles:

RolePrincipal responsibility
Data ownerDefines purpose, risk tolerance, access policy, and business accountability for a domain
Data stewardMaintains definitions, quality rules, metadata, issue resolution, and appropriate use
Data custodianOperates technical storage, backup, encryption, and platform controls
Privacy officerAdvises on lawful processing, data-subject rights, impact assessments, and privacy risk
Security officerManages security architecture, threat monitoring, incident response, and resilience
Data userUses data according to approved purposes, controls, and professional standards
Review committeeEvaluates high-risk data uses, models, exceptions, and unresolved harms

Ownership does not mean that an individual owns people’s personal information as property. It means that an accountable organizational role has authority and responsibility for decisions concerning a data domain.

1.2 Policy hierarchy

A useful hierarchy is:

  1. Principles: broad commitments, such as fairness, necessity, transparency, and security.
  2. Policies: mandatory organizational rules, such as classification and retention policy.
  3. Standards: precise requirements, such as approved encryption methods or logging fields.
  4. Procedures: repeatable operational steps, such as access-request approval.
  5. Evidence: records demonstrating compliance, such as audit logs, assessments, and training records.

Policies should be enforceable and assigned to named roles. A statement such as “protect sensitive data” is insufficient unless it specifies classification, permitted locations, authentication, monitoring, breach escalation, and review frequency.

2. Metadata, Catalogs, Lineage, and Contracts

2.1 Data catalogs

A data catalog is an inventory of data assets and their context. Useful metadata includes the asset name, owner, steward, description, source, schema, sensitivity classification, quality indicators, update frequency, lawful or approved purpose, retention period, access conditions, and downstream dependencies.

A catalog improves discovery and reduces duplicated extraction. It also supports impact analysis: if a field changes, users can identify reports, pipelines, models, and decisions that may be affected. A catalog is not automatically a governance system; it becomes useful only when metadata is maintained, searchable, linked to controls, and treated as part of operational work.

2.2 Data lineage

Data lineage records how data move and change from origin to consumption. It can be represented as a directed graph in which nodes are sources, transformations, stores, models, reports, or decisions, and edges represent data dependencies.

Lineage may be:

  • Technical, showing tables, columns, jobs, and transformations.
  • Business, showing how a metric supports a business decision.
  • Process, showing people, approvals, and operational steps.
  • Model, showing training data, features, versions, outputs, and users.

Lineage supports reproducibility, regulatory explanation, root-cause analysis, deletion requests, and change management. It is especially important when a model uses derived variables or joins several sources, because apparently harmless combinations can reveal sensitive attributes.

2.3 Data contracts

A data contract is an explicit agreement between a data producer and its consumers. It normally specifies schema, data types, definitions, allowed values, freshness, completeness expectations, versioning, ownership, change-notification rules, and handling of failures.

For example, a contract may state that customer_id is non-null and unique within a source system, transaction_time uses Coordinated Universal Time, and a breaking schema change requires 30 days’ notice. Contracts convert informal assumptions into testable obligations. They do not guarantee that data are correct; they make expectations visible and failures actionable.

2.4 Data quality dimensions

Common dimensions include accuracy, completeness, consistency, timeliness, validity, uniqueness, and integrity. A quality measure must be defined in relation to a purpose. For example, a postal address can be syntactically valid but geographically wrong.

For a dataset containing N records, a simple completeness rate for a field is:

Completeness = (number of non-missing values ÷ N) × 100%

This measure assumes that missingness is identifiable and that each record has equal relevance. It does not measure accuracy or whether missing values are acceptable for a particular use. Quality thresholds should therefore be tied to decisions and risk, not treated as universal scores.

3. Privacy Principles and Regulatory Reasoning

3.1 Personal and sensitive data

Personal data are information relating to an identified or identifiable person. Direct identifiers include names, government identifiers, and email addresses. Indirect identifiers, such as age, location, occupation, and event time, may identify a person when combined. Sensitive categories often include health, biometric, genetic, financial, precise location, children’s, and information about protected characteristics, although legal definitions differ by jurisdiction.

Pseudonymization replaces direct identifiers with tokens while retaining a possibility of re-identification through additional information. It reduces exposure but is not equivalent to anonymization. Anonymization aims to make re-identification reasonably infeasible under a defined threat model; it is difficult to guarantee, especially in high-dimensional data.

3.2 Core privacy principles

Across major privacy regimes and professional frameworks, recurring principles include:

  • Purpose limitation: collect and use data for specified, legitimate purposes.
  • Data minimization: use no more personal data than necessary.
  • Accuracy: keep data sufficiently correct for the intended use.
  • Storage limitation: retain data only as long as justified.
  • Security and confidentiality: protect data against unauthorized or unlawful processing.
  • Transparency: explain relevant collection, use, sharing, and automated decision practices.
  • Accountability: demonstrate compliance rather than merely assert it.

Applicable law depends on jurisdiction, sector, data type, organizational role, and cross-border transfers. Examples include the EU General Data Protection Regulation, the California Consumer Privacy Act and related state laws, HIPAA in relevant United States health contexts, sectoral financial rules, and national data-protection statutes. These instruments are not interchangeable. Organizations must obtain jurisdiction-specific legal advice rather than assuming that one compliance model applies everywhere.

3.3 Lawful basis and consent

Consent should be informed, specific, freely given, and capable of withdrawal where the applicable law requires those qualities. A pre-ticked box, confusing notice, or service that unnecessarily conditions access on unrelated data use may not constitute meaningful consent.

Consent is not always the only lawful basis. Depending on the jurisdiction, processing may rely on contract, legal obligation, vital interests, public task, or legitimate interests subject to safeguards and balancing. A valid basis for collection does not automatically authorize every later use. Secondary uses should be assessed for compatibility, necessity, transparency, and risk.

A sound consent record identifies what was explained, when consent was obtained, the version of the notice, the purpose, the person or mechanism providing consent, and any withdrawal. Consent should not be used as a substitute for ethical reflection: a person may agree without understanding downstream inferences or power asymmetries.

3.4 Rights and impact assessments

Depending on applicable law, individuals may have rights to access, correction, deletion, restriction, portability, objection, and information about automated decision-making. Organizations need processes to verify identity, locate data through lineage, assess exceptions, respond within required periods, and record outcomes.

A Data Protection Impact Assessment or similar privacy impact assessment is appropriate for high-risk processing. It should describe the purpose, data flows, necessity, proportionality, affected groups, threats, mitigations, residual risk, consultation, and approval. It must be performed early enough to influence design, not merely filed after deployment.

4. Security Across the Data Lifecycle

Security is commonly organized around confidentiality, integrity, and availability—the CIA triad.

  • Confidentiality limits disclosure to authorized parties.
  • Integrity protects accuracy and prevents unauthorized alteration.
  • Availability ensures authorized access when needed.

A lifecycle approach considers collection, ingestion, storage, transformation, analysis, sharing, archiving, and deletion. Controls should follow the data rather than stop at a central database.

4.1 Access control

The principle of least privilege grants only the access necessary for an approved task. Role-based access control assigns permissions to roles; attribute-based access control evaluates attributes such as user role, location, device assurance, data sensitivity, and purpose. Separation of duties prevents one person from authorizing, executing, and concealing a high-risk action.

Important controls include strong authentication, privileged-access management, periodic access reviews, time-limited access, service-account governance, network segmentation, encryption in transit and at rest, key management, data-loss prevention, immutable audit logs, vulnerability management, and secure deletion. Encryption protects confidentiality when keys are well managed; it does not correct excessive access or compromised endpoints.

4.2 Threat and risk assessment

Threat modeling asks what can go wrong, who may cause it, which assets are affected, and how controls reduce likelihood or impact. Risks include credential theft, insider misuse, ransomware, supply-chain compromise, inference attacks, re-identification, model extraction, poisoning of training data, and accidental disclosure through notebooks or logs.

A qualitative risk rating may combine likelihood and impact. Such ratings are useful for prioritization but should not create false precision. High-impact risks affecting vulnerable people may require action even when likelihood is uncertain.

4.3 Incident response

An incident plan should define detection, triage, containment, eradication, recovery, notification, evidence preservation, communication, and lessons learned. Notification obligations and deadlines vary by law and sector. Organizations should conduct exercises, maintain contact lists, and preserve logs before an incident occurs.

5. Ethics, Fairness, and Representational Harm

5.1 Ethical foundations

Responsible data practice draws on autonomy, beneficence, non-maleficence, justice, and respect for human dignity. Professional codes additionally emphasize competence, honesty, public interest, explainability, and accountability.

Ethical analysis should ask:

  1. Who benefits and who bears risk?
  2. Who is absent from the dataset or decision process?
  3. Could the use reinforce historical disadvantage?
  4. Can affected people understand, challenge, or correct the outcome?
  5. Is the use proportionate to its purpose?
  6. What happens when the system is wrong?

5.2 Fairness is context-dependent

Fairness has no single universal metric. Possible criteria include demographic parity, equal opportunity, equalized odds, calibration, individual similarity, and procedural fairness. These criteria can conflict, particularly when base rates differ between groups. Therefore, choosing a metric is a normative and domain-specific decision, not merely a technical optimization.

For a binary classifier, the true-positive rate for group g is:

TPRg = TPg ÷ (TPg + FNg)

Here, TP_g is the number of genuine positive cases correctly identified in group g, and FN_g is the number of genuine positive cases missed. Equal opportunity seeks approximately equal TPR across groups. This measure is meaningful only when the positive outcome and labels are defined appropriately. Equal TPR does not guarantee equal precision, equal harms, or overall fairness.

5.3 Bias and representational harms

Bias can enter through problem formulation, sampling, measurement, labels, missingness, historical decisions, feature construction, deployment, and feedback loops. A model trained on past hiring decisions may reproduce prior discrimination. Removing a protected attribute may not remove its proxies, such as geography or educational history.

Representational harm occurs when data systems portray people or groups in degrading, stereotyped, exclusionary, or systematically inaccurate ways. Examples include image datasets with poor coverage of darker skin tones, language systems that associate occupations with one gender, or classification schemes that erase minority identities.

Fairness evaluation should be disaggregated by relevant groups and intersections, while protecting privacy and avoiding unnecessary sensitive-data collection. Small samples make estimates unstable; uncertainty should be reported rather than hidden. Quantitative parity is not enough: qualitative consultation and affected-community participation can reveal harms that metrics miss.

6. Responsible AI and Analytical Review

A model should have a documented purpose, owner, intended users, prohibited uses, training-data description, validation results, limitations, fairness assessment, monitoring plan, and retirement conditions. Model cards, datasheets for datasets, system cards, and decision logs support traceability.

A risk-tiered review process is more effective than treating every model identically. Low-risk descriptive dashboards may require standard quality and access checks. High-impact systems involving employment, credit, health, education, housing, policing, or essential services require stronger validation, human oversight, contestability, independent review, and post-deployment monitoring.

Human oversight must be meaningful. A human who merely approves an automated recommendation without time, authority, competence, or relevant information is not an effective safeguard. Appeals should be accessible, timely, and capable of changing an outcome.

Generative AI introduces additional concerns: confidential prompts may be retained by vendors; outputs can hallucinate, reproduce bias, or disclose memorized information; and generated code may introduce vulnerabilities. Organizations should define approved tools, prohibit sensitive data in unapproved services, validate outputs, record material use, and assign responsibility to the human decision-maker.

7. Retention, Deletion, and Secondary Use

Retention schedules specify the data category, business or legal justification, retention period, archive conditions, owner, and destruction method. Retention should reflect necessity, legal holds, audit requirements, scientific reproducibility, and the rights of individuals. “Keep everything because storage is cheap” increases breach impact and future misuse.

Deletion must cover primary stores, replicas, caches, extracts, backups where technically and legally required, notebooks, and vendor copies. Some systems use cryptographic erasure, in which destruction of keys renders encrypted data inaccessible; this is effective only if encryption and key isolation were correctly implemented.

Secondary use should undergo a compatibility and risk review. De-identification reduces risk but does not eliminate it. Data combinations, external datasets, and model outputs may permit inference of attributes never explicitly collected.

8. Implementing an Accountable Governance Program

A practical implementation can proceed in stages:

  1. Establish mandate: define objectives, executive sponsorship, scope, risk appetite, and decision rights.
  2. Inventory and classify: identify assets, owners, personal and sensitive fields, systems, vendors, and jurisdictions.
  3. Define critical data elements: document business meaning, quality rules, lineage, and contracts.
  4. Assess risk: perform privacy, security, fairness, and impact assessments proportionate to use.
  5. Implement controls: apply access, encryption, minimization, retention, logging, quality checks, and approval workflows.
  6. Operationalize accountability: maintain evidence, review exceptions, train users, and establish escalation paths.
  7. Monitor and improve: track incidents, quality, access anomalies, fairness indicators, complaints, and control effectiveness.

Useful indicators include the percentage of critical assets with named owners, catalog completeness, unresolved quality incidents, overdue access reviews, mean time to revoke access, retention exceptions, assessment completion, incident response performance, and the number and severity of substantiated complaints. Metrics should not become targets that encourage concealment. A lower number of reported incidents may reflect weaker detection rather than better security.

Applied Case: Illustrative Retail Credit-Eligibility System

Background

A fictional retailer, Northstar Retail, plans to offer instant installment credit. It proposes combining purchase history, loyalty information, device data, and external marketing data to predict repayment risk.

Problem

The initial proposal lacks a clear purpose specification, contains no retention schedule, and gives analysts broad access to raw customer records. Historical approval data reflect manual decisions that were less favorable to customers in certain neighborhoods. The proposed model has strong overall accuracy but has not been tested across groups.

Analysis

The governance team maps the data lineage from point-of-sale systems and vendors through feature engineering, model training, decision APIs, and customer communications. It identifies neighborhood as a possible proxy for protected characteristics and discovers that marketing consent does not clearly authorize credit assessment. The team also finds that an external vendor cannot explain its data provenance.

A privacy and impact assessment identifies risks of function creep, excessive collection, opaque adverse decisions, and discriminatory outcomes. Security review identifies unnecessary analyst privileges and unencrypted extracts in a shared workspace.

Approach and solution

Northstar narrows the purpose to credit assessment, removes unrelated marketing attributes, and requires documented lawful processing. It introduces a data contract for transaction feeds, assigns a data owner and steward, and records lineage. Access is granted through role-based, time-limited permissions; raw identifiers are separated from modeling data; and extracts expire automatically.

The model is evaluated by relevant groups using error rates, true-positive rates, false-positive rates, calibration, and confidence intervals. A simpler model is selected because it offers comparable performance with greater explainability. Applicants receive understandable reasons for adverse decisions and a human appeal route. The organization establishes monitoring for drift, disparate outcomes, vendor changes, and complaint patterns.

Outcome

The launch is delayed briefly but produces a system with narrower data use, stronger evidence, and clearer accountability. Monitoring later detects that a change in merchant coding disproportionately increases erroneous declines for small businesses. The data steward pauses the affected release, corrects the pipeline, and documents the incident.

Learning points

The case demonstrates that governance is not a final compliance check. Purpose, lineage, contracts, access controls, fairness testing, explanation, and monitoring must be designed together. Better governance may reduce short-term speed while improving long-term reliability, legitimacy, and risk control.

Challenges and Limitations

Governance programs can become bureaucratic if approvals are disconnected from actual risk. Ownership may be unclear in matrix organizations, and data lineage may be incomplete in legacy systems. Privacy rules differ across jurisdictions, while cross-border cloud services complicate control and accountability. Fairness metrics can conflict, sensitive-group data may be unavailable, and correcting bias in outputs may not address biased institutions or labels.

Automated compliance tools also have limits. A catalog cannot determine whether a purpose is ethically justified; a scanner cannot understand contextual harm; and a dashboard cannot replace informed judgment. Governance therefore requires multidisciplinary participation from technical experts, legal and privacy professionals, domain specialists, security teams, managers, and affected communities.

Best-Practice Checklist

  • Assign a named owner and steward to every critical data domain.
  • Maintain searchable metadata, lineage, contracts, and quality rules.
  • Classify data before granting access.
  • Collect only what is necessary and document purpose and lawful basis.
  • Separate identifiers, restrict privileged access, and review permissions regularly.
  • Encrypt sensitive data and manage keys independently.
  • Define retention and deletion across production, replicas, extracts, and vendors.
  • Conduct privacy, security, and fairness assessments before high-risk deployment.
  • Document model limitations, intended use, prohibited use, and human escalation.
  • Monitor outcomes, drift, complaints, incidents, and control effectiveness.
  • Provide meaningful notice, correction, appeal, and remedy.
  • Preserve evidence so that decisions can be audited and explained.

Chapter Summary

Data governance establishes decision rights and accountability for data, while stewardship operationalizes definitions, quality, metadata, lineage, and appropriate use. Catalogs make assets discoverable; lineage explains dependencies; and data contracts make producer–consumer expectations testable. Privacy requires purpose limitation, minimization, transparency, security, retention control, and respect for applicable rights and lawful bases. Security protects confidentiality, integrity, and availability through lifecycle controls such as least privilege, encryption, logging, monitoring, and incident response.

Ethical data practice extends beyond legal compliance. It examines autonomy, power, distributive effects, bias, fairness, representational harm, explainability, contestability, and remedy. Responsible analytical and AI systems require risk-tiered review, documented limitations, meaningful human oversight, and continuous monitoring. Effective governance is therefore an organizational capability that integrates policy, technology, professional judgment, and participation by affected stakeholders.

Key Terms

Data governance: The system of authority, accountability, policies, and processes used to manage data.

Data owner: The accountable role that defines purpose, access, risk tolerance, and policy for a data domain.

Data steward: The role responsible for definitions, metadata, quality, and appropriate operational use.

Data custodian: The technical role responsible for storage, platforms, backup, and operational safeguards.

Data catalog: An inventory of data assets and their descriptive metadata.

Data lineage: A record of data origins, transformations, dependencies, and destinations.

Data contract: An explicit agreement specifying a data product’s schema, meaning, quality, and change rules.

Personal data: Information relating to an identified or identifiable person.

Pseudonymization: Replacing direct identifiers with tokens while retaining possible re-identification.

Anonymization: Processing intended to make re-identification reasonably infeasible under a threat model.

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

Data minimization: Using no more personal data than necessary for the stated purpose.

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

CIA triad: Confidentiality, integrity, and availability.

Privacy impact assessment: A structured evaluation of privacy risks, necessity, safeguards, and residual risk.

Fairness: A context-dependent judgment about equitable treatment and distribution of benefits and harms.

Representational harm: Stereotyping, exclusion, degradation, or inaccurate portrayal caused by data systems.

Model card: Documentation describing a model’s purpose, performance, limitations, and risks.

Retention schedule: A rule specifying how long data are kept and how they are archived or destroyed.

Accountability: The duty to take responsibility for decisions and demonstrate that controls are effective.

Review Questions

Short Answer Questions

  1. Distinguish a data owner from a data steward.
  2. What information should a data catalog contain?
  3. Why is pseudonymization not the same as anonymization?
  4. State the three elements of the CIA triad.
  5. Why should retention schedules include data extracts and backups?

Long Answer Questions

  1. Explain how catalogs, lineage, and data contracts jointly improve data reliability and accountability.
  2. Discuss the relationship between privacy law, organizational policy, and ethical data practice.
  3. Compare role-based and attribute-based access control, including situations in which each is useful.
  4. Explain why fairness cannot be reduced to one universal statistical metric.
  5. Design a governance operating model for a high-impact predictive system.

Analytical / Application Questions

  1. A university wants to predict student dropout using attendance, disability information, location, and social-media data. Identify governance, privacy, security, fairness, and ethical issues, then recommend a proportionate review process.
  2. A data pipeline reports 98% completeness but produces many incorrect customer addresses. Analyze why the completeness measure is insufficient and propose additional quality controls.
  3. A model has equal true-positive rates across two groups but substantially different false-positive rates. Explain what this reveals, what it does not establish, and what further evidence decision-makers should examine.

Multiple Choice Questions with Answers

Question 1

Which role is primarily accountable for defining the purpose and access policy of a data domain?

A. Data owner

B. Data custodian

C. Data user

D. Network administrator

Correct Answer: A. Data owner

Question 2

What is the main purpose of data lineage?

A. To increase storage capacity

B. To show origins, transformations, and dependencies

C. To replace encryption

D. To eliminate the need for data owners

Correct Answer: B. To show origins, transformations, and dependencies

Question 3

Which principle requires an organization to collect no more personal data than necessary?

A. Storage limitation

B. Data minimization

C. Separation of duties

D. Availability

Correct Answer: B. Data minimization

Question 4

Why does pseudonymization not automatically make data anonymous?

A. Pseudonyms always contain names

B. The data cannot be encrypted

C. Additional information may permit re-identification

D. Pseudonymized data cannot be analyzed

Correct Answer: C. Additional information may permit re-identification

Question 5

Which access-control principle grants only the permissions needed for an approved task?

A. Open access

B. Least privilege

C. Data portability

D. Purpose expansion

Correct Answer: B. Least privilege

Question 6

In the formula TPRg = TPg ÷ (TPg + FNg), what does FN_g represent?

A. Correct positive predictions for group g

B. Incorrect positive predictions for group g

C. Genuine positive cases missed for group g

D. All negative cases for group g

Correct Answer: C. Genuine positive cases missed for group g

Question 7

Which statement best describes a data contract?

A. A legal document that transfers ownership of all data

B. An agreement specifying data structure, meaning, quality, and change expectations

C. A backup copy of a database

D. A model fairness score

Correct Answer: B. An agreement specifying data structure, meaning, quality, and change expectations

Question 8

What is a key limitation of fairness metrics?

A. They can never be calculated

B. They always produce identical conclusions

C. Different fairness criteria may conflict and require contextual judgment

D. They apply only to storage systems

Correct Answer: C. Different fairness criteria may conflict and require contextual judgment

Question 9

Which activity should occur during incident response?

A. Deleting all logs immediately

B. Ignoring vendor involvement

C. Containment, recovery, notification assessment, and lessons learned

D. Expanding access to every analyst

Correct Answer: C. Containment, recovery, notification assessment, and lessons learned

Question 10

Why is meaningful human oversight important in high-impact automated decisions?

A. It guarantees that the model is accurate

B. It ensures a person has authority, competence, and information to review and change outcomes

C. It removes the need for documentation

D. It makes privacy law irrelevant

Correct Answer: B. It ensures a person has authority, competence, and information to review and change outcomes

Data Preparation & Analysis
Chapter 14 of 15