Big Data & Data-Driven Strategy

Chapter 11
Data Governance, Security and Privacy

Advance Diploma in Business Analytics
Big Data & Data-Driven Strategy   •   Advance Diploma

Data Governance, Security and Privacy

Introduction

Data has become a strategic asset for organisations using analytics, artificial intelligence, digital platforms and real-time decision systems. However, data creates value only when it is trustworthy, accessible to authorised users, protected from misuse and managed throughout its life cycle. Poorly governed data produces inconsistent reports, biased models, regulatory exposure, security incidents and loss of stakeholder confidence.

Data governance is therefore not merely an information-technology activity. It is an organisational system of decision rights, accountability, standards, processes and controls that determines how data is created, described, accessed, used, shared, retained and destroyed. Data security protects confidentiality, integrity and availability. Data privacy protects people in relation to the collection and use of information about them. These disciplines overlap, but they are not identical: security concerns protection from unauthorised or harmful access, whereas privacy concerns legitimate, fair and responsible processing of personal information.

For a business analyst, governance is strategically important because analytical conclusions are only as reliable as the data and controls supporting them. A sophisticated model built on duplicated customer records, unclear definitions or unlawfully obtained data remains an organisational liability.

Learning objectives

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

  • explain the purpose and scope of data governance;
  • design roles for ownership, stewardship and custodianship;
  • establish data standards, catalogues, quality controls and retention rules;
  • apply access-control and cybersecurity principles;
  • distinguish privacy from security and explain privacy-by-design;
  • interpret major data-protection principles and compliance obligations;
  • evaluate governance risks in analytics and artificial-intelligence projects; and
  • recommend an implementable governance structure for an organisation.

1. The governance problem in data-driven organisations

Data is commonly distributed across enterprise applications, cloud platforms, spreadsheets, APIs, data warehouses, data lakes and external suppliers. Each system may use different identifiers, formats and definitions. For example, “active customer” might mean a customer who purchased in the past 30 days in one system and one who has an open account in another. Without agreed definitions, two departments can produce apparently precise but contradictory performance indicators.

Governance addresses six fundamental questions:

  1. What data exists?
  2. Who is accountable for it?
  3. What does it mean?
  4. Who may use it and for what purpose?
  5. How can its quality and security be demonstrated?
  6. When should it be archived or deleted?

A useful governance principle is that accountability should follow business responsibility. Technology teams operate platforms, but business leaders usually understand the meaning, risks and acceptable uses of the data. Governance must therefore connect executive decision-making, operational processes, analytics and technical controls.

2. A governance operating model

A practical operating model combines central direction with distributed responsibility.

2.1 Governance bodies

A data governance council or committee establishes policy, resolves cross-functional disputes and prioritises investment. It normally includes business executives, information-technology leadership, legal or compliance representatives, security specialists and data leaders.

A data office coordinates standards, maintains the governance roadmap, supports stewards and monitors performance. In smaller organisations, these activities may be assigned to a chief data officer or a cross-functional team.

Domain forums address subject-specific issues such as customer, finance, employee, product or supply-chain data. They are useful because governance decisions often depend on operational context.

2.2 Core roles

RoleMain accountability
Data ownerDefines business accountability, risk tolerance, access rules and quality expectations for a data domain
Data stewardApplies definitions, standards, quality procedures and issue resolution in daily operations
Data custodianOperates storage, platforms, backups, technical access and security controls
Data protection officer or privacy leadAdvises on privacy obligations, rights, assessments and regulatory communication where required
Data consumerUses data according to approved purposes, controls and professional standards
Internal audit or assuranceIndependently evaluates whether controls operate effectively

Ownership does not mean that one executive personally edits every record. It means that the owner has authority and accountability for decisions about the domain. Stewardship translates those decisions into operational practice. Custodianship concerns technical management.

2.3 Decision rights

A governance charter should specify who may approve:

  • data definitions and critical data elements;
  • access to sensitive or personal data;
  • external data sharing;
  • retention and deletion exceptions;
  • changes to master data;
  • new analytical uses or model features; and
  • responses to data-quality and security incidents.

A RACI matrix can clarify whether a role is Responsible, Accountable, Consulted or Informed. One person may be responsible for performing a task, but accountability should normally be assigned to one clearly identified role.

3. Data standards, metadata and catalogues

3.1 Data standards

Standards create consistency across systems. They may specify:

  • naming conventions and business definitions;
  • data types, formats and permitted values;
  • units of measurement and currency rules;
  • identifier and reference-data conventions;
  • validation and reconciliation rules;
  • classification labels;
  • lineage and documentation requirements; and
  • interoperability requirements for APIs and shared datasets.

A standard should be precise enough to implement and flexible enough to remain useful. For example, a date standard should distinguish calendar date, timestamp, time zone and business date rather than merely stating “use a standard date.”

3.2 Metadata

Metadata is data about data. Business metadata explains meaning, ownership and permitted use. Technical metadata describes schemas, fields, data types, interfaces and storage locations. Operational metadata records refresh times, processing status, volumes, failures and quality results. Lineage metadata shows where data originated, how it was transformed and which reports or models depend on it.

3.3 Data catalogues

A data catalogue is an organised inventory of datasets and their metadata. A useful catalogue allows a user to search for a dataset, read its definition, identify the owner, inspect quality indicators, understand sensitivity, trace lineage and request access.

A catalogue is not automatically a governance programme. If entries are incomplete, outdated or disconnected from access workflows, the catalogue becomes a passive directory. It should be integrated with data discovery, classification, approval and monitoring processes.

3.4 Master and reference data

Master data represents important business entities such as customers, suppliers, products and locations. Reference data consists of controlled values such as country codes, currencies, account categories or risk ratings. A master-data programme establishes authoritative sources, matching rules, survivorship rules and processes for resolving duplicates.

For example, if three systems contain different customer addresses, governance must determine which source is authoritative for billing, delivery and marketing. There may be more than one legitimate source, but the purpose of each source must be explicit.

4. Data quality and accountability

Data quality is fitness for a defined use, not an abstract property. Common dimensions include:

  • accuracy: closeness to the real-world value;
  • completeness: required values are present;
  • validity: values conform to rules or permitted domains;
  • consistency: related records and systems do not conflict;
  • timeliness: data is available and current when needed;
  • uniqueness: entities are not unnecessarily duplicated; and
  • integrity: relationships and constraints remain reliable.

A simple completeness rate for a field can be expressed as:

Completeness = (Number of non-missing required values ÷ Total required values) × 100%

The formula assumes that records and required fields have been correctly identified. It measures presence, not accuracy or suitability. A field containing an incorrect but non-missing value will count as complete.

For example, if 9,600 of 10,000 required customer email values are present, completeness is 96%. This does not establish that the addresses are valid, belong to the correct customers or have been collected lawfully.

Quality controls should be risk-based. A minor formatting defect in an internal description may have little consequence, while one incorrect digit in a payment account or medical identifier can be critical. Data-quality issues should have owners, severity levels, target resolution times and documented root-cause analysis.

5. Access governance and cybersecurity

5.1 The security objectives

The classic CIA triad consists of:

  • Confidentiality: information is not disclosed to unauthorised parties;
  • Integrity: information and systems are accurate, complete and protected from unauthorised alteration; and
  • Availability: authorised users can access systems and data when required.

Additional objectives include authenticity, accountability, resilience and non-repudiation.

5.2 Identity and access management

Access should be based on a documented business need. Important controls include:

  • unique user identities;
  • multi-factor authentication for sensitive access;
  • role-based or attribute-based permissions;
  • least privilege;
  • segregation of duties;
  • periodic access reviews;
  • privileged-access management;
  • time-limited access for contractors; and
  • prompt removal of access when employment or responsibilities change.

Role-based access control grants permissions through job roles. Attribute-based access control evaluates attributes such as department, location, data classification, device posture, time and purpose. The latter can express more context-sensitive policies but may be more complex to design and govern.

Least privilege means granting only the access necessary for an approved task. It does not mean that everyone should receive access to an entire database because some fields are useful. Field-level masking, tokenisation, row-level security and controlled analytical views can reduce exposure.

5.3 Defence in depth

Security should not rely on one control. Defence in depth combines secure configuration, encryption in transit and at rest, network segmentation, endpoint protection, vulnerability management, backups, logging, monitoring, incident response and staff awareness.

Encryption protects confidentiality when correctly implemented, but it does not solve all governance problems. Poor key management, excessive user privileges, compromised endpoints or authorised misuse can still expose data. Logs should be protected from unauthorised alteration and reviewed for meaningful indicators rather than collected without operational purpose.

5.4 Incident management

An incident-management process should identify, contain, eradicate, recover from and learn from security events. It should define escalation thresholds, evidence preservation, communications, regulatory assessment and post-incident review. Organisations must know in advance which events constitute a personal-data breach and which authorities or affected individuals may need notification under applicable law.

6. Privacy and data-protection principles

Privacy is concerned with how information about identifiable or identifiable individuals is collected, used, disclosed, retained and deleted. Definitions and obligations differ by jurisdiction, sector and context. Organisations must obtain current legal advice rather than assuming that one framework applies universally.

Major data-protection regimes commonly express principles such as the following:

  1. Lawfulness, fairness and transparency: processing must have a valid legal basis, must not be deceptive or unjust, and individuals should receive understandable information.
  2. Purpose limitation: data collected for one purpose should not be reused for incompatible purposes without a valid justification.
  3. Data minimisation: collect and use only what is adequate, relevant and necessary.
  4. Accuracy: take reasonable steps to keep personal data accurate and correct errors.
  5. Storage limitation: retain information only as long as justified by purpose, law or documented business need.
  6. Integrity and confidentiality: apply appropriate technical and organisational security.
  7. Accountability: be able to demonstrate compliance through policies, records, assessments, controls and evidence.

Depending on the jurisdiction, individuals may have rights of access, correction, deletion, restriction, objection, portability and protection from certain solely automated decisions. These rights may have lawful exceptions and procedural limits.

6.1 Legal basis and consent

Consent is not the only possible legal basis for processing. Depending on the applicable law, bases may include contract, legal obligation, protection of vital interests, public task or legitimate interests. Consent should be informed, specific, freely given and withdrawable where the law requires these conditions. An organisation should not use consent as a convenient substitute for analysing whether the processing is genuinely necessary and fair.

6.2 Sensitive data and high-risk processing

Some categories, such as health, biometric, genetic, financial, precise location or children’s information, may attract heightened protection. High-risk processing may require a privacy or data-protection impact assessment. Such an assessment should describe the processing, evaluate necessity and proportionality, identify risks to individuals and specify mitigations.

6.3 Anonymisation and pseudonymisation

Anonymisation aims to make re-identification reasonably infeasible, taking account of available data and realistic means. It is difficult to achieve permanently, particularly when datasets can be linked. Pseudonymisation replaces direct identifiers with codes, but a separate key or other information can restore identity; therefore, pseudonymised data generally remains personal data where re-identification is possible.

Removing names alone is not sufficient if combinations such as postcode, age and event date can identify individuals. Privacy risk should be assessed against linkage, singling-out and inference risks.

7. Privacy-by-design and by-default

Privacy-by-design integrates privacy into the architecture and life cycle of a product or analytical solution rather than adding a notice after implementation. Its practical principles include:

  • proactive prevention rather than reactive correction;
  • privacy as a default setting;
  • privacy embedded in system design;
  • full functionality without unnecessary data collection;
  • end-to-end protection across the information life cycle; and
  • visibility, transparency and respect for user interests.

A privacy-by-design workflow can be applied as follows:

  1. Define the business purpose and expected benefit.
  2. Identify affected individuals, data elements and processing activities.
  3. Test necessity and proportionality: can the objective be achieved with less data or lower sensitivity?
  4. Establish lawful basis, notices, consent mechanisms and rights procedures.
  5. Classify data and specify access, retention, deletion and sharing controls.
  6. Assess re-identification, discrimination, security and misuse risks.
  7. Build privacy-enhancing measures such as aggregation, masking, separation, minimisation and controlled environments.
  8. Test the design, document decisions and monitor after deployment.

Privacy-enhancing technologies may include encryption, secure multiparty computation, differential privacy, federated learning and trusted execution environments. Their suitability depends on the use case. For example, statistical privacy techniques may reduce disclosure risk but can reduce analytical accuracy; the trade-off must be evaluated rather than assumed away.

8. Retention, records and deletion

Retention is a governance decision balancing legal requirements, operational need, historical value, cost and privacy risk. A retention schedule should identify the record category, owner, retention trigger, retention period, disposal method and legal hold process.

A legal hold suspends ordinary deletion when litigation, investigation or regulatory action is reasonably anticipated. Deletion should cover live systems, derived datasets, temporary files, backups where technically and legally feasible, and copies held by processors. Organisations should distinguish deletion from merely removing a record from a user interface.

Long retention is not automatically safer. Old personal data increases exposure, may become inaccurate and can enable harmful profiling. Conversely, premature deletion can undermine financial records, auditability, scientific reproducibility or legal obligations. Retention rules should therefore be documented and reviewed.

9. Governance across the analytics and AI life cycle

Governance must extend beyond source databases. Analytics projects should document data acquisition, consent or legal basis, transformations, feature engineering, labels, model versions, validation data, users, outputs and monitoring responsibilities.

Important controls include:

  • provenance and lineage for training and evaluation data;
  • representativeness and bias assessment;
  • separation of training, validation and test data where appropriate;
  • controls against data leakage;
  • explainability suitable for the decision context;
  • human review for high-impact decisions;
  • monitoring for drift, degradation and unexpected outcomes;
  • security testing against prompt injection, poisoning and extraction where AI systems are used; and
  • processes for appeal, correction and withdrawal.

A model can be statistically accurate and still be unlawful or unethical. Accuracy does not establish fairness, necessity, transparency or legitimate purpose. Governance should evaluate both model performance and the consequences of its use.

10. Applied case: Northbridge Retail Group

The following is an illustrative case.

Background

Northbridge Retail Group operates stores, an e-commerce platform and a loyalty programme. Its marketing team wants a predictive model to identify customers likely to stop purchasing. Data is distributed across point-of-sale, web, customer-service and email systems. Different systems use different customer identifiers, and some records contain outdated contact preferences.

Problem

A preliminary analysis found duplicate customers, inconsistent definitions of “active customer” and unrestricted access to raw loyalty data. The proposed model included detailed purchase history, location, complaint text and inferred household characteristics. The organisation had no documented retention period for historical clickstream data.

Analysis

The project created risks involving inaccurate targeting, excessive collection, unauthorised access, discriminatory outcomes and incompatible reuse of data. The analysts could not demonstrate which source supplied each field or whether marketing preferences applied to all proposed communications. A model built immediately would have produced a technically convenient but poorly governed result.

Approach and solution

The governance council appointed the customer-data director as owner and a marketing-operations manager as steward. The team created a catalogue entry for each source, defined “active customer” for the project, established a survivorship rule for duplicate profiles and recorded lineage into the analytical dataset.

The privacy lead completed an impact assessment. The team removed unnecessary household inferences, limited location to an appropriate geographic level, reviewed the lawful basis and updated notices. Raw complaint text was excluded from the first model because it was not necessary for the stated purpose. Access was provided through a controlled analytical view rather than unrestricted raw tables. Sensitive fields were masked, and model outputs were restricted to authorised campaign users.

Quality checks measured duplicate rates, missing contact preferences, identifier matches and data freshness. The retention schedule specified when campaign features and predictions would be deleted or refreshed. A human review process was introduced for unusual or potentially harmful recommendations.

Outcome

The project took longer initially but produced an auditable dataset, clearer accountability and more defensible model use. Marketing gained a useful prioritisation tool without exposing unnecessary raw information. The organisation also identified improvements applicable to customer service and finance data.

Learning points

The case demonstrates that governance is not an obstacle placed after innovation. Early definitions, ownership, minimisation, lineage and access design reduce rework and improve confidence. It also shows that a catalogue, privacy assessment or model metric is valuable only when connected to decisions and controls.

11. Measuring governance effectiveness

Governance should be evaluated through evidence rather than policy publication alone. Useful indicators include:

  • percentage of critical datasets with named owners and stewards;
  • catalogue coverage and metadata completeness;
  • critical-data quality results and issue resolution times;
  • percentage of privileged accounts reviewed on schedule;
  • number and severity of security incidents;
  • time to detect, contain and recover from incidents;
  • completion of privacy assessments for high-risk projects;
  • percentage of datasets with documented retention rules;
  • number of unresolved rights requests; and
  • audit findings and repeat control failures.

Metrics require interpretation. A falling incident count could indicate improvement, but it could also indicate weak detection. A high catalogue-completion rate may conceal inaccurate entries. Mature governance combines quantitative indicators with assurance testing, stakeholder feedback and evidence that decisions improved.

12. Challenges and limitations

Governance programmes commonly face several tensions:

  • Central control versus local agility: excessive approval can delay useful work, while decentralisation can create inconsistency.
  • Access versus protection: analysts need data to create value, but broad access increases exposure.
  • Quality versus cost: perfect quality is unrealistic; investment should reflect business and human consequences.
  • Retention versus deletion: legal, analytical and privacy interests may conflict.
  • Transparency versus security: detailed public explanation can sometimes reveal attackable system information.
  • Automation versus accountability: automated decisions can scale unfairness and make responsibility unclear.
  • Global operations versus local law: transfers, definitions and individual rights vary across jurisdictions.

Effective governance uses proportionality and risk-based prioritisation. It does not seek to eliminate every risk, which is impossible, but to identify, reduce, monitor and accept residual risk through authorised decisions.

13. Best-practice implementation roadmap

An organisation beginning a governance programme can proceed in stages:

  1. Obtain executive sponsorship and define business outcomes.
  2. Inventory critical data domains, systems, flows and third parties.
  3. Assign owners and stewards and approve a governance charter.
  4. Classify data according to sensitivity, criticality and regulatory exposure.
  5. Establish priority definitions, standards and quality rules.
  6. Implement catalogue, lineage and access-request capabilities.
  7. Apply least privilege, authentication, encryption, logging and backup controls.
  8. Create privacy assessment, retention, breach and rights-request processes.
  9. Embed controls in procurement, system development and analytics delivery.
  10. Measure performance, audit controls and improve continuously.

The programme should begin with high-value or high-risk domains rather than attempting to govern every field simultaneously. Governance is a capability that matures through repeated decisions, evidence and learning.

Chapter Summary

Data governance establishes organisational accountability, decision rights, standards and controls for data throughout its life cycle. Owners make business decisions, stewards operationalise standards, and custodians manage technical environments. Data catalogues, metadata, lineage, master-data controls and quality measures make data discoverable and trustworthy.

Security protects confidentiality, integrity and availability through identity management, least privilege, defence in depth, monitoring and incident response. Privacy focuses on fair, lawful and proportionate processing of information about people. Major data-protection principles include purpose limitation, minimisation, accuracy, storage limitation, security and accountability. Privacy-by-design embeds these concerns in architecture and default settings.

Governance must cover analytics and AI, including provenance, bias, access, explainability, monitoring and human accountability. Effective programmes use risk-based priorities, measurable controls, impact assessments, retention schedules and continuous assurance. The strategic objective is not simply compliance; it is trustworthy data use that creates value while respecting people and organisational responsibilities.

Key Terms

Data governance: The system of authority, accountability, policies, standards and processes governing data.

Data owner: The business role accountable for decisions about a data domain.

Data steward: The role that applies data standards and resolves operational data issues.

Data custodian: The technical role responsible for storing, operating and protecting data platforms.

Metadata: Data describing the meaning, structure, origin, use or status of other data.

Data catalogue: An organised inventory of datasets and associated metadata.

Data lineage: The record of data origins, transformations and downstream uses.

Master data: Core entities such as customers, products, suppliers or locations.

Reference data: Controlled values used to classify or describe data.

Data quality: Fitness of data for a defined purpose.

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

Confidentiality: Protection against unauthorised disclosure.

Integrity: Protection against unauthorised or improper alteration.

Availability: Accessibility of systems and data to authorised users when needed.

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

Pseudonymisation: Replacing identifiers while retaining a possible means of re-identification.

Anonymisation: Processing intended to make re-identification reasonably infeasible.

Privacy-by-design: Integrating privacy protections into system and process design from the outset.

Legal hold: Suspension of normal deletion because of anticipated or ongoing legal or regulatory action.

Data-protection impact assessment: A structured assessment of privacy risks and mitigations for processing activities.

Review Questions

Short Answer Questions

  1. Distinguish the responsibilities of a data owner, data steward and data custodian.
  2. What are the three elements of the CIA triad?
  3. Explain why a data catalogue is more than a list of database tables.
  4. Define purpose limitation and data minimisation.
  5. Why is pseudonymised data generally still treated as personal data when re-identification remains possible?

Long Answer Questions

  1. Design a governance operating model for a medium-sized organisation with customer, finance and employee data domains.
  2. Explain how metadata, lineage, master-data management and data-quality controls contribute to trustworthy analytics.
  3. Compare role-based access control and attribute-based access control, including situations in which each may be appropriate.
  4. Discuss how privacy-by-design can be integrated into the analytics and AI life cycle.
  5. Evaluate the tensions between retention, deletion, business value, legal obligations and privacy risk.

Analytical / Application Questions

  1. An organisation gives all analysts unrestricted access to raw customer data because access approvals are considered slow. Analyse the risks and propose a proportionate alternative control design.
  2. A churn model uses purchase history, location, complaint text and inferred household characteristics. Identify governance and privacy questions that should be answered before deployment, and recommend which data should be included in an initial version.
  3. A data-quality dashboard reports 98% completeness, but managers continue to receive incorrect reports. Explain why the completeness figure is insufficient and design additional quality tests and governance actions.

Multiple Choice Questions with Answers

Question 1

Which role is primarily accountable for business decisions about a data domain?

A. Data owner

B. Data custodian

C. Data consumer

D. Network administrator

Correct Answer: A. Data owner

Question 2

Which statement best describes data lineage?

A. A list of authorised users

B. A record of data origins, transformations and downstream uses

C. A schedule for deleting old records

D. A password-management procedure

Correct Answer: B. A record of data origins, transformations and downstream uses

Question 3

If 9,600 of 10,000 required values are present, what is the completeness rate?

A. 9.6%

B. 90%

C. 96%

D. 99.6%

Correct Answer: C. 96%

Question 4

Which control best represents the principle of least privilege?

A. Giving all employees read access to all databases

B. Granting only the permissions necessary for an approved task

C. Allowing permanent administrator access to contractors

D. Removing all access controls from analytical environments

Correct Answer: B. Granting only the permissions necessary for an approved task

Question 5

Which item is not part of the CIA triad?

A. Confidentiality

B. Integrity

C. Availability

D. Profitability

Correct Answer: D. Profitability

Question 6

What is the main purpose of purpose limitation?

A. To require all data to be stored indefinitely

B. To prevent data from being reused for incompatible purposes without justification

C. To ensure every dataset is publicly available

D. To eliminate the need for access controls

Correct Answer: B. To prevent data from being reused for incompatible purposes without justification

Question 7

Why does pseudonymisation usually not remove data-protection obligations?

A. Pseudonymised data cannot be stored electronically

B. The original identity may be restored using additional information

C. Pseudonymisation makes data more accurate

D. Pseudonymised data is always publicly disclosed

Correct Answer: B. The original identity may be restored using additional information

Question 8

Which activity is most consistent with privacy-by-design?

A. Collecting every available field before defining a purpose

B. Adding a privacy notice after system deployment only

C. Testing whether the objective can be achieved with less sensitive data

D. Allowing unrestricted access during development

Correct Answer: C. Testing whether the objective can be achieved with less sensitive data

Question 9

What is the function of a legal hold?

A. To accelerate routine deletion

B. To suspend normal deletion during anticipated or ongoing legal action

C. To replace encryption with authentication

D. To make all records publicly accessible

Correct Answer: B. To suspend normal deletion during anticipated or ongoing legal action

Question 10

Which statement about data quality is correct?

A. Completeness alone proves that data is accurate

B. Data quality is fitness for a defined use and includes dimensions such as accuracy and timeliness

C. Data quality is determined only by storage volume

D. Data quality is unrelated to governance

Correct Answer: B. Data quality is fitness for a defined use and includes dimensions such as accuracy and timeliness

Big Data & Data-Driven Strategy
Chapter 11 of 15