13. Database Security, Privacy, Ethics and Governance

Introduction and Context

Database systems contain some of an organisation’s most valuable assets: customer identities, financial transactions, health records, intellectual property, employee information, operational data, and analytical models. Their value also makes them attractive targets for theft, manipulation, misuse, and accidental disclosure. Database security is therefore not limited to installing a firewall or assigning passwords. It is a continuing organisational capability that combines technology, people, processes, law, and ethical judgement.

Security protects data and database services from unauthorised access, alteration, destruction, and interruption. Privacy concerns the appropriate collection, use, disclosure, storage, and deletion of information relating to identifiable individuals. Ethics addresses what organisations ought to do, including situations where an action may be technically legal but unfair or harmful. Governance provides the structures through which responsibilities, policies, controls, risk decisions, and accountability are established.

For data science professionals, these concerns are especially important. Data scientists often combine datasets, create derived attributes, use automated decision systems, and transfer data across platforms. A technically accurate model can still be unacceptable if its data was collected without meaningful consent, if it exposes sensitive information, or if its decisions cannot be explained or challenged. Database security, privacy, ethics, and governance must therefore be treated as design requirements rather than activities added after implementation.

Learning Objectives

After studying this chapter, students should be able to:

1. Explain the relationship between database security, privacy, ethics, and governance.

2. Apply authentication, authorisation, role-based access control, encryption, masking, auditing, and secure coding practices.

3. Design controls based on least privilege, separation of duties, defence in depth, and risk.

4. Evaluate privacy issues involving consent, purpose limitation, retention, ownership, sharing, and individual rights.

5. Analyse regulatory and governance requirements in organisational database environments.

6. Identify ethical risks in data collection, analytics, profiling, and automated decision-making.

7. Recommend practical controls and governance mechanisms for professional case situations.

The Security, Privacy and Governance Landscape

A useful starting point is the information-security triad of confidentiality, integrity, and availability. Confidentiality means that information is disclosed only to authorised parties. Integrity means that data remains accurate, complete, and protected from unauthorised modification. Availability means that authorised users can access data and services when required. These objectives may conflict. For example, highly restrictive access controls may protect confidentiality but make emergency healthcare access difficult. Governance is needed to make and document such trade-offs.

Database security has several layers. Physical security protects servers, storage devices, and backup media. Network security controls connections between users, applications, database servers, and cloud services. Database-level security manages accounts, privileges, views, encryption, auditing, and configuration. Application security prevents vulnerable code from allowing unintended database operations. Organisational security includes policies, staff training, incident response, vendor management, and independent review.

Privacy is broader than secrecy. Information may be private even when it is not confidential in the traditional sense. Privacy includes control over how personal information is collected and used, whether the purpose is legitimate and transparent, and whether the processing is proportionate. A dataset can be publicly available and still create privacy harm when combined with other datasets to infer a person’s location, health condition, income, or behaviour.

Ethics provides a normative perspective. It asks whether a practice respects autonomy, avoids unjustified harm, distributes benefits and burdens fairly, and supports accountability. Governance converts these principles into decisions, responsibilities, standards, approval processes, monitoring, and corrective action.

Important Concepts and Terminology

A principal is a user, application, service, or process that requests access to a resource. Authentication verifies the claimed identity of a principal, while authorisation determines what that principal is permitted to do. An entitlement is a specific permitted action, such as reading a table or executing a stored procedure. A privilege is a database permission granted directly or through a role.

A threat is a potential cause of harm, such as a malicious insider or ransomware. A vulnerability is a weakness that may be exploited. Risk combines the likelihood of an adverse event with its potential impact. An asset is something of value requiring protection. An audit trail is a record of relevant activities that supports accountability and investigation.

Personal data is information relating to an identified or identifiable person. Sensitive personal data generally requires stronger protection because misuse may cause serious harm; examples can include health, biometric, financial, or highly personal information, depending on applicable law. A data controller or equivalent organisation determines why and how personal data is processed, whereas a processor acts on behalf of another organisation in many regulatory frameworks.

Data ownership describes decision rights and responsibilities over information, although legal ownership may vary by jurisdiction and contract. A data steward manages quality, definitions, access, and lifecycle practices for a data domain. Data lineage records where data originated, how it was transformed, and where it is used. Data minimisation means collecting and retaining only what is necessary for a legitimate purpose.

A Risk-Based Security Architecture

Security controls should be selected according to risk rather than applied as isolated technical features. A risk assessment identifies assets, threats, vulnerabilities, business impacts, legal obligations, and existing controls. The organisation then decides whether to avoid, reduce, transfer, or accept each risk. Risk acceptance should be explicit and approved by an accountable authority; it should not arise merely because a weakness was ignored.

The principle of least privilege states that a subject should receive only the permissions necessary for its legitimate work, for only as long as necessary. Separation of duties prevents one person or process from controlling an entire sensitive transaction. Defence in depth uses multiple independent controls so that failure of one control does not expose the whole system. Secure defaults deny access unless it has been deliberately granted. Fail-safe design avoids revealing sensitive information when an error occurs.

A typical database security architecture separates development, testing, and production environments; places databases behind controlled network zones; restricts administrative interfaces; uses centrally managed identities; encrypts sensitive traffic and storage; monitors high-risk operations; and maintains tested backups. Cloud databases add responsibilities involving identity and access management, provider configuration, key ownership, network endpoints, logging, and shared-responsibility boundaries.

Identity, Access and Authorisation

Authentication may use passwords, certificates, hardware tokens, authenticator applications, biometrics, or combinations of these. Multi-factor authentication requires two or more independent factors, such as something the user knows and something the user possesses. Passwords should be stored using a suitable slow, salted one-way hashing scheme rather than reversible encryption or plaintext. Administrative and service accounts require particular attention because compromise may provide broad access.

Authorisation should be centralised and reviewed. Directly granting numerous privileges to individual accounts creates complexity and makes removal difficult. Role-based access control (RBAC) groups permissions into job-related roles, such as claims examiner, data analyst, database administrator, or auditor. Users receive roles according to their duties. A mature implementation may include hierarchical roles, temporary privilege elevation, approval workflows, and constraints that prevent conflicting roles from being assigned together.

RBAC is not a substitute for careful design. Roles that are too broad undermine least privilege, while excessive role proliferation becomes difficult to administer. Attribute-based access control (ABAC) can supplement RBAC by evaluating attributes such as department, location, data classification, purpose, time, or device trust. For example, an analyst may access de-identified research data but not identifiable customer records, and a support employee may access a customer record only while handling an assigned case.

Views and stored procedures can expose only the rows and columns required by an application. Row-level security can enforce restrictions for individual records, while column-level controls protect especially sensitive attributes. Privileges should be reviewed periodically, after job changes, and immediately when employment or contractual access ends. Emergency or break-glass access should be time-limited, justified, logged, and reviewed afterwards.

Encryption, Masking and Data Protection

Encryption transforms readable data into ciphertext using a cryptographic key. Encryption in transit protects communication between clients, applications, and databases, usually through appropriately configured secure protocols. Encryption at rest protects database files, backups, snapshots, and storage media if those assets are obtained by an unauthorised party. Encryption does not automatically prevent an authorised but malicious user from reading data through the application.

Key management is as important as the encryption algorithm. Keys should have controlled access, defined ownership, rotation procedures, backup and recovery arrangements, and separation from the data they protect. A key-management service or hardware security module may be used for high-value environments. Loss of a key can make data permanently inaccessible, while uncontrolled copies of keys can defeat the intended protection.

Data masking hides sensitive values for display or use. Static masking creates a protected copy for development or testing. Dynamic masking changes what a user sees at query time while preserving the underlying value for authorised operations. Tokenisation replaces a sensitive value with a surrogate token and stores the mapping separately. Pseudonymisation replaces direct identifiers but may still permit re-identification if additional information is available. Anonymisation aims to make re-identification reasonably infeasible, although it is difficult to guarantee when multiple datasets can be linked.

Masking should be evaluated against realistic inference attacks. Removing names does not necessarily anonymise a dataset if rare combinations of age, location, occupation, and date can identify individuals. Privacy-preserving techniques such as aggregation, generalisation, suppression, differential privacy, and secure multiparty computation may be appropriate for particular analytical contexts, but each introduces utility, complexity, or accuracy trade-offs.

Auditing, Monitoring and Secure Coding

Auditing creates evidence about who accessed or changed data, what action occurred, when it occurred, through which application or device, and whether it succeeded. High-value events may include privilege changes, access to sensitive records, bulk exports, failed logins, schema changes, and modifications to audit configuration. Logs should be protected from tampering, time-synchronised, retained according to policy, and reviewed through alerts or periodic analysis.

Audit data itself may contain sensitive information and must therefore be access-controlled. Excessive logging can create cost, performance, and privacy problems. The objective is not to record everything indiscriminately, but to record events that support accountability, detection, investigation, compliance, and service improvement.

Secure database coding begins with parameterised queries or prepared statements. Constructing SQL by concatenating untrusted input creates injection vulnerabilities, which may permit unauthorised reading, modification, or deletion. Input validation, output encoding, safe error handling, and restricted database accounts provide additional protection. Applications should avoid exposing detailed database errors to users, should use secure session management, and should not embed credentials in source code.

Stored procedures can reduce exposure when carefully designed, but they are not inherently secure. Dynamic SQL within a procedure can still be vulnerable. Database drivers, operating systems, extensions, and third-party components require patch management. Backups must be encrypted, access-controlled, tested for restoration, and protected against ransomware through suitable isolation or immutability.

Privacy by Design and the Data Life Cycle

Privacy should be considered throughout the data life cycle: collection, ingestion, storage, use, sharing, archival, and deletion. Privacy by design incorporates privacy safeguards into architecture and default settings. A privacy impact assessment can identify affected individuals, purposes, data flows, risks, mitigations, and residual concerns before a new system is deployed.

Collection should have a specified and legitimate purpose. Notice should explain what is collected, why it is needed, how long it will be retained, with whom it may be shared, and what choices or rights individuals have. Consent, where relied upon, should be informed, specific, freely given, and withdrawable where applicable. Consent is not always the only lawful basis for processing, and organisations must not treat a vague acceptance of general terms as meaningful consent for unrelated secondary uses.

Purpose limitation prevents data collected for one reason from being silently repurposed. A retail loyalty dataset, for example, may support rewards administration but not automatically justify sensitive employment screening. Data minimisation reduces exposure and improves governance. Retention schedules should reflect legal requirements, operational necessity, archival value, and the cost of secure storage. Deletion should include derived copies, temporary files, replicas, and backups where feasible, while recognising that legal holds may require preservation.

Individuals may have rights concerning access, correction, deletion, portability, objection, or review of automated decisions, depending on the applicable jurisdiction and context. Organisations need procedures to authenticate requests, locate relevant records, respond within required periods, and protect the rights of other individuals. Cross-border transfers may require contractual, technical, or organisational safeguards.

Ethics, Fairness and Responsible Data Use

Ethical data practice requires more than regulatory compliance. A lawful use may still be unfair, excessive, discriminatory, or inconsistent with reasonable expectations. Important ethical questions include: Did individuals reasonably understand the use? Could the processing cause physical, financial, psychological, or reputational harm? Are benefits and risks distributed fairly? Can affected people contest an outcome? Is the organisation collecting information merely because it can?

Data quality and representativeness influence fairness. Historical data may reproduce unequal treatment, while missing data may disadvantage particular groups. Proxy variables can encode protected characteristics indirectly. A database or model that excludes certain populations may produce apparently efficient but systematically harmful decisions. Fairness assessment should examine relevant groups, error types, data provenance, and the consequences of false positives and false negatives.

Explainability and accountability are particularly important in high-impact decisions such as credit, employment, insurance, education, and healthcare. Explanations should be meaningful to the affected person and useful for correction, not merely technical descriptions of an algorithm. Human review must be genuine rather than a ceremonial approval of automated results.

Professional judgement also matters when data scientists combine records from different contexts. Data linkage can create new sensitive information that no source dataset revealed alone. Ethical review, data-access committees, documented assumptions, model cards or data sheets, and stakeholder consultation can help identify these risks.

Governance Frameworks and Organisational Responsibilities

Database governance establishes who may decide, who must perform an action, who is consulted, and who is informed. A governance structure commonly includes executive sponsorship, a security or risk committee, privacy leadership, information-security personnel, data owners, data stewards, database administrators, application owners, legal advisers, and internal audit. Responsibilities should be documented rather than assumed.

A data classification scheme may distinguish public, internal, confidential, and restricted information. Each class should have rules for access, encryption, sharing, retention, disposal, and incident handling. Policies are effective only when translated into technical controls and measurable procedures. Examples include access-review completion rates, time to revoke departed-user accounts, unresolved critical vulnerabilities, restoration-test success, and the proportion of sensitive databases with centralised logging.

Governance frameworks such as the NIST Cybersecurity Framework, ISO/IEC 27001, COBIT, and privacy-management frameworks can provide structured approaches to identifying, protecting, detecting, responding, recovering, and improving. They do not eliminate the need for context-specific judgement. Regulatory obligations differ by jurisdiction and sector, but commonly address lawful processing, security safeguards, breach response, individual rights, records management, and accountability. Organisations should obtain qualified legal advice when interpreting specific laws.

Incident response should define preparation, detection, analysis, containment, eradication, recovery, notification, and lessons learned. A suspected database breach should not be handled by quietly deleting evidence. Investigation requires preservation of logs, coordinated communication, technical containment, assessment of affected records, and legally appropriate notifications. Post-incident review should address systemic causes rather than assigning blame only to an individual.

Applied Case: Meridian Health Analytics

Background

Meridian Health Analytics is an illustrative regional healthcare organisation operating hospitals and outpatient clinics. It stores patient identity records, clinical notes, diagnostic results, billing information, and de-identified datasets used by an internal research team. The organisation plans to create a predictive system to identify patients at high risk of readmission.

Situation and Problem

An analyst requests a full production extract for model development because the research environment lacks several fields. The extract includes names, addresses, detailed diagnoses, insurance numbers, and free-text clinical notes. A database administrator grants the analyst broad read access using an existing reporting role. The extract is copied to a cloud workspace, where a developer discovers that database credentials are stored in a configuration file. Audit logs record successful logins but not individual record exports. Later, a patient asks why information collected during treatment was used for a prediction system.

Analysis

The organisation faces confidentiality, privacy, security, and ethical risks. The reporting role violates least privilege because it grants more data than the modelling task requires. The clinical notes and insurance numbers are not justified merely because they are available. The cloud copy creates a new data location and possible cross-border or contractual issues. Credentials in a configuration file create a technical vulnerability. Inadequate export logging weakens accountability and incident investigation. Finally, the patient’s question reveals a purpose-transparency problem: treatment data has been used for a secondary analytical purpose without an adequately communicated governance process.

Approach and Strategy

Meridian should first suspend unnecessary access and preserve relevant evidence. A data protection and security review should define the model’s purpose, required variables, lawful and ethical basis, affected populations, retention period, and acceptable uses. The research environment should receive a minimised dataset, with direct identifiers removed or replaced by controlled tokens. Free-text notes should be excluded unless a documented need and stronger safeguards exist.

A separate research role should provide only the necessary tables, columns, and rows. Row- and column-level controls, multi-factor authentication, and time-limited approval should be applied. Data should be encrypted in transit and at rest, with keys managed separately. Secrets should be stored in a managed secrets service rather than source files. Export events, privileged queries, and access to sensitive fields should be logged and reviewed.

Before deployment, Meridian should assess data quality and performance across relevant patient groups. Model documentation should state intended use, limitations, training-data characteristics, and human-review requirements. Patients should receive a clear explanation of relevant secondary uses, and the organisation should establish procedures for correction, complaints, and review of high-impact predictions. A retention schedule should require deletion of temporary extracts and obsolete model-training copies.

Outcome

The revised design reduces exposure while preserving analytical value. The research team receives only the variables needed for the approved purpose, and access is periodically reviewed. Meridian can demonstrate who accessed the data and why. The model is not treated as an autonomous clinical decision-maker; clinicians use it as one input and can challenge its recommendations. The organisation also identifies a broader need for a data-access committee and a formal catalogue of sensitive data assets.

Learning Points

The case illustrates that security controls, privacy safeguards, ethical review, and governance are interdependent. A technically functioning database may still be poorly governed. Minimisation is often more effective than attempting to secure unnecessary copies of data. Finally, transparency and human accountability are essential when analytical systems affect people’s health or opportunities.

Challenges, Limitations and Common Mistakes

One common mistake is treating compliance certification as proof of security. Frameworks and audits provide structure, but controls may be ineffective if passwords are shared, alerts are ignored, or access reviews are completed mechanically. Another mistake is relying on encryption while leaving excessive authorised access unexamined. Encryption protects stored assets under particular threat conditions; it does not solve misuse by legitimate accounts.

Organisations also underestimate non-production environments, spreadsheets, screenshots, exports, data lakes, and backups. These copies often escape central controls. Excessive privileges accumulate over time because access is granted quickly but rarely removed. Service accounts may have permanent administrative rights and no clear owner. Logging may be enabled but not monitored, producing an illusion of oversight.

Privacy programmes can fail through vague purposes, indefinite retention, ambiguous consent, or ineffective anonymisation. De-identification is not a single binary operation; re-identification risk depends on available auxiliary data, attacker capability, and context. Automated fairness assessments may also be misleading if the selected metrics do not reflect the real harms of the application.

Security and privacy controls may create operational friction. Strong controls can delay legitimate work, reduce analytical utility, or make emergency access difficult. These trade-offs should be managed through risk assessment, exception procedures, usability testing, and continuous improvement rather than by abandoning controls.

Current Developments and Emerging Directions

Modern data platforms increasingly use cloud-native databases, data warehouses, lakehouses, application programming interfaces, and distributed analytics. This increases the number of identities, copies, interfaces, and jurisdictions requiring governance. Data security posture management tools can discover assets, identify misconfigurations, map sensitive data, and support continuous control monitoring, but automated findings still require human prioritisation.

Confidential computing, hardware-backed key protection, privacy-enhancing technologies, federated learning, and differential privacy are being explored for situations in which data should remain distributed or hidden during processing. Synthetic data can support testing and experimentation, but it may reproduce biases or leak characteristics of the source population and therefore requires validation.

Generative artificial intelligence introduces new database risks. Sensitive records may be exposed through prompts, retrieval systems, logs, or model-training pipelines. Organisations need controls for data provenance, retrieval permissions, prompt and output monitoring, retention, model access, and human review. AI governance should connect security and privacy controls with transparency, risk classification, accountability, and testing for harmful outcomes.

Best Practices for Professional Implementation

A practical programme should begin with an inventory of databases, data flows, owners, classifications, and dependencies. It should then establish identity governance, least-privilege roles, strong authentication, secure configuration baselines, encryption and key management, protected backups, parameterised queries, patching, and centralised monitoring. Access should be approved according to business need, reviewed regularly, and revoked promptly.

Privacy should be built into requirements through purpose specification, minimisation, impact assessment, retention controls, transparent notices, and mechanisms for individual requests. Ethical review should address affected stakeholders, fairness, explainability, proportionality, and avenues for challenge. Governance should assign accountable owners, define measurable controls, test incident and recovery procedures, and document exceptions.

The most mature organisations treat security and privacy as continuous capabilities. They test controls, conduct independent assessments, learn from incidents, rehearse recovery, and update policies as technology and law change. Effective governance is not an obstacle to data science; it is what makes data use trustworthy, sustainable, and defensible.

Chapter Summary

Database security protects confidentiality, integrity, and availability through layered technical and organisational controls. Authentication verifies identity, authorisation grants permitted actions, and RBAC or ABAC helps align access with business duties and context. Least privilege, separation of duties, encryption, masking, secure coding, auditing, backup protection, and incident response form important elements of a risk-based architecture.

Privacy concerns appropriate collection and use throughout the data life cycle. Purpose limitation, minimisation, consent or another valid basis, retention control, transparency, individual rights, and careful de-identification reduce privacy risk. Ethics extends beyond legal compliance by examining fairness, autonomy, harm, accountability, and reasonable expectations. Governance assigns responsibilities, establishes classifications and policies, measures control performance, and connects organisational decisions with regulatory and professional obligations. The central lesson is that trustworthy database management requires security, privacy, ethical judgement, and governance to be designed together.

Key Terms

Authentication: Verification of the identity of a user, application, or service.

Authorisation: Determination of the actions a verified principal is permitted to perform.

Audit trail: Protected record of activities used for accountability, monitoring, and investigation.

Data minimisation: Collection and retention of only the information necessary for a legitimate purpose.

Data steward: Person responsible for managing data definitions, quality, access, and lifecycle practices.

Differential privacy: A mathematical approach that limits what can be inferred about an individual from published results.

Encryption: Transformation of readable data into ciphertext using a cryptographic key.

Least privilege: Granting only the minimum access needed for an authorised task.

Masking: Hiding or transforming sensitive values from users or environments that do not require the originals.

Multi-factor authentication: Authentication requiring two or more independent categories of evidence.

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

Pseudonymisation: Replacement of direct identifiers with substitutes while retaining a possibility of re-identification.

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

Role-based access control: Access management in which permissions are assigned to job-related roles.

Separation of duties: Division of sensitive responsibilities among different people or processes.

Threat: Potential cause of an unwanted event or harm.

Tokenisation: Replacement of sensitive data with a surrogate token whose mapping is separately protected.

Vulnerability: Weakness that may be exploited by a threat.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorisation.

2. What are the three objectives of the information-security triad?

3. Explain the principle of least privilege in a database environment.

4. Why is encryption alone insufficient to ensure database security?

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

Long Answer Questions

1. Explain how RBAC, ABAC, views, and row-level security can be combined to control access to sensitive data.

2. Discuss the role of encryption, key management, masking, tokenisation, and pseudonymisation in protecting database information.

3. Describe how privacy should be managed across the data life cycle from collection to deletion.

4. Analyse the relationship between database security, privacy, ethics, and governance.

5. Explain the major stages of incident response and the organisational responsibilities associated with them.

Analytical / Application Questions

1. A data analyst requests a complete production database for a forecasting project. Design a secure and privacy-preserving alternative, including access, minimisation, masking, monitoring, and retention controls.

2. A bank uses an automated system to reject loan applications. Propose a governance and ethical review process addressing data quality, fairness, explainability, human review, and individual challenge.

3. An organisation discovers that a former employee’s account remains active and has accessed confidential records. Analyse the immediate response, evidence requirements, risk assessment, notifications, and long-term preventive measures.

22. Multiple Choice Questions with Answers

Question 1

A database analyst needs access to regional sales totals but not customer identities or transaction-level records. Which control most directly follows the principle of least privilege?

A. Granting the analyst database administrator privileges

B. Providing an aggregated view containing only required regional totals

C. Encrypting the entire database while granting unrestricted access

D. Allowing access through a shared reporting account

Correct Answer: B. Providing an aggregated view containing only required regional totals

Question 2

Which statement best distinguishes privacy from confidentiality?

A. Privacy concerns only encryption, while confidentiality concerns data quality

B. Privacy concerns appropriate collection and use, while confidentiality concerns limiting unauthorised disclosure

C. Privacy applies only to public data, while confidentiality applies only to personal data

D. Privacy and confidentiality are identical concepts

Correct Answer: B. Privacy concerns appropriate collection and use, while confidentiality concerns limiting unauthorised disclosure

Question 3

An organisation wants to prevent one employee from both creating a supplier and approving payment to that supplier. Which principle is most relevant?

A. Data minimisation

B. Purpose limitation

C. Separation of duties

D. Dynamic masking

Correct Answer: C. Separation of duties

Question 4

Why is storing database passwords in application source code a serious security weakness?

A. Source code cannot execute SQL queries

B. Anyone who gains inappropriate access to the code may obtain reusable credentials

C. Passwords in source code are automatically encrypted by the database

D. It prevents all users from authenticating

Correct Answer: B. Anyone who gains inappropriate access to the code may obtain reusable credentials

Question 5

Which practice best reduces SQL injection risk?

A. Concatenating user input into SQL strings

B. Displaying detailed database errors to users

C. Using parameterised queries and restricted database accounts

D. Giving the application administrative privileges

Correct Answer: C. Using parameterised queries and restricted database accounts

Question 6

A company removes names from a dataset but leaves exact dates, rare occupations, and detailed locations. What is the principal concern?

A. The data is necessarily encrypted

B. The remaining attributes may permit re-identification through linkage

C. The dataset cannot be used for analysis

D. Removing names violates availability

Correct Answer: B. The remaining attributes may permit re-identification through linkage

Question 7

Which activity is most closely associated with data governance?

A. Assigning accountability for data ownership, classification, access, and lifecycle decisions

B. Replacing every database with a spreadsheet

C. Disabling all audit logs to improve performance

D. Allowing each analyst to define retention independently

Correct Answer: A. Assigning accountability for data ownership, classification, access, and lifecycle decisions

Question 8

A hospital uses treatment records to build a prediction system for a different purpose. Which question is most important for privacy and ethics review?

A. Whether the database has enough tables

B. Whether the secondary use is transparent, justified, proportionate, and appropriately safeguarded

C. Whether the model uses the newest programming language

D. Whether all records can be copied to a personal device

Correct Answer: B. Whether the secondary use is transparent, justified, proportionate, and appropriately safeguarded

Question 9

Which statement about audit logs is most accurate?

A. They should record relevant high-risk activities and be protected from tampering

B. They should be accessible to every database user

C. They eliminate the need for access controls

D. They should never record privilege changes

Correct Answer: A. They should record relevant high-risk activities and be protected from tampering

Question 10

A cloud database is secure in transit and at rest, but a broad analyst role permits unrestricted bulk exports. What is the most appropriate conclusion?

A. The database has no security risk because encryption is enabled

B. Encryption is useless in every situation

C. Authorised access and export controls remain necessary despite encryption

D. Audit logs are unnecessary when data is encrypted

Correct Answer: C. Authorised access and export controls remain necessary despite encryption