12. Governance, Security, Privacy and Responsible Analytics

Introduction and Context

Big data analytics creates value by transforming extensive, varied, and rapidly generated data into evidence for decisions, services, research, and automation. The same characteristics that make big data valuable also make it difficult to govern. Data may be collected from multiple jurisdictions, combined across organizational boundaries, processed by opaque algorithms, and used for decisions affecting employment, credit, health, education, mobility, or access to public services. Consequently, technical performance alone is not an adequate measure of analytical quality. A system may be accurate yet unlawful, secure yet discriminatory, innovative yet socially harmful, or efficient yet impossible to audit.

Governance provides the institutional arrangements through which an organization directs data and analytics. Security protects data, systems, and analytical operations from unauthorized compromise. Privacy engineering incorporates protection of individuals into the design of data systems. Responsible analytics extends these concerns to fairness, explainability, accountability, human agency, consent, sustainability, and social impact. These dimensions are interdependent. Weak ownership can produce poor access control; poor metadata can undermine privacy assessments; insecure data can invalidate consent; and opaque models can obstruct accountability.

For doctoral researchers and technology leaders, the central issue is not simply how to comply with rules. It is how to design sociotechnical systems in which legitimate purposes, institutional responsibility, technical controls, and public values remain aligned throughout the data life cycle. This requires attention to power, context, uncertainty, and competing interests rather than reliance on a single checklist.

Learning Objectives

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

1. Explain the relationship among data governance, cybersecurity, privacy, and responsible analytics.

2. Design roles for data ownership, stewardship, custodianship, and access decision-making.

3. Apply risk-based frameworks for classification, access, retention, incident response, and third-party management.

4. Distinguish privacy protection from security protection and select suitable privacy-enhancing techniques.

5. Evaluate algorithmic systems for fairness, transparency, explainability, validity, and accountability.

6. Incorporate legal, regulatory, sovereignty, and ethical requirements into analytics architectures.

7. Critically assess trade-offs between analytical utility, privacy, security, innovation, and social legitimacy.

8. Formulate a responsible analytics program with measurable controls and continuous assurance.

Governance as an Operating Model for Data and Analytics

Data governance is the allocation of decision rights and responsibilities for data assets, together with the policies, standards, processes, and controls used to exercise those rights. It is broader than data management. Data management concerns the operational handling of data, whereas governance determines who may decide what data means, who may use it, for which purposes, under which conditions, and with what accountability.

A mature governance model usually operates at three levels. Strategic governance establishes principles, risk appetite, investment priorities, and accountability. Tactical governance translates these decisions into policies, standards, taxonomies, and control requirements. Operational governance applies them to datasets, pipelines, models, applications, incidents, and user requests. The three levels must be connected. A principle such as “use data lawfully and fairly” has little practical value unless it becomes a documented purpose assessment, access rule, model review, monitoring requirement, and escalation process.

Ownership is a decision-right rather than an assertion of physical possession. A data owner is accountable for the purpose, quality expectations, risk classification, access policy, and acceptable use of a data domain. A data steward performs coordinating and quality-related work: defining terms, resolving inconsistencies, maintaining metadata, monitoring quality rules, and supporting users. A data custodian operates the technical environment and implements controls such as encryption, backup, identity management, and logging. A privacy officer, security officer, legal adviser, model-risk manager, and ethics or impact-review body may provide independent challenge. In smaller organizations, one person may hold several roles, but the responsibilities should remain distinguishable.

A useful governance artifact is a responsibility matrix that identifies who is accountable, responsible, consulted, and informed for activities such as collection, classification, access approval, quality remediation, model deployment, retention, and incident response. Governance councils should not become ceremonial committees. Their value depends on decision authority, appropriate expertise, documented records, and the ability to stop or redesign high-risk initiatives.

Data as a Governed Asset

Governance begins with an inventory of data assets and analytical products. The inventory should record source, owner, steward, business purpose, sensitivity, legal basis, lineage, retention period, quality indicators, permitted uses, geographic location, recipients, and dependencies. A business glossary provides shared definitions for terms such as “customer,” “active account,” “adverse event,” or “high-risk transaction.” Without common definitions, different departments may produce technically correct but institutionally incompatible analyses.

Data quality should be treated as fitness for a specified use, not as an abstract property. Accuracy, completeness, timeliness, consistency, validity, uniqueness, and traceability may matter differently in different contexts. A small error rate can be unacceptable in a medical alert system but tolerable in exploratory market analysis. Quality controls should therefore connect measurable thresholds to consequences, including rejection, quarantine, correction, human review, or disclosure of uncertainty.

Lineage records the movement and transformation of data from origin to output. It supports impact analysis, reproducibility, regulatory inquiry, and incident investigation. In machine-learning environments, lineage must include training data, feature engineering, code versions, model parameters, validation results, deployment changes, and monitoring history. A model without traceable lineage is difficult to validate and nearly impossible to govern responsibly.

Security Architecture for Analytics Environments

Security protects confidentiality, integrity, and availability, but analytics introduces additional concerns. Data lakes may contain raw information copied from many systems. Distributed processing can create temporary files and replicated datasets. Notebooks may contain credentials or extracts. Application programming interfaces may expose sensitive features. Model artifacts can reveal information about training data, while adversarial inputs can manipulate predictions.

A risk-based security architecture begins with threat modeling. Analysts should identify assets, actors, trust boundaries, attack paths, potential impacts, and controls. Common threats include credential theft, ransomware, insider misuse, supply-chain compromise, insecure interfaces, re-identification, data poisoning, model evasion, membership inference, and unauthorized secondary use. Security controls should be proportionate to risk but should not be interpreted as a reason to ignore low-frequency, high-impact events.

Identity and access management is foundational. Least privilege gives users only the permissions needed for an authorized task. Role-based access control assigns permissions to job roles, while attribute-based access control evaluates contextual properties such as project, location, data sensitivity, time, purpose, and device status. Privileged access should be separately controlled, strongly authenticated, time limited, and logged. Access reviews must remove obsolete permissions rather than merely document them.

Protection should be layered across the data life cycle. Encryption in transit and at rest reduces exposure if communications or storage are intercepted. Key management must separate key administration from ordinary data access and support rotation, revocation, and recovery. Tokenization or pseudonymization can reduce direct exposure of identifiers, although pseudonymized data may remain personal data when re-identification is reasonably possible. Network segmentation, secure configuration, vulnerability management, endpoint protection, backup testing, and immutable audit logs are complementary controls.

Security monitoring should detect abnormal access, unusual extraction volumes, failed authentication, privilege escalation, suspicious model queries, and changes to critical data or code. An incident-response plan defines preparation, detection, containment, eradication, recovery, notification, evidence preservation, and post-incident learning. A plan that omits legal notification duties, affected individuals, third-party providers, or model rollback is incomplete.

Privacy Engineering and Data Protection

Privacy concerns the appropriate handling of information about identifiable or identifiable individuals, including the ability to control, understand, and contest uses of data. Security is a major privacy safeguard, but it is not equivalent to privacy. An encrypted system can still violate privacy if it collects excessive data, uses it for an incompatible purpose, retains it indefinitely, or makes consequential decisions without due process.

Privacy engineering translates principles into system properties. Common principles include purpose limitation, data minimization, accuracy, storage limitation, transparency, accountability, and protection against unauthorized disclosure. Privacy by design requires these considerations during problem formulation and architecture, not after implementation. A privacy impact assessment should describe the processing, individuals affected, data flows, purposes, risks, safeguards, residual risks, and consultation or approval requirements.

A lawful and ethical analytics program should identify an appropriate basis for processing. Depending on jurisdiction and context, this may include consent, contract, legal obligation, protection of vital interests, public task, or legitimate interests. Consent should be informed, specific, freely given, and withdrawable where applicable. It is not a universal solution: consent may be invalid where there is a substantial power imbalance, and it does not automatically justify indefinite retention or unrelated uses.

Privacy-enhancing technologies reduce exposure while preserving analytical value. Pseudonymization replaces direct identifiers but preserves a linkage possibility. Aggregation reports groups rather than individuals, but small groups may still permit inference. Differential privacy adds mathematically calibrated noise and offers a formal privacy guarantee under defined parameters; however, repeated queries consume a privacy budget and excessive noise can reduce utility. Federated learning keeps some training data at local sites, while secure aggregation allows a coordinator to receive combined updates rather than individual contributions. Homomorphic encryption permits computation on encrypted data, though computational cost and supported operations may limit practical use. Secure multiparty computation enables parties to calculate jointly without revealing their private inputs. No technique is universally superior; selection depends on threat model, accuracy requirements, computational resources, and governance context.

De-identification should be tested against realistic auxiliary information and attack capabilities. Removing names is insufficient if combinations of dates, locations, occupations, or rare events can identify a person. Privacy risk is contextual and dynamic: data released safely today may become identifiable when new datasets, tools, or public records become available.

Legal Compliance, Sovereignty, and Cross-Border Data

Legal compliance is a design constraint, not a final approval step. Requirements differ across jurisdictions and sectors, but recurring themes include lawful collection, transparency, individual rights, security safeguards, breach notification, retention limits, restrictions on sensitive categories, and controls over automated decision-making. Organizations must map legal obligations to concrete controls and evidence rather than assuming that a general privacy policy is sufficient.

Data sovereignty concerns the authority of a state or jurisdiction over data, processing, access, and infrastructure. Data residency specifies where data is stored; sovereignty may additionally concern which laws apply, who can access data, and whether foreign authorities can compel disclosure. Cloud contracts, subcontracting arrangements, support access, replication, backup locations, and encryption-key jurisdiction all affect sovereignty. A cross-border architecture should document transfer mechanisms, supplementary safeguards, localization requirements, and exit arrangements.

Compliance should be supported by records of processing, data inventories, consent or authorization evidence, access logs, retention decisions, impact assessments, vendor reviews, training, and incident records. Auditability does not mean retaining everything forever. Excessive logs and duplicated datasets can increase privacy and security risk. Evidence should be sufficient, proportionate, protected, and subject to retention rules.

Algorithmic Accountability and Fairness

Algorithmic accountability assigns responsibility for decisions made with or through models. Accountability must remain with an identifiable organization and decision-maker; it cannot be transferred to software or a vendor. A model card, system documentation, decision log, and approval record can clarify intended use, limitations, training data, performance, affected groups, human oversight, and known risks.

Fairness is not a single statistical property. Group fairness examines differences in outcomes or error rates across protected or relevant groups. Individual fairness asks whether similar individuals receive similar treatment under an appropriate notion of similarity. Procedural fairness addresses notice, explanation, contestability, consistency, and the opportunity for human review. Causal fairness investigates whether decisions depend on impermissible pathways or structural disadvantage. These perspectives can conflict. For example, equal selection rates and equal false-negative rates may not both be achievable when base rates differ. A fairness assessment must therefore state the normative objective, population, decision context, metric, and trade-offs.

Important measures include demographic parity, equal opportunity, equalized odds, false-positive and false-negative rate comparisons, calibration, subgroup performance, and intersectional analysis. Metrics alone are inadequate. A model can satisfy a selected parity measure while relying on poor labels, excluding relevant groups, or causing harm through the decision process. Researchers should examine label validity, missingness, measurement error, historical bias, proxy variables, feedback loops, and deployment conditions.

Transparency operates at several levels. System transparency explains purpose, data sources, model class, limitations, and governance. Decision transparency provides an understandable reason for an individual outcome. Technical explainability methods such as feature importance, counterfactual explanations, and local surrogate models can assist analysis, but explanations may be unstable or misleading. An explanation should be evaluated for fidelity, comprehensibility, actionability, and consistency with the actual model.

Human oversight is meaningful only when reviewers have authority, time, competence, and access to relevant evidence. A human who merely approves automated recommendations under workload pressure may provide symbolic rather than substantive oversight. High-impact systems should include appeal, correction, override, and suspension mechanisms. Monitoring should continue after deployment because data distributions, social conditions, behavior, and institutional policies change.

A Lifecycle Framework for Responsible Analytics

Responsible analytics can be organized as a lifecycle of connected decisions rather than a one-time ethics review.

Problem formulation asks whether the proposed objective is legitimate, necessary, and proportionate. It identifies affected communities, potential benefits, foreseeable harms, alternatives, and success criteria beyond predictive accuracy.

Data acquisition and preparation establish provenance, consent or legal basis, quality, representativeness, sensitivity, retention, and permitted uses. Data collected for one purpose should not automatically be repurposed for another.

Model development and validation address reproducibility, leakage, uncertainty, subgroup performance, robustness, privacy risk, and security threats. Independent review is especially important for high-impact applications.

Deployment and use define user permissions, human roles, explanations, appeal processes, operational thresholds, rollback procedures, and communication to affected persons.

Monitoring and retirement track drift, incidents, fairness, privacy events, changing laws, user feedback, and realized benefits. Retirement includes deletion or archival decisions, revocation of access, model replacement, and communication about discontinued systems.

This lifecycle should be supported by stage gates. A low-risk descriptive dashboard may require lightweight review, whereas a system influencing eligibility for housing, employment, healthcare, or financial services may require formal impact assessment, legal review, security testing, fairness testing, executive approval, and continuing independent audit.

Illustrative Case: A Regional Health Analytics Platform

Background

The fictional Northbridge Health Alliance consists of several hospitals and community clinics. It proposes a platform that combines laboratory results, appointment histories, medication records, and social-care referrals to predict which patients may require intensive follow-up after discharge.

Situation and Problem

The proposed system could reduce avoidable readmissions, but the data is distributed across institutions, contains highly sensitive information, and reflects unequal access to healthcare. Some clinics use different coding practices, and social-care data was originally collected for service delivery rather than prediction. Leaders must decide whether and how to proceed.

Analysis

A preliminary inventory identifies multiple data owners, inconsistent definitions, varying retention rules, and different levels of data quality. The privacy assessment identifies risks of incompatible secondary use, re-identification, excessive access, and stigmatizing predictions. Security analysis identifies the need to isolate clinical systems from the analytics environment, strengthen service-account controls, and monitor bulk extraction. Fairness analysis shows that historical access patterns may cause the model to underpredict need among patients who use fewer services. A high predicted risk may also trigger unwanted attention or resource allocation decisions without patient understanding.

Approach and Strategy

The alliance establishes a joint governance board with clinical, technical, privacy, legal, patient-representation, and community expertise. A data dictionary and lineage register are created before model development. Direct identifiers are separated from analytical features, access is granted through project-specific roles, and sensitive fields are included only when their necessity is demonstrated. The model is initially limited to a clinical decision-support function; it cannot automatically deny or ration services.

The team evaluates several models and reports calibration, false-negative rates, and subgroup performance across age, ethnicity, disability, language, and service-use patterns where lawful and methodologically appropriate. Clinicians receive explanations and uncertainty indicators. Patients are informed about the use of their data through accessible notices, and a process is created for questions, correction, and objection where applicable. A pilot is independently reviewed, monitored for drift and disparate outcomes, and subject to a predefined suspension threshold.

Outcome

The pilot is approved only for a limited population and purpose. It improves prioritization in some clinics, but the governance process reveals that inconsistent referral coding limits generalization. The alliance therefore postpones expansion, invests in data quality, and publishes a limitations report. The result is not simply a model deployment; it is a controlled learning process in which operational evidence changes the scope of the system.

Learning Points

The case demonstrates that responsible innovation can require narrowing a project rather than cancelling it. It also shows that privacy, security, fairness, and quality are mutually reinforcing. Most importantly, a technically promising model does not establish a sufficient justification for deployment. Purpose, authority, evidence, human impact, and continuing review must be addressed together.

Organizational Implementation and Professional Practice

Implementation succeeds when governance is embedded in ordinary delivery practices. Procurement should require vendors to disclose data use, subprocessors, hosting locations, security controls, model limitations, audit rights, incident obligations, deletion procedures, and assistance with individual rights. Contracts should prevent a vendor from quietly repurposing organizational data for unrelated model training.

A governance portfolio can include data inventories, glossaries, classification schemes, access standards, retention schedules, privacy impact assessments, model registers, model cards, fairness test reports, security threat models, incident playbooks, and audit dashboards. Metrics should measure outcomes rather than paperwork. Examples include unresolved high-risk access violations, time to revoke access, percentage of critical datasets with lineage, quality-rule failure rates, privacy incidents, model drift, subgroup error gaps, appeal resolution time, and percentage of retired assets removed from active environments.

Training should be role-specific. Executives need risk and accountability education; stewards need metadata and quality skills; engineers need secure development and privacy-enhancing methods; analysts need lawful-use and disclosure training; decision-makers need awareness of uncertainty, bias, and automation limits. Professional competence includes the willingness to question a technically feasible but unjustified use.

Challenges and Limitations

Governance programs face recurring tensions. Centralization can create consistency but may slow legitimate experimentation. Decentralization can encourage innovation but produce duplicated data, incompatible definitions, and uneven controls. Strict minimization can reduce risk but may limit research value. Excessive de-identification can impair usefulness, while weak de-identification can create serious exposure. Fairness metrics may conflict, and protected attributes needed for auditing may be legally or socially sensitive. Explainability may improve communication without making a model genuinely fair or correct.

Organizations also face governance fatigue. Too many forms can encourage superficial compliance, while too few controls leave high-risk decisions unexamined. Automated governance tools can classify data, detect anomalies, and monitor policies, but automated labels and risk scores require validation. Finally, governance cannot solve structural injustice through technical means alone. Biased institutions may produce biased data, and a fairer model cannot by itself correct unequal access to resources.

Current Developments and Emerging Directions

Regulatory attention is increasingly moving toward risk-based obligations for artificial intelligence, high-impact automated decisions, foundation models, and cross-border data use. Organizations are developing machine-readable policies, confidential computing, privacy-preserving synthetic data, model observability, algorithm registers, and continuous control monitoring. Synthetic data may reduce direct exposure, but it can reproduce source-data bias, leak rare records, or fail to represent important populations; it requires privacy and utility validation.

Generative AI introduces additional governance questions concerning training-data provenance, prompt confidentiality, hallucination, copyright, model supply chains, retrieval permissions, and human review. Large models may expose sensitive information through memorization or infer attributes not explicitly provided. Responsible deployment therefore requires restricted tools, content filtering, provenance records, evaluation datasets, red-teaming, usage monitoring, and clear limits on autonomous action.

The emerging direction is toward continuous assurance: governance evidence is generated and evaluated throughout development and operation rather than assembled only for an annual audit. This approach is promising, but its legitimacy still depends on human judgment, affected-community participation, and the willingness to suspend systems when evidence indicates unacceptable harm.

Best-Practice Design Principles

A robust program should observe the following principles:

• Assign explicit accountability for every important dataset, model, decision, and control.
• Govern purposes and uses, not merely storage locations.
• Classify data and models according to potential harm, not only technical sensitivity.
• Apply least privilege, strong authentication, encryption, segmentation, logging, and tested recovery.
• Build privacy and security requirements into architecture, procurement, and development.
• Maintain provenance, lineage, reproducibility, and version control.
• Evaluate fairness, validity, robustness, and uncertainty across relevant populations.
• Provide understandable notice, meaningful human review, appeal, correction, and redress.
• Monitor deployed systems for drift, misuse, security events, and social impact.
• Use independent challenge for high-impact applications and document residual risk.
• Treat governance as a learning system that adapts to evidence, law, and stakeholder experience.

Chapter Summary

Data governance defines decision rights, responsibilities, standards, and controls for data and analytics. Ownership, stewardship, custodianship, privacy, security, legal compliance, and algorithmic accountability must be coordinated across the data life cycle. Security protects confidentiality, integrity, and availability, while privacy engineering addresses appropriate purpose, minimization, transparency, retention, and individual interests. Privacy-enhancing technologies can reduce exposure but require threat-specific evaluation.

Responsible analytics extends technical evaluation to fairness, explainability, contestability, human oversight, social impact, and institutional accountability. A lifecycle approach examines problem formulation, data acquisition, development, deployment, monitoring, and retirement. Risk-based governance, strong lineage, access control, impact assessment, independent review, and continuous monitoring enable innovation without treating compliance as a substitute for judgment. The strategic objective is not merely to prevent data misuse but to create trustworthy analytical capability that remains lawful, secure, explainable, and socially defensible.

Key Terms

Data governance: The allocation of decision rights, responsibilities, policies, and controls for data and analytics.

Data owner: The person or function accountable for a data domain’s purpose, access policy, quality expectations, and risk.

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

Data custodian: The technical role that implements storage, access, security, backup, and operational controls.

Data lineage: A record of data origins, transformations, movements, and uses.

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

Attribute-based access control: Access decisions based on attributes such as user, resource, purpose, location, or context.

Pseudonymization: Replacing direct identifiers while retaining a controlled possibility of linkage.

Differential privacy: A formal privacy method that limits the effect of any individual record on an output.

Federated learning: Collaborative model training in which data remains at local sites and updates are shared.

Privacy impact assessment: A structured evaluation of privacy risks, safeguards, and residual impacts of processing.

Data sovereignty: The authority of a jurisdiction over data, processing, access, and applicable law.

Algorithmic accountability: The assignment of responsibility and review obligations for algorithm-supported decisions.

Explainability: The extent to which a system’s operation or outputs can be understood by relevant stakeholders.

Fairness: The normative and measurable requirement that analytical systems avoid unjustified differential treatment or impact.

Model drift: A change in data, relationships, or operating conditions that reduces model relevance or performance.

Purpose limitation: The principle that data should be collected and used for specified, legitimate, and compatible purposes.

Responsible analytics: Analytics conducted with attention to legality, security, privacy, fairness, transparency, human agency, and social impact.

Review Questions

Short Answer Questions

1. Distinguish the responsibilities of a data owner, data steward, and data custodian.

2. Why is encryption alone insufficient to guarantee privacy?

3. What is the purpose of a privacy impact assessment?

4. Define algorithmic accountability and explain why it cannot be transferred to software.

5. What is the difference between data residency and data sovereignty?

Long Answer Questions

1. Explain how a risk-based governance model can coordinate data quality, security, privacy, and analytics accountability.

2. Discuss the major privacy-enhancing technologies and the circumstances in which their limitations become significant.

3. Critically evaluate the relationship between fairness metrics, historical bias, and human oversight in high-impact analytics.

4. Design a responsible analytics lifecycle for a system used in healthcare, finance, or public administration.

5. Analyze the organizational requirements for implementing continuous assurance rather than one-time compliance reviews.

Analytical / Application Questions

1. An organization wants to combine employee performance data with location and communication records to predict attrition. Identify the governance, privacy, security, legal, and fairness questions that must be answered before deployment.

2. A credit model has equal approval rates across two groups but a substantially higher false-negative rate for one group. Analyze what this reveals, which further evidence is needed, and what corrective actions might be considered.

3. A multinational company stores analytics data in a cloud region outside the country where it was collected. Develop a decision framework addressing sovereignty, vendor access, encryption keys, transfers, retention, incident response, and exit planning.

22. Multiple Choice Questions with Answers

Question 1

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

A. Data owner

B. Data custodian

C. Network administrator

D. End user

Correct Answer: A. Data owner

Question 2

Why does pseudonymization not necessarily make data non-personal?

A. It always removes analytical value

B. The data may still be linkable to individuals using additional information

C. It prevents encryption from being applied

D. It guarantees public disclosure

Correct Answer: B. The data may still be linkable to individuals using additional information

Question 3

Which control most directly implements the principle of least privilege?

A. Giving all analysts administrator access

B. Granting access according to the minimum permissions required for a task

C. Retaining all accounts indefinitely

D. Disabling audit logs

Correct Answer: B. Granting access according to the minimum permissions required for a task

Question 4

A model has equal selection rates across groups but unequal false-negative rates. What is the most appropriate conclusion?

A. The model is automatically fair

B. The model satisfies every fairness definition

C. One fairness criterion is satisfied, but another relevant disparity remains

D. The model cannot be evaluated statistically

Correct Answer: C. One fairness criterion is satisfied, but another relevant disparity remains

Question 5

Which statement best distinguishes security from privacy?

A. Security concerns protection from threats, while privacy concerns appropriate collection and use of information

B. Privacy applies only to paper records

C. Security eliminates the need for consent

D. They are identical concepts

Correct Answer: A. Security concerns protection from threats, while privacy concerns appropriate collection and use of information

Question 6

What is the primary purpose of data lineage in a machine-learning environment?

A. To hide model inputs from auditors

B. To record origins, transformations, versions, and dependencies for traceability

C. To increase data duplication

D. To replace access controls

Correct Answer: B. To record origins, transformations, versions, and dependencies for traceability

Question 7

A hospital uses a predictive model to prioritize follow-up care. Which practice best represents meaningful human oversight?

A. Clinicians approve every output automatically without reviewing it

B. The model makes irreversible decisions without appeal

C. Authorized clinicians can inspect relevant evidence, override outputs, and escalate concerns

D. The organization removes all performance monitoring after deployment

Correct Answer: C. Authorized clinicians can inspect relevant evidence, override outputs, and escalate concerns

Question 8

Why can consent be an inadequate justification for some analytics projects?

A. Consent can never be withdrawn

B. Consent may be invalid under power imbalance or may not cover incompatible secondary uses

C. Consent prevents all data processing

D. Consent eliminates security obligations

Correct Answer: B. Consent may be invalid under power imbalance or may not cover incompatible secondary uses

Question 9

Which emerging technique allows computation on encrypted data, although often with significant computational limitations?

A. Homomorphic encryption

B. Data deduplication

C. Role-based access control

D. Network segmentation

Correct Answer: A. Homomorphic encryption

Question 10

What is the strongest reason for monitoring a model after deployment?

A. Model behavior and the surrounding data-generating environment can change over time

B. Monitoring guarantees that the original training data was unbiased

C. Monitoring makes legal review unnecessary

D. Deployed models never require retirement

Correct Answer: A. Model behavior and the surrounding data-generating environment can change over time